Scrum在大型游戏团队中的应用

当游戏遇到了Scrum
  Scrum并不是什么高深的管理方法，Scrum的科学原理中，没有什么是值得被拿出来，放在学术界讨论的东西，就连其估算方法，也是使用了看似游戏一般的扑克牌估算法，实在是难登大雅之堂。Scrum的指导原则很简单，没有把软件开发中的所有的事情都详细的规定，或许可以说，Scrum只明确阐述了极少数的几个问题，Scrum容忍混乱，甚至是一种对于混乱的妥协。但是Scrum成功了，在很多领域中都获得了巨大的成功，究其原因，在于Scrum抓住了软件开发中最终要的因素：人的管理。不同于传统的开发方法集中于对过程的探索与执著，Scrum完全抛开了繁琐的过程，把软件开发重新放在了人的身上，Scrum妥协，容忍混乱，不使用复杂高深的管理方法，就是在于他要将人凝聚成一个团队，让团队来完成软件，而不是让规则、标准、过程和文档来完成软件。
我的Scrum和游戏开发管理经验来自于我的工作，我所在的公司是一家软件研发管理工具供应商，帮助全世界的游戏公司管理其开发过程，也包括了中国的游戏公司。我所深入接触过的十余家大型游戏公司，全部对敏捷开发表示了强烈的兴趣，我也亲自帮助其中的部分游戏公司的多个游戏项目组实践了敏捷开发，并取得了良好的成绩。

我在今年早些时候或了的Scrum联盟授予的Scrum Master认证，在参加认证课程的过程中，引发了我对于Scrum和游戏开发的深入的反思。

共同的核心价值
看了Scrum的科学原理和游戏项目开发遇到的问题，我们不难发现他们之间存在着很多相

似的价值观。

Scrum希望能够在最短的时间里完成最高价值的功能，游戏也是如此，策划们会提出海量的需求，永远不可能做完，又要在规定的时间上线，这就使得游戏开发团队不得不在规定的时加内，完成最高价值的需求

Scrum拥抱变化，不做完美的需求文档，而是在每个Sprint结束后，对产品Backlog重新进行一番审视，主动地去接受变更，改变产品Backlog，以确保能在下一个Sprint内开发出最重要的内容。游戏团队开发也是如此，策划人员需要不停的根据玩家反馈、市场变化等因素来调整游戏的策划案，开发团队需要以一种积极应对的方式来处理策划变更。

Scrum不做完美的开发计划，多变更的环境中，没有任何一个计划能被良好的执行，如果我们不能执行一个既定的计划，那么我们不如不制定这种计划，而是用另外的方式，基于承诺的方式来完成开发工作。有过游戏开发经验的人都知道，游戏开发根本不能按照既定的计划进行，但是不计划又没法管，而Scrum正式提出这种非计划驱动型的研发管理方式。

游戏中很多文档的价值很低，如功能分析与设计文档，当产品被制作好以后，这些文档便没有了任何价值，一个功能和其他功能的关联，也都在策划文档中有详细的记录，因此在开发过程中，根本不会尊寻传统软件开发中的先文档再开发的方法。同属于敏捷开发的Scrum方法也坚持交付有价值的功能，从而尽可能减少不必要的文档，这也正和游戏开发的做法完全吻合。

游戏对于产品质量有极高的要求，普遍高于一般的软件，传统的开发方法，不论是瀑布、RUP，总是会在开发后期时间内出现Bug大爆发，团队疲于奔命的应付Bug的局面，对于功能高耦合度的游戏而言，这简直是致命的。Scrum倡导风险前移，对于“完成”的概念有明确的定义，每个Sprint都以产品演示和评审作为结束标志，这对于提高产品质量，起到了关键的作用。

从以上这几点来看，Scrum的价值观和游戏开发管理价值观完全的吻合，Scrum完全可以运用到游戏开发过程当中。

然而，当游戏团队的项目经理们阅读了敏捷开发、Scrum的一大堆经典著作之后，大都提Scrum倡导弱分工，小团队应用。在强分工和大团队的游戏开发项目中，Scrum是否已经失去了它的立足的根基？

出了一个相同的疑问：

Scrum意味着改变

