对于软件开发领域来讲，变更始终是最让人头疼的东西，大家对于如何消除变更，如何控制变更，提出了很多很多的理论与方法。无奈变更这东西就像是个打不死的小强，倔强的与软件开发一起生存了半个多世纪，到了现如今的网络时代，不但没有被压制住，反倒更加猖獗了。那么在小强最繁荣的游戏圈里面，大家是如何面对变更的呢？
整体而言，游戏行业（尤其是网络游戏行业）对于变更是又爱又恨的，很纠结，很痛苦。因此在网络游戏行业中，变更管理也不是简单的放任或者控制，而是要权衡各方面的因素，让变与不变维持在一个平衡点上。一句话概括其管理方式就是：胡萝卜+大棒政策。
游戏公司中对于变更的两种意见
主变派：策划、制作人；观点：变化乃游戏生存之本
变化是网络游戏生存之根本，大家评判一个网络游戏发展势头的最重要的标准有两个：在线人数与更新频率。一个更新频率趋于变缓的游戏，基本上可以说是快进入消亡期了。追逐玩家们不断变化的口味，引领游戏圈的新潮流，创造更高的吸金效率，这些都是以不断的变化为基础的。
因此，游戏必须变。不让游戏发生变化，就等于是要了游戏的命。就算是限制变更，也相当于扼住了游戏赖以生存的咽喉。
不变派：开发团队，项目经理；观点：变化是浪费，是隐患
说到底，游戏还是个软件，单机游戏也好，网络游戏也好，无非都是运行在计算机上的软件。变更对于软件开发而言，灾难性的，这一点所有软件开发人员都深有体会，变更会导致大量的重复工作，严重影响开发进度；会对已完成的所有工作产生冲击与影响，带来更多的不可预期的Bug；没有被良好重新设计的变更，甚至会直接威胁到软件构架的稳定性，为将来埋下极大的隐患，等等。这些软件本身的问题，同样也适用于游戏开发。
更要命的是，频繁的变更会让开发团队感到强烈的挫败感，自己辛辛苦苦做好的东西，没过几天就被彻底改掉了，感觉自己就像是做了很多没有用的东西一样，长此以往，开发团队将会士气受挫，导致开发效率低下。
看来矛盾是不可避免了。那么到底听谁的呢？听策划的，还是听开发的？按照大自然物竞天择的自然规律来判断的话：谁强，听谁的。
谁更强？策划，还是程序？如果我在这里挖个坑，盖个楼的话，邀请大家来评价一下的话，我相信会相当的火爆。
事实证明，策划与程序，都很重要。
变更的分类，哪些可以变？哪些不能变？
如果我们根据变更是否会对开发工作产生影响来对游戏需求变更进行分类，我们可以整体上分为两种变更：1.对当前的游戏开发工作产生直接影响；2.不会对当前的游戏开发工作产生直接影响。
当前的工作，是指正在开发、测试、美术人员手上处理，或者进入到当前迭代周期内待处理的工作。发生直接影响，则是指会打断当前正在进行的开发工作，比如一个游戏需求：玩家自定义聊天频道功能，现在这个需求已经到了程序手中，开始编写代码了，这时候如过策划人员发起变更，就会对当前工作产生直接的影响。而如是另一种情况：这个需求目前还在策划阶段，还没有送到程序员与美术人员的手中，这时候策划人员发起需求变更，不会对当前的开发任务产生直接影响，因为现在还根本没有人在开发这个功能。
如果我们仔细分析一下程序人员反对变更的理由的话，我们会发现，其实程序人员仅仅是反对会产生直接影响的变更，而对于那些不会产生直接影响的变更，则不是很反对。那些不产生直接影响的变更，虽然也会对现有的工作产生一些间接的影响，但是影响不会很大，这个问题我们会在后面来讨论。
胡萝卜+大棒
基于上面提到的变更的分类方法，我们可以得到这样一个变更管理的方法：
当一个需求（或者策划案）还处在策划阶段，还没有被送去开发与实现的时候，我们允许这个需求发生改变，甚至允许它发生任何的改变，没有任何限制。而一旦这个需求被送去开发与实现了，那么我们将不再允许这个需求发生任何改变，需求与设计将会被锁定，开发人员将会按照锁定的版本进行开发。
如果在开发过程中，策划人员实在忍不住要提出变更，那么他仅有两个选择：
1，要求项目经理彻底终断掉该需求当前的开发工作，将该需求从当前的开发列表中取消，待其将需求变更修改好后，再重新纳入到下一轮开发计划中；
2，等待已经送交开发的需求开发完成，在已经完成的基础上提出修改（作为一个新需求）并纳入到下一轮的开发计划中。
当一个需求被完成后，如果策划人员需要对已经完成的内容进行变更，那么他需要提出一个新需求，就叫做“对自定义聊天频道修改”，将这个需求纳入到需求库中，并要求项目经理纳入到接下来的开发周期中，作为一个新的开发任务来处理。
那么以上的假设是否可行呢？有没有人真的这么实践过呢？答案是肯定的，敏捷开发方法论（不论是Scrum与XP）都是在以这种方法在管理需求变更，实践的结果也是相当不错的；另外，据我接触的游戏公司中，也有一些公司在采用类似的方法来管理变更（金山的一些项目组就是这么做的，效果很好）。如果想更多的了解敏捷式变更管理，可以参考Ken Schwaber伯伯的书：《Scrum敏捷项目管理》（Agile Project Management With Scrum）
以上的做法，基本上满足了策划与程序的不同需求：策划需要变更，开发不需要变更。开发人员应该对这个方法很满意，既然变化是势不可挡的，但是只要不会直接影响当前工作，也是完全可以接受的；但是策划人员心里还是有一丝不爽：在漫长的开发周期内不能变更，是否太不人道了？
