Scrum与传统方式之间的不同

在使用Scrum之前，公司或者开发团队多多少少已经有一些成型并且大家都已经习惯的开发模式。打个比方说，策划先行，然后召集大家讨论策划案，之后得出程序和美术的工作量再定义出里程碑拟订好开发计划，然后大家开始正式分头动工。在这个开发流程中，开发人员面临的最大困难是策划案也就是需求的变化量非常大，并且这种变更，很大一部分情况可能是直到里程碑快结束的时候，大家才一起意识到有些功能压根就无法实现或者勉强实现的效果并不理想。这时似乎只剩下修改策划案这一条路。于是大家对于无论如何严格的审核策划案，到中途总是会以这样那样的理由变更的情况已经习以为常。因为需求变更而导致产品推出时间可能一推再推，以至于最后不得不砍掉一些功能才能确保产品在可以接受的时间之内被推出。

尽管传统的开发方式可能有些地方老是出问题，但大多数情况下大家也会比较倾向于下次注意点，而不是尝试一套新的开发方法。在MMO的开发模式的选择上，Scrum在许多地方的确可以解决传统模式所遇到的问题，比如Scrum能在拥抱变化这一点上极大的帮助开发者。类似这样的优点，在Scrum的拥护派看来，可以列出好几页来。但是，要说服一个原有的团队选择一种新的开发模式来代替大家已经熟悉的方式，光列举优点是不够的，我们也需要直面Scrum与现有模式的其他差别，有些甚至是Scrum的劣势。

1． 每次提交可运行的版本

Scrum的精髓在于拥抱变化，并强调通过频繁的交付来获得及时的反馈，以便于尽可能快的调整不合理的需求。但对于某些大型MMO而言，比如MMORPG，系统的复杂度往往超出我们的想象。如果没有一款已经使用过的引擎，光是前期对低层技术的开发就是一个漫长的过程，如果采取Scrum的方式，要求每一小段时间提供一个可运行的版本无疑是一个噩梦。而对于同时进行的策划案的撰写，要求提供一个反应策划内容的版本更是困难。Scrum在这个阶段如何开展，是需要克服的一个问题。

2． Sprint的划分

相对于传统的基于里程碑的开发，Scrum要求划分出一个个相对较短的Sprint。并且每个Sprint需要有可以提交的版本，以及一个比较明确的可以体验的目标。而在MMO的开发中许多工作，比如系统架构设计，数据库设计，美术概念讨论等都很难在Sprint中体现出来，也就无法通过Sprint Review的形式获得反馈。但是这些东西又跟所有的人的工作息息相关。Scrum如何在能够保持紧密沟通的同时，对类似的相对独立的部分也照顾周全？

3． Scrum的管理

Scrum是一个强调自我管理的开发方式。无论是Stand Up Meeting还是Sprint Planning的时候都要求少干涉多聆听。对于项目经理来说，某些时候参与感很差，总是好像找不到自己在团队中合适的位置。但是项目经理又不得不对进度负责，面对各个并行的小组，每天都可能有大量新的task提出，又有大量task被否决，如果你这个时候去问项目经理“我们到底能不能按时完成，如果推迟，那还需要多久”这样的问题的话，他也许只能对你摇摇头。我们在使用Scrum的时候，进度管理上的缺失也是我们需要直接面对的问题。

类似的问题，在我们推广Scrum的时候可能会遇到很多。为什么会有如此的问题归纳一下，原因可能如下：

1． Scrum最早来自于软件工程，虽然现在扩展到开发的各个方面，由于其自身的限制性，注定要面临许多困难。（笔者曾经听说过某公司号称用Scrum进行管理，要求销售，HR部门都实行Scrum方式，很难想象这是一种怎么样的Scrum。）

2． MMO开发本身结合了跨平台，分布式，周期长，变动大等多个开发难题， Scrum能够很好的解决一些问题，但对需要长期规划的问题明显缺乏控制力。

融合：和其光 避其尘