实施敏捷，尤其是要实施Scrum，就意味着我们要彻底改变传统的，计划驱动型的开发方法，这个改变不但包括了项目管理思路上的转变，对于团队的划分、项目流程，乃至工作方式，都要发生改变。同时改变也是双向的，开发者在改变的同时，Scrum也要根据游戏公司的实际环境发生相应的改变。Scrum实施成功的关键，就是做好从传统向敏捷的转变，Scrum实施的最大的风险，就是Scrum But，意思是说，虽然我们实施了Scrum，但是我们却没有遵守Scrum的核心要求做事情，也就是说没有做好彻底的转变。Scrum But导致了大量尝试Scrum的团队失败，并严重的误解了敏捷与Scrum。

在接下来的文章中，会详细说明团队在使用Scrum中所作出的改变，以及这些改变的出发点及其重要性。

T公司的老纪和他的项目组

很抱歉，因为商业保密问题，在这篇文章中，我不能说明任何一家我所接触过的游戏公司的实际管理方法，连公司及其中的任何人员的名字等信息也不能使用，所以在下面的文章中，我会使用T公司来代表我所接触过的全部游戏公司，在下文中所使用的公司、项目、人员名称以及时间点均为虚构，请勿对号。

T公司是国内一家网络游戏开发、运营公司，有自己的开发、运营团队，T公司在游戏开发领域经营多年，有丰富的游戏开发经验。从去年开始，T公司开始正式在其中一个项目组中尝试使用敏捷开发方法，在这之前，T公司也一直尝试着在其开发方法中融入敏捷因素，但是一直没有正式的使用纯粹的敏捷方法。

该项目是一个新的网络游戏研发项目，项目经理是老纪，老纪虽说叫老纪，其实年龄并不算大，资历确实很深，曾经当过很长一段时间程序员，后来领导过两个个游戏项目，都取得了不错的成果，老纪并不是敏捷开发的忠实拥护者，对于敏捷开发的了解也是在实践敏捷的过程中逐渐积累起来的。但是他很乐意接受敏捷和Scrum能够带来的好处，因此在我们的帮助下，他很快的在他的项目组中实践了Scrum，并获得了良好的结果。

下面我们以T公司中老纪的项目组实践敏捷开发的故事来说说Scrum是如何被运用的。在下面的实践中，你可能会发现我们对传统的Scrum作了大量的改变，但是我们依然把握了Scrum的最核心本质，Scrum的团队构架，还有Scrum的最重要的实践活动。

 

定义Scrum的角色

Scrum中不再有传统意义上的产品经理、项目经理，而是使用了Product Owner、Scrum Master、Team和Stake holder这样的新角色，当项目组是从传统开发模式转变过来的时候，我们需要重新定义这些新的角色。

团队

    这里所有的团队，是指Scrum中的团队，而非整个游戏项目组。在游戏开发中推行Scrum时，团队是人员结构中最大的改变。

    对于传统Scrum而言，团队是一个跨职能团队，分析设计人员、开发人员、测试人员一起组成了一个团队，大家在弱化分工，每个人都参与设计、开发与测试中。之所以能够实现这种跨职能的团队，是因为在传统软件开发中，我们只写代码，文字和美术图片只不过是软件的一个完全可以忽略的方面，客户不会因为文字优美，界面漂亮而认同一款软件，他们要的是软件功能。再看看传统软件团队中的各种角色，都在和代码直接打交道，分析、设计人员往往都是程序员出身，白盒测试人员本身也是要写代码的，这使得在传统项目中所谓的分工是完全能被打破的。

    对于游戏团队，尤其是大型网络游戏团队，实现跨职能团队有相当大的难度。游戏公司大多采用矩阵式结构，按照职能，会分为策划、开发、美术、测试等部门，根据项目再从各个部门抽调人手形成项目组。策划人员工作在文字上，美术人员工作在2D、3D图像上，均不和代码打交道，只有程序、测试人员，才在代码上工作。假象如果我们让策划、美工、程序、测试坐在一起，一同讨论数值大小，脚本动作，一起些策划案，编代码，写脚本，画模型，想必是件很疯狂至极的事情。大家都很希望能找来一大批又能策划有能编码还能画画的全才来开发游戏，不过现实是一个也找不出来。

    老纪也没有找来这些全才，他的手下也是策划人员、程序人员、美工人员和测试人员，矩阵式的组织结构使来自不同职能部门的人组成了一个项目组。老纪很想组成一个大范围的跨职能的团队，但是发现不大现实：策划人员是需求提出者，更应该被归为Product Owner，美工团队有点像内部外包，定期反馈完成的作品。能组成团队的，就只有程序与测试人员了，于是老纪将所有的开发与测试人员组成了他的团队。

    这个团队也可以是跨职能的，这里的跨职能是一个小范围的跨职能，是相对于传统的开发方法而言的。在传统的游戏开发团队中，每个程序都负责一个特定的功能模块，如有人专门负责生活技能的代码，有人专门负责聊天系统，大家都有明确的分工，不但程序如此，测试人员也是如此。对于Scrum的跨职能团队而言，我们希望能够打破程序、测试人员的分工，我们希望所有程序人员都能应对多个功能于模块的代码，测试人员也能了解多个模块的业务逻辑，这样，实际开发工作中，团队成员能够互相帮助，评估过程中，团队成员也能各抒己见，加深大家对于功能的理解，提高团队生产效率。

    在很多游戏公司中，测试人员被分为两类，一类是和程序人员坐在一起，进行单元测试的人员，一般我们称为程序测试，另一类则是在体验服务器上进行功能、系统、压力、集成测试的人员，我们一般称为系统测试人员；在组织团队的时候一定要将这两类测试人员均放入团队中，共同作为团队的一部分。

    老纪所在的游戏公司，代表了绝大多数游戏公司的组织架构情况，事实上，我们在几乎所有的实施敏捷的游戏公司和项目组中，都是用了和老纪相同的团队定义。

