Scrum 是由 Ken Schwaber 和 Jeff Sutherland 在 1990 年创建的主流敏捷技术。进入新世纪，互联网带来的巨变使敏捷方法受到了更多开发团队的青睐，而其中Scrum以其扩展性、门槛低、名字和术语更容易被项目经理接受等因素，逐渐成为最受欢迎的敏捷流派，超过 50%以上的项目在运用这项方法。与其说Scrum是一种方法，不如将其称之为一个框架更为贴切，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付可能最高价值的产品。自上世纪 90 年代初以来，它就已经被应用于管理复杂产品的工作上。Scrum 并不是一种过程、技术或决定性方法。倒不如说，它是一个框架，在此框架中您可以使用各种不同的过程和技术。Scrum 让你的产品管理和工作技术的相对成效更加清晰地显现出来，以便你可以持续改进产品、团队和工作环境。

一、起源

Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作，原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。争球双方各有8个队员参与，各方出3名前锋队员，并肩各站成一横排，面对面躬身互相顶肩，中间形成一条通道，其他前锋队员分别站在后面，后排队员用肩顶住前锋队员的臀部，组成3、2、3或3、4、1阵形。然后，由犯规队的对方队员在对阵一侧1码外，用双手低手将球抛入通道，不得有利于本队。当球抛入通道时，前排的3对前锋队员互相抗挤，争相踢球给本方前卫或后卫队员，前卫和后卫队员必须等候前锋将球踢回后，方可移动。把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的，而Scrum就是这样的一个开发流程。

二、发展

1986 Scrum这个词汇首次应用于产品开发。

1986年，竹内弘高和野中郁次郎在New New Product Development Game文章首次提到将Scrum应用与产品开发，他们指出：传统的“接力式”的开发模式已经不能满足快速灵活的市场需求，而整体或“橄榄球式”的方法——团队作为一个整体前进，在团队的内部传球并保持前进，这也许可以更好的满足当前激烈的市场竞争。

1993年Jeff Sutherland首次将Scrum用于软件开发。敏捷思想深受日本工业界最佳实践的影响，尤其是丰田和本田公司推行的精益原则，以及竹内弘高和野中郁次郎开发的知识管理策略。受到以上思想的影响，以及对世界范围内软件项目的研究，Jeff Sutherland在1993年首次在Easel公司定义了用于了软件开发行业的Scrum流程，并开始实施。

1995年Jeff Sutherland和Ken Schwaber规范化了Scrum框架，并在OOPSLA 95上公开发布。

2001年敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。

2001年，Ken Schwaber和Mike Beedle推出第一本Scrum书籍《Scrum敏捷软件开发》。

2002年Ken Schwaber 和Mike Cohn共同创办了Scrum联盟。虽然Scrum最初只应用于软件开发，但是今天Scrum的影响已经远远超出软件开发，成为零售、军事、风险投资甚至学校里完成各种任务的创新方法，也被用于开发金融产品，互联网产品，以及医药产品。现在Scrum通常被认为是一种用于开发任何产品或管理人和工作的迭代式的，增量的过程。

Scrum 流行的原因：

• Scrum 提供简单和可证明的结果
• 它包含其他敏捷工程技术
• 它强调小型团队和团队授权
• 欢迎需求的变更
• 它允许单一来源的优先项目工作开展
• Scrum 会议包括日常状态会议
• 提供团队在冲刺阶段一个潜在的可交付增量承诺

Scrum 三大支柱：

• 透明性 Transparency：
• 过程或项目的各个方面必须是对结果负责任的，透明的；
• 运用信息发射源，让这些关键信息，如产品待办事项列表、冲刺待办事项、障碍、风险和项目进展对所有的利益相关者是透明的。

检视 Inspection：

• 团队根据项目目标定期检查他们的绩效和进展；
• 他们不断寻找问题和计划的偏离。

适应Adaptation：

• 基于观察期间的检查，采取必要的变更流程，以避免问题再次发生，提高项目交付成功率。

三、Scrum的3-3-5-5

从整体上来讲，SCRUM这个框架里面包含了这几个核心的要素，就是我们说的3355：

三个角色：SM、PO、开发团队（自然包括了我们的开发人员和QA）。
三个工件：产品待办列表Product Backlog、Sprint 待办列表Sprint Backlog、产品增量。
五个仪式：计划会、sprint评审会、回顾会、每日立会、Product Backlog待办事项梳理。
五个价值观：公开、专注、勇气、承诺、尊重。

在具体实施流程之前需要先了解一下什么是Sprint：
Sprint是短距离赛跑的意思，这里面指的是一次迭代，其长度(持续时间)为一个月或更短的限时，这段时间内构建一个“完成”、可用的和潜在可发布的产品增量，也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。在整个开发过程期间，Sprint的长度保持一致。前一个 Sprint 结束后，下一个新的Sprint紧接着立即开始。

将Sprint的时间长度限制在一个月的原因是，如果Sprint太长的话，对于构建事物本身的定义可能会改变，复杂度也可能增加，随之而来的还有风险的变化。

