|
当一个需求被完成后，如果策划人员需要对已经完成的内容进行变更，那么他需要提出一个新需求，就叫做“对自定义聊天频道修改”，将这个需求纳入到需求库中，并要求项目经理纳入到接下来的开发周期中，作为一个新的开发任务来处理。项目管理者联盟
那么以上的假设是否可行呢?有没有人真的这么实践过呢?答案是肯定的，敏捷开发方法论(不论是Scrum与XP)都是在以这种方法在管理需求变更，实践的结果也是相当不错的;另外，据我接触的游戏公司中，也有一些公司在采用类似的方法来管理变更(金山的一些项目组就是这么做的，效果很好)。如果想更多的了解敏捷式变更管理，可以参考Ken Schwaber伯伯的书：《Scrum敏捷项目管理》(Agile Project Management With Scrum)项目管理者联盟
以上的做法，基本上满足了策划与程序的不同需求：策划需要变更，开发不需要变更。开发人员应该对这个方法很满意，既然变化是势不可挡的，但是只要不会直接影响当前工作，也是完全可以接受的;但是策划人员心里还是有一丝不爽：在漫长的开发周期内不能变更，是否太不人道了?pmp.mypm.net
应用正确的开发模型项目管理者联盟
网络游戏开发应该是有周期性的，短迭代周期的增量式开发是比较好的开发模型。瀑布模型肯定是行不通的，如果还有公司在用瀑布模型开发网络游戏，唉，只能默默的祝愿他们一路走好了。长周期的迭代(半年一个周期)也是行不通的，这倒不是这种方法本身有什么问题，而是太长的迭代对于这个快速变化的花花世界来说，太痛苦了。项目管理者联盟
但是在我们访谈记录中，却发现很多游戏公司居然没有任何开发模型，完全是一种混沌的开发方法，买来一个现成的游戏引擎，想到什么就开发什么，感觉做的差不多了就打个包上线，没采用任何开发模型，没有什么明确的开发周期，一切都是凭着感觉来。这是一个很危险的事情，很多这样的公司，在游戏上线以后，会发现这个游戏制作工作彻底陷入了一团糟的境地，任何局域性方法都无法提供有效的帮助，最终公司进入一个死循环，决的办法也变得很残忍：要么死掉，要么彻底改革。PgMp.mypm.net
任何的针对具体软件开发管理问题的解决办法，都是要在软件开发模型的大框架下才能起效果的。我们不可能把瀑布模型中制定计划的方法用在敏捷开发模型下，我们也不能把打牌估算的方式用在瀑布模型中，因为这些具体方法都是在具体的开发模型的框架下，才具备了生存的条件。就像生态系统一样，热带雨林里的鳄鱼，放到沙漠里面，肯定活不下去的。所以如果一个游戏公司连基本的开发模型都没有引入的话，那么就不要考虑变更怎么管理了;就像在真空中任何生物都无法生存一样，在没有开发模型的环境中，任何开发管理方法也都无法取得效果。项目管理者联盟
所以，上文提到的这种这种需求(策划)变更管理方法，是要在敏捷开发的大环境下，才能够起作用的，在瀑布、长周期的迭代式开发模型中，都不会有啥正面作用。项目管理者联盟
迭代周期的选择talent.mypm.net
一般的共识是这样的：相对较长的Sprint迭代周期，能够有效的提高开发效率。因为一个Sprint周期中，有些工作是不能被省略的，如Backlog的整理、估算、计划会、评审会与反思会、代码集成、测试、打包等，这些活动一般都要占用不少的时间，越长的Sprint周期，这些活动所占用的时间比例会越少，为开发人员留下的整块开发时间就越多，工作效率也越高。项目管理者联盟
而Sprint周期越短，对于需求变化的响应速度就越快。人们对于未来变化的把握能力其实很弱，越短的时间，把握越强，考虑的也越详细，太长时间以后的事情(如2个月以后)，则基本没有什么把握能力了。training.mypm.net
Sprint周期的选择，就是开发效率与响应速度之间的一个平衡。项目管理者联盟
一般在开发期的游戏，会选择相对较长的Sprint周期，如1-2个月左右，这时候策划相对比较明确，还没有引入玩家与运营反馈，需求变更相对较少，选择相对较长的开发周期能够保证开发期的游戏开发效率，争取尽早达到上线标准。这时候也希望策划团队能够尽可能减少不确定的变更，如果一个功能或玩法没法确认真的比改变前更好，那么就不要贸然提出改动，等到上线之后听到玩家的反馈后再提出，能节省不少工作量。talent.mypm.net
而从游戏上线封测开始，Sprint周期就开始逐步缩短，以适应逐渐增多的Bug、调整与变更，在游戏正式运营后，一般都会将Sprint周期控制在1-3周左右，一般都是与游戏的更新周期保持同步。从管理的角度来说，为了适应更短的Sprint周期，很多管理上的规章与流程也要随之相应的简化，以适应高相应速度的要求。项目管理者联盟 项目管理论坛
|