在笔者看来，Scrum是一种优秀的开发方法，许多特征的确证明了它比它的前辈们更好的解决了游戏开发中所遇到的诸多问题。可是，如同它的前辈一样，Scrum并不是游戏开发中的那颗Sliver Bullet，再次应征了Brooks大师所言。所幸的是，我们可以使用Scrum与传统开发方式“混血”式执行的办法，根据自身情况，灵活的选择有利的方面执行，对不适应的地方进行改进，从而能最大限度的在MMO游戏的开发中发挥出Scrum的威力。

笔者有幸在参与的一些项目中使用过Scrum方法，同样也经历了Scrum与本土MMO开发结合时候遭遇的种种尴尬。笔者认为，Scrum对于MMO游戏的开发，有其利也有其弊，对于整体进度的把握以及对于文档工作的控制Scrum做得并不是十分到位。对于任何一种开发方法论而言，执行团队都需要从自身实际的条件出发，选择性的使用。最怕的是盲目执行，暴力式地推行，而其他软件的工作却不跟上，执行的团队并不明其所以，最后可能搞得人人谈敏捷而色变，失败当然是一个必然的结果。笔者始终认为，工具，方法始终是死的，如何使用才是真正出学问的地方，只有从自己实际出发，冷静分析，在合适的地方用合适的工具，才能做到庖丁解牛，游刃有余。

那么Scrum应该如何结合传统的MMO开发方式呢？我们从项目开发的各个阶段来一一分析，如何让Scrum发挥自己的威力。

项目前期

项目前期我们面临的问题有哪些？首先是产品尚未成型，团队也许对将要制作的产品并没有一个十分清晰的概念，更谈不上对项目规模的预估。其次有一大堆技术性的难题摆在团队面前。这些难题能否解决，如何解决，都势必会对策划案的成型有决定性的影响。这个时候，我们可以分两头采取不同的开发模式。

对于将面对的技术难题，这个时候目标明确，团队规模较小。比较适合采用Scrum的形式一一攻克这些问题。我们可以把大家公认会遇到的难题列举出来，通过Scrum Planning的形式分解成一个个User Story再划定各个问题的优先级和互相的依赖关系，然后分别组建Scrum团队。这个时候的目标很明确，即得到这些难题的解决方案。我们希望在这个阶段结束的时候，程序对所要面对的技术问题心中有数，策划也对哪些能做哪些不能做有一个清楚的认识。同时我们还希望对一些我们必须要克服的东西，在这个阶段已经能产生一些行之有效的工作流程。

对于Scrum小组的组建，这个阶段我们可以以程序为主，策划和美术作为某些User Story的Customer，负责对程序工作成果的审查。为避免过早的陷入需求更改的陷阱，这个时候策划除了验收成果之外，不应过多的干涉程序实现的方法，而仅仅在设计User Story的时候提出自己的意见（事实上很多User Story应该由策划和美术直接提出）。在Sprint的划分上，我们可以以2～4周的标准划分。尽量将这个阶段控制在2～4个Sprint之内（这取决于团队的大小和技术基础）。对于一些经过验证存在困难的User Story可以在每个Sprint Review结束后的Planning Meeting上经大家讨论做少许更改，让下一个Sprint向更接近我们的目标（切实可行的解决方案）的方向上前进。对于Scrum的范围，笔者建议尽量不涉及高耦合的工作，将涉及多个方面的User Story拆分成相对独立的部分再分头进行。举个例子来说，可以将服务器端和客户端的技术难题分开进行，对于涉及服务器端和客户端交互的功能再单独提出来作为一个Scrum，尽量保证工作的粒度比较小，减少互相依赖的关系。我们的首要目标是证明技术可行性，这对整个流程的开展有一定的好处。