Scrum Master

    Scrum Master是Scrum项目中的灵魂人物，按照Scrum中的定义，Scrum Master不再是一个执行管理技能的领导，而是一个秩序维护者、教练以及团队成员的第一助手。Scrum Master要为团队、Product Owner教授Scrum知识，维护Scrum秩序，必须要在整个项目组内有很高的威望，甚至要有能力调配测试、美工、策划资源，在T公司中，老纪是一位资历很深的项目经理，是项目组中的二号人物（一号人物是一名公司股东，并不过问项目具体事宜），因此由老纪来担当Scrum Master的职位。

    当团队规模还很小的时候（项目初始阶段，5人不到的时候），Scrum Master还会兼职做一些开发之类的事情，当团队开始扩大到10人左右时，Scrum Master就要求为全职了，要一心一意的来维护这个团队。当团队继续扩大，超过10人以后，就要考虑分拆，使用Scrum of Scrum的管理形式；在传统的Scrum定义中，Scrum of Scrum是Scrum Master的议事厅，不再有Scrum of Scrum的Scrum Master，但是在游戏项目组中，我们必须要有一名能够统管全局的Scrum Master，他需要协调其他部门的资源，能够直接面对强势的主策划、制作人，告诉他们团队应该怎么做，不应该怎么做；这个Scrum of Scrum Master的最终人员，还是落回了优秀的项目经理的头上。

    Scrum of Scrum 中，子团队的项目成员在每个Sprint中都有可能发生一些变动，但是一定要保证子团队中的Scrum Master不要经常发生变动，这样对于保障团队开发效率是极为不利的。

Product Owner

    传统敏捷项目中，Product Owner大多是由原来的产品经理负责，也就是直接对产品负责的人来。Product Owner要负责维护Product Backlog，为Product Backlog排序，为团队逐条讲解Product Backlog，解答团队的疑惑。

按照最简单的映射关系来看，Product Owner应该非游戏主策划莫数，他直接对游戏负责，总管游戏需求。不过游戏项目和传统软件项目差别很大，简单的映射关系是没法成立的。

    传统Scrum要求我们只能有一个Product Owner，对于传统的不太大的敏捷项目来讲，只有5-9名项目成员，User Story最多也不过百十余条，1名Product Owner足以应付。但是在大型网络游戏开发中，当游戏开发到后期时，动辄会有上千份策划文档，其中过百页的文档少说也有百余份，如果将这些策划文档整为User Story，会有几千条，如果让一个主策划来维护这个海量的Product Backlog，恐怕所有的主策都会被吓跑了吧。现实中的状况是：策划人员（包括主策在内），共同在维护庞大的策划库。

    因此我们应当将全部策划人员一同作为Product Owner组，这个组内，每个策划人员维护游戏中的一部分功能的策划案，主策划作为Product Owner组的总负责人。Product Owner组共同讨论游戏功能的分割，创建并维护游戏Product Backlog，计划会上，每个策划分别讲解他所负责的Backlog 条目，并在团队开发过程中帮助团队成员解答疑问。在Sprint结束后的评审会议中，全体策划人员也都要参加评审，给出自己的评审意见。

    虽然Product Owner的范围方面我们做了很大的改变，但是对于Product Owner的职能、Product Owner应当遵守的纪律，我们没有做任何的变动。对于Scrum而言，最大的风险就是我们实施了Scrum But。

