你真的了解Scrum吗？一文总结敏捷管理Scrum

去年11月份进入了一个项目组，这是一个IT开发项目组，发现不少问题：

大家对于项目管理没有概念，工作经常拖延，有个项目已经拖了一年都没有交付。

项目的需求经常变动，导致最后做出来的产品用户不满意。

员工没有紧张感，来一天就做一天工作，反正交不交付不关我的事，大家比较懒散。

进入项目以后，就想着从项目管理角度对于团队进行改造，针对需求变动大，我们决定采用敏捷项目管理，使用scrum框架来管理项目。

1

传统项目管理

1）什么是项目管理

项目管理是项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望的过程。

2）瀑布式开发模式

瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。

这种模式适合于需求明确，文档规范，这样一步一步走下来，能够很好地完成任务。

但是我们的项目特点就是需求变化大，这样不停做，等到最后发现不满足需求，已经来不及了，于是我们需要转向敏捷项目管理。

2

敏捷项目管理

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，在敏捷开发中，项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征 。

敏捷项目管理简化了繁琐的流程和文档管理，主张团队内部的面对面沟通和交流。以 Scrum 为代表，简单、持续集成、不断交付、价值优先、拥抱变化的原则在面对时刻变化的市场经济和不断发展的技术时变得十分友好。

1）敏捷宣言

2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。

这套价值观，通过一份简明扼要的《敏捷宣言》，传递给世界，宣告了敏捷开发运动的开始

第一，个体与互动高于流程和工具

流程和工具虽然重要，特别是在大公司里面，看得特别重，但是他们无法代替有能力的个体已经他们之间的互动产生的能量。

敏捷团队作为一个整体，他们的目标是快速完成项目，这个时候要发挥每个成员的主观能动性。

在工作中，大家一起工作，包括产品、开发、测试、在面对面的沟通交流中建立互信，共同完成每个任务。

第二，工作的软件高于详尽的文档

能够工作的软件比起漂亮的文档更加重要，在敏捷中，小步快跑，不断迭代，发布成果，而不是纠结于完美的设计，详尽的文档。

当然了，也不是完全没有文档，架构设计，原型、交互设计，这些都是必要的文档。

第三，客户合作高于合同谈判

在我们开发过程中，不断变化的需求不能体现到合同上，而与客户的合作，产出符合客户的需求的成果更为重要。

建立可行的合作框架，而不是纠结于一点一点的谈判，这样更有利于与客户建立完善的关系，同时把事情做得更好。

第四，响应变化高于遵循计划

响应变化就是欢迎需求变化，适应客户的需求，在与客户的合作过程中，不断确认需求，不断改变计划成为了计划的一部分。

总体的规划是有的，但是敏捷就是根据需求改变来调整计划，通过一个个迭代，得到用户的成果，同时完成总体规划。

2) 敏捷十二大原则

我们遵循以下选择：

第一，我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。
第二，欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
第三，经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
第四，业务人员和开发人员必须相互合作，项目中的每一天都不例外。
第五，激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
第六，不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
第七，可工作的软件是进度的首要度量标准。
第八，敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
第九，坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
第十，以简洁为本，它是极力减少不必要工作量的艺术。
第十一，最好的架构、需求和设计出自组织团队。
第十二，团队定期地反思如何能提高成效，并依此调整自身的行为表现。

3) 敏捷的优点

第一，拥抱变化，敏捷开发高适应性，更加灵活。

第二，充分利用开发者的个人优势，调动开发者的工作热情，增加产出

第三，管理需求的优先级，更好地响应客户需求

第四，改进项目的可见性，最小化风险 （短的迭代），快速应对市场

第五，以人为本，改进团队精神

第六，简化开发流程，增强软件质量

4）敏捷的挑战

第一，由于项目周期长，不能保证人员不更换，没有文档会造成交接的困难

第二，强烈依赖开发者主动性，对于人员要求更高，否则容易遇到瓶颈

第三，当有多个利益相关者（stakeholder）时难以设定优先级

敏捷管理有很多不同的方式，极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程。下面要介绍的是Scrum。

