么這個(gè)變更將會(huì)在未來產(chǎn)生相當(dāng)大的工作量。那么我們是否在當(dāng)前的工作中考慮這些存在著潛在影響的變更呢？
6、迭代周期的選擇
一般的共識(shí)是這樣的：相對(duì)較長的Sprint迭代周期，能夠有效的提高開發(fā)效率。因?yàn)橐粋€(gè)Sprint周期中，有些工作是不能被省略的，如Backlog的整理、估算、計(jì)劃會(huì)、評(píng)審會(huì)與反思會(huì)、代碼集成、測試、打包等，這些活動(dòng)一般都要占用不少的時(shí)間，越長的Sprint周期，這些活動(dòng)所占用的時(shí)間比例會(huì)越少，為開發(fā)人員留下的整塊開發(fā)時(shí)間就越多，工作效率也越高。
而Sprint周期越短，對(duì)于需求變化的響應(yīng)速度就越快。人們對(duì)于未來變化的把握能力其實(shí)很弱，越短的時(shí)間，把握越強(qiáng)，考慮的也越詳細(xì)，太長時(shí)間以后的事情（如2個(gè)月以后），則基本沒有什么把握能力了。
Sprint周期的選擇，就是開發(fā)效率與響應(yīng)速度之間的一個(gè)平衡。 一般在開發(fā)期的游戲，會(huì)選擇相對(duì)較長的Sprint周期，如1-2個(gè)月左右，這時(shí)候策劃相對(duì)比較明確，還沒有引入玩家與運(yùn)營反饋，需求變更相對(duì)較少，選擇相對(duì)較長的開發(fā)周期能夠保證開發(fā)期的游戲開發(fā)效率，爭取盡早達(dá)到上線標(biāo)準(zhǔn)。這時(shí)候也希望策劃團(tuán)隊(duì)能夠盡可能減少不確定的變更，如果一個(gè)功能或玩法沒法確認(rèn)真的比改變前更好，那么就不要貿(mào)然提出改動(dòng)，等到上線之后聽到玩家的反饋后再提出，能節(jié)省不少工作量。
從管理的角度來說，為了適應(yīng)更短的Sprint周期，很多項(xiàng)目管理上的規(guī)章與流程也要隨之相應(yīng)的簡化，以適應(yīng)高相應(yīng)速度的要求。而從游戲上線封測開始，Sprint周期就開始逐步縮短，以適應(yīng)逐漸增多的Bug、調(diào)整與變更，在游戲正式運(yùn)營后，一般都會(huì)將Sprint周期控制在1-3周左右，一般都是與游戲的更新周期保持同步。
項(xiàng)目經(jīng)理勝任力免費(fèi)測評(píng)PMQ上線啦！快來測測你排多少名吧~
http://www.vanceur.cn/pmqhd/index.html
