Scrum 心得体会

我是Scrum 的信徒。

Scrum 敏捷开发 (下文简称Scrum) 被大量的互联网公司采用。根据我所了解，国外的公司都比较认可这种开发模式，国内也越来越多的公司开始尝试Scrum，但是大多数执行效果都不是很好。

我最早工作过的两家公司雅虎北京研发中心和大众点评网都采用Scrum。在这两家公司的让我体验了失败的Scrum 和较为成功的Scrum。其中雅虎北京研发中心的Cooktails IDE 团队Scrum 执行的比较失败，而大众点评网的预约预订团队的Scrum 执行的相对成功。这两次不同的体验，让我对Scrum 有很深的体会：Scrum 被验证是一种非常好的敏捷开发模式，特比适合于互联网这类市场快速变化的公司；但同时，它也是一把双刃剑，你使得好，它可以快速磨合团队，增加团队化学反应，快速提升团队的战斗力和效率；如果使得不好，它将会变成一种非常形式化的条文，不但没有什么帮助，反而会降低开发效率，浪费时间。

接下来，我介绍一下Scrum，以及我的一些体会和观点。

一、What is Scrum?

Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程。

Scrum 敏捷宣言 (代表了Scrum的理念)

1. 个体和互动 高于流程和工具
2. 工作的软件 高于详尽的文档
3. 客户合作 高于合同谈判
4. 响应变化 高于遵循计划

在这个框架中，一个产品的开发过程被划分为多个短的开发周期，一个开发周期称为一个迭代或者一个Sprint，每个Sprint 建议为1~4 周。一般比较常见的Sprint 是2周，我的经验是基本都是2周。之前有团队的Sprint 是1周，从他们的反馈来看，会感觉节奏比较快，会比较累。

在Scrum 中，使用产品Backlog 来管理产品的需求，产品Backlog 是一个按照优先级排序的需求列表，列表条目的通常为用户故事(user story)，你的每一个需求都是在说一个故事。用户故事正确的写法是这样的：As a user, I want to do something, so that I can benifit from it （角色-工作-目标）。举个例子：作为用户，我希望订单页面有评价功能，这样我可以对我的订单进行评价。还可以从其他角色角度来写，比如开发者，产品经理，运营，客服等，代表了他们的需求。

每个Sprint，Scrum 团队从产品Backlog 中挑选最高优先级的需求，在Sprint 中完成这些需求。在每个迭代结束时，Scrum 团队将递交潜在可交付的产品增量。

Scrum 起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。

二、How Scrum?

2.1 Scrum 角色

PO, Product Owner, 产品负责人, 一般对应于产品经理 (Product Manager)

收集、整理、完善需求
确定需求优先级
优化投资回报
跟进项目进展和状态

SM, Scrum Master, 一般是对Scrum 比较了解的成员

把控Scrum 流程，引导团队遵循Scrum 的理论、实践和规则
协调团队内部合作 (Coordinator，协调员)
确保团队高效工作并改进质量
屏蔽外部对团队的干扰 (很重要)

注：SM 不是管理者，不是项目经理。

TM, Team Member, 团队成员，可以是开发，测试，设计等。

跨职能，5-9 个成员
根据自己情况，给出工作承诺
与其他成员合作，完成所承诺的工作任务
向PO 展示工作结果

Scrum 建议团队成员都是跨职能的，用比较通俗的话就是多栈工程师。如果你是java 后端工程师，对前端的工作感兴趣，想学习一些前端的开发，你可以在迭代中认领一些前端开发的工作任务。

跨职能 的团队拥有完成工作所需要的全部技能,不需要依赖团队外部的人。Scrum 团队模式的目的是最大限度地优化适应性、创造性和生产力。

这在短期内会影响团队的工作效率，因为每个人做自己最擅长的事情，肯定是效率最高的。但是从中长期来看，这对团队是有帮助的。一是，团队的成员可以选择自己喜欢的工作，可以激发大家的工作积极性。二是，每次迭代中的各个工作的任务量不会是平衡的，可能一个迭代后端开发多一些，另一个迭代前端开发多一些，这时候，就需要协调前后端的开发，而不需要额外添加人员。这样团队的战斗力就很强大，什么任务都能完成。

2.1+ Scrum 角色+

Scrum 团队是全职能的团队，包含：Product Owner、项目组组长、Scrum Master、设计师、前端工程师、后端工程师、测试工程师等，建议人数为 5-15 人。

Product Owner (PO) 责任：对业务成功负责，与各自业务方沟通明确目标和需求，主要工作有收集完善需求、制定需求优先级、优化投资回报等；

项目组组长职责：对项目组最终目标和产出负责，做任何可以帮助团队达成目标的事情。比如：设定目标，争取团队资源，帮助团队成长，确保产品稳定可靠等；

Scrum Master (SM) 职责：对项目组研发节奏、研发效率负责，帮助团队按照共同约定的 Scrum 原则执行。比如：组织早会、回顾会议、协调处理迭代中的问题等。

