此页面上的内容需要较新版本的 Adobe Flash Player。
最新开发文章
最新信息推荐
上市公司专栏
实时股价每分更新
纳斯达克（美元）（市值：亿美元）
综指：　涨跌幅：
恒生指数（港币）（市值：亿港币）
综指：　涨跌幅：
综指：　涨跌幅：
Scrum的中国式生存
作者：青猫来源：游戏创造02-24-2010
　　Scrum，这只敏捷家族中的生力军，现在正被越来越多的人认识并且接受。在游戏开发领域中，近年来国内的许多企业也开始尝试采用Scrum进行游戏开发。Scrum这种强调频繁交付紧密沟通的开发方式似乎证明了比它的前辈们更适合游戏开发领域。但正如人月神话中的那句老话“No silver bullet”。那么对于如今国内占主流的大型多人在线游戏（MMO）开发领域而言，Scrum是否就是那枚传说中的银弹，一经发射，就能让摆在你面前的所有问题都瞬间灰飞烟灭？我们在具体的执行层面又应该怎么去控制和管理它呢？笔者希望以下的文字能帮助你解答以上两个问题。
　　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对长期进度缺乏控制，以及文档管理缺失的一些劣势，从而发挥其在需求管理，针对性解决问题上的优势，更好的解决我们在开发过程中可能会遇到的问题。
相关新闻：
相关专题：
<button style="border:2px solid #background-color:#margin-right:10" onclick='javascript:var _title=document.var _url=document.location.if( document.all ) {var _text=_title+" - "+ _clipboardData.setData("Text",_text);this.innerHTML="已经复制成功，请用 Ctrl+V 粘贴";}'>复制本文地址推荐给朋友
收藏这篇文章创始人/Scrum
JeffSutherlandJeff Sutherland的第一份工作居然是美国空军战斗机飞行员，还曾于1967年获得了“壮志凌云”称号，完成过100次飞越北部越南的作战任务。服役后期，他到斯坦福大学拿下统计学硕士学位，并在美国空军学院教授数学统计Jeff SutherlandKenSchwaberKen Schwaber最初的职业也很特别——商船经理。在随后40多年开发生涯的前10年中，他曾经编写过操作系统，搞过嵌入式，为IBM大型机开发系统软件；先后在芝加哥大学、伊利诺伊理工学院、王安公司实验室工作，并逐渐展现出在软件开发方法上的天赋。在CASE工具和结构化方法热门的时候，他自己创办了ADM公司，从事软件开发方法培训服务。期间，公司开发了软件方法自动化工具MATE，用来生成各种软件流程所需的模板、计划等，生意很好。合作经历Sutherland和Schwaber相识于1980年代早期。1987年，两人开始合作。一天，Sutherland问Schwaber：“你们开发MATE工具都用了现在流行的哪一种方法？”“当然什么都没用，”Schwaber回答，“要不然公司早就完蛋了。”他们意识到问题的严重性，开始与开发者交谈，研究新方法。1993年，Sutherland读到了两位日本管理教授竹内弘高和野中郁次郎介绍制造业里出现的新的产品开发方法Rugby（橄榄球）的文章。这种方法的特点是整个流程都由一个高性能、跨功能的团队执行到底。他受到启发，结合自己多年的经验，与Easel公司的John Scumniotales和Jeff McKenna一起开发了一套方法，取名为Scrum（来源于橄榄球术语，不是缩写）。而Schwaber则从杜邦公司一位化工过程控制专家那里取经，意识到项目分为两种：确定性项目，一切都已经确定，可以自动化生产流程；实验性项目，充满不确定性，哪怕一点微小的变化也会牵一发而动全身，因此只能用各种仪表不断监控，随时做出调整——这就是每日站会的由来。两人在一个IBM项目合作，并做了更详尽的研究，Scrum诞生了。1995年OOPSLA大会上他们第一次向世人介绍了Scrum。可当时，两个人的公司都还在做千年虫和各种重型开发方法咨询方面的业务呢。进入新世纪，互联网带来的巨变使敏捷方法受到了更多开发团队的青睐，而其中Scrum以其扩展性、门槛低、名字和术语更容易被项目经理接受等因素，逐渐成为最受欢迎的敏捷流派。而推出CSM等系列认证，虽然争议颇大，但客观上对Scrum扩大影响力起到了重要作用。今天，Scrum的影响已经远远超出软件开发，成为零售、军事、风险投资甚至学校里完成各种任务的创新方法，正在改变着世界。
特性/Scrum
Scrum过程Scrum是一个包括了一系列的实践和预定义角色的过程骨架（是一种流程、计划、模式，用于有效率地开发软件）。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。在每一次冲刺（一个15到30 天周期 ，长度由开发团队决定），开发团队创建可用的（可以随时推出）软件的一个增量。每一个冲刺所要实现的特性来自产品订单（product backlog，我觉得翻译成“产品目标”更恰当）， 产品订单（产品目标）是指按照优先级排列的需要完成的工作的概要的需求（目标）。哪些订单项（目标项目）会被加入一次冲刺，由冲刺计划会议决定。 在会议中，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。 在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog），这意味着在一个冲刺中需求是被冻结的。管理Scrum过程有很多实施方法，从白板上的即时贴到软件包。Scrum最大的好处是它非常容易学习，而且应用Scrum不需要太多的投入。区别之一： 迭代长度的不同XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.区别之二: 在迭代中, 是否允许修改需求XP在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需求将其替换， 替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队受到干扰区别之三: 在迭代中，User Story是否严格按照优先级别来实现XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活， 可以不按照优先级别来做，Scrum这样处理的理由是： 如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。 另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10.区别之四:软件的实施过程中，是否采用严格的工程方法，保证进度或者质量Scrum没有对软件的整个实施过程开出工程实践的处方。要求开发者自觉保证，但XP对整个流程方法定义非常严格，规定需要采用TDD, 自动测试， 结对编程，简单设计，重构等约束团队的行为。“猪”角色猪是全身投入项目和Scrum过程的人； they are the ones with "their bacon on the line."产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写用户故事，排出优先级，并放入产品订单。Scrum主管（或促进者）Scrum主管促进Scrum过程，他的主要工作是去除那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导（由于他们是自我组织的），而是负责屏蔽外界对开发团队的干扰。Scrum主管确保Scrum过程按照初衷使用。Scrum主管是规则的执行者。开发团队负责交付产品的团队。由5至9名具有跨职能技能的人（设计者，开发者等）组成的小团队完成实际的开发工作。。“鸡”角色鸡角色并不是实际Scrum过程的一部分，但是必须考虑他们。敏捷方法的一个重要方面是使得用户和利益相关者参与到过程中的时间。参与每一个冲刺的评审和计划，并提供反馈对于这些人来说是非常重要的。用户软件是为了某些人而创建！就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？”利益所有者（客户，提供商）影响项目成功的人，只直接参与冲刺评审过程。经理为产品开发团体架起环境的那个人。
会议/Scrum
在冲刺中，每一天都会举行项目状况会议，被称为“scrum”或“每日站立会议”。每日站立会议有一些具体的指导原则：会议准时开始。对于迟到者团队常常会制定惩罚措施（例如罚款，做俯卧撑，在脖子上挂橡胶鸡玩具）欢迎所有人参加，但只有"猪"可以发言。不论团队规模大小，会议被限制在15分钟。所有出席者都应站立。（有助于保持会议简短）会议应在固定地点和每天的同一时间举行。在会议上，每个团队成员需要回答三个问题：今天你完成了哪些工作？明天你打算做什么？完成你的目标是否存在什么障碍？（Scrum主管需要记下这些障碍）每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在4小时。Scrum提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范（disciplines），这些有助于创造自我组织的团队。Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。同样，Scrum采用了经验方法– 承认问题无法完全理解或定义，而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。
文档/Scrum
产品订单产品订单（product backlog）是整个项目的概要文档。产品订单包括所有所需特性的粗略的描述。产品订单是关于将要创建的什么产品。产品订单是开放的，每个人都可以编辑。产品订单包括粗略的估算，通常以天为单位。估算将帮助产品负责人衡量时间表和优先级（例如，如果"增加拼写检查"特性的估计需要花3天或3个月，将影响产品负责人对该特性的渴望）.冲刺订单冲刺订单（sprint backlog）是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。任务被分解为以小时为单位，没有任务可以超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。燃尽图燃尽图（burn down chart）是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目。不要把燃尽图与挣值图相混淆。燃尽图可以使'冲刺(sprint)'平稳的复盖大部分的迭代周期，且使项目仍然在计划周期内。
项目管理/Scrum
以下是一些Scrum的通用实践：客户成为开发团队中的一部分。（例如客户肯定对开发的结果真正感兴趣。）和所有其他形式的敏捷软件过程一样，Scrum有频繁的包含可以工作的功能的中间可交付成果。这使得客户可以更早的得到可以工作的软件，同时使得项目可以变更项目需求以适应不断变化的需求。频繁的风险和缓解计划是由开发团队自己制定。– 在每一个阶段根据承诺进行风险缓解，监测和管理（风险分析）。计划和模块开发的透明 – 让每一个人知道谁负责什么，以及什么时候完成。频繁的进行所有相关人员会议，以跟踪项目进展 – 平衡的（发布，客户，员工，过程）仪表板更新 – 所有相关人员的变更 – 你必须拥有预警机制，例如提前了解可能的延迟或偏差。没有问题会被藏在地毯下。认识到或说出任何没有预见到的问题并不会受到惩罚。在工作场所和工作时间内必须全身心投入。– 完成更多的工作并不意味着需要工作更长时间。
其他领域/Scrum
虽然Scrum最初只应用于软件开发，它也可以被成功地应用于其他产业。现在Scrum通常被认为是一种用于开发任何产品或管理人和工作的迭代式的，增量的过程。用于产品开发将Scrum应用于产品开发是在《"T新新产品开发游戏"》（哈佛商业评论 6, 1986年）第一次提出，之后野中郁次郎和竹内弘高合着的《"创造知识的企业"》（牛津大学出版社，1995年）进行了详细的阐述。今天Scrum被用于开发金融产品，互联网产品，以及医药产品。项目管理方法由于市场营销通常以项目的方式运作，许多一般项目管理的原则应用在市场营销上。市场营销也可以像项目管理技术那样进行优化。以Scrum方法进行市场营销被认为有助于克服市场营销经理们所遇到的问题。短时和固定的会议对于小的市场营销团队来说很重要，这是因为团队的每一个成员都可以了解其他人在做些什么，以及整个团队在朝着什么方向前进。Scrum在市场营销中应用可以：在早期发现可能的问题，可以更快地，最小损失地应对问题。 根据Scrum的主要原则 “没有问题被扫入地毯下”，Scrum鼓励每一个团队成员描述他所遇到的困难，而这个困难可能会对整个团队的工作造成影响。降低财务风险。 在每一个冲刺周期的开始，企业所有者可以不付出任何代价的改变任何市场营销的因素：包括增加投资以夸大顾客数量，减少投资直至未知风险被减轻，或用于支持其他活动。使得市场营销计划更灵活。采用冲刺的短期市场营销计划可以更加有效。如果一种促销方法在冲刺过程中显示无效，市场营销经理有机会将其换成另一种促销方法。向每一个团队成员说明每一个小的，但重要的任务的交付时间也变得更容易。使得客户以不同的方式参与。
项目管理软件/Scrum
禅道项目管理软件，也称ZenTaoPMS，是为了解决众多企业在管理过程中出现的混乱，无序的现象，开发出来的一套项目管理软件。它集产品管理、项目管理、测试管理于一身，同时包含事务管理、组织管理等诸多功能，是中小型企业项目管理的最佳选择！ZenTaoPMS基于国际流行的敏捷项目管理方式——Scrum，同时也融合了PMP中的很多概念，完美地体现了Scrum中迭代开发的精髓，很好地融合了燃尽图的概念。ZenTaoPMS基于LGPL协议，企业或者个人都可以免费获取禅道项目管理软件的源代码并安装使用，并可以结合自己的实际需要进行修改。禅道在遵循SCRUM管理方式基础上，又融入了国内研发现状的很多需求，比如bug管理，测试用例管理，发布管理，文档管理等。因此禅道不仅仅是一款scrum敏捷项目管理工具，更是一款完备的项目管理软件。基于scrum，又不局限于scrum。
&|&相关影像
互动百科的词条（含所附图片）系由网友上传，如果涉嫌侵权，请与客服联系，我们将按照法律之相关规定及时进行处理。未经许可，禁止商业网站等复制、抓取本站内容；合理使用者，请注明来源于www.baike.com。
登录后使用互动百科的服务，将会得到个性化的提示和帮助，还有机会和专业认证智愿者沟通。
此词条还可添加&
编辑次数：10次
参与编辑人数：10位
最近更新时间： 03:50:17
贡献光荣榜
扫码下载APP