《scrum在游戏开发项目管理中的应用》由会员分享，可在线阅读，更多相关《scrum在游戏开发项目管理中的应用（3页珍藏版）》请在金锄头文库上搜索。
1、关于 scrum 在游戏开发项目管理中的应用李政 12040742摘要：Scrum 是一种迭代式增量软件开发过程，通常用于敏捷软件开发。包括了一系列实践和预定义角色的过程骨架。Scrum 中的主要角色包括同项目经理类似的 Scrum 主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。游戏开发也是一种软件开发项目，在其开发过程中能够运用运用 scrum 工作方法是没有任何疑问的，但是游戏毕竟不同于一般的软件开发，其中有其特有的要求，所以在本篇文章中所要论述的是 scrum 在游戏开发中如何较好兼容的问题，通过 scrum 让游戏开发团队更有效率的完成一个游戏开发项
2、目。关键词：scrum,游戏开发，项目管理，应用，联系与区别1共同的核心价值1.1Scrum 希望能够在最短的时间里完成最高价值的功能，游戏也是如此，策划们会提出海量的需求，永远不可能做完，又要在规定的时间上线，这就使得游戏开发团队不得不在规定的时加内，完成最高价值的需求。12 Scrum 拥抱变化，不做完美的需求文档，而是在每个 Sprint 结束后，对产品 Backlog 重新进行一番审视，主动地去接受变更，改变产品 Backlog，以确保能在下一个 Sprint 内开发出最重要的内容。游戏团队开发也是如此，策划人员需要不停的根据玩家反馈、市场变化等因素来调整游戏的策划案，开发团队需要以一
3、种积极应对的方式来处理策划变更。项目经理圈子游戏中很多文档的价值很低，如功能分析与设计文档，当产品被制作好以后，这些文档便没有了任何价值，一个功能和其他功能的关联，也都在策划文档中有详细的记录，因此在开发过程中，根本不会尊寻传统软件开发中的先文档再开发的方法。同属于敏捷开发的 Scrum 方法也坚持交付有价值的功能，从而尽可能减少不必要的文档，这也正和游戏开发的做法完全吻合。1.3Scrum 不做完美的开发计划，多变更的环境中，没有任何一个计划能被良好的执行，如果我们不能执行一个既定的计划，那么我们不如不制定这种计划，而是用另外的方式，基于承诺的方式来完成开发工作。有过游戏开发经验的人都知道，
4、游戏开发根本不能按照既定的计划进行，但是不计划又没法管，而 Scrum 正式提出这种非计划驱动型的研发管理方式。从以上这几点来看，Scrum的价值观和游戏开发管理价值观完全的吻合，Scrum 完全可以运用到游戏开发过程当中。2Scrum 意味着改变实施敏捷，尤其是要实施 Scrum，就意味着我们要彻底改变传统的，计划驱动型的开发方法，这个改变不但包括了项目管理思路上的转变，对于团队的划分、项目流程，乃至工作方式，都要发生改变。同时改变也是双向的，开发者在改变的同时，Scrum 也要根据游戏公司的实际环境发生相应的改变。Scrum 实施成功的关键，就是做好从传统向敏捷的转变，Scrum 实施的最
5、大的风险，就是虽然我们实施了 Scrum，但是我们却没有遵守 Scrum 的核心要求做事情。 3定义 Scrum的角色Scrum 中不再有传统意义上的产品经理、项目经理，而是使用了 Product Owner、Scrum Mas ter、Team 和 Stake holder 这样的新角色，当项目组是从传统开发模式转变过来的时候，我们需要重新定义这些新的角色。项目经理圈子3.1团队项目经理圈子对于传统 Scrum 而言，团队是一个跨职能团队，分析设计人员、开发人员、测试人员一起组成了一个团队，大家在弱化分工，每个人都参与设计、开发与测试中。对于游戏团队，尤其是大型网络游戏团队，实现跨职能团队有
6、相当大的难度。游戏公司大多采用矩阵式结构，按照职能，会分为策划、开发、美术、测试等部门，根据项目再从各个部门抽调人手形成项目组。我们这里所讲的新的 scrum 团队也可以是跨职能的，这里的跨职能是一个小范围的跨职能，是相对于传统的开发方法而言的。在传统的游戏开发团队中，每个程序都负责一个特定的功能模块.对于 Scrum 的跨职能团队而言，我们希望能够打破程序、测试人员的分工，我们希望所有程序人员都能应对多个功能于模块的代码，测试人员也能了解多个模块的业务逻辑，这样，实际开发工作中，团队成员能够互相帮助，评估过程中，团队成员也能各抒己见，加深大家对于功能的理解，提高团队生产效率。3.2Scrum
7、 Master Scrum Master 是 Scrum 项目中的灵魂人物，按照 Scrum 中的定义，Scrum Master 不再是一个执行管理技能的领导，而是一个秩序维护者、教练以及团队成员的第一助手。Scrum Master要为团队、Product Owner 教授 Scrum 知识，维护 Scrum 秩序，必须要在整个项目组内有很高的威望，甚至要有能力调配测试、美工、策划资源. 当团队规模还很小的时候(项目初始阶段，5 人不到的时候)，Scrum M aster 还会兼职做一些开发之类的事情，当团队开始扩大到 10 人左右时，Scrum Master 就要求为全职了，要一心一意的来维
8、护这个团队。Product Owner传统敏捷项目中，Product Owner 大多是由原来的产品经理负责，也就是直接对产品负责的人来按照最简单的映射关系来看，Product Owner 应该非游戏主策划莫数，他直接对游戏负责，总管游戏需求。不过游戏项目和传统软件项目差别很大，简单的映射关系是没法成立的。Scrum of Scrums传统 Scrum 一直认为 5-9 人是一个最佳范围，团队过小，管理成本会过高，团队过大，则不利于团队的沟通，降低团队工作效率。在 40 人团队规模下如果要继续有效的使用 Scrum 方法，唯一的办法就是分拆团队，采用 Scrum of Scrum 的方法。当开
9、发团队规模较小的时候，如不超过 10 个人，我们可以采用一个 Scrum 团队的管理方式，项目经理即为 Scrum Master。如果团队扩大到 10 人以上以后，那我们就不得不拆分团队了。其实拆分团队并不困难，当团队扩大以后，自然就形成了一个分割，如某一些人专门负责技能与任务的开发，另一些人则专门负责副本的开发与维护，这样我们就可以把开发内容有紧密关联的团队成员组成一组，人数控制在 5-10 人左右，在这个组内再任命一名技术、管理能力均衡的成员作为这个小组的 Scrum Master，管理所在的子团队，同时听命于项目经理。整体而言，游戏行业(尤其是网络游戏行业)对于变更是又爱又恨的，很纠结，
10、很痛苦。因此在网络游戏行业中，变更管理也不是简单的放任或者控制，而是要权衡各方面的因素，让变与不变维持在一个平衡点上。一句话概括其管理方式就是：胡萝卜+大棒政策。4应用正确的开发模型4.1网络游戏开发应该是有周期性的，短迭代周期的增量式开发是比较好的开发模型。但是很多游戏公司居然没有任何开发模型，完全是一种混沌的开发方法，买来一个现成的游戏引擎，想到什么就开发什么，感觉做的差不多了就打个包上线，没采用任何开发模型，没有什么明确的开发周期，一切都是凭着感觉来。这是一个很危险的事情，很多这样的公司，在游戏上线以后，会发现这个游戏制作工作彻底陷入了一团糟的境地，任何局域性方法都无法提供有效的帮助，最
11、终公司进入一个死循环，决的办法也变得很残忍：要么死掉，要么彻底改革。任何的针对具体软件开发管理问题的解决办法，都是要在软件开发模型的大框架下才能起效果的。我们不可能把瀑布模型中制定计划的方法用在敏捷开发模型下，我们也不能把打牌估算的方式用在瀑布模型中，因为这些具体方法都是在具体的开发模型的框架下，才具备了生存的条件。就像生态系统一样，热带雨林里的鳄鱼，放到沙漠里面，肯定活不下去的。所以如果一个游戏公司连基本的开发模型都没有引入的话，那么就不要考虑变更怎么管理了;就像在真空中任何生物都无法生存一样，在没有开发模型的环境中，任何开发管理方法也都无法取得效果。4.2迭代周期的选择一般的共识是这样的：
12、相对较长的 Sprint 迭代周期，能够有效的提高开发效率。因为一个Sprint 周期中，有些工作是不能被省略的，如 Backlog 的整理、估算、计划会、评审会与反思会、代码集成、测试、打包等，这些活动一般都要占用不少的时间，越长的 Sprint 周期，这些活动所占用的时间比例会越少，为开发人员留下的整块开发时间就越多，工作效率也越高。而 Sprint 周期越短，对于需求变化的响应速度就越快。人们对于未来变化的把握能力其实很弱，越短的时间，把握越强，考虑的也越详细，太长时间以后的事情(如 2 个月以后)，则基本没有什么把握能力了。项目管理论坛Sprint 周期的选择，就是开发效率与响应速度之
13、间的一个平衡。一般在开发期的游戏，会选择相对较长的 Sprint 周期，如 1-2 个月左右，这时候策划相对比较明确，还没有引入玩家与运营反馈，需求变更相对较少，选择相对较长的开发周期能够保证开发期的游戏开发效率，争取尽早达到上线标准。这时候也希望策划团队能够尽可能减少不确定的变更，如果一个功能或玩法没法确认真的比改变前更好，那么就不要贸然提出改动，等到上线之后听到玩家的反馈后再提出，能节省不少工作量。而从游戏上线封测开始，Sprint 周期就开始逐步缩短，以适应逐渐增多的 Bug、调整与变更，在游戏正式运营后，一般都会将 Sprint 周期控制在 1-3 周左右，一般都是与游戏的更新周期保持同步。从管理的角度来说，为了适应更短的 Sprint 周期，很多管理上的规章与流程也要随之相应的简化，以适应高相应速度的要求。参考文献管理者联盟文章
