【敏捷FAQ 第10期】速度不稳定。可以用于计划吗？

 感谢您阅读本文。我是隶属于敏捷小组的藤井智弘。
 在第9期中，我讲了不将点数换算为人日，而是根据速度的实际数据给出带有范围的预测。也写到，换算表的问题在于将动态的实际数据固定为一个数字。虽然在番外篇中绕道讲了一下估算的原理，但这次将继续第9期的话题，讨论其基础——速度本身。而同样的“固定”问题，会以另一副面孔出现。

 每个 Sprint 的速度在 20→35→18 之间波动。我一直取平均值用于下一次 Sprint 计划，但经常不准确，团队中也有人说：“在速度稳定之前，是不是不能依赖它？”应该等待它稳定下来吗？

 提出这一烦恼的人，通常同时抱有以下三个疑问。

• 之所以有波动，是因为我们团队还不成熟吗？
• 要等多少个 Sprint，才能稳定下来？
• 一直波动的数字，可以用于计划吗？

 让我们依次来看。出现波动并不是因为不成熟。刚开始几个月的团队，速度出现波动才是正常的。无论是估算的基准、团队的协作，还是 PBI 的粒度，都还处于发展过程中。无论等待多少个 Sprint，“完全不波动的单一数字”都不会到来。而且，即使保持波动，也可以用于计划。问题不在于波动，而在于，试图用单一平均值来处理会波动的事物。请不要使用平均值，而是使用范围。只要把说法改成“我们的速度是 18～35”，速度就会成为计划工具。不过，范围要在积累大约 5 个 Sprint 的实际数据后才能变得可靠；在此之前，是专注于记录的时期（后文的处方中会详细说明）。
 如果只提炼两个要点，那就是：“将波动作为信息来解读”，以及“不要以让它稳定为目标”。

 我想很多人在培训或书籍中都学过：“速度会在几个 Sprint 后逐渐稳定下来”“稳定的速度是计划的基础”。当时，您是否有过以下疑问？

• 我们过了半年也没有稳定下来，是不是哪里出了问题？
• 每次的休假、故障和插入工作都不同，稳定下来反而不奇怪吗？
• 面对不稳定的东西，该如何向上司说明？

 我在还是培训参与者的时候，也有过同样的疑问。先说答案，这是对**“稳定下来”这一含义的误解**。稳定的不是一个数字，而是范围。每次波动的原因不同，这确实如此；正因如此，才要以范围来持有。而且可以直接用范围向上司说明。不过，如果到此为止，就仍然只是一句口号。先看看速度通常会被怎样对待，然后再认真思考这个问题。

 对波动感到苦恼的团队中，存在几种反模式。请与您团队对待数字的方式对照看看。

模式一：观望型——决定“在速度稳定之前不使用速度”，于是凭感觉和干劲来制定计划。虽然有记录，却不去看。稳定不会因为等待而到来，因此这种观望会无限持续下去。

模式二：凑数型——以“让速度稳定”为目标的模式。其起点通常是管理层开始要求解释：“上个月明明是 35，这个月为什么是 18？”在速度开始被用于考核或团队间比较的组织中，这几乎必然会发生。之后，团队会开始注意不让数字下降：把估算刻意报大、只挑看起来能完成的事项、悄悄把遗留事项也算作完成。数字会变得漂亮而稳定，但实际情况丝毫没有改善。第9期中看到的古德哈特定律，在这里同样等着你。在番外篇中我写过，估算的波动无妨，但偏差会残留在总量中。凑数行为制造的，正是这种偏差。

