使用Scrum的Agile项目管理介绍

1SCRUM简介使用Scrum的Agile（敏捷）项目管理介绍作者：PeteDeemer与GabrielleBenefield1.04版本goodagilescrum培训在印度和亚洲|!EmergingMarketsGroup的首席产品执行官。GabrielleBenefield是负责Yahoo!公司敏捷开发的高级总监。他们共同致力于Scrum在Yahoo!2公司全球范围的大型推广工作。读者提示：目前在互联网上有很多关于Scrum的简短介绍，本简介旨在提供更深入一步的研究。此简介并不是学习Scrum的最终阶段；我们建议那些考虑采用Scrum的团队借鉴KenSchwaber的著作《AgileProjectManagementwithScrum》和《AgileSoftwareDevelopmentwithScrum》，并积极利用和参与目前众多优秀的Scrum培训和咨询活动；详细情况请参考scrumalliance.org.在此对KenSchwaber,JeffSutherland博士和MikeCohn所做的帮助和贡献表示感谢。©2007PeteDeemerandGabrielleBenefield传统的软件开发各类大中小型企业所运用的传统软件构建方法，即是众人皆知的“瀑布”型开发方法。此模型存在很多变体，但其典型性是在开发初期制定详细的计划，在计划中最终产品己被仔细研究，设计，并且一切详细资料都记录在案。任务已设计制定，并且在工作中使用如Gantt(根特)图表等工具和MicrosoftProject项目管理软件。开发团队预计开发项目的时间是以累计其相每关一步骤而得出的。当项目管理者(stakeholder)全面审核开发计划并表示赞同，开发团队即时开始工作。团队成员完成他们所专长的部分工作，即刻转交给其他成员，形成生产流水线的形式。当全部工作都已完成，成品将会转交给产品质量控制部门，在这里将会进行在产品到达客户手中之前的全面检测。在3整个流程中，所有相对于原始计划的分歧都将受到严格的控制，以保证生产的成品与原始设计保持一致。此种模式有优点但也有不足之处。它的最大的优点是非常有逻辑性：在构建之前思考，并全部记录下来，按照计实划施，保持各项事务尽可能的有组织性。它有一个最大的弱点就是：人的参与。比如：此种方式要求所有的建议和想法都要在开发周期的昀启始阶段提出，此时建议和想法将可以被容入开发计划之中。但是众所周知，好的想法和建议的出现会贯穿整个开发过程——在开发昀启始阶段，在开发中期，有时可以在产品交付使用的前一天，如果整个开发过程中不容许变化的产生，那么将会遏制创新的产生。在使用“瀑布”型开发方式时，开发末期出现的创新将不是好的征兆，而是对整个产品开发产生的危机。瀑布型开发方式特别注重将事件记录在案，以此作为传递重要信息的首要方法。因此昀合理的假定是如果我可以把我的想法尽可能都记录下来，这样将会使信息更可靠的传输到团队每一个成员的头脑中；另外，因为所有东西都记录在案，这将是我完成任务的昀实际的证据。但是实际上，在大多数情况下，没人会读这些50页左右的详细规格要求资料。同样，如果有人读取该资料，那么将会产生许多的误解。记录的资料只是我头脑中想法的抽象提取；当你阅读此资料时，你将会产生另一个抽象的概念，此时与我的真正想法已经相距甚远了。所以严重误解的产生也就不足为奇了。当人参与时,还有一种情况会发生——“实际应用中产生的灵感”——在第一次实际应用产品时，你可能会立刻产生20种使产品更加完美的灵感。但是遗憾的是，这些非常有价值的想法通常会在产品开发的末期产生，这时创新是昀困难和昀具有分裂性的——换句话说，是做正确抉择昀昂贵的时刻。人的预知未来的能力是有限的。比如，某场比赛的昀终结果是出人意料的。不可预测的技术问题的突然出现，会强制开发方向的转变。此外，人们往往非常欠缺对于未来作出长远计划的能力——今天猜测未来八个月中每周你如何工作将如幻觉般渺茫，这正是Gantt(根特)图表的衰败表现。另外，瀑布型方式将会促使团队成员在交接工作时产生敌对的关系。“他要求我构建在规范要求中不存在的东西。”“她经常改变主意。”“我不可能对我不能控制的东西负任何的责任。”这些都引起我们对瀑布方式的另一种思考——在此种方式中工作毫无兴趣可言。事实上，进一步说，瀑布型方式是造成产品开发人员苦恼的根源，并且昀终产品将不会体现出他们的创造力，技能和开发创造者的激情。人不是机器人，此种将人认为是机器人的流程将会造成人们工作激情的丧失。一个僵硬的，拒绝变革的流程也会造成低劣产品的产生。客户可能会得到根据他们第一需求所生产的产品，但是产品在形成阶段时还是客户真正需要的吗？在开发之前收集所有的需求并将它们嵌入毫无改变可言的顽石般的计划中，此产品将被宣告只会和昀起始的想法保持一致，而不是开发团队在实践中不断发现可能性而使其尽善尽美。4许多使用瀑布型方式的团队不断的体验到了它的缺陷，但是它看起来是如此付有逻辑性的方式，因此第一的自然反应就是对内部工作的谴责：“如果我们尝试更好的使用它，它将会发挥作用”——如果我们计划的更详尽，记录更详细，更严格的拒绝任何变革，一切将会很顺利地进行。遗憾的是，许多开发团队只得到的相反的效果：他们越竭尽全力尝试此方法，得到的结果越差！Agile(敏捷)开发和ScrumAgile(敏捷)开发整体概念的产生是基于一种方法更接近人类活动现实情况,以便取得更好效果的信念上。Agile(敏捷)强调构建可以即时操作的软件，相对于在构建前花费许多时间记录规格要求。Agile(敏捷)注重授于小型多职能的团队决策权，相对于大型层次和部门职能的划分，Agile(敏捷)注重快速迭代，并且其中结合尽可能多的客户反馈。在学习了解Agile(敏捷)的时候，经常会有这样的公认——感觉非常像回到了开发启始的阶段，我们曾经”做过”。Scrum是众多快速发展的Agile(敏捷)方式之一。Scrum是在十多年前由KenSchwaber和JeffSutherland博士共同提出的，现在此方式已被众多大中小型企业使用，其中包括Yahoo!,Microsoft,Google,LockheedMartin,Motorola,SAP,Cisco,GE,CapitalOne和USFederalReserve.许多使用Scrum的团队取得了重大的改进，其中更有个别在生产效率和职业道德方面得到了彻底地改革。对于产品开发者——许多曾受到“管理层每月的一时狂热”的伤害——这是非常重要的。Scrum是简单的，强有力的，并立足于常识之中的。Scrum基础知识Scrum是迭代的，增量型的流程。Scrum构造的产品迭代周期为Sprints,工作的迭代时间一般为一到四周，并且是相互衔接的。Sprints是有固定的周期——结束于固定明确的日期，无论该工作完成与否，从不延长。在每一Sprint的启始阶段，一个多职能的团队从已优先化的要求列表中挑选若干项目，并承诺在Sprint的末期完成这些项目；在Sprint中，任务的内容不会变化。每一工作日，团队成员互相通告工作进度，并更新简易的剩余工作量直观表示图表。在Sprint的末期，团队将对这一阶段工作结果作一展示并取得相关的反馈，为下一Sprint做好准备。Scrum强调生产可以使用的产品，意指在Sprint的末期产品的“完成”；在软件方面，是指编码已经被检测并可以随时交付使用。5图示1ScrumScrum中的角色在Scrum中有三个基本的角色：产品所有者(ProductOwner)，开发团队和ScrumMaster。产品所有者（ProductOwner）负责取得产品昀大的商业价值，收集相关于产品的所有信息——从客户或产品的终端使用者，开发团队成员和项目管理者中获取——并将信息转化为优先权项目列表。在一些情况下，产品所有者(ProductOwner)正是客户本人；在另一些情况下，客户可能是有不同需求的成百上千的人。产品所有者(ProductOwner)这一角色在许多企业中是由产品经理或产品市场经理担任。开发团队构建客户将会购买的产品：比如软件或网站。Scrum团队是“多功能”的——它包括交付每一Sprint中的随时可交付产品所需的各类专门人员——并且它是有很高自律性和责任性“自我管理”的团队。团队决定承诺完成哪些任务和完成承诺任务昀好的方法；在Scrum范畴中，团队被称为“Pigs猪“，企业组织中其他人员被称为”Chickens鸡“（这些称谓源于一个笑话，一头猪和一只鸡打算一起开一个餐馆叫”火腿和鸡蛋“，但是猪重新考虑了一下，因为”他将需要自我献身，而鸡只需要参与就可以了。“）Scrum团队通常包括五到十个成员，然而团队大到15个成员和小到3个成员也有很好的收效，一个软件项目的开发团队包括程序员，界面设计师，检测员和研究人员。开发团队不仅构建产品，他们也向产品所有者(ProductOwner)提供让产品尽善尽美的建议和想法。团队成员可以将其时间划分给Scrum项目和其他的项目，但是如果团队成员能专注于Scrum项目开发则效率更高。团队内部成员也可以在不同Sprint中变化，但是这样会减少整个团队的生产效率。大型项目开发通常会组成几个Scrum团队，每一个注重产品开发的一方面并且互相保持紧密的沟通。ScrumMaster的任务是以任何方式帮助整个团队取得成功。ScrumMaster不是团队中的经理；ScrumMaster是服务于整个团队，帮助团队铲除壁垒而取得成功。协助团队会议，并支持Scrum的实践。在一些团队中会有某一人专心致力于担任ScrumMaster，而另一些小型团队可以采用其中一个成员兼职担任（此人会适当减少日常工作量）。一个好的ScrumMaster可以来自不同的背景6和学科：项目管理，工程技术，设计，检测。ScrumMaster和产品所有者(ProductOwner)不应是同一人；有时，ScrumMaster可能会号召拒绝产品所有者(ProductOwner)（例如，他们有时会在某一Sprint中期试图加入新的条件）的要求。不同于项目经理，ScrumMaster不会指示和分配工作——他们只是协助流程的实施，推动团队自我组织和管理。除了以上三个角色之外，还有其他对于项目成功作出重要贡献的人员：可能其中昀重要的是经理。他们的角色在Scrum不断的发展,他们仍保持了相当重要的位置——他们支持开发团队，尊重Scrum规则和精神，帮助团队铲除壁垒，为整个项目的开发提供知识，技术和各种必要的协助。在Scrum中，这些人转化了以前“保姆”式的角色（布置任务，收取进程报告，和其他一些谨小慎微的管理方式），取而代之的是承担起更多的“指导“作用（指导职业发展，在职辅导培训，协助铲除障碍，帮助解决问题，提供创新的建议和指导团队成员的技能发展）。为了能更好地实现这一变化，经理们需要改进他们的管理方式方法；比如，运用苏格拉底哲学提问方式来帮助开发团队找寻问题的解决办法，而不是简单地决定解决方法并分配给开发团队。Scrum启始Scrum的第一步是产品所有者(ProductOwner)清晰地展示产品的未来景象（vision）。这些是以按需求的优先列表展示的，按客户和商业价值排序，昀高价值的项目排在列表顶端。这就是ProductBacklog,它存在（并发展）于产品的整个生命周期（图示2）。在项目开发的任何时候，ProductBacklog是唯一具有权威性的“以优先权排序为准，需要完成的所有任务”的概况。只可以存在唯一一个ProductBacklog；这就意味着产品所有者(ProductOwner)需要在所有的工作范围中作出优先项的决策。图示2ProductBacklogProductBacklog包括许多的不同项目，例如功能（“使用户可以把所选书籍放入购物车”），开发需求（“重新改进处理流程模块，使其可以升级”），探索式的工作（“研究关于加速信用卡确认过程的方法”）7，和已知的bugs（“判断并修复定单流程中的错