对于策划案以及美术风格的概念设计，这个时候则采取较为传统的方式，由策划和美术师内部产生。策划在对程序的Scrum小组提出User Story的同时即提出了自己的疑问，在程序执行Sprint的过程中获得对自己提出问题的反馈，进而决定自己的策划案如何撰写。美术则在这个时候确定美术风格，以及在与程序Scrum小组合作的过程中确定某些美术工作的工作流程。笔者不建议这个时候就加入程序对策划案进行讨论，这也许和某些团队采取的方式不同。这种方式对策划和美术的要求较高，既需要向程序的Scrum小组提出User Story，并从审查中获得反馈；也需要保持设计工作的相对独立，做好策划案的前期工作。这需要策划或美术在前期就对中期可能发生的问题有所预见，向程序有针对性的提出需要测试的地方而不是等待程序来告诉你不可行。如果这个时候能有富有经验的产品经理或者制作人来负责这两方面的协调工作，也是一个确保这个过程可以顺利进行的有效因素。对于程序美术在前期就加入讨论，笔者是持保留意见的。比如曾经经历过的一个项目就因为太早冻结策划案以至于美术和程序花了几天来讨论每个UI元素的具体坐标是多少，但最后却不得不尴尬的面临因为用户体验不友好而更改UI方案的情况。

在这个阶段结束的时候，我们应该得到一个策划案的初稿，起码完成了整个系统以及世界的架构，可以估计出项目将来在程序，美术和策划工作上的规模。还应该有几套行之有效的工作流程，能根据项目的预计规模估计出将要投入的人力和项目需要进行的时间，以便于之后的市场等多项工作的计划和开展。接着，我们就便可以投入更多资源进入正式开发的阶段。

项目中期

在MMO项目中期，我们面对的主要问题是对整体进度的把握，确保能按时推出我们需要的版本。其中面临最主要的难题就是对需求变更的控制。这个方面Scrum有其决定性的优势，但如何在高度拥抱变化的同时又不失对进度的把握是Scrum在这个阶段所要面临的问题。笔者建议这个时候需要根据团队对Scrum的熟悉程度来选择不同的解决办法，分别采取以Scrum方式为主导传统方式为辅的方式，或者反之。

对于一个熟悉Scrum的团队而言，笔者的建议是在正式开发之前，整个团队坐在一起，讨论策划案。将策划案中划分的各种系统分解为不同阶段的User Story，再通过团队之间的讨论以及各组之间的工作配合需要制定出优先级。现在我们有了一大堆由策划案分解出来的User Story，这些User Story有一定的依赖关系和不同的优先级，这时候根据我们的需要将这些User Story组合成不同的Sprint，再视这些Sprint的目标和内容组合成不同组合，每个组合我们可以视之为一个里程碑。如果你的项目的时间预算非常有限，你可能会倾向于将一些不是很重要但如果不完成其他部门就无法开展工作的User Story先行制作；如果你的时间充裕，你则可能更倾向于先有一个完备的系统设计以及一个方便扩充的灵活架构，让其他部门暂时等待或者做其他的事情。总之，这一切取决于项目具体的需要和团队资源，并没有孰是孰非之分。

由User Story来构建里程碑这对团队的Scrum能力而言是一个考验，需要团队对User Story乃至Sprint的划分有一定经验，并且能够预见整个过程中可能面临的风险。选择合适，制定好的，可实现的User Story可以规避很多由于后期Sprint变更时候带来的连锁反应。这也是为什么笔者建议有一定Scrum经验的团队选用该方法的原因。

对于初次尝试Scrum的团队，可以尝试采取相对保守的方法。通过传统的方式对策划案进行技术评估后，划分出里程碑，然后根据每个里程碑的目标制定User Story，再划分Sprint。这在一定程度上降低了对User Story制定上的要求。同时在每个Sprint结束的时候根据Sprint完成情况结合里程碑的目标对User Story进行修正。听起来似乎和上个方式大同小异，但执行过程中可以省略对Sprint筛选和组合的过程，可以说目标更加明确，对尝试达成这个目标的团队来说也相对轻松一些。