模式三：原因不明型——记录了数字，却没有留下该 Sprint 中发生了什么的模式。即使看着半年的数字，也不知道“35 的时候什么做得好”“18 的时候发生了什么”。只要原因不明，波动就不过是噪声。

 尽管表现不同，这三种模式，以及提问者“按平均值安排”的做法，都源于同一个误解：速度是精密的测量值。一旦以这个前提来思考，波动就是测量误差，取平均值便会接近真实值，不稳定的数字不能使用，下降的数字必须解释——这些判断都会显得顺理成章。它们全都是这个前提的自然实践。正如第9期中的换算表将动态的实际数据固定为一个系数，平均值也会将波动固定为一个数字。表面不同，发生的事情却是一样的。

 那么，接下来依次解决这三个疑问。

 首先，半年后仍然不稳定，是不是哪里出了问题。没有问题。速度不是物理常数，而是对团队这个生命体的观测记录。成员休假、插入工作多少、PBI 粒度不一致、估算基准的变化……所有这些都会反映在数字中。半年后仍会波动，仅仅意味着半年后的团队仍然在运转。逐渐稳定的是波动的“范围”。像 18～35 这样的范围，会随着实际数据的积累而变得更可靠，也会随着原因被消除而逐渐缩小。

 接下来，每次原因都不同，稳定下来反而不奇怪吗。确实如此。因此，不要试图消除波动，而是采用一种在保留波动的前提下用于预测的方法。这就是范围。用范围来表达，是以降低 precision（精密度）来换取提高 accuracy（准确性）。与其用狭窄的范围却预测失准，不如用宽一些的范围来预测准确。计划所需要的是后者。另外，还要观察波动的原因，只处理能够处理的部分。将休假和突发故障作为范围的一部分接受下来，改善插入工作的受理方式和 PBI 的粒度。能够完成这种分类时，“因为会波动所以不能用”的讨论，就会转变为“这个原因能否消除”的讨论。

 然后，如何向上司解释不稳定的东西。直接按范围说明。第9期中介绍的带范围的发布预测，正是根据这里的最差值和最佳值得出的。“我们的速度是 18～35，因此剩余工作需要 6～11 个 Sprint。”如果对外必须给出单一日期，就以悲观值一侧的日期作出承诺，并将范围用于内部计划和进度管理。在第5期中，我写过在将改造项目通过实际 Sprint 测得的速度提交审批时，应采用周期和金额上限一侧的数值；这也是这种范围用法。已承诺的日期，也可以随着范围缩小而提前重新评估。

 剩下的问题是，为什么我们会认定它是“精密的测量值”。我们中的大多数人都被教导，计划应当以单一数字来制定。交期是一个日期，工时是一个数字。在这样的文化中遇到速度时，想把它塑造成“波动很小的单一数字”，是很自然的反应。这并不是谁的错。只是速度究竟是为了解决什么问题，并没有像单位的说明那样被充分传达而已。

 那么，速度本来是为了什么而存在的数字？在第9期中，我写过故事点是用于“从实际数据进行预测”的工具。在番外篇中，我写过估算误差不是由方法决定的，而是由事项的大小和得到验证前所需的时间决定的。速度则属于“实际数据”这一侧，是每个 Sprint 验证结果的记录本身。
 观察——原样记录每个 Sprint 完成的点数。不夸大，不削减，不将遗留工作计入。这种诚实，是之后一切的基础。
 检视——排列记录，查看范围和波动原因。预测与实际之间的偏差不是失败，而是修正下一次计划的信息。
 适应——以范围制定下一次计划，改善可消除的原因，将无法消除的原因作为范围来接受。随着 Sprint 的不断积累，范围会缩小，计划也会越来越准确。

 套入这三个层次，便能明白提问者的“按平均值安排”停在了哪里。虽然进行了观察，却没有检视波动，而是用平均值将其抹平后用于计划。至于凑数型，甚至扭曲了观察本身。不是“造出一个波动很小的数字”，而是“以范围持有，解读原因，以范围计划”。换句话说，事情就是这样。若没有这一转变，即使只尝试后面的处方，也无法长久持续。

 下面列出的是工具，而不是目的。预测方法有很多选择，其中也包括第9期扩展部分提到的方法，选择哪一种都可以。不过，如果只是形式上说“我们改成范围了”，那也不过是把一个平均数字增加成两个而已。尝试之后，请通过“计划是否变得准确”“波动原因是否减少”来验证。

