变更自从软件开发半个世纪以来，一直不离不弃，像打不死的小强。到了现如今的网络时代，不但没有被压制住，反倒更加猖獗了。对于软件开发领域来讲，变更始终是最让人头疼的东西，大家对于如何消除变更，如何控制变更，提出了很多很多的理论与方法。那么在游戏圈里面，大家是如何面对变更的呢？
整体而言，游戏行业（尤其是网络游戏行业）对于变更是又爱又恨的，很纠结，很痛苦。因此在网络游戏行业中，变更管理也不是简单的放任或者控制，而是要权衡各方面的因素，让变与不变维持在一个平衡点上。一句话概括其管理方式就是：胡萝卜+大棒政策。
游戏公司中对于变更的两种意见：
主变派：策划、制作人；观点：变化乃游戏生存之本
变化是网络游戏生存之根本，大家评判一个网络游戏发展势头的最重要的标准有两个：在线人数与更新频率。一个更新频率趋于变缓的游戏，基本上可以说是快进入消亡期了。追逐玩家们不断变化的口味，引领游戏圈的新潮流，创造更高的吸金效率，这些都是以不断的变化为基础的。
因此，游戏必须变。不让游戏发生变化，就等于是要了游戏的命。就算是限制变更，也相当于扼住了游戏赖以生存的咽喉。
不变派：开发团队，项目经理；观点：变化是浪费，是隐患
说到底，游戏还是个软件，单机游戏也好，网络游戏也好，无非都是运行在计算机上的软件。变更对于软件开发而言，灾难性的，这一点所有软件开发人员都深有体会，变更会导致大量的重复工作，严重影响开发进度；会对已完成的所有工作产生冲击与影响，带来更多的不可预期的Bug；没有被良好重新设计的变更，甚至会直接威胁到软件构架的稳定性，为将来埋下极大的隐患，等等。这些软件本身的问题，同样也适用于游戏开发。
更要命的是，频繁的变更会让开发团队感到强烈的挫败感，自己辛辛苦苦做好的东西，没过几天就被彻底改掉了，感觉自己就像是做了很多没有用的东西一样，长此以往，开发团队将会士气受挫，导致开发效率低下。
看来矛盾是不可避免了。那么到底听谁的呢？听策划的，还是听开发的？按照大自然物竞天择的自然规律来判断的话：谁强，听谁的。
谁更强？策划，还是程序？如果我在这里挖个坑，盖个楼的话，邀请大家来评价一下的话，我相信会相当的火爆。
事实证明，策划与程序，都很重要。
变更的分类，哪些可以变？哪些不能变？如果我们根据变更是否会对开发工作产生影响来对游戏需求变更进行分类，我们可以整体上分为两种变更：
1.对当前的游戏开发工作产生直接影响；
2.不会对当前的游戏开发工作产生直接影响。
当前的工作，是指正在开发、测试、美术人员手上处理，或者进入到当前迭代周期内待处理的工作。发生直接影响，则是指会打断当前正在进行的开发工作，比如一个游戏需求：玩家自定义聊天频道功能，现在这个需求已经到了程序手中，开始编写代码了，这时候如过策划人员发起变更，就会对当前工作产生直接的影响。而如是另一种情况：这个需求目前还在策划阶段，还没有送到程序员与美术人员的手中，这时候策划人员发起需求变更，不会对当前的开发任务产生直接影响，因为现在还根本没有人在开发这个功能。
如果我们仔细分析一下程序人员反对变更的理由的话，我们会发现，其实程序人员仅仅是反对会产生直接影响的变更，而对于那些不会产生直接影响的变更，则不是很反对。那些不产生直接影响的变更，虽然也会对现有的工作产生一些间接的影响，但是影响不会很大，这个问题我们会在后面来讨论。
胡萝卜+大棒
基于上面提到的变更的分类方法，我们可以得到这样一个变更管理的方法：
当一个需求（或者策划案）还处在策划阶段，还没有被送去开发与实现的时候，我们允许这个需求发生改变，甚至允许它发生任何的改变，没有任何限制。而一旦这个需求被送去开发与实现了，那么我们将不再允许这个需求发生任何改变，需求与设计将会被锁定，开发人员将会按照锁定的版本进行开发。
如果在开发过程中，策划人员实在忍不住要提出变更，那么他仅有两个选择：
1，要求项目经理彻底终断掉该需求当前的开发工作，将该需求从当前的开发列表中取消，待其将需求变更修改好后，再重新纳入到下一轮开发计划中；
2，等待已经送交开发的需求开发完成，在已经完成的基础上提出修改（作为一个新需求）并纳入到下一轮的开发计划中。
当一个需求被完成后，如果策划人员需要对已经完成的内容进行变更，那么他需要提出一个新需求，就叫做“对自定义聊天频道修改”，将这个需求纳入到需求库中，并要求项目经理纳入到接下来的开发周期中，作为一个新的开发任务来处理。
那么以上的假设是否可行呢？有没有人真的这么实践过呢？答案是肯定的，敏捷开发方法论（不论是Scrum与XP）都是在以这种方法在管理需求变更，实践的结果也是相当不错的；另外，据我接触的游戏公司中，也有一些公司在采用类似的方法来管理变更（金山的一些项目组就是这么做的，效果很好）。如果想更多的了解敏捷式变更管理，可以参考KenSchwaber伯伯的书：《Scrum敏捷项目管理》（AgileProjectManagementWithScrum）
以上的做法，基本上满足了策划与程序的不同需求：策划需要变更，开发不需要变更。开发人员应该对这个方法很满意，既然变化是势不可挡的，但是只要不会直接影响当前工作，也是完全可以接受的；但是策划人员心里还是有一丝不爽：在漫长的开发周期内不能变更，是否太不人道了？
应用正确的开发模型网络游戏开发应该是有周期性的，短迭代周期的增量式开发是比较好的开发模型。瀑布模型肯定是行不通的，如果还有公司在用瀑布模型开发网络游戏，唉，只能默默的祝愿他们一路走好了。长周期的迭代（半年一个周期）也是行不通的，这倒不是这种方法本身有什么问题，而是太长的迭代对于这个快速变化的花花世界来说，太痛苦了。
但是在我们访谈记录中，却发现很多游戏公司居然没有任何开发模型，完全是一种混沌的开发方法，买来一个现成的游戏引擎，想到什么就开发什么，感觉做的差不多了就打个包上线，没采用任何开发模型，没有什么明确的开发周期，一切都是凭着感觉来。这是一个很危险的事情，很多这样的公司，在游戏上线以后，会发现这个游戏制作工作彻底陷入了一团糟的境地，任何局域性方法都无法提供有效的帮助，最终公司进入一个死循环，解决的办法也变得很残忍：要么死掉，要么彻底改革。
任何的针对具体软件开发管理问题的解决办法，都是要在软件开发模型的大框架下才能起效果的。我们不可能把瀑布模型中制定计划的方法用在敏捷开发模型下，我们也不能把打牌估算的方式用在瀑布模型中，因为这些具体方法都是在具体的开发模型的框架下，才具备了生存的条件。就像生态系统一样，热带雨林里的鳄鱼，放到沙漠里面，肯定活不下去的。所以如果一个游戏公司连基本的开发模型都没有引入的话，那么就不要考虑变更怎么管理了；就像在真空中任何生物都无法生存一样，在没有开发模型的环境中，任何开发管理方法也都无法取得效果。
所以，上文提到的这种这种需求（策划）变更管理方法，是要在敏捷开发的大环境下，才能够起作用的，在瀑布、长周期的迭代式开发模型中，都不会有啥正面作用。
迭代周期的选择一般的共识是这样的：相对较长的Sprint迭代周期，能够有效的提高开发效率。因为一个Sprint周期中，有些工作是不能被省略的，如Backlog的整理、估算、计划会、评审会与反思会、代码集成、测试、打包等，这些活动一般都要占用不少的时间，越长的Sprint周期，这些活动所占用的时间比例会越少，为开发人员留下的整块开发时间就越多，工作效率也越高。
而Sprint周期越短，对于需求变化的响应速度就越快。人们对于未来变化的把握能力其实很弱，越短的时间，把握越强，考虑的也越详细，太长时间以后的事情（如2个月以后），则基本没有什么把握能力了。
Sprint周期的选择，就是开发效率与响应速度之间的一个平衡。
一般在开发期的游戏，会选择相对较长的Sprint周期，如1-2个月左右，这时候策划相对比较明确，还没有引入玩家与运营反馈，需求变更相对较少，选择相对较长的开发周期能够保证开发期的游戏开发效率，争取尽早达到上线标准。这时候也希望策划团队能够尽可能减少不确定的变更，如果一个功能或玩法没法确认真的比改变前更好，那么就不要贸然提出改动，等到上线之后听到玩家的反馈后再提出，能节省不少工作量。
而从游戏上线封测开始，Sprint周期就开始逐步缩短，以适应逐渐增多的Bug、调整与变更，在游戏正式运营后，一般都会将Sprint周期控制在1-3周左右，一般都是与游戏的更新周期保持同步。从管理的角度来说，为了适应更短的Sprint周期，很多管理上的规章与流程也要随之相应的简化，以适应高相应速度的要求。
产生间接影响的变更如何应对有一些变更虽然不会对当前的开发工作产生任何影响，但是却会在将来对开发工作产生一定的影响，如一个变更会导致我们对当前的游戏构架进行调整，那么这个变更将会在未来产生相当大的工作量。那么我们是否在当前的工作中考虑这些存在着潜在影响的变更呢？