无论采取什么样的方式，对于进度的管理上都是需要按照传统的方式划分里程碑。这可以方便我们把握项目整体进度,防止由于Sprint过多并且更改过快以至对项目整体进度没有概念。每个里程碑就像一扇扇保险门，明确里程碑所要达到的目的以后就不再轻易变更，严格控制好里程碑中间Sprint的变更范围。从某种意义上讲，这种互相结合的方式能够有效降低项目中期由于变更过多而造成进度失控的风险。

这个阶段的Scrum团队的组建也不同于项目前期。这时一个Scrum团队是一个包含程序，美术，策划乃至市场人员的复合小组。这个阶段中的Sprint的之间的变更乃至小组成员的身份的变化也会更加复杂。同一个Sprint中一个User Story的执行者可能是另一个User Story的Customer，需要在开发过程中保持高效的沟通。小组成员也并不是固定不变，在一个Sprint结束之后根据下个Sprint的目标可能组合成不同的小组。比如这2周做NPC交易的小组成员，可能下个Sprint会和其他人组成摆摊系统的Scrum小组。重要的是我们作为一个整体的团队如何达成每个Sprint的目标，而不是保持单个Scrum小组的独立性，毕竟灵活性也是Scrum的一大优势。

这是一个频繁迭代的阶段，也是游戏内容不断增加和修正的过程，在每个Sprint结束的时候，我们都应该得到一个可以运行的版本用于衡量该Sprint的目标是否达到。策划要在每个Sprint review之后总结更正自己的设计，美术也随着一个个Sprint的完成，看到自己的作品一批批导入到游戏中的效果。所有这些都需要建立在团队成员之间高效的沟通，以及默契的合作之上。这也对团队的自我管理能力也提出考验。

在项目中后期，我们会面对成批从QA部门反馈的bug以及为配合市场活动而临时增加的开发需求。Scrum的灵活性在这个时候可以得到进一步的发挥，随着投入资源的增多，我们可以对这些工作内容建立单独的Scrum团队，用于解决这些琐碎但庞大的新增需求。别忘了，Scrum是最善于解决目标相对明确的短周期需求。

随着Sprint的一个个进行，里程碑的一个个完成，我们终于走到项目交付和维护的时候，这个时候我们面对的是单机游戏不曾经历的维护和运营阶段。

项目后期

一个MMO的开发并不随着产品发行的结束而结束，无休止的维护和资料片的推出是团队必须要面对的现实。同时团队人员的更迭也需要在这个时候开始进行。我们慢慢要把原来开发团队的部分人员抽离出来，以便于开始新的项目。对现有项目的维护和对新加入人员的培训是我们在项目后期需要面对的主要问题。

项目后期的工作，笔者看来分为两大类，一是原有系统的BUG，运营商的2次开发需求以及来自于市场或者策划方面的活动需求，二是并行的资料片开发。先说资料片开发，开发量和内容都基本上相当于项目中期的一个或两个里程碑，对于Scrum的处理方式可以按照项目开发中期的方式通过复合的Scrum团队来处理。通常会在版本控制系统中建立一个平行的分支进行开发，值得注意的是需要随时准备集成对原有版本的改动。对于第一类问题，则通常不会涉及太多原有系统的改动，可以单独建立程序或者美术+程序的Scrum小组进行有针对性的开发。通常这个时候，进度已经不会再成为压力，对积累了开发阶段Scrum经验的团队来说，不会有太大问题。值得一说的是如果不是自主营运，对来自运营方的需求如果要对方来适应Scrum的开发模式可能有点强人所难。好消息是来自运营方的需求并不会像我们可爱的策划案一样频繁变更。Scrum小组定义好一个接口人以后可以仍然按照自己习惯的方式进行开发，把哪些恼人的外部沟通工作扔给接口人吧，这样可以在一定程度上降低我们沟通的成本。

Scrum的过程控制工具

在使用Scrum的过程中，尤其是周期比较长的项目，对于负责项目进度控制的人来说，整体进度把握和对基础架构工作的控制都是比较头痛的问题。这时，有许多工具可以帮助我们对目前的风险和进度有一个清楚的认知。