Scrum of Scrums

    随着游戏项目的进展，项目组会逐渐扩大，老纪所领导的项目组，最初只有10个人，5个策划，4个程序，等到了游戏内测阶段，项目组已经发展为90多人，近30名策划，近40名程序与测试人员，20名美术人员和几名产品组成员。

按照我们关于团队的定义，老纪的开发团队在后期已经达到了40人的规模，关于团队的规模，传统Scrum一直认为5-9人是一个最佳范围，团队过小，管理成本会过高，团队过大，则不利于团队的沟通，降低团队工作效率。在40人团队规模下如果要继续有效的使用Scrum方法，唯一的办法就是分拆团队，采用Scrum of Scrum的方法。

    当开发团队规模较小的时候，如不超过10个人，我们可以采用一个Scrum团队的管理方式，项目经理即为Scrum Master。如果团队扩大到10人以上以后，那我们就不得不拆分团队了。其实拆分团队并不困难，当团队扩大以后，自然就形成了一个分割，如某一些人专门负责技能与任务的开发，另一些人则专门负责副本的开发与维护，这样我们就可以把开发内容有紧密关联的团队成员组成一组，人数控制在5-10人左右，在这个组内再任命一名技术、管理能力均衡的成员作为这个小组的Scrum Master，管理所在的子团队，同时听命于项目经理。

   

    当我们刚刚开始在T公司实施Scrum的时候，老纪手下只有4名程序员，他是Scrum Master。当团队扩大到12个人的时候，老纪将团队分拆为两个子团队，一个团队专门做帮会系统，4个固定人员，1个临时帮忙的成员，老纪选择了一名最早加入该项目组的成员作为这个子团队的Scrum Master。其他7个人组成另外一个子团队，负责帮会系统以外的其他开发工作，依然由老纪作为Scrum Master。

    在团队分拆过程中，最容易发生的问题是按照工作职能划分子团队，如：逻辑程序员一组，脚本程序员一组，测试人员一组；这是万万要不得的，我们费尽千辛万苦才淡化了团队分工，形成了跨职能团队，如果以这样的错误方式进行的分组，我们的工作岂不是全都白费了？

    随着老纪的团队扩大和项目的进展，老纪后来又对团队作了几次分拆与合并。团队的重组在每个Sprint之间进行，每次重组都是和团队成员协商后的结果，子团队的Scrum Master也基本没有更换过。Scrum of Scrum的团队形式从项目的第4个月开始持续到现在已经1年多了，运转非常良好。

    策划人员的数量在游戏团队中占有了相当大的比重，当团队扩大时，策划人员必然也会要进行分组。传统策划分组是按照游戏功能模块进行分组，如会被分为技能组、副本组、阵营组、任务组等，每个组会有一个组长，负责管理本组工作，并向主策划汇报工作进度。当我们采用了Scrum方法后，策划人员在决定分组的时候，应当和Scrum团队进行沟通，尤其在团队实行Scrum of Scrum之后，策划人员的分组，应当尽可能和团队的分组保持一致，一组策划人员最好能够和一个Scrum子团队对应，并形成一个相对较稳定的Scrum组合，有利于提高团队工作效率。

 

对于软件开发领域来讲，变更始终是最让人头疼的东西，大家对于如何消除变更，如何控制变更，提出了很多很多的理论与方法。无奈变更这东西就像是个打不死的小强，倔强的与软件开发一起生存了半个多世纪，到了现如今的网络时代，不但没有被压制住，反倒更加猖獗了。那么在小强最繁荣的游戏圈里面，大家是如何面对变更的呢？

    整体而言，游戏行业（尤其是网络游戏行业）对于变更是又爱又恨的，很纠结，很痛苦。因此在网络游戏行业中，变更管理也不是简单的放任或者控制，而是要权衡各方面的因素，让变与不变维持在一个平衡点上。一句话概括其管理方式就是：胡萝卜+大棒政策。