Tech Leader (TL) 职责：对研发资源调配、员工成长负责，帮助员工明确其在项目组中的职责，指导员工工作帮助其成长，以及对其进行绩效考核等。

2.2 Scrum 活动

1. 产品Backlog 梳理（ Product Backlog Refinement）
2. Sprint 计划会议（Sprint Planning Meeting）
3. 每日站会（Daily Scrum Meeting）
4. Sprint 评审会议（Sprint Review Meeting）
5. Sprint 回顾会议（Sprint Retrospective Meeting）

产品Backlog梳理由PO 主导。其他活动都是由SM 主导。每次会议都需要限定时间，避免陷入无聊的争论和扯淡，浪费时间降低效率。

2.3 Scrum 一般流程

Product Backlog Refinement (产品Backlog 梳理) 在每个迭代开始之前，PO 需要从各方 (服务方，包括用户，开发，运营，客服等) 收集需求，对需求进行过滤，梳理、完善做成Backlog。并对各个需求按优先级排序，排序的原则的最大化投资回报，然后做成Product Backlog。

Planning Meeting (计划会议) 计划Sprint 里应该做哪些任务，一般从两个方面来确定，一是需求的优先级，另外一个是工作量。确定完任务后，团队成员主动挑选这个迭代承诺完成的任务，成员之间再协商确保任务都被挑选。之后，每个成员需要把任务分解成小任务，可以更好的追踪工作进度。这样就确定了Sprint Backlog。

工作量通过估算点数来确定。点数是一组类似斐波那契数列的集合，有1，2，3，5，8，13，21，40，100。1个点是多少呢？由各个团队来确定的。团队内部确定一个参考值，以此做为参考，来确定其他需求的工作量。比如我在雅虎的团队是以画一个UI 页面为5个点，也是一天的工作量作为参考值。在点评，1个点需要两个小时工作量，一天为3个点工作量作为参考值。(对于评点这个事是有争议的，Scrum 要求按工作的难易程度来评，但是我认为简单的按工作时间来评也是合理的。)

确定需求的工作量，是很主观的事情，谁来决定呢？标准的做法由所有的团队成员共同确定。流程如下：

1. PO 向团队成员讲解需求，大家讨论这个需求，然后每个成员单独评估点数。
2. 如果最高点数和最低点数相差大于一个等级，投最高点的人和投最低点的人需要解释自己给出点数的原因。然后，所有人再投一次。
3. 直到点数差别小于等于一个等级时，取较大的点数。

Daily Meeting (每日站会) 每天早上(刚上班)或者傍晚(下班前)[建议在每天早上开站会，对于程序员来说，晚上也是开发时间]，团队成员站成一团，每个成员说三件事:

从上次站会到现在做了什么？
现在到下次站会将要做什么？
什么事阻碍了进展？

SM 需要根据每个成员的工作情况，了解项目进度，评估项目风险，比如项目进度是否延误，哪些任务的工作量评估是否不准确，需要调整。同时，需要帮忙成员协调，解决遇到的问题。

团队一般会有任务板，任务板上有这个Sprint 所有需要完成的任务便签，以及每个任务当前的状态，如下图所示。每一个迭代的过程，就是便签纸从左往右蠕动的过程。每日站会需要更新任务的点数，其正确的做法是预估这个任务还剩多少点，而不是直接减去做了多少点。

同时，使用燃尽图 (burn down)的 工作量/时间 的曲线，来观察团队的工作情况，是否偏离预期，是否需要做出调整等。

站着的目的是，表明这是一个简短的会议，不会花太多时间。一般建议不超过15 分钟，大家的时间都是很宝贵的。

Review Metting (评审会议) 主要是向PO 和需求方(或者利益相关方, stockholder)展示工作成果。同时PO 验收相应的工作，可能对部分工作提出一些修改建议，让团队做相应的修改。这里最好能让需求方参与，比如这个一个运营的需求，运营需要参加这个评审会议。

检验做了什么
围绕产品的检验和适应
建立与PO和利益相关人的信任
获得PO 和利益相关人的反馈

definition of DONE (完成的定义): 完成上线前的所有工作。

Retrospective Meeting (回顾会议) 主要回顾这个迭代的工作，每个成员表达本迭代哪些方面做得比较好，哪些方面需要改进。并挑出1-2个问题，大家讨论并给出解决方案，由SM 跟进这些问题的改进情况。我个人认为，这个会议非常重要。因为这是一个总结的会议，团队从经历中学习并交流改进，扬长避短，才能不断的提高。这也是Scrum 很重要的理念。

检验“怎么做的”
围绕过程的检验和适应
从经历中学习并改进交流
帮助团队关注过程改进

在点评的时候，这个会议很欢乐，经常就变成了吐槽的时间，而且经常是吐槽PO，关键PO 经常诚恳的接受吐槽。