可交付物件列表（Deliverable Check List）

不同于其他采取Scrum方式进行开发的软件项目，MMO的开发过程中，文档还是扮演着相当重要的角色。一个MMO可能产生上万甚至百万字的文档工作量，我们既需要保证开发的高速和灵活，也要保证这些文档的创建和维护。在项目的各个阶段我们需要有一个或者多个可交付物件列表。这个列表可以方便我们跟踪策划案，美术工作量，以及诸多程序设计的文档的制作情况。

列表中的每一项都是一个可提交的物件，每个物件都需要设定相关的负责人，审批人以及预计完成时间。这种列表是传统开发方式的产物，然后在Scrum进行的过程中，这些物件可以作为一个个User Story分布在各个阶段的Sprint中，也可以独立在Scrum之外。通常这些文档可以作为某个阶段结束的标志，然后再以这些文档为基础来做下个Sprint的Planning。通过维护这样的一个列表，我们可以对一定范围内的整体工作量有所控制，能够弥补原本Scrum在这点上的不足。

每天编译 （Daily Build）

存在着多个并行的Scrum小组就意味着会可能同时存在多个不同的版本。前面建议大家在Scrum过程中尽量将不同Scrum小组目标的耦合度降低正是为了减少系统集成的时间。有不少团队采取分头开发，然后在一个约定的时间统一进行系统集成的办法。然而笔者并不建议采用这种方式，主要原因是随着分头开发的持续，各个小组之间并不清楚对方在做什么，代码上产生的差异会累积下来。等到做系统集成的时候，有时候会被迫面对二者只能取其一或者又要花费大量的时间来修改已经完成的系统的尴尬情况。这个时候，建立一套每天自动编译最新版本的系统可以帮助你化解这个方面的危机。

这个系统每天会从版本控制系统中更新最新的代码来编译一个可运行的版本，并自动做一些简单的系统测试工作。这里的测试工作相当简单，往往只要能保证启动程序或者连上服务器端这样的基本功能。当编译出错或者系统测试无法通过的时候，该系统能够通知相关人员，从而迫使程序员在上传代码的时候做好merge工作。为了合并好代码，不同的Scrum小组之间也需要经常沟通，以了解对方的工作进展，帮助程序员养成符合Scrum精神的工作习惯。

向下燃烧进度表（Burn down Chart）

对于Sprint与Sprint之间，乃至里程碑与里程碑之间的完成情况，通过Burn down chart这个工具我们可以随时了解任务的完成情况以及和计划的偏差。同时Burn down chart也能很好的反映在项目进行过程之中，user story的变更情况。

拿下面的一个burn down chart来说。

这是一个持续了3周的sprint，这个表反应的是在这个sprint过程中所有任务每天的完成情况。这里每天的完成百分比是由从第二天在每日起立会议以后收集到的任务完成情况决定的。我们可以看到在4-28和5-2这两天的计划曲线有一个起伏，这是由于当天有新增加的任务，这对我们Sprint review的时候评估这个Sprint的完成情况可以起到参考作用。

其他的比如告示板，索引卡，Sprint Planning等工具和方法，一般的Scrum的书籍都有介绍，笔者在这里就不再一一列举。笔者主要列举的是基于MMO的Scrum开发过程各个层面上的简单进度控制工具，以帮助团队及早发现风险，并得出应对之策。

推广Scrum过程中要注意的问题

向一个已经有过开发经验团队推广Scrum的方式并不是一件轻松的事情。没注意好的话，往往最后流于形势，不仅团队的积极性没有调动起来，甚至会让人产生反感。

环境的营造

使用一个类似Scrum这样自组织式的开发方式的时候，需要特别注意的是对于整个Scrum环境的营造。尤其不要流于形式，不然就真的是费力不讨好的事情了。笔者遇到的一个很典型的例子是：Sprint Review之前，程序的版本并没有集成编译过。于是为了准备Review中需要演示的东西，花了大半天的时间来合并代码并修改，演示结果可想一般。更糟糕的是，在user story被否决了以后，团队的积极性受到打击，对Scrum也颇有微词。

