Scrum: 最为广泛使用的敏捷开发方式

Posted 2021-04-25 技术大V

文章已提请相应维权机构保护，未经许可严禁转载，否则将承担一切相应后果。

开发模式演进史(三)

在上一篇中，我们介绍了由《敏捷软件开发宣言》带来的敏捷开发。敏捷(Agile)主要是价值观和指导思想，比如宣言中所提到的四大价值观，和12项原则。然而在认同敏捷思想的技术人员中，如何用具体的做法，来践行这些价值观和原则，则有不同的方法论，分为各式各样的流派。今天我们就来介绍，其中最常用的方法--Scrum.

和早先的瀑布开发模式一样。事实上Scrum也是最早来源于传统行业，然后被引入到到软件开发管理之中的。Scrum的方式，最早由两位日裔教授，哈佛商学院的竹内弘高和一桥大学的野中郁次郎提出，发表在著名的《哈佛商业评论》上。这种方式本来用于在汽车，复印机和打印机等行业的商品生产中，称为橄榄球方式。因为两位教授认为，这些行业的生产工作，都是由多职能团队在多个互有重叠的阶段内完成的，正如在橄榄球比赛中，一个团队既要作为一个整体坚持到底地战斗，又要为了规避对手的逼抢把球传来传去。Scrum这个词的本意，是指在橄榄球类运动中，死球之后，双方队员相向列阵，争夺球的控制权的环节，这就是Scrum 名称的由来。

橄榄球运动中的Scrum,双方队员激烈拼抢，争夺球的控制权。

Scrum充分认同敏捷思想中提出软件开发的不可预测性，这种不可预测性来自于两个方面：没有预料到的技术挑战和总是变来变去的客户需求。为了贯彻敏捷思想中小步快跑，逐渐迭代的思想，Scrum把任务和时间都作了切分。

Scrum把软件开发的过程从时间上分为不同的Sprint(冲刺)，每个Sprint的时间可以是1到4周，通常是用2周。

Scrum把要开发的软件分为一个个具体的的功能(User Story),放在产品待办列表Backlog里面。Backlog里面所有的功能加起来，就是这个软件蓝图中的理想状态。每个User Story被给定了相应的优先级，这样便于决定先做什么后做什么。然而，Backlog里面的User Story并不是恒定的，而是随着用户的需求在不断的动态变化。用户提出一个新需求，就有相应的User Story被加进来。很多刚开始认为高优先级的任务。可能随着时间的推移被降为低优先级。有些功能一再被拖后。到最后已经不需要了。所以很多时候很多旧的或无效的User Story会积压在Backlog里，需要定期对其审查修订，进行清理或重定优先级。

Scrum的三种角色

Scrum把参与者分为三种角色：产品拥有者，开发团队，Scrum Master

产品负责人(Product Owner,简称PO)

PO代表着来自客户的声音，也是客户与开发团队之间的桥梁。他负责将客户的具体需求变成一个个User Story放到Backlog里，根据客户当前需要的紧迫程度不断更新优先级，管理Backlog。他既需要向客户通报项目的进度，展示开发团队做出的半成品以收集反馈和建议，也需要代表开发团队，管理客户的期望，在客户面前解释为什么某些功能不能实现或需要花费特别长的时间。PO的主要职责之一是沟通，所以对交流和语言能力有着很高要求。很多时候，PO由项目经理(Project Manager)担任。

开发团队

即软件开发人员，产品的生产者，包括但不限于软件工程师，因为这其中还可能包括美工、数据科学家、测试QA、内容提供者等职能人员。在Scrum里，一个团队一般保持在九人以下。Scrum对开发团队给予充分信任，让他们自主管理，自我激励。同时Scrum淡化了title职级的概念，成员之间是平等的，鼓励大家互相协商作出团队决定，让每个人发挥出最大的潜力。

Scrum Master

Scrum Master是Scrum的促进者，他主要有两个职责：1.帮助开发团队扫清产品交付中的障碍，让开发团队能集中精力在生产上。2.确保开发团队遵循了正确的Scrum流程。Scrum Master不一定在职级上是管理者，而是一种相应的服务型领导。笔者印象最深的是一个Scrum Master对开发团队说过的话：“我就是你们的锤子，你们碰上了什么阻碍就交给我，让我去砸碎它。”这是一个很形象的比喻。

一个完整的Sprint和四大会议

以前有一种提法，说Scrum是“三种角色，四大会议”，我们在前面已经介绍了三种角色。现在让我们来看一下所谓的四大会议以及一个完整的Sprint流程。

