本文要点

速度（velocity）预测的准确率通常在50%左右。我们是在掷硬币打赌
蒙特卡洛模拟是更好的预测方法
避免设定测量目标
关注趋势，而不是单一的数据点
测量系统的多个方面

Doc Norton在2019年体验敏捷（Experience Agile 2019）大会上表示，速度（Velocity）不适用于预测或诊断。它是一个过于波动的复杂系统的滞后指标，无法知道我们未来的表现如何；它不够稳定，无法可靠地使用。我们可以使用蒙特卡洛（Monte Carlo）模拟来预测、用累积流图（cumulative flow diagrams）来跟踪工作、查看范围的变化及发现瓶颈问题。

Norton把速度定义为随着时间推移交付价值的工作单元。他提到，这需要一个合理的衡量标准。但是，即使速度与实际部署或交付有关，它仍然没有告诉我们跟流程相关的任何信息。仅凭这个测量结果，我们无法判断一个团队的表现是否良好，他这样说到。

为了得到更高的概率预测，我们需要知道速度的历史、积压量、起始日期以及作为积压增长指示器的分割率。Norton演示了我们如何使用蒙特卡洛模拟来预测团队何时能够进行交付。根据我们希望拥有的置信度，团队将需要更多的时间直到他们能够交付。

关于诊断，Norton展示了我们如何使用累积流图。它们有助于我们跟踪在一段时间内完成的和未完成的工作数量、查看范围的变化以及看到瓶颈的所在。

Doc Norton是一位敏捷和领导力教练，他在2019年体验敏捷大会上就使用速度和其他指标进行了演讲。InfoQ对他进行了采访。

InfoQ：您如何定义速度？

Doc Norton：用最简单的话来说，速度是随着时间推移实现价值的工作单元。在大多数地方，它仅仅是个随着时间变化的工作单元，但是，那不是速度，因为它没有明确的方向。那只是速率。速度是个矢量，它需要一个方向；这就是我们为什么要加上“导向价值”这几个字。它提醒我们，我们在朝着一个特定的方向努力。在我看来，价值是学习、降低风险或增加效用。

对于我来说，我们直到意识到价值，才算速度。如果团队学到了一些东西（如新的处理方法是否增加了互动），我们确实降低了风险（如证明新的缓存技术在我们所依赖的脆弱系统宕机时有用），或者我们已经交付了效用（如用户实际参与的功能），那么，我们认为事情完成了，并把它算进速度。在很多地方，在开发完成时会计算速度。如果用户故事从未上线，它们仍然把它算进速度。我认为，他们漏掉了一个关键点。
在更深的层次上，速度还是一个复杂系统的滞后指标。与所有的滞后指标一样，关于预测未来，它们不是很有用，但是，在确认趋势和模式方面，它们做得不错。想想在多数零售领域的季度销售额，第4个季度并不是下一个第1个季度销售额的预测指标，但是，它可以为我们确定总体趋势，每年的年尾销售额都要更高一些。

InfoQ：您在演讲中表示，速度几乎没有什么用处。您能阐述一下吗？

Norton：到目前为止，我在敏捷大会上已经对1000多人进行了问卷调查。在被调查的人当中，约有90%的人对自己的速度没什么信心、速度和部署之间脱节或无法仅用速度来可靠地预测大量工作。

在接受调查的敏捷采用者中，只有10%的人认为速度对于实际测量和预测工作何时完成并投入生产是有用的。计划和预测是速度的目的。
基于这些数据，我认为，可以说速度几乎是无用的。

InfoQ：有时候，人们说速度是团队可以控制的东西。您怎么看？

Norton：这是个危险的观点，特别是如果我们是管理人员的时候。一个批评行动者的领导者忽视了大局，没有看到在创造结果的过程他们要扮演的角色。