游戏公司中对于变更的两种意见
    主变派：策划、制作人；观点：变化乃游戏生存之本

    变化是网络游戏生存之根本，大家评判一个网络游戏发展势头的最重要的标准有两个：在线人数与更新频率。一个更新频率趋于变缓的游戏，基本上可以说是快进入消亡期了。追逐玩家们不断变化的口味，引领游戏圈的新潮流，创造更高的吸金效率，这些都是以不断的变化为基础的。

    因此，游戏必须变。不让游戏发生变化，就等于是要了游戏的命。就算是限制变更，也相当于扼住了游戏赖以生存的咽喉。

    不变派：开发团队，项目经理；观点：变化是浪费，是隐患

    说到底，游戏还是个软件，单机游戏也好，网络游戏也好，无非都是运行在计算机上的软件。变更对于软件开发而言，灾难性的，这一点所有软件开发人员都深有体会，变更会导致大量的重复工作，严重影响开发进度；会对已完成的所有工作产生冲击与影响，带来更多的不可预期的Bug；没有被良好重新设计的变更，甚至会直接威胁到软件构架的稳定性，为将来埋下极大的隐患，等等。这些软件本身的问题，同样也适用于游戏开发。

    更要命的是，频繁的变更会让开发团队感到强烈的挫败感，自己辛辛苦苦做好的东西，没过几天就被彻底改掉了，感觉自己就像是做了很多没有用的东西一样，长此以往，开发团队将会士气受挫，导致开发效率低下。

    看来矛盾是不可避免了。那么到底听谁的呢？听策划的，还是听开发的？按照大自然物竞天择的自然规律来判断的话：谁强，听谁的。

    谁更强？策划，还是程序？如果我在这里挖个坑，盖个楼的话，邀请大家来评价一下的话，我相信会相当的火爆。

    实施证明，策划与程序，都很重要。

变更的分类，哪些可以变？哪些不能变？
    如果我们根据变更是否会对开发工作产生影响来对游戏需求变更进行分类，我们可以整体上分为两种变更：1.对当前的游戏开发工作产生直接影响；2.不会对当前的游戏开发工作产生直接影响。

    当前的工作，是指正在开发、测试、美术人员手上处理，或者进入到当前迭代周期内待处理的工作。发生直接影响，则是指会打断当前正在进行的开发工作，比如一个游戏需求：玩家自定义聊天频道功能，现在这个需求已经到了程序手中，开始编写代码了，这时候如过策划人员发起变更，就会对当前工作产生直接的影响。而如是另一种情况：这个需求目前还在策划阶段，还没有送到程序员与美术人员的手中，这时候策划人员发起需求变更，不会对当前的开发任务产生直接影响，因为现在还根本没有人在开发这个功能。

    如果我们仔细分析一下程序人员反对变更的理由的话，我们会发现，其实程序人员仅仅是反对会产生直接影响的变更，而对于那些不会产生直接影响的变更，则不是很反对。那些不产生直接影响的变更，虽然也会对现有的工作产生一些间接的影响，但是影响不会很大，这个问题我们会在后面来讨论。

胡萝卜+大棒
    基于上面提到的变更的分类方法，我们可以得到这样一个变更管理的方法：

    当一个需求（或者策划案）还处在策划阶段，还没有被送去开发与实现的时候，我们允许这个需求发生改变，甚至允许它发生任何的改变，没有任何限制。而一旦这个需求被送去开发与实现了，那么我们将不再允许这个需求发生任何改变，需求与设计将会被锁定，开发人员将会按照锁定的版本进行开发。

    如果在开发过程中，策划人员实在忍不住要提出变更，那么他仅有两个选择：

    1，要求项目经理彻底终断掉该需求当前的开发工作，将该需求从当前的开发列表中取消，待其将需求变更修改好后，再重新纳入到下一轮开发计划中；

    2，等待已经送交开发的需求开发完成，在已经完成的基础上提出修改（作为一个新需求）并纳入到下一轮的开发计划中。

    当一个需求被完成后，如果策划人员需要对已经完成的内容进行变更，那么他需要提出一个新需求，就叫做“对自定义聊天频道修改”，将这个需求纳入到需求库中，并要求项目经理纳入到接下来的开发周期中，作为一个新的开发任务来处理。

    那么以上的假设是否可行呢？有没有人真的这么实践过呢？答案是肯定的，敏捷开发方法论（不论是Scrum与XP）都是在以这种方法在管理需求变更，实践的结果也是相当不错的；另外，据我接触的游戏公司中，也有一些公司在采用类似的方法来管理变更（金山的一些项目组就是这么做的，效果很好）。如果想更多的了解敏捷式变更管理，可以参考Ken Schwaber伯伯的书：《Scrum敏捷项目管理》（Agile Project Management With Scrum）

    以上的做法，基本上满足了策划与程序的不同需求：策划需要变更，开发不需要变更。开发人员应该对这个方法很满意，既然变化是势不可挡的，但是只要不会直接影响当前工作，也是完全可以接受的；但是策划人员心里还是有一丝不爽：在漫长的开发周期内不能变更，是否太不人道了？

