Scrum——在变化中求进化

贾儒（高级开发工程师）

移动互联网当道的今天，变化已经是大家习以为常的事情了。也许昨天还在街边苦等久久不来的出租车，今天已经可以在手机上点点预约车辆准时到达门口。优秀的产品带来了生活习惯、甚至生活方式的变化，这是从前无法想象的。在这背后则是互联网产品服务的变化，在这个大潮中，“进化”的周期变得越来越短，大家也许还记得当年各大杀毒软件厂商，每年才会发布一个新的功能版本，而如今几乎每一天大家的手机上都会收到各种各样的软件更新。而在这种快速更新的软件背后，需要一种能够很好适应并响应变化的团队组织方式——已经为大家所熟知的敏捷开发方法Scrum。

Scrum是一个基于经验、实践的项目组织框架，由预定义的角色参与，按照既定的基本过程来管理项目的进行。既然是以经验和实践为指导的框架，那么单纯形式化的介绍很难让人理解Scrum中各种规则的来由和好处，我将在本文中介绍Scrum的基本特性，也结合自己5年来的Scrum实践，提供一些经验供大家参考，也推荐大家，不论是团队成员、Scrum Master还是Project Owner，在Scrum的实施过程中不断回头看一看Scrum的各个规则，并且多和其他人交流，这样可以更好地理解和实施Scrum。

虽然Scrum定义了角色，也给出了基本的组织流程，但是Scrum并不是一套方法论，它并不提供具体的解决问题的方法，更不会直接告诉我们怎样能够更好，更快地开发出符合需求的软件系统。Scrum核心的内涵是：检验（inspection）和适应（adaptation），主张在周期性地迭代和交付中，不断提升团队，不断改进产品。

 Scrum中的三个角色

Scrum中定义了三个角色，分别是PO（Project Owner），SM（Scrum Master）和TEAM。

Project Owner（WHAT）

PO，即产品负责人，在团队中最主要的职能是“What”，他将从产品的视角出发，定义产品特性及其优先级，决定发布的时间与内容，对产品收益负责（ROI），并参与评审开发的结果。

TEAM（HOW）

TEAM，即团队，在这里专指开发团队，通常每个团队由5-9人组成。开发团队的任务就是在每个迭代周期中将计划好的产品特性实现出来。Scrum的团队是自组织的，同时也是平等的，没有头衔区分的。在每一个迭代周期正常进行的过程中，团队应当交付的产品特性是锁定不改变的，在这个过程中，有团队自行决定怎样去达到预定的目标，因此，团队在Scrum中意味着“How”。

Scrum Master（SUPPORT）

SM，即Scrum教练，负责整个Scrum过程的实践，并在过程中确保每一位成员在游戏规则内能够无障碍地活动，专注在团队开发中。对于Scrum Master，不论从其名称“Master”一词，还是在众多实践中看到的其与团队之间的关系，都很容易把Scrum Master理解成为开发团队的管理者，其实不然，这个Master更像一个教练，重在指导和支持团队，因此，Scrum Master更接近于一个辅导者的定位，他应该帮助团队更好地理解Scrum的核心价值观，组织、协调好项目进行过程中的各种会议，为团队清除障碍，替团队抵御外部的干扰因素等。Scrum Master并不是传统意义上那种管理层，而是一个支持者，如同润滑剂一般让整个团队更高效，顺利地运作，以一言蔽之，那就是“Support”。

Scrum所包含的以上三种角色中，并没有“领导”，这也是Scrum的核心价值所决定的。领导不属于Scrum团队，但是实际情况下必然会在团队之外有领导，有投资方，这些都是一定程度上不平等的关系，也会在Scrum的执行过程中对团队产生各种影响，这些将在之后的Scrum实践中介绍。

Scrum的基本流程

