跨越SCRUM常见的那些坑

从敏捷宣言诞生二十年来，敏捷开发方法越来越被企业组织所认同并持续发展。SCRUM作为一种轻量级的，清晰的敏捷框架，在企业组织的敏捷转型过程中，往往会成为大家优选的方法。

但是，纵观企业的敏捷转型效果，很多组织往往事倍功半，中途夭折者更是数不胜数。为什么企业组织的敏捷转型会这么难？

今天，拿SCRUM框架的实施为例，和大家分享一下在SCRUM实施中，经常会误踩的一些坑以及应对措施，希望大家能够有所启迪。

坑1：迭代周期，随心所变

大家对于SCRUM的第一印象，往往就是“敏捷迭代开发”。但是在SCRUM的具体实施中，尤其是一些新手Scrum Master，误踩的第一个坑往往就是“迭代周期，随心所变”。具体表现有哪些呢？

首先呢，团队也定义了一些迭代周期，但是有些时候，当碰到计划任务比较多，在迭代结束时还完成不了时：“迭代差一天就结束了，可是还有2个需求没启动呢，怎么办”？管理者眉头一皱，哦，那迭代再延长两天吧。

诸如此类，迭代周期没有固定，而是按照管理者的意志随意变换。可能在管理者的意识里，开发周期不就延长一点吗？有什么大不了!

嗯，如果有了这种想法，那么，很遗憾，这种方式已经触碰了SCRUM的底线！

为什么呢？我们知道，SCRUM是一种基于固定迭代（SCRUM中，称为sprint）周期的敏捷开发框架。时间盒是它的一个基础概念。

“时间盒”，时间是不可见的，盒子是可见的，在SCRUM中，用时间盒这个概念对开发中的事件进行了有效管理。

比如，每日站会，SCRUM建议是控制在15分钟内，迭代计划会、回顾会根据迭代周期可以设定对应的时间盒长度，比如，2周的迭代周期建议设定在2个小时。

那么，为什么SCRUM会有时间盒的概念和要求呢？我们来看Sprint的中文翻译“冲刺”。SCRUM认为或者期望，每一次迭代周期，团队都是在进行一次冲刺，从而实现迭代交付。

那么为什么迭代周期要固定呢？因为要保持节奏感。只有保持了节奏感，团队成员的工作状态才能保持在一个较佳的水平上，而保持了节奏感，团队也容易与外部组织更好地进行协同。

所以，怎样防止第一个坑：迭代周期，随心所变。很简单，一旦设定了迭代周期，要尽量固定。当然，不是说一旦设定了周期，就无论如何都不能更改，敏捷崇尚拥抱变化，迭代周期也可以变化，但是不要随意更改。

坑2：迭代没有交付

我们在一些实施SCRUM的团队中，当迭代结束总结回顾时，经常会发现这样一种现象：某某需求，本迭代完成了70%；某某需求，本迭代完成了95%，诸如此类，不一而足。

我们在谈论敏捷开发方法的优势时，经常会和传统的瀑布方法作比较。下图是一个明显的对比，大家看到下图都会侃侃而谈SCRUM迭代开发相对瀑布开发的优势。

图 SCRUM迭代开发与瀑布开发的对比

SCRUM框架相对瀑布开发的一个巨大的优势就是在于，它把漫长的产研周期迭代化切割，同时，要求在每个迭代周期，都有一定的交付产出，这在SCRUM中称为迭代增量式交付。通过每个迭代的定期交付，团队第一能够快速产出，第二能够快速获得用户的反馈，从而调整后续的工作计划。所以，迭代交付具有重大的价值，无论对于用户还是团队。

当一个迭代结束时，所有进行中的需求工作，对于团队而言都是0。因为没有实现交付，没有产生价值。

所以对于团队，当需求较多时，应该“聚焦完成，停止启动”，应该聚焦于迭代完成，能够实现完成哪些高优先级需求。