每个系统都是完美的；它产生的结果与设计的完全一样。如果现行的系统在生成错误的结果，那么，这不是系统内行动者的错误，更多的是系统本身的错误。我们可以告诫人们不要成为更好的行动者。基于人类的某些信仰或规则（一些道德或伦理期望），我们可以坚持他们应该表现得不同。但是，所有人类行为的一个关键因素是人类正在操作的这个系统或环境。一个完全理性的人，如果想要做好工作，那么，在一个促进和奖励速度多过促进和奖励安全的环境中，他会夸大估计或偷工减料。这并非普遍如此。有些工作人员会坚持安全胜于速度。但是，在大多数组织中，大多数团队确实都受到了影响。
因此，当管理层专注于速度，或更糟的是，为速度设立目标时，那么，行动者的结果行为就是自然的结果。它不是控制系统的团队，而是创建这种控制的系统设计者。

InfoQ：如果团队希望使用速度来查看他们是否有改善，这可能吗？

Norton：也许吧，但是，不是很好。

首先，由于速度通常是每个迭代的故事点，并且，故事点是抽象的，并由团队估计，因此，速度极易偏移。
偏移是随着时间的推移而累积的细微变化。我们通常不会在较小的时间范围内注意到它们，但是，在一个比较广阔的时间范围内，它是显而易见的。以一个团队为例，他们知道应该随着时间的推移而提高速度。可以肯定的是，他们会这么做。我们可能看到，他们在交付更多的价值。但是，还有多少呢？我们如何能确定呢？

在很多情况下，如果我们从几年前的故事中选一组，要求团队重新评估它们，那么，他们会给我们一个比最初估计更高的整体数字。我的前提是，这是因为我们的估计常常随着时间的推移而升高。更大的估计偏差在每次迭代之间不是那么明显，但是，随着季度或年份的推移就变得明显。我们可以使用参考故事来帮助降低这种偏移，但是，我不知道大家是否可以消除它。

其次，即使我们可以证明，估计完全没有偏移，我们仍然只是测量了一个维度：交付的速率。为了知道我们是否在改善，我们可能也需要知道代码质量、客户采用率、客户保留率和系统性能等信息。
速度不会告诉我们关于系统健康状况、团队健康状况或公司健康状况的任何事情。它甚至不会告诉我们交付的健康状况。很难用这么少的信息来判断我们是否有改善。

InfoQ：对于使用速度来预测某事何时会完成，您的建议是什么？

Norton：预测的好坏取决于用来创建它的数据及技术。对于大多数团队来说，用速度估计意味着我们大概有一半对一半的机会在预测的日期或之前完成工作。想一想，我们在使用一种平均值和外推法，当然，我们的预测会在可能性范围内。它还意味着，我们几乎不知道我们会错过目标的差异有多大。可能的交付日期范围是几天、几个星期还是几个月？根据我们使用的技术，我们无法知道这个问题的答案。

我习惯对平均值应用标准差以得到范围。然后，我意识到，很多速度分布不符合高斯分布，而是偏移的。因此，标准差从数学上来讲是不正确的。难以用概率来解释范围。

目前，我知道的最可靠的技术是运行蒙特卡洛模拟。Focused Objective的人有个专门为我们做的电子表格；它被称为“吞吐量预测器（Throughput Forecaster）”，我们可以从Free Tools和Resources下载它。基于历史速度数据和大量的工作积压，他们运行500个模拟的项目来确定在设定日期前或在设定日期前完成工作的概率。这是对于发生了什么事情的一个简单解释，对于基本的理解来说，已经足够了。

该技术提供一个概率范围，允许我们更好地进行沟通。通过使用这个技术，很多客户已经发现他们使用的速度技术所产生的数值的有效率小于50%。当他们意识到，不是因为他们无法管理好团队，而是因为他们的预测制定得不充分，看到他们脸上如释重负的样子，真是太好了。

InfoQ：我们如何使用逃逸缺陷（escaped defects）来测量质量？

Norton：逃逸缺陷是在生产过程中发现的缺陷。对我教导的团队而言，没有其他类型的缺陷，因此，“逃逸”是多余的。但是，在一些组织中，存在质量管理（QA）缺陷和逃逸缺陷的概念。我们在这里关心的是逃逸缺陷。