3

Scrum管理方法

1） Scrum定义

Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。

那什么是Scrum呢？Ken Schwaber and Jeff Sutherland在《Scrum指南》中，对于Scrum是这么定义的：Scrum 是一个轻量的框架，它通过提供针对复杂问题的自适应解决方案来帮助人们、团队和组织创造价值。

Scrum 基于经验主义和精益思维。 经验主义主张知识源自实际经验以及根据当前观察到的事物作出的判断所获得。精益思维减少浪费，专注于根本。

Scrum 的成功应用取决于人们变得更加精通践行并内化 5 项价值观：承诺， 专注， 开放， 尊重和勇气

2）scrum团队

第一， 产品负责人（Product Owner）从业务角度驱动项目，传播产品的明确愿景，并定义其主要特性。Product Owner 的主要职责是确保团队只开发对于组织最重要的 Backlog 条目，在 Iteration 中帮助团队完成自己的工作，不干扰团队成员，并迅速提供团队需要的所有信息

第二，流程管理员（Scrum Master）保护团队不受外界干扰，是团队的领导和推进者，负责提升 Scrum 团队的工作效率，控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化，他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。

第三，开发团队（Scrum Team）主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

团队负责交付产品并对其质量负责，团队与所有提出产品需求的人一起工作，包括客户和最终用户，并共同创建 Product Backlog 。团队按照大家的共识来创建功能设计、测试 Backlog 条目交付产品。

3）Scrum开发流程

这是Scrum开发总流程

第一，我们首先需要确定一个Product Backlog（产品需求列表），这个是由Product Owner负责的。

Product Owner通过与客户的沟通，可以得到产品的需求列表，这个列表每一行是一个用户故事（User story)，包含名称，描述，时间估算，优先级。如果这个时间大于5，可以称为史诗级故事（epic story）

第二，有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 再从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog。

在Spring Backlog还包括技术需求，这个不是由Product Owner来创建，而是由技术经理来创建，这是在完成用户故事的过程中，需要完成的技术需求，例如升级数据库，优化代码等等。

Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）。

第三，Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，更新系统。

每个人更新完个人完成的任务，这样Scrum Master可以根据完成的进度来绘制燃尽图，燃尽图的横轴表示整个Iteration 的总时间，纵轴表示 Iteration 中所有的任务，其单位可以是小时，人天等。一般来说，燃尽图有”Iteration燃尽图”和”Release燃尽图”之分。
Iteration燃尽图可以追踪迭代的进度，如果燃尽图一直是上升状态，或当 Iteration 进行一段时间之后，Iteration 燃尽图上的Y值仍然与 Iteration 刚开始时相差无几，就说明这个 Iteration 中的 Story 过多，要拿掉一些 Story 以保证这个 Iteration 能顺利完成。如果Iteration 燃尽图下降得很快，例如 Iteration 刚过半时Y值已经接近0了，则说明这个 Iteration 分配的任务太少，还要多加一些任务进来。在 Iteration 计划会议上，如果团队对即将要做的任务理解和认识不充分，就很可能导致这两种情况的出现。（锻炼团队人员的自我估算时间）
Release 燃尽图：记录整个Scurm项目的进度，它的横轴表示这个项目的所有Iteration，纵轴表示各个Iteration开始前，尚未完成的工作，它的单位可以是个（Story 的数量），人天等。

第四，当所有Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Sprint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品。

在这个会议上，产品负责人和客户会提出意见，如果是小问题，可以完成修复，否则加入到Product Backlog里面，在下个迭代会议确认是否加入进来做。

最后，把成果发布给用户，这样用户可以使用，提供反馈。

第五，最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

4

写在最后

Scrum 采纳一种迭代和增量的方法来优化对未来的预测性并控制风险。Scrum 让一群共同拥有所有技能和专长的人员参与进来完成工作，并根据需要分享或获得所需技能。

Scrum是一个框架，指导我们从项目发起到发布一系列过程，在框架里面的每一步，用户可以根据自己的需要完善内容，实施它。

参考书目： 《Scrum指南》