在这里，给大家一个建议：将产品版本与迭代进行匹配。

首先，从产品层面，定义若干产品版本。

其次，产品版本和迭代进行适配。

这样，我们就把产品和研发迭代进行了有效的连接。

每个迭代的产出目标，也有了更加清晰的指向。

坑3：需求理解不一致

看到这个主题，很多人都会挠头，或者迷惑不解。在工作过程中，需求讨论、需求评审、需求沟通等等，需求的会议一箩筐。还会理解不一致？那么，大家看看在日常工作中，团队有没有如下的情况：

需求沟通会上，产品经理详细讲解了需求，会上也和设计、开发、测试都一一确认了，大家表示没有疑问。可是后面到了具体实现过程中，除去需求变更之外，为什么设计、开发、测试还会频繁要求产品经理进行需求澄清？

这里面有几种可能的原因：

产品、设计、开发、测试有自己的思维方式和理解视角，对同一条需求的理解是存在侧重点差异的。

各种角色在描述自己对需求的理解时，都是基于自身的表达方式，在表达过程中可能存在着信息过滤和偏离。

因此，需要有一些约定和工具能够帮助各种角色对需求的理解达成真正一致。

用户故事方法的“故事点”概念和基于故事点的“计划扑克”估算能够解决这个问题。

“故事点”是对需求条目的规模进行相对度量的一种单位。

请注意，故事点是一种相对度量单位，只有在多个故事存在时，点数才有意义。同时，不同产品需求的故事点数比较没有意义。

图 相对大小的故事点

需求条目的估算可以采用“计划扑克”来估算。

图 计划扑克

计划扑克的估算方式如下：

参加游戏的人每人各拿一叠扑克牌，牌上有不同的数字。

产品负责人为大家挑选一个 Story（Backlog），并简单解释其功能，以供大家讨论。

每个游戏参加者按自己的理解来估计这个 Story 的故事点数，从自己手里的牌中选一张合适数字的牌，同时亮牌。

游戏参加者各自解释自己选择这个数字的原因，数字最大和最小的人必须发言。

根据每个游戏参加者的解释，重新估计时间并再次出牌，直到大家的估计值比较平均为止。

计划扑克估算活动中，重要的是通过多轮次大家对需求不一样的理解来逐渐澄清真正的需求是什么？最后得出的故事点数是大家的共识。

故事点数可以记录在用户故事中。

坑4：需求没有验收标准

需求的验收标准是往往被大家共同忽略的问题。大多数情况下，产品经理会准备大量的PRD，大量的原型设计文件。而设计、研发、测试更关心的是产品经理能不能把需求说清楚，能不能承诺在后面的开发过程中，尽量没有什么需求变化。

所以，很多时候，需求的验收标准就被大家给忽略掉了。

在这里，先给大家说明一下什么是需求的验收标准。这个需求的验收标准来源于敏捷需求方法用户故事中。上文和大家讲过，一个合格的用户故事有六大特征，而最后一项就是“可测试的”，而为了保证用户故事的可测试，一项关键的措施就是每一条用户故事都应该有“验收标准”。

那么什么是验收标准？为了保证沟通的一致性，我们建议用户故事用业务语言来描述，所以用户故事的验收标准也是业务层面的验收标准。如果验收标准是清晰的，那么用户故事在迭代中完成后是否能够通过验证，就有了依据。

同时，用户故事的验收标准也是测试用例的关键输入。

验收标准的可以如下格式：

图验收标准示例

当然，具体的产品、团队，验收标准的格式可以有所差别。

当用户故事有了验收标准，就可以在这个基础之上进行测试用例的编写。

一个即将进入迭代的用户故事，需要有相应的测试用例与其对应，作为验证用户故事是否能够实现完成的依据。

同样，用户故事有了测试用例进行关联，那么由此产生的缺陷也可以进行关联。这样，能够便于进一步的透明化团队需求的实现情况