测量在迭代或吞吐量样本中引入的逃逸缺陷的数量可能有帮助，但是，也可能会产生误导。我们可能会发现，每次迭代产生的逃逸缺陷的数量在增加。我们知道，这不是“好”消息，但是，我们是否知道，这个消息有多“坏”吗？
为了帮助我们做出决定，我们可以查看相对于吞吐量的逃逸缺陷的数量。这给我们一个比例，我们可以用来查看趋势。困难的部分是，我们需要作出一致的努力，识别出在哪个迭代或吞吐量采样周期中引入了缺陷。根据团队和系统的使用方式，这不总是容易做到的。

假设我们有速度历史，分别为8，9，12，14，19和21，相应的逃逸缺陷的数量为2，2，3，3，4，4。如果逃逸缺陷是衡量质量的指标，那么，该质量是提高了，还是下降了，或者保持不变呢？
如果我们只看逃逸缺陷，那么，我们可以得出结论，它们显然在增长。从这一点，我们可以总结出，每个周期我们发布的软件质量都在下降。

但是，如果，我们把它看作吞吐量与逃逸缺陷的比率，那么，我们得到0.25，0.12、0.25、0.21、0.21和0.19。从这一点，我们看到通过吞吐量的逃逸缺陷总体上是下降的趋势。这意味着，尽管在缺陷率上有增加，但是，实际上，相对于值的速率是下降的。

InfoQ：团队如何能更好地使用指标？

Norton： 如果团队需要以更有益的方式利用指标，那么，我认为，团队需要考虑这些事情。避免设定测量目标。关注趋势，而不是单一的数据点。测量系统的多个方面。使用这些信息来通知系统调整。

避免设定测量目标。当测量指标成为目标时，它就不再是好的测量目标了。古德哈特定律（Goodhart’s Law）就是这样阐述的。指标是关于系统如何运行的信息。它们是系统的副产品。当我们选取一种测量，通过设定目标，把它转换成一个控件，我们把该测量注入系统，实际上，我们改变了系统。这个测量指标就不是原来那样了，结果，我们刚刚设立的目标也完全不是最初预想的那样了。

关注趋势，而不是单一数据点。少关心今天的价值，多关心趋势。指标的趋势如何？它是否在朝着基于我们策略的期望的方向变化？如果趋势跟预期不一样，那么，要考虑一下，系统中的什么问题可能是根源，然后去解决它。要知道，有时很好的策略会造成指标跟通常期望方向的趋势相反。比如，当我们在从单体架构向微服务过渡时，代码倾向于变得更复杂。一旦旧的单体代码被移除，那么，复杂性会再次下降。

测量系统的多个方面。每个系统都有紧密的关系。如果我们只测量一个维度，那么，我们很可能不了解系统真正的健康状况。比如，如果我们只关注交付速率，那么，我们很可能没有注意到对质量、功能的客户采用率或员工满意度的影响。这些最终都会影响我们维持系统的能力。

使用这些信息通知系统调整。我们测量是为了提供信息，而不是为前进设定目标。我们查看趋势，把它们跟基于我们策略的预期进行对比。我们查看多个维度的信息以帮助我们确保我们没有过度优化特定的维度。当我们的趋势在任何这些维度上都偏离的时候，我们希望考虑需要做什么调整，使系统更接近健康的平衡。

受访者介绍

敏捷和领导力教练Doc Norton是软件交付专家，致力于让软件开发世界变得更好。他的经验涵盖了广泛的开发领域。Norton不会宣称专长哪门语言或方法来宣称，并对任何宣称自己专长的人立即表示怀疑。作为一名作家和国际演说家，Norton热衷于帮助他人成为更好的开发人员，与团队合作以改进交付，并建立伟大的组织。在OnBelay的工作中，Norton每天都有机会挥洒他的热情。

原文链接：

Velocity and Better Metrics: Q&A with Doc Norton

创作场景

专访软件交付专家 Doc Norton：速度和更好的指标