走进敏捷软件开发——Scrum实施指南

Momenta Paper Reading致力于打造一个“无人驾驶学术产业前沿知识”的分享沟通平台，让你轻松读懂AI

Scrum是一种敏捷开发的模式，借助Scrum，团队可以实现产品的迅速迭代，十分适用于需求变化快的行业。因此，Scrum这种模式在互联网时代被广泛地使用，受到越来越多人的追崇。本文中，Momenta无人驾驶软件架构师梁潇分享了Scrum的基本特点及具体使用流程。

传统的开发模型

在讲Scrum这种敏捷开发模式之前，我们先来回顾一下传统的软件开发模式。

起初，软件开发最基础的模型叫做瀑布模型（Waterfall Model），它的方式是从分析、设计、开发到测试，所有的阶段全都是分开的。分析全都做好了之后会去做设计，设计全都做好之后才会去做开发。开发的过程中，也都是到了中后期才开始进行测试，当然测试的时间也一定比开发还要长的多，所以这个就叫瀑布。这种模型是比较传统和经典，但是它并不过时。

为什么呢？目前很多的大型软件仍是用这种方式在进行开发的。比如说像大家熟知的Windows，一个版本的更新可能会需要一年到两年的时间，在这样长周期的情况下，把每一步都做好，其实开发成本并不高。

而且像这么大的一个软件，如果在过程中有需求的修改，简直是一个灾难。比如在开发过程中推翻了之前的一个设计，可能会导致很多相关的功能都要跟着改，很多代码就要推回去重做。传统的软件开发很忌讳在过程中改变需求，如果没有改变，瀑布的方式其实就是很合适的。

瀑布模型存在两个明显的缺点，一个是不能在开发的过程中继续进行设计。在互联网时代的开发过程中这个缺点尤为明显，因为用户有一些需求上的变化是极其正常的。如果版本迭代周期过长，就很难赶上市场的趋势；另一个是浪费资源，比如分析设计的时候，开发全都没办法工作，效率非常低下。

为了解决以上两个问题，可以对瀑布进行一些改变。在这个新的模型里面，不管是分析、设计还是开发以及测试，其实都划分了不同的阶段。

当第一个阶段的分析做完了之后，就会进行设计，与此同时开始第二个阶段的分析。

通过这种方式，资源的利用率变高了。很多应用表明，它能够节省整体成本，使整个开发的生命周期变短。

不过这种方式仍不能解决需求迭代的问题。因为在需求改变的时候，需要把之前的东西推翻，所以这种方式还是不能适应版本迭代。

在这种情况下，敏捷开发（Agile Development）流行了起来，大家为了解决需求不断变化的问题，将分析、设计、开发和测试分成了几个不同的周期。

在整个软件周期中有很多不同的小周期，每个周期里面全都是按照A-D-C-T来进行的。如果在某一个周期里面需求发生了巨大的变化，我们只需要把这一个周期取消，然后重新开始进行分析。这样对整体效率的损耗就降低了很多。

同样的，如果发现市场趋势产生变化，我们就会在下一个阶段进行重新分析，这样开发出来的产品永远能够跟上市场的节奏，这个叫做敏捷开发。

Scrum的特点及使用流程

Scrum是一种敏捷开发的方式，它的特点是：灵活性、适应需求变化、更适合团队比较小的情况、每一个迭代均有产出、容易学习。

Scrum的使用流程如上图：

在每一个Scrum开始的时候，需要进行Sprint Planning，确定这个Sprint要做的事Sprint backlog，随后大家开始执行。在每天开始时，进行Daily Scrum会议。

在这一个周期结束的时候，一般是2-4周后，开review meeting，review之后要开一个retrospective meeting。

以上步骤完成后，再开始下一次的Sprint。

Scrum中的角色分类

Scrum里面把人分为两类，一类叫做鸡，一类叫做猪。这个是来源于美国一个较著名的笑话：有一只猪跟一只鸡在商量做生意，讨论卖什么产品合适，鸡说：卖火腿与鸡蛋如何？猪立刻就说：这样不行，我可是全身投入，你只是参与而已。

同样的，在同一个项目里面，每一个人职责不一样，他对这个项目的贡献度、参与度也就不一样。根据这种参与度的不同，我们可以把这个团队分成两部分，一部分叫鸡队，一部分叫猪队。

鸡队里面包括用户、利益相关者和经理。用户的意见是非常重要的，但是他并不属于项目的核心成员，因为用户并不一定要选择这个产品，对这个项目的参与度并不高。经理可能同时会管很多的项目，但在某一特定的项目上，花的时间并不会很多。利益相关者对这个项目，可以发表一些言论、权利，但是他在这个项目上整体投入也不会很高。

猪队包括产品负责人、Scrum教练和开发团队。猪队中，最重要的角色就是产品负责人，因为这个项目失败的话，他和开发团队是需要承担责任的。Scrum教练不对项目里面的任何细节负责，他只对这个团队是否合理的使用Scrum负责。

Scrum框架具体阐述

1.Product Backlog

Product Backlog是记录所有已知需求的一个数据库。在整个开发过程中，要不断的把已知的所有需求记录到这里面来，任何时间或步骤中产生的新需求都需要进行更新。

2.Sprint Planning和Sprint Backlog

Sprint Planning是对这个Sprint进行规划的会议。它的主要的目标就是从Product Backlog里面选择一些任务，放到Sprint Backlog中。

参加Sprint Planning的人员是所有的猪队的成员。会议形式是：首先由项目负责人决定需求，然后全体成员一起细分任务，并预估时间。随后，把任务指派给不同的人，最后对每一条任务进行“举手通过”，让每个人充分发表意见，以保证明确定义任务，统一大家的认识和便于补位。当任务分配好之后，要记录到Sprint Backlog里面，后续严格按照Sprint Backlog去实现开发。

