应用正确的开发模型
　　网络游戏开发应该是有周期性的，短迭代周期的增量式开发是比较好的开发模型。瀑布模型肯定是行不通的，如果还有公司在用瀑布模型开发网络游戏，唉，只能默默的祝愿他们一路走好了。长周期的迭代（半年一个周期）也是行不通的，这倒不是这种方法本身有什么问题，而是太长的迭代对于这个快速变化的花花世界来说，太痛苦了。
　　但是在我们访谈记录中，却发现很多游戏公司居然没有任何开发模型，完全是一种混沌的开发方法，买来一个现成的游戏引擎，想到什么开发什么，感觉做的差不多了打个包上线，没采用任何开发模型，没有什么明确的开发周期，一切都是凭着感觉来。这是一个很危险的事情，很多这样的公司，在游戏上线以后，会发现这个游戏制作工作彻底陷入了一团糟的境地，任何局域性方法都无法提供有效的帮助，终公司进入一个死循环，解决的办法也变得很残忍：要么死掉，要么彻底改革。
　　任何的针对具体软件开发管理问题的解决办法，都是要在软件开发模型的大框架下才能起效果的。我们不可能把瀑布模型中制定计划的方法用在敏捷开发模型下，我们也不能把打牌估算的方式用在瀑布模型中，因为这些具体方法都是在具体的开发模型的框架下，才具备了生存的条件。像生态系统一样，热带雨林里的鳄鱼，放到沙漠里面，肯定活不下去的。所以如果一个游戏公司连基本的开发模型都没有引入的话，那么不要考虑变更怎么管理了；像在真空中任何生物都无法生存一样，在没有开发模型的环境中，任何开发管理方法也都无法取得效果。
　　所以，上文提到的这种这种需求（策划）变更管理方法，是要在敏捷开发的大环境下，才能够起作用的，在瀑布、长周期的迭代式开发模型中，都不会有啥正面作用。
　　迭代周期的选择
　　一般的共识是这样的：相对较长的Sprint迭代周期，能够有效的提高开发效率。因为一个Sprint周期中，有些工作是不能被省略的，如Backlog的整理、估算、计划会、评审会与反思会、代码集成、测试、打包等，这些活动一般都要占用不少的时间，越长的Sprint周期，这些活动所占用的时间比例会越少，为开发人员留下的整块开发时间越多，工作效率也越高。
　　而Sprint周期越短，对于需求变化的响应速度越快。人们对于未来变化的把握能力其实很弱，越短的时间，把握越强，考虑的也越详细，太长时间以后的事情（如2个月以后），则基本没有什么把握能力了。
　　Sprint周期的选择，是开发效率与响应速度之间的一个平衡。
　　一般在开发期的游戏，会选择相对较长的Sprint周期，如1-2个月左右，这时候策划相对比较明确，还没有引入玩家与运营反馈，需求变更相对较少，选择相对较长的开发周期能够保证开发期的游戏开发效率，争取尽早达到上线标准。这时候也希望策划团队能够尽可能减少不确定的变更，如果一个功能或玩法没法确认真的比改变前更好，那么不要贸然提出改动，等到上线之后听到玩家的反馈后再提出，能节省不少工作量。
　　而从游戏上线封测开始，Sprint周期开始逐步缩短，以适应逐渐增多的Bug、调整与变更，在游戏正式运营后，一般都会将Sprint周期控制在1-3周左右，一般都是与游戏的更新周期保持同步。从管理的角度来说，为了适应更短的Sprint周期，很多管理上的规章与流程也要随之相应的简化，以适应高相应速度的要求。
　　产生间接影响的变更如何应对
　　有一些变更虽然不会对当前的开发工作产生任何影响，但是却会在将来对开发工作产生一定的影响，如一个变更会导致我们对当前的游戏构架进行调整，那么这个变更将会在未来产生相当大的工作量。那么我们是否在当前的工作中考虑这些存在着潜在影响的变更呢？