么这个变更将会在未来产生相当大的工作量。那么我们是否在当前的工作中考虑这些存在着潜在影响的变更呢？
6、迭代周期的选择
一般的共识是这样的：相对较长的Sprint迭代周期，能够有效的提高开发效率。因为一个Sprint周期中，有些工作是不能被省略的，如Backlog的整理、估算、计划会、评审会与反思会、代码集成、测试、打包等，这些活动一般都要占用不少的时间，越长的Sprint周期，这些活动所占用的时间比例会越少，为开发人员留下的整块开发时间就越多，工作效率也越高。
而Sprint周期越短，对于需求变化的响应速度就越快。人们对于未来变化的把握能力其实很弱，越短的时间，把握越强，考虑的也越详细，太长时间以后的事情（如2个月以后），则基本没有什么把握能力了。
Sprint周期的选择，就是开发效率与响应速度之间的一个平衡。 一般在开发期的游戏，会选择相对较长的Sprint周期，如1-2个月左右，这时候策划相对比较明确，还没有引入玩家与运营反馈，需求变更相对较少，选择相对较长的开发周期能够保证开发期的游戏开发效率，争取尽早达到上线标准。这时候也希望策划团队能够尽可能减少不确定的变更，如果一个功能或玩法没法确认真的比改变前更好，那么就不要贸然提出改动，等到上线之后听到玩家的反馈后再提出，能节省不少工作量。
从管理的角度来说，为了适应更短的Sprint周期，很多项目管理上的规章与流程也要随之相应的简化，以适应高相应速度的要求。而从游戏上线封测开始，Sprint周期就开始逐步缩短，以适应逐渐增多的Bug、调整与变更，在游戏正式运营后，一般都会将Sprint周期控制在1-3周左右，一般都是与游戏的更新周期保持同步。
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