3. Daily Scrum

Daily Scrum是一个用于同步进度的会议。会议形式是每日站会（站立的会议，维持在15分钟以内），要求参会的猪队成员每个人发言在两分钟以内，每个人只说三个问题，我昨天做了什么，我今天打算做什么，我遇到了什么样的困难。遇到的困难由Scrum Master在会议后进行解决，成员不在会上讨论问题解决方案。

4. Sprint Review

Sprint Review是一个用于Sprint总结的会议。参会成员包括猪队成员和鸡队成员。会议形式叫做“非正式”演示，目的是把之前做的Sprint新功能给大家进行演示，并规避正式演示会造成的准备时间过长的缺点。通过演示可以给大家打气、激励组内成员，并且听取 feedback，同步收集新的需求。

5. Sprint Retrospective

Sprint Retrospective是一个用于Sprint回顾的会议。会议目的是回顾组内成员在项目开发过程中做的怎么样。会议形式首先要创造安全的讨论环境，

比如发给每人一张小纸条，写出有没有你觉得哪个人在场你会不敢说话，然后收集起来，最后统计处理，Scrum Master会决定将谁请出这个会议。

安全环境建立好后，讨论之前“哪个方面做的好（Continue）”、“哪个方面不好（Stop doing）”和“要新开始做什么（Start doing）”这三个问题。Scrum Master在会后便致力于解决以上提出的问题。所以在Scrum的这种工作方式里面， Scrum Master承担的工作是非常繁重的，建议是由一个人全职担任，或采用轮职的方式。

使用Scrum需要注意的事项

· Scrum绝对不能代替传统软件开发方法

如果整体需求是很平稳的，不会发生变化的，那么瀑布是一个效率最高的方法。如果是Scrum开发，需要在较短的时间内得出分析，很难保证完全的正确性。

· Scrum适合十人左右的团队

如果团队人数过多，Daily Scrum的时间会很长，从而影响效率。但是分组（Scrum on Scrum）的方法可以解决团队过大的问题。十个人一个小团队做一个Scrum，然后每个团队的Product Owner再组成一个Scrum，大的团队也可以用这种方式使用Scrum的。

·Scrum的一个Sprint时间为2周–4周

Scrum是适应变化的，因为Scrum主要是用Sprint的方式进行周期的迭代，所以在每一个周期（2-4周）都可以对需求重新归纳和总结，而不像瀑布的方式，需要两年之后才能响应。

· Scrum需要一个强有力的产品负责人

除了强有力的产品负责人，Scrum也需要开发人员的技能相对综合，能够互相补位。

· Scrum 的 Sprint 内任务不应变更

Scrum要求每个Sprint是2周-4周的时间，在这段时间中，任务是不应该改变的。如果一个重要需求一定需要改变，那就应当把某一个Sprint取消掉，重新开始下一个Sprint。

如何开始使用Scrum

· 确定团队是不是适合用Scrum

外界的需求变化多，这是决定使用Scrum的出发点。团队人数多少、项目中间是否需有产出和团队成员技能点是否均衡并不是主要的决定标准。

· 找一个Scrum Master

Scrum Master作用是帮助维持Scrum的整个流程，并负责移除开发进度上的障碍。他的职责包括：1.找一个适合记录Product Backlog的工具；2.移除开发进度上的障碍；3.督促团队使用Scrum的规范。

· 找到一个合适的工具

因为Scrum的节奏很快，所以重量级的工具并不实用，应当使用轻量级或被动式的工具。

第一个工具是Kanban， Kanban是一个非常简单的工具，它把所有的事情都罗列出来详情和进度。

Backlog这一类是指的Product Backlog，To Do指的是Sprint Backlog。当Sprint开始的时候，需要从Backlog中选择任务放入To Do，然后进行Sprint项目，把To Do的内容放入到In Progress中，最后做到Done。所以Kanban和Scrum的整体的流程是非常匹配的，绝大多数的Scrum team都用Kanban管理自己的功能。

第二个是统计工具，例如燃尽图（Burndown Chart）。燃尽图就是统计在一个Sprint中的剩余工作时间，如果Product Backlog不断增加，燃尽图的时间会增加，当整个Sprint完成时，燃尽图的时间就会归零。燃尽图的具体使用方法在本篇文章中不做详细介绍。

Q&A

Q1：如果有A和B两个需求，在会议上将其确定为A和B两个任务，如果任务A跟B的关联性比较大，做完A之后再做B时，会不会产生任务需要推翻重来的情况？

答：会的。这其实是考验项目负责人很重要的一点，如果A和B是同时出现的，他应该先预见到这两个东西的关联性，把A和B放在一个Sprint中。如果是先决定做A，然后突然B需求出现，那这个需求上的变化可能导致框架改变，这件事是没有办法避免的。

Q2：能否详细描述一下Scrum Masters负责的内容？

答：Scrum Masters不对项目负责，只是保证Scrum进度，监督大家按照Scrum流程进行项目开发。如果某人遇到了困难是他负责解决，当然他负责解决不代表他去解决，是他负责帮助找人去解决。如果一个团队做的好的话，Scrum Master几乎不用做什么事情，这种情况下，Scrum Master可以是兼职，但是Product Owner一般是不推荐由某个成员兼职。

Q3：总结和回顾在Scrum的什么阶段？

答：从框架上来看，在一个Sprint开始的时候进行Planning，然后当一个Sprint结束的时候进行Review，Review结束后是Retrospective。Review和Retrospective这两个会议，基本上是先后连在一起开的，基本上是在Sprint的最后一天。