首先，在数字旁留下简短备注
 在采取对策之前，先从记录开始。请在每个 Sprint 中，将一行备注和速度数字一起留下。“35：没有大型连休，插入工作少”“18：处理生产故障耗费 3 人日，某某休假”。积累几个 Sprint 后，就能对波动原因进行分类。改善可以处理的因素（插入工作的受理方式、PBI 粒度不一致），将无法处理的因素（休假、突发故障）作为范围接受。这是摆脱原因不明型的唯一方法；后续的处方也必须先有这些记录，才能运转起来。

不用平均值，而是使用范围
 范围的制作方式，如第9期所述，只要从最近 5～8 个 Sprint 的实际数据中取最差值和最佳值即可。本文补充的是，如何将这个范围用于 Sprint 计划。说到底，这就是“昨天的天气”的范围版：通过悲观值延续“只安排已经能够完成的量”的保守性，并用乐观值准备好剩余能力的用途。在下一次 Sprint 的计划中，以“悲观 18、乐观 35”为前提，用悲观值安排确定要纳入的工作，剩余部分则作为“如果能完成就开始做”的候选项排列好。按悲观值安排的工作成为 Sprint 目标的基础，出现余力时再拾取候选项。
 需要注意的是，在刚引入、只有 2～3 个 Sprint 实际数据的时期，范围也还不可靠。这段时间不要追求预测精度，而应当认定为“积累实际数据的时期”，只持续记录即可。范围大致从第 5 个 Sprint 开始才具有意义。与观望型的差异在于：即使在等待期间，也要记录并持续观察。

通过范围的变化趋势，预见终点
 范围有两种用途。其一，是为了让下一次 Sprint 不失准，使用范围下限（悲观值）进行安排。前一条处方说的就是这个，也就是“昨天的天气”的范围版，目的是提高下一次的达成可能性。其二，是为了预见终点，使用范围的变化趋势。用范围去除剩余点数，完成时间也会变成一个范围；如果这个范围随着 Sprint 的累积而缩小，说明预测正在变得可靠。如果没有缩小，就表示仍存在尚未消除的原因。“昨天的天气”对于前者已经足够，但并不能展示后者——也就是最终究竟有多大把握。能够展示这一点的，是第9期提到的带范围燃尽图。用范围下限守住下一次，用范围趋势观察终点。这是同一个范围的两种不同解读。