坑5：迭代没有度量，不透明

透明，是SCRUM框架中的支柱之一。透明，能够使团队内部成员彼此更加互相了解工作的情况，便于增加内部团队成员的信任。

度量，无疑是能够将事实情况更加客观的可视化、透明化出来的有效工具。因为对同一个事情，不同的人由于各自角色的不同，观点肯定也会有较大的差异性。而度量数据，相对人的主观意见而言，是一种更加客观的事物，所以，任何事情如果有了度量数据的支撑，就会显得更加客观，也会更容易让人信服。

所以，在SCRUM实施中，需要使用度量来增加整个迭代过程的透明性。

而有些团队，由于种种原因，在SCRUM迭代过程中，会忽略掉度量，所以，我们建议大家在SCRUM执行过程中，一定有若干的度量，那么，可以有那些度量呢？

第一：迭代燃尽图。

迭代燃尽图也叫燃烧图，就是本次迭代中，所有故事（或拆分的任务，以下仅称故事）的剩余时间总和，随日期的变化而逐日递减的图。

迭代燃尽图是在迭代完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。燃尽图向团队成员和相关干系人提供工作进展的一个公共视图。

图 迭代燃尽图

迭代燃尽图可以用于每日站会，在每日站会上，团队成员通过检视燃尽图的趋势，分析存在的问题，并提出应对措施。

迭代燃尽图也可以用于迭代回顾会上，在回顾会上，团队成员通过分析若干团队数据，的带燃尽图是其中的重要一项，分析迭代内的问题，并提出改进措施。

第二：速度图。

敏捷术语“速度”是指团队在固定的迭代周期内能够交付的工作量。团队可以通过每个迭代的速度图，来分析当前迭代的计划与实际完成情况；可以通过若干迭代的速度图，来分析团队的产出趋势。

图 速度图

迭代燃尽图与速度图是SCRUM中的两种基本度量工具。在敏捷方法中，还有若干度量工具可供选择使用，大家在实际工作中可以按需选取。

坑6：没有时间回顾

在很久之前，当团队管理者第一次对我说出这句话时，我很吃惊。但是，后来再有人和我这样说，我就习以为常了。

因为，“没有时间回顾”真的是一个很普遍的问题。

第一次吃惊，是因为，我觉得作为一个一线团队的管理者，他们应该知晓在基本的“PDCA”管理循环中，总结回顾是多么重要的一件事情。但是，后来，我慢慢能够理解他们为什么能说出这句话，因为团队确实太忙了。

假设一个团队7个人，每两周花2个小时来做总结回顾的话，大概要占用14个总工时，将近2个标准工作日的时长，所以从这个角度，我可以理解。

但是，因为工作忙，就可以不总结回顾了吗？

我们看一下SCRUM框架，敏捷方法追求简洁、高效的沟通，但是仍然把迭代回顾会放进了SCRUM框架中。

为什么？因为，我们不单要完成任务。更重要的是，我们需要打造一个高绩效的敏捷团队。而只有不断的持续改进，我们整个团队才能不断提升。这其中，周期性的迭代回顾会是一个重要的管理活动。

在每个迭代结束时，团队管理者都应该组织团队成员进行固定的迭代回顾会议。在迭代会议之前，SCRUM Master应该先期准备好迭代数据便于迭代会议上大家进行分析，探寻原因，从而促进找到存在的问题，进而探索改进措施。

在回顾会上，团队可以检视上迭代的改进项进展，并记录本迭代的改进项，便于后续跟踪。

图 迭代回顾

SCRUM是敏捷方法中一种轻量级的，目前应用最广泛的框架。知易行难，看起来简单，但是实施起来并没有那么容易。

所以，本文列举了几个常见的坑或者误区，就是希望所有在做SCRUM开发的朋友，能够避开雷区，实行真正的敏捷开发，从而促进团队成长，获得更高的业务绩效，为客户、公司增加价值和收益。