应用正确的开发模型
    网络游戏开发应该是有周期性的，短迭代周期的增量式开发是比较好的开发模型。瀑布模型肯定是行不通的，如果还有公司在用瀑布模型开发网络游戏，唉，只能默默的祝愿他们一路走好了。长周期的迭代（半年一个周期）也是行不通的，这倒不是这种方法本身有什么问题，而是太长的迭代对于这个快速变化的花花世界来说，太痛苦了。

    但是在我们访谈记录中，却发现很多游戏公司居然没有任何开发模型，完全是一种混沌的开发方法，买来一个现成的游戏引擎，想到什么就开发什么，感觉做的差不多了就打个包上线，没采用任何开发模型，没有什么明确的开发周期，一切都是凭着感觉来。这是一个很危险的事情，很多这样的公司，在游戏上线以后，会发现这个游戏制作工作彻底陷入了一团糟的境地，任何局域性方法都无法提供有效的帮助，最终公司进入一个死循环，决的办法也变得很残忍：要么死掉，要么彻底改革。

    任何的针对具体软件开发管理问题的解决办法，都是要在软件开发模型的大框架下才能起效果的。我们不可能把瀑布模型中制定计划的方法用在敏捷开发模型下，我们也不能把打牌估算的方式用在瀑布模型中，因为这些具体方法都是在具体的开发模型的框架下，才具备了生存的条件。就像生态系统一样，热带雨林里的鳄鱼，放到沙漠里面，肯定活不下去的。所以如果一个游戏公司连基本的开发模型都没有引入的话，那么就不要考虑变更怎么管理了；就像在真空中任何生物都无法生存一样，在没有开发模型的环境中，任何开发管理方法也都无法取得效果。

    所以，上文提到的这种这种需求（策划）变更管理方法，是要在敏捷开发的大环境下，才能够起作用的，在瀑布、长周期的迭代式开发模型中，都不会有啥正面作用。

迭代周期的选择
    一般的共识是这样的：相对较长的Sprint迭代周期，能够有效的提高开发效率。因为一个Sprint周期中，有些工作是不能被省略的，如Backlog的整理、估算、计划会、评审会与反思会、代码集成、测试、打包等，这些活动一般都要占用不少的时间，越长的Sprint周期，这些活动所占用的时间比例会越少，为开发人员留下的整块开发时间就越多，工作效率也越高。

    而Sprint周期越短，对于需求变化的响应速度就越快。人们对于未来变化的把握能力其实很弱，越短的时间，把握越强，考虑的也越详细，太长时间以后的事情（如2个月以后），则基本没有什么把握能力了。

    Sprint周期的选择，就是开发效率与响应速度之间的一个平衡。

    一般在开发期的游戏，会选择相对较长的Sprint周期，如1-2个月左右，这时候策划相对比较明确，还没有引入玩家与运营反馈，需求变更相对较少，选择相对较长的开发周期能够保证开发期的游戏开发效率，争取尽早达到上线标准。这时候也希望策划团队能够尽可能减少不确定的变更，如果一个功能或玩法没法确认真的比改变前更好，那么就不要贸然提出改动，等到上线之后听到玩家的反馈后再提出，能节省不少工作量。

    而从游戏上线封测开始，Sprint周期就开始逐步缩短，以适应逐渐增多的Bug、调整与变更，在游戏正式运营后，一般都会将Sprint周期控制在1-3周左右，一般都是与游戏的更新周期保持同步。从管理的角度来说，为了适应更短的Sprint周期，很多管理上的规章与流程也要随之相应的简化，以适应高相应速度的要求。

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/yock_zhang/archive/2010/03/03/5343110.aspx