三、Why Scrum?

软件开发是一个复杂的活动， 在软件产品开发的过程中不仅存在着需求的不确定性 (产品的需求是经常会变的，你懂得)，也存在着技术的不确定性，再加上参与软件开发的主体通常是由多人组成的软件开发团队，加上人的因素，就让整个软件开发的活动变得非常复杂。如下图所示，软件开发活动通常处在下图的很复杂的区域。

如果我们期望解决的问题比较复杂，并且存在着较大的不确定性的时候，我们需要使用经验性过程。经验性过程的特点是过程是不能够完全预先定义好，结果是不可预知的，生产过程是不可重复的。比如研究一项新技术，下一盘棋，踢一场球赛，在过程运行当中，我们需要通过不断的获得真实的反馈，然后进行适应和调整，使得过程能够产出我们需要的结果。

Scrum以经验性过程控制理论做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。

Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下：

第一：透明性（Transparency）。透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。

第二：检验（Inspection）。开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。

第三：适应（Adaptation）。如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。

天下武功，唯快不破。现在的公司，特别是互联网公司竞争非常激烈，都要求迅速的适应市场的变化，抢占市场的先机。当发现市场的机会或者用户的痛点时，需要快速构建原型，推向市场验证，然后迅速的优化和调整。Scrum 可以帮助我们快速迭代，快速验证，快速调整，不断优化提高。《精益创业》这本书中比较详细的阐述这个观点。

四、My Opinion

4.1 我的经验

为什么我在的雅虎团队执行Scrum 不是很成功？

SM 由Project Manager 兼任，工作方式其实还是原来的项目管理模式。而且SM 点子很多，很多需求是他直接提的，没有进入Product Backlog。

Scrum 的执行过程流于表面，没有足够的training。当时参与相应的会议的时候，很像是走过场。Sprint Review 经常失败，各种各样的问题导致演示效果很不理想。有些可能为了节约时间，省去了很多环节，其实不算严格意义上的Scrum 了。没有真正的感受到Scrum 带来什么不一样，也没有感受到团队的交流合作。做一件事件，如果只知其然，而不知其所以然，这样的收获是非常有限。

为什么我在的点评团队执行的比较成功？

预订团队的SM 工作到位，流程把握比较好，而且还不断的学习Scrum。团队成员对Scrum 的认可度比较高。团队各个成员间相互信任，团队气氛不错。

据我所知，点评内部大多数Scrum 团队都执行的不算成功。很多团队都放弃了Scrum，走回原来的模式。改变团队固有的观念是很难的事情，要想成功，得看有多大的决心去执行Scrum。预订团队的老大，为之付出了很大的努力。

1. 说服团成员接受Scrum。因为很多资深的员工，感觉Scrum 的很多活动浪费时间，降低工作效率。而且Scrum 强调团队，弱化了单个员工的贡献。(而工作不久的员工对这个接受度相对高一些，可塑造性比较强，这也是很多公司喜欢应届毕业生的原因！)
2. 顶住Scrum 教练的压力，不硬推行Scrum 中的所有理念。选择适合的团队的工作方式，并做适当的调整来让团队更好的适应。

我问过他，Scrum 是提高了效率，还是降低了效率。他的回答是，没有显著的提高效率，但是对于他来说，解放了他的时间，他不需要花很大的精力来管理团队，跟进开发进度。

这也是我认为其Scrum 比较成功，但是非常出色的原因。团队没有不断强大，我认为还处于“破”的初级阶段。(Scrum 三个阶段，守、破、离)

4.2 适用/不适合 的场景

适用的场景 快速变化，强调团队合作，有创造性的工作。

不适用的场景 工作流程明确，不需要改变，喜欢单兵作战，不愿意团队合作。

4.3 Scrum 成功要点

一个合格的SM 是Scrum 成功的关键。特别是对于一个相对初级的Scrum 团队来说，需要SM 引导整个团队遵循Scrum 规范，执行Scrum 流程，灌输Scrum 的理念。

有足够的taining 让每个成员知道其所以然。并使每个人接受这种开发模式。不仅限于分享和培训，更重要的是在迭代过程中，让成员真正的理解Scrum。

产品Backlog 足够细化 产品Backlog 需要清晰明了，细化到每一个迭代的需求都是相对独立的，而不是强依赖。

权衡 (trade off) 不能强制要求使用Scrum 中的所有元素，可以根据团队的实际情况和实践的效果，有选择性的选取。

保持迭代节奏 有节奏的执行scrum，迭代过程不要被过多的突发需求打断。比如，临时修改需求，修改bug等。建议每个迭代安排特定时间完成非计划内的需求。

强调团队 成员之间地位平等，由团队来自我管理，团队来做决策。否则很容易又走会项目经理管理的老路了。

五、Reference

[1] Scrum MASTER 认证课程 – 吕毅

[2] http://www.Scrumcn.com/agile/Scrum-knowledge-library/Scrum.html