如何进行Scrum开发？
1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；

2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；

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

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

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

6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；

7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Sprint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

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

四、“完成”的定义ＤoＤ

一个迭代做完后，团队要进行验收，来决定本个迭代是否完成。但每个团队对于是否完成无法达成统一，有的认为编码完成，就表示任务完成了；有的认为还需要简单自测一下，确保功能可以正常使用；还有的认为需要把自动化用例写完并测试通过才算完成。

为了避免这个问题，在敏捷软件开发中，常用Definition of Done“完成的定义”来表示工作是否已完成，不同的活动有不同的完成定义。首先要知道，所有的DoD都不是一成不变的，在随着时间的推移、经验的积累、成员的变更、项目的变更，我们的DoD也会有很大的不同，所以，我们也需要定期地检查和改进。

有了上面的思想准备，我们再来看下面的DoD定义，就会觉得并没有那么难了。

1、迭代DoD
最典型的是迭代DoD，这也是最初DoD应用的地方。常见的一些规则有：

• 所有代码通过静态检测，严重问题都已修改
• 所有新增代码得到人工评审
• 所有完成的用户故事都有对应的测试用例
• 测试用例都已执行
• 所有完成的用户故事得到Product Owner的验证

2、发布DoD
对于发布，一般就有更加严格的要求，发布DoD的典型条款有：

• 完成发布规划所要求的重点需求
• 至少通过一次全量回归测试
• 修复所有等级为1、2的缺陷，3、4级缺陷不超过20个

3、版本DoD
版本DoD就是针对每个版本上线前后的一些规则，比如：

• 产品文档已全部更新
• 代码已部署到产品服务器上
• 运维在验收测试环境上冒烟通过
• 原始需求提交人对功能已经验收通过
• 对运维、市场、客服的新功能培训已完成

4、每日DoD
其他典型的DoD有每日DoD，典型条款有：搭建每日构建环境，晚上自动静态代码检查、编译、部署和测试，每日修复前一日构建和测试发现的缺陷和问题。

• 下班前必须检入当天编写的代码，check in的backlog要填写清晰
• 当天的代码必须在当天或者第2天邀请同伴进行代码评审
• 检入的功能代码必须要有对应的单元测试（严格采用TDD）
• 每天晚上触发静态代码检查、自动化回归测试
• 当天持续集成、构建环境中的问题，请当天解决

5、用户故事DoD
还有针对用户故事（或者用例）的DoD，比如：

• 用户故事最终的描述符合INVEST
• 用户故事得到测试用例的对应覆盖
• 用户故事得到对应的自动化测试用例
• 用户故事得到PO试用并初步认可

当测试集比较大的时候，无法在1天之内完成测试，可以开展每周全量回归自动化测试，这样就有每周DoD ，典型条款有：

• 上上周发现的缺陷是否解决
• 上周新增功能的自动化测试是否加入到每周测试集。

Tips：DoD必须是团队在项目启动时共同讨论出来的，团队愿意共同遵守的原则，一旦确定，团队就应共同遵守。

DoD是对软件有价值的活动的清单
DoD是一个简单的清单，包含了一系列的活动。例如：编码，加注释，单元测试，集成测试，发行声明，设计文档等等。所有这些活动都能够给产品带来实际的价值。使用DoD，可以让团队集中在那些必须完成的事情上，同时让那些无用的，仅仅使软件开发变得复杂的活动被消除掉。

DoD是团队成员的主要状态参考依据
对于迭代最简单形式的汇报就只有一句话：“这个feature完成了”。毕竟，一个feature或者一个product Backlog Item的状态只有两种：完成或未完成 。DoD是对“feature完成了”这句话的最佳补充。使用DoD作为参考标准，团队成员可以迅速有效地让其他团队成员或PO了解状态。

DoD不是不变的
DoD随着时间会改变。组织的帮助和团队能力的增加可以移除掉更多障碍，使得更多的活动可以包含到sprint或者feature的DoD中来。

DoD是一个可以被审视的列表
feature/用户故事在sprint plan meeting和sprint中都可以被拆分成task。DoD可以用来衡量是不是所有的主要工作都被计划在内的（剩余的时间）。而且，在一个feature或者sprint结束的时候，DoD可以用来考查是不是所有的必须的增值活动都已经完成了。

必须引起注意的是，DoD本身也是存在缺陷的。
并不是所有的增值活动都可以应用到每一个feature上面，而DoD本身是一个大而全的检查事项的审核制度。团队需要基于一个feature来审视每项增值活动是否适用于这个feature。

比如说，追求用户体验对于web服务这样的feature来说可以加分，但是对于其他的一些feature来说就是不必要的了。

最后需要注意的是，对于验收标准，并不一定是由Product owner决定，要根据显示情况而定， 每个团队都要根据自己的情况选择合适的DoD原则。

文章最后附上一个7分钟的视频链接，初步了解“怎么进行SCRUM”：https://www.bilibili.com/video/av21945150/

Scrum