让团队真正理解什么是Scrum并不是简单跟大家宣读一下章程这么简单。持续的培训和心得交流是一个比较好的办法，有助于让团队了解每一步的意义和目的。同时还要鼓励大家多沟通交流，在Planning的时候提出自己的想法，多了解同伴的工作情况。不能再像原来一样各家自扫门前雪。

团队适应能力

谈团队素质是一个比较尴尬的问题，中国的游戏业毕竟还非常年轻。笔者的一个朋友曾经跟笔者抱怨过，原来尝试过Scrum方法，但试行了半年之后就放弃了。理由是Scrum太讲究团队的自我管理能力，他的团队并不能很好的适应这种自我管理的方式，而他的团队中还不乏有多年经验的开发人员。笔者的观点则是团队的适应能力跟团队成员的态度有关。我们当然不能苛求所有的团队成员都有多年的开放经验，尤其是项目失败经验，以便于他们理解Scrum可以帮他们解决多少他们曾经遇到过的问题。同样，就算有多年经验，抱着原来的方式不放，觉得这些新东西只是花招式，还不如自己的老三套来得实在也要不得。

团队是否能很好的适应Scrum方法，跟团队是否抱着积极开明的学习的态度有关。这在一定程度上也是依赖于团队内部的环境建设。而团队成员中参差不齐的素质笔者认为并不是太大的问题，我们并不需要所有人都能够对任务的规划和分解深刻把握，团队成员在这个高度强调沟通的环境中反而成长会更为迅速。

多次交付VS多次迭代

多次迭代并不等于多次交付，这是Scrum常有的一个误区。在每个Sprint开始的时候，我们都必须要明确这个Sprint结束的时候我们需要Review的是哪些东西。很多时候，如果一个Scrum开展不是很顺利，在Sprint Review的时候我们常常会听到这样的理由，“因为某些原因，这个功能我没有办法展示给你，但是这个功能是有了的，我只需要改动小小一点东西就可以了。”或者是“这个部分与另一个系统相关，我代码已经写好了，但我要一起改好了你才可以看到。”如果放任的话，这些理由到后期会泛滥成灾。我们所能做的，除了拒绝通过这些相关的User Story之外，在每个Sprint开始的时候还应该帮助团队了解到我们需要在Sprint Review上看到什么东西。强调我们重视的是可交付的版本，而不是一个口头上的功能增加。

有些时候这也取决于我们的User Story是否范围太大太空以至于无法实现。这也对要求我们提出更具体可实现的User Story，否则就需要及时拒绝它或者再细化。

结队

是否结队编程这个问题，笔者是持保留意见的。曾经有过一段不太愉快的结队经历，虽然不是随时“面向显示器编程”但相当时候两个人坐在一起写一段代码是常有的事情。个人认为在两人没有达到足够默契的程度的话，还是不要轻易尝试结队开发。而对于Scrum来说，除了结队，也可以通过buddy check（在提交代码前交由另一人检查提交）来确保互相对工作情况的了解。同时前面提到的每天Merge同伴的代码也是一个帮助团队成员互相了解工作情况的好机会。

最后

Scrum毕竟是个新东东，大家还正从适应中慢慢了解和熟悉。但从笔者看来，它的确是目前最适合游戏开发的方法论之一。除了能够从容应对需求的变化之外，他鼓励沟通的方式也能一定程度上激发团队的创造力，促进团队内气氛。在面对中国式MMO的开发上，灵活的把Scrum和传统方式相结合，通过不同的工具进行控制，能很好的弥补原来Scrum对长期进度缺乏控制，以及文档管理缺失的一些劣势，从而发挥其在需求管理，针对性解决问题上的优势，更好的解决我们在开发过程中可能会遇到的问题。