Sprint计划会(Sprint planning)

Sprint计划会在一个Sprint的开始召开，PO、开发团队和SCRUM Master聚在一起，根据客户需求从Backlog里选出当前最急需完成的任务，开发团队对每个任务进行评估和讨论，得出一个所需时间的估算，再看这个估算能不能在这个Sprint里完成，如果不能的话，可能会把这个任务扔回Backlog里下个Sprint再说，或者把这个任务拆成几个小片，这个Sprint只完成一部分。在计划会结束后，这个Sprint所需完成的任务和每个任务的耗时估算就确定了。

每日站会 (Daily Scrum或Daily Standup)

每天早上(其实也可以是中午或下午，并无限制), 整个的开发团队和SCRUM Master聚到一起，大家站成一个圈，每个人轮流发言，汇报三件事：

1. 昨天我做了什么？

2. 今天我要做什么？

3. 当前的任务遇到了什么阻碍和挑战？

   
   

通过这样的每日简报，团队里每个人都会对当前项目进度有一个大致的了解。Scrum Master更可借此机会了解到当前的阻碍和挑战。帮助团队扫清障碍、排除问题。每日站会 应准时开始，尽量控制在15分钟以下，每个人发言应尽量简短，最好不超过三分钟。如果有人没有按时到达，不用等他立刻开始。之所以让每个人都站着发言并严格控制时间，是为了尽量减少不必要的会议时间开销。把时间都用在代码生产上。同时由于这个会每天都开，团队自始至终都对整个项目的进度都有着很精准的把握。PO不需要每天都参加每日站会，只在他需要了解当前进度的时候参加就可以了。

一个开发团队正在进行每日站会

Sprint评审会(Sprint Review)

在一个Sprint的结束举行，由PO、开发团队和Scrum Master共同参加。在会上重新一一检查这个Sprint内计划的任务的完成情况，那些完成了，哪些没有完成。对完成了的任务，展示成品，演示Demo，同时也根据这个Sprint的完成情况对下个Sprint要做的东西得出大概印象。

Sprint回顾会(Sprint Retrospective)

在一个Sprint的结束举行，由开发团队和Scrum Master共同参加，Scrum Master主导，PO可以不参加。对刚刚过去的Sprint,讨论三个问题:

1. 在上一个Sprint里，我们有哪些做得好的地方？

2. 在上一个Sprint里，我们有哪些做得不好的地方？

3. 在下一个Sprint里，我们将采取什么行动来对不足的地方进行提高？

每次回顾会的总结都以文字记录，由此可以与之前的回顾会记录相互对比参照，看看出现的问题是否逐渐得到解决。还是仍然一直存在。

这四个会议贯穿了Sprint的始终，构成了一个完整的Sprint流程。

由以上的介绍可以看到，Scrum很好地体现了敏捷的思想。通常为两周，短小精悍的Sprint使得整个开发计划进程或用户需求出现变化时，可以很好的及时响应调整。在Scrum计划会和评审会上，可以充分考虑用户反馈，对User Story和优先级进行相应修改。每个Sprint的完成功能都是可以立即工作的。自主管理、淡化职级、协商决定的开发团队充分给予了个体实现自己潜力的机会。每日站会让团队成员间能相互交流，培养团队感，同时让每个人都对当前进度了如指掌。这样，Scrum把总体上难于预测的软件开发过程变成了一个个局部上相对可预测，易控制的Sprint，同时降低了管理成本，提高了工作效率。这些优点，让Scrum成为最为常用，也是最广为人知的敏捷开发方法。以致在很多人眼里，Scrum就是敏捷的代名词。

Scrum的种种优点和在软件开发中的大获成功也让更多的行业对Scrum产生了兴趣。Scrum的方法现在也被广泛引入到其他行业的项目管理和工程管理中。然而，最让人感到惊奇的是，Scrum的应用居然被扩展到了军事领域。2007年，时任美军驻伊拉克将领大卫彼得雷乌斯把Scrum的方法应用到了驻伊美军特种部队的任务上。和软件开发团队一样，特种部队小队也是汇集了精通各种专业技能的多职能团队，他们也需要作为一个整体相互合作完成任务，所以的确有共通之处。按照Scrum的方法，特种部队的原本的长期任务被划分成一个个不超过一周的Sprint, 成员在执行任务时提高了士气，更加专注，使得任务的成功率大幅上升。

点此查看前篇:开发模式演进史(二):