与组织就速度的用途达成共识
 速度是团队为了提升自身计划精度而使用的内部指标。一旦被转用于考核、比较或目标值，数字就会变成自我防卫的工具；其原因正如第9期关于点数所述，速度也是一样。也就是说，第9期中针对换算值划分的“面向外部的货币”和“内部工具”的界线，也应当划在速度数字本身上。请尽早与管理层就这条界线明确达成共识。在“报告速度下降原因”的要求开始之前。这里也不是团队单方面能完成的。团队应每次以相同格式公开范围和原因备注，管理层则不看数字的升降，而是看“范围是否正在缩小”“可消除的原因是否正在减少”。堵住通向凑数型的入口，靠的是这种双向互动。

 如前所述，用单一数字制定计划的文化，并不是一次培训就能改写的。而且，每当有新成员加入，都会被重新带进团队。因此，对速度波动感到不满的声音，会随着团队一代代成员更替而必然再次出现。

 然而，敏捷的计划制定并不是为了消除不确定性，而是为了与不确定性共存并持续前进。当你对速度波动感到烦躁时，需要调整的不是数字，而是对数字的期待。范围是否在缩小？波动的原因是否在减少？定期向自己提出这些问题，便能够确认团队的速度是否正在作为计划工具发挥作用。

 第9期中，我写过：“1 点＝某人日”这样的换算值，是描述事项成本的数字；速度则是描述团队流量的数字，两者看似相近，实则不同。于是就会有人问：“逐项赋予点数后，用总点数除以速度；和逐项乘以换算值后相加，结果不都是一样的吗？”这是个好问题，因此我将在第9期中简略说明的答案，在这里展开一下。

 先从算术开始。如果换算值是通过“Sprint 人日÷速度”得出的，那么各事项“点数×换算值”的总和，就等于“换算值×总点数”，也就是“总点数÷速度×Sprint 人日”。如果每个 Sprint 都重新计算换算值，并且只用于总量，那么它只不过是“用速度除以总量”的另一种写法。在这种情况下，两者没有区别。区别产生于实际工作往往偏离这一理想形式，主要有以下四点。

 固定什么——用速度除以总量的方式，可以把速度作为每个 Sprint 都重新观察的动态值来处理，同时保留其范围（18～35）。因此预测也会成为范围；如本文所见，实际数据积累得越多，它越可靠，原因消除得越多，范围就越窄。换算值则在从实际数据产生的那一刻成为一个常数，在作为表格分发时更新就停止了，范围也会消失。理论上，“换算值也可以带着范围每次更新”，但我从未见过这样的换算表。制作成表格这一行为本身，就容易导致固定化。

 数字附着在哪里——在按总量计算的方式中，人日和金额只附着于总量，不会附着于单个事项。逐项乘以换算值时，“这个事项是 3 人日”这样的数字就会在事项层面产生。副作用会由此连锁：可以逐项压价，可以责备一个在“3 人日事项”上花了 5 天的人，可以在团队间比较单价，而估算者也会预先考虑这些而抬高点数。一旦金额附着到事项上，点数就会变成绩效指标，古德哈特定律便开始起作用。如果数字只附着于总量，单项估算就不会受到压力，相对比较的速度和达成共识的便利性也能得到保留。第9期的四种类型（对照表型、成绩单型、压价型、沉默型）中，除了沉默型以外的三种，都是由此产生的。

 检视与适应的循环是否能够运转——速度是事后测量并回到下一次预测中的数值，因此按总量计算的方式会在每个 Sprint 中自我修正。偏差会以“预测更新”的形式出现。若在估算阶段就乘上换算值，计划便在当时确定下来，与现实的偏差则会以“延期”的形式出现。即使是同一种偏差，一方会成为学习，另一方却会成为责任问题。每次按平均值安排却失准时都说“这次是特殊情况”，正是这个循环没有运转的表现。

 会计单位——“总量÷速度×团队月成本”是在计算“让这个团队运行几个月”，它自然适用于为固定团队按周期配置资金的模型。逐项赋予人日，则是在计算“各个交付物的成本”，会被拉向一种要求单项估算精度、并在每次变更时重新估算与重新审批的模型。第9期的处方中，之所以用团队的运营费用回答“需要多少钱”，正是因为这一差异。

 顺带一提，一个常见的实践陷阱是：在不少现场，“1 点＝0.5 人日”中的 0.5，并不是从速度得出的，而是根据“理想人日”设定的。在这种情况下，包含会议和插入工作的团队实际吞吐量没有进入公式，因此会造成系统性的低估。用速度相除的方式，会自动将这类开销作为测量值包含在内。即使是本文一行备注中写着“插入工作多”的 Sprint，也会默默地被纳入范围之中。

 总结一下。如果正确制作并正确使用换算值，计算结果是相同的。不同之处在于：是将速度作为动态观察值处理，还是固定为常数；人日是只附着于总量，还是附着于每个事项；以及由此导致检视与适应的循环能够运转，还是会停止。用一句话来说，就是不要将团队的流量变成事项的成本。第9期和本期想表达的，归根结底就是这一点。

下期：“Sprint 内每次都会出现无法完成的任务”