Scrum是一个不断迭代的过程，整个软件的开发过程由连续的迭代周期组成，每一个迭代周期叫做一个Sprint，时常建议为1-4周。Sprint的长度可以根据团队的需要来调整，但是仅仅在必要的时候才这样做，在长期的软件开发过程中，应该尽量保持Sprint的长度稳定不变，这样才能保证整个团队从计划、执行到评估等各方面的工作保持一个固定的节奏，如同在长跑中运动员会将自己每一步的节奏保持在一个相对衡定的水平。相对稳定的周期，一方面可以让团队的工作状态维持在比较稳定的状态；另一方面，按照固定周期迭代一段时间后，可以让团队对自己每个周期内的产出能力有比较准确地把握，并且时间越长，了解就越准确，这样就能够对产品未来的计划做出指导。下图是一个典型的Sprint中的主要流程。 

Scrum中两个产品功能列表

Product Backlog (PBL)

PBL是带有优先级的产品特性列表，所有已经确认计划实现到产品中的特性都会记录在这个列表中。PBL是对产品的总体计划，由PO来维护，其他的所有人都可以对PBL提出建议，但是只有PO一个人能够最终决定PBL的修改。PBL是PO所谓产品视野的最好体现，维护一个合适的PBL是PO在整个开发过程中调整产品目标的主要途径。

Sprint Backlog (SBL)

SBL是每个Sprint中TEAM所承诺实现的所有产品特性的列表，这个列表的基础内容从PBL顶端（优先级高的一端）取出，一旦SBL制定完成，在整个Sprint过程中将保持锁定不改变，实现SBL中的所有特性是TEAM在每个Sprint中唯一的目标。

根据TEAM每个Sprint所能完成的工作量估计，从PBL中取出适量的任务之后，还需要经过TEAM全体讨论来细分任务，通常每个SBL中每个任务的时间应该保持在1人天以内可完成，因为我们要在每天的Daily Scrum会议上回答经典的三个问题，而这些问题都是面向1天时间的，所以如果任务的时间超过这个限制，那么我们对风险的控制和项目进度的了解，就会受到这个长时间任务的影响。

如果从一个比较粗的时间粒度来看待Scrum的过程就是：每个Sprint开始的时候，TEAM从PBL顶端取适量的任务，然后负责将其全部完成；PO随时增减PBL中的特性，并加以描述，调整优先级，把最重要的放在顶端，需要注意的一点是——在一个Sprint已经开始之后，即使在PBL最顶端的任务也只能在下个Sprint交给TEAM去实现。

Scrum实践

既然Scrum最核心的价值在于检验和适应，因此实践Scrum的过程也是继续学习Scrum的过程。我从2009年下半年开始接触Scrum，到现在已用Scrum来管理项目约5年了，这个过程中每过一段时间我都会去看一些有关Scrum的资料，反思自己遇到的问题，并且看一看他人实施Scrum的经验，以及关于Scrum实践过程中的各种疑问的讨论，每一次都会对Scrum的某些有争议的细节有更新的认识。

紧急任务

当出现优先级非常高的紧急任务突然需要加入时，问题就来了，这个任务应该以怎么样的形式加入到Scrum流程中，团队什么时候来做？

我们知道PO在整个产品开发过程中可以决定每一个特性做与不做，也能够决定要做的所有特性的优先级。从一个较长的时间段来看，PO决定了产品的一切，因为他将决定每一个产品在什么时间发布，并且每个版本包含怎么样的特性。但是需要注意的是PO完成这一切的方式主要是依靠维护PBL来完成的，PBL中依次排列的项目决定了产品未来将要实现的特性，而PBL的优先级决定了TEAM下个Sprint将选择哪些任务来实现，同时PO还可以决定哪些版本对外发布（虽然每个Sprint结束之后TEAM都会交付一个潜在的可发布版本，但是并不一定每次都需要发布，这将由PO来决定）。

我们还提到过一旦SBL制定完成，在Sprint进行中就不能再更改，因为这是TEAM在Sprint中最主要的目标，我们需要保证团队将精力完全集中在目标上，因此目标应该是确定不变的。面对紧急任务，我见到的有一部分团队的做法是简单地将紧急任务插入到SBL中，然后容许这个Sprint完成度受影响或者简单地从SBL中置换出一些未开始的任务，这些都是不可取的，作为Scrum Master，一定不能允许这样的事情发生。因为每一个Sprint是需要预估，需要全体团队成员讨论达成一致之后确定目标然后开始实施的，中途加入的任务将会破坏这种预估，更没有经过完整的讨论，这将极大增加未知，也就意味着风险。因此，当Sprint进行过程中遇到紧急任务需要加入时，有两个选择：

1. 将这些紧急的任务添加到PBL的最顶端，保证下个Sprint它们一定会被实现；
2. 中断当前的Sprint，将紧急任务添加到PBL最顶端，重新开始新的Sprint；

可以看到，不论以那种方式，紧急任务都只能被添加到PBL中，而非SBL。Scrum适应变化的能力很大程度体现在Sprint这个时间长度上，因为相较传统的软件开发模式，Scrum可以在每个Sprint开始的时候添加新的需求，在每个Sprint结束时都会有一个可用的版本。而当团队处在Sprint的执行过程中时，Scrum则要求更强的稳定性。SBL中的每一项都应该在Spring Planning会议上经过全部团队成员的讨论，在这个会议每个人都可以自由提问，以保证每一个人对Sprint的目标有足够清晰的理解，这是团队每一个人作为一个负责任的成员对Sprint目标做出承诺的前提，也是Sprint进行过程中团队集中精力完成目标的基础。

Daily Scrum

Daily Scrum会议在Sprint中的每一天都要开，而且强烈建议在每一天的同一个时间，同一地点开，最理想的时间是每天早上，因为这个会将影响每一位团队成员今天工作的上下文。

Daily Scrum每日站会可能是大家了解到Scrum时很容易留下深刻印象的一个特点，不同于我们平时多人围坐，一开则几个小时的大会议，这个会议是站着开的，而且时间非常短。大家都很痛恨开会，参会人数越多，会议时间越长，效率就越低，Daily Scrum既然是每天都要开的会议，那么这个问题是一定要避免的。Daily Scrum所有的TEAM成员都要发言，但是每个人的发言仅限于回答三个问题：

1. 你昨天做了什么？
2. 你今天打算做什么？
3. 你遇到了什么阻碍？（需要什么帮助？）

当每一位成员回答完这三个问题，TEAM就可以很好的掌握项目当前的状态，什么已经完成了，什么还没有做。需要注意的是，这个会议最主要的目的是让团队成员之间有足够的交流，而不是用来让领导了解项目进度的，所以在Daily Scrum上每个人回答这三个问题的时候，应该面向团队的每一位成员，而不是领导。Daily Scrum的参会成员包括整个Scrum团队，包含PO、SM，在这之外的人也可以参加，但是它们只能听而不能发言，保证了这一点，能够很好的提高Daily Scrum会议的交流效率。

Daily Scrum很简短，任何细节问题都不应该拿到这里来讨论。所以如果开会过程中遇到了细节的问题需要进一步讨论，那么应该在Daily Scrum结束之后，另外组织会议讨论这个问题，因此在Daily Scrum进行过程中Scrum Master一定要注意控制会议的主题，防止进入过度的细节中而使会议效率降低，在适当的时候要阻止这个趋势。

在实践中，我发现要严格地做到控制Daily Scrum时长并不是容易的事情，大家一起讨论很容易就不自觉地开始描述细节。这里有一个小技巧，我见过某些Scrum团队会在Daily Scrum的时候以传递物品的方式来轮流发言，比如传递一个小公仔之类的物品，这个方式的本意是防止发言的人被其他人打断，而如果把这个小公仔更换成一个重物（要足够重哦，哑铃、板砖什么的都可以），当发言的人搬着重物说的时候，就会发现越来越吃力，于是就能够不断提醒自己简短地说，尽快结束发言了。

关于检验（inspection）和适应（adaptation）的游戏

在参与Scrum Master的培训过程中，老师让参与该课程的约30人玩了一个游戏，规则如下：每个人持有一张个写有一个正整数（每个人的数字不相同，并且所有这些数字的取值区间很大）的纸条，自己可以把数字说出来，但不允许把纸条给其他人看。参与游戏的人围站成一个圈，老师把一个球交给所有人中数字最小的人，然后开始计时，参与游戏的人需要按照每人所持数字的递增顺序来传递这个球，直到每个人都经手这个球，最终传递到持有最大数字的人手里，游戏结束。游戏过程中大家可以自由交流，唯一的限制就是不允许把纸条给其他人看。这是一个很简单的游戏，同时也因为规则很简单，也没有很多细节说明，于是就可以有很多的变化。

在集体讨论了几分钟后，大家很快想到一个办法，由一个人作为主持来组织大家的行为，大家以类似的二分法来寻找当前还没有接触过球的最小值的人，然后把球传递过去，但是实施过程中并不如想象中那么理想，因为老师给的数字取值区间太大，并且分布不均匀，因此每次找下一个传球人花费的时间很多。于是还没等球传完，这种做法已经被否定了，大家重新开始想办法。

新的办法是每当一个人接到球，就把自己的数字报出来，大家认为自己和他接近就报出自己的数字，然后只要自己的数字比已经报出的最小值还要小就抢答，这样我们提高了每一次寻找最小值的代价。这个办法很奏效，使得球在每个人手里停留时间都不长，保持了比较好的传递状态，当传递完成时，我们花费了约5分钟。

接下来，老师让我们不断优化这个传递的过程，规则不变。于是大家开始询问和尝试各种改变，比如重排大家站立的顺序，经老师许可后，我们在开始传递之前将站立的顺序提前调整为按照数字增序排列，这样传递过程中就很大程度上缩小了寻找下一个人的代价。很快我们就完成了传递，这次是1分10秒，这看起来是一个很大的进步。

但是，这还没有结束，我们还在继续想办法，希望进一步优化。大家发现上一轮传递球的过程中，传递球这个动作需要从上一个人那里接过球，转身，再给下一个人，这个是该方法耗时的关键，于是再次和老师确认：我们需要的是每个人按照数字顺序接触到球（不一定要握在手中）。于是就有了新的办法，这一次让球静止放在桌子上，球不动而人动，大家排成长队，还是按照数字的增序，依次跑过桌边，在球上摸一下。这看起来很理想，因为我们将传递的时间缩短为轻触一下的瞬间，时间一定会再次被刷新。当计时结束时，老师很遗憾地告诉我们，这一次时间反而变长了。大家停下来分析原因，是前后两个人跟着跑的间隙，以及球被触的力量稍大后还会滚动，这给我们的传递带来了不稳定的影响。

在大家继续思考的时候，老师终止了整个过程，并且提供了一个他目前见到的最快纪录的传递方式——大家站成弧形，然后伸出手放在同样高的位置，由第一名持球人带着球从弧形内侧跑过，用球碰每个人的手一下。这是一个开放性的游戏，没有标准答案，也许某天有更好的方式，还可以在此刷新最快纪录。在整个游戏过程中，作为一个团队，我们经历了初期的团队组织；实施过程中对规则（即潜在优化的机会）的不断探索；并得到了一些好的优化，也伴随着失败的尝试。这就是一个典型的检验和适应过程，团队需要不断总结之前的经验，为之后的行为做出指导，每次改变一小点以保持风险可控的同时积累经验，不论好的还是坏的改变，都可以为以后的选择做出经验性指导。

Scrum是一个经验性框架，Scrum是一种组织方式，但所有的实施过程怎样进行，还要靠我们自己，在整个过程中不断检验和适应，找出最适合我们的方法。

参考

1. Scrum Rule: No Additional Requirements Can Be Added to a Sprint!, http://www.civicactions.com/blog/2011/sep/07/scrum_rule_no_additional_requirements_can_be_added_to_a_sprint
2. Wikipedia——Scrum, http://zh.wikipedia.org/wiki/Scrum
3. The Daily Scrum Meeting, http://www.mountaingoatsoftware.com/agile/scrum/daily-scrum