本文要点

敏捷团队通常会参与交付业务的重大里程碑，这种里程碑是业务在特定时间点所期望的，相关的预算也是商定好的。所以团队需要做好预测，否则就可能会被指责"敏捷却迟到"。

根据逻辑，项目延迟有六大可能的原因——也就是“逻辑六成因”。其中的三条因素是在技术团队控制下的：低估工作量；缺乏可用的人才；并且缺乏团队生产力。另外三条是发起人控制的：需求不明确；范围变更；并且缺乏所需的持续投入。

有一些指标针对的就是这六条潜在的延迟原因——测量这些指标以提高预测的准确性是至关重要的。

这些指标需要从多个数据源中总结出来，因此需要端到端的交付指标/分析平台，否则这些指标就很难评价。

然后可以使用这些指标创建红色/琥珀色/绿色（RAG）根本原因进度报告——与发起人共享更准确的预测和明确的改善措施，并分配责任来实施已确定的改善措施。

我们合作的敏捷团队有着多种多样的规模和形态，而可预测性几乎是所有主题的重中之重——因为“敏捷”和“可预测”这两个词并不总是相辅相成的……

那么开发团队如何才能保持敏捷并提高交付的可预测性呢？做到这一点，当利益相关方问到关于可预测性的问题“我们是不是在如期推进？”，他们才可以给出一个有意义的回答。

典型的敏捷团队预测方法

基于产品的敏捷软件开发团队会频繁交付小幅度的增量改进，可能很少花时间来操心预测的话题。

但是，敏捷团队往往需要交付一些重大里程碑，这些里程碑是业务在特定时间点所期望的，相关的预算也是商定好的；因此团队需要有效地预测，否则就可能被指责为“敏捷却迟到！”。

根据我们的经验，敏捷团队的预测往往很不准确，并且通常仅基于团队本身对积压、速度和口头保证的简单观察结果。

我们认为，真正有意义的预测需要更广泛的经验数据集，以反映会导致项目延迟的所有潜在因素。

像这样的“项目”环境中是否适合使用敏捷软件开发方法，还有另一场争论，但这就是另一个话题了

“逻辑六成因”——项目延迟的六大原因

逻辑表明项目迟到可能有六条成因——也就是所谓的“逻辑六成因”。六成因中的三条是由技术团队直接控制的：

任务的大小和复杂性被低估了
计划中符合需求的工程师小组并不可用
交付团队的交付效率不及预期。

其他三条由与技术团队互动的业务发起人控制。这些是：

需求定义不清晰——内部客户对他们实际想要的东西不够清楚
范围变更——业务目标内容变化（变更/新需求或优先级改变）
持续的投入——在需要的地方/时间缺乏利益相关者的投入而延迟了开发过程。

我们认为，你需要收集跟踪所有这六条杠杆的指标，否则你将永远无法真正准确地预测，并提升交付的可预测性。

只有做到这一点，你才能真正了解一个项目是否可能“迟到”，以及需要做什么才能使其回到正轨上。

"逻辑六成因"——项目延迟的六大根本因素

通过分析重要的交付指标来挑战团队的预测结果

那么，与项目延迟的六大成因相关的测量指标都有哪些，它们对于交付的可预测性和预测准确性的提升是至关重要的吗？

下表显示了我们在每个领域中最喜欢的一些指标。我们鼓励交付主管在与交付团队负责人合作，重点关注这些指标，以做出更现实的预测。

概括来说，这些指标有：

人员可用性——显然很关键。如果我们没有所期望的工程师，我们将迟到。
团队生产力涉及：
1. 生产时间——另一大关键指标，考虑了工程师必须专注于编写新功能的时间比例
2. 流程效率——开发流程中的摩擦会破坏最佳的交付计划。因此，真正了解这种摩擦的趋势及其成因是关键
3. 实现价值的速度和时间——了解我们的吞吐量和实现价值的时间如何随着项目的进行而变化，是我们预测中的另一个决定性变量
估计精度——如果我们采用基于Scrum的方法，则冲刺的完成水平是衡量我们预测能力的很好指标。如果我们无法达到每两周的冲刺目标，那么我们就不太可能有效地估算工作量并进一步预测未来
可以使用从协作中心（如Slack）收集的量化工程师反馈来跟踪需求定义、利益相关者的输入和范围变更。我们在内部经常使用这种方法来改进我们的预测，因为它利用了实际工作人员的定量观察能力。它通常会为原本只在理论上的交付预测增添信心，并使人看清楚“逻辑六成因”中的三条（需求定义、利益相关者的投入和真实范围变更）。

跟踪导致项目延迟的逻辑六杠杆的关键指标

趋势指标	相关性
可用的工程资源： - 活跃工程师人数（与计划相比）	显然是关键——显示我们是否有计划的资源来交付工作。
生产时间 - 在新功能上花费的时间（%） - 花费在维护上的时间（%） - 与非产品相关的活动损失的时间（%）	关键指标，用来了解随着时间推移的趋势变化。如果我们在非生产性任务上花费更多的精力，显然这将影响我们的前进步伐。
流程效率 - 流量效率（%） - 返工（工作日） - WIP/开发人员	这些指标分析了开发过程中的"摩擦"及其随着时间推移的趋势。流量效率下降往往是一个可以解决的问题，因此它是改善预测的关键指标。返工显示了处理未通过质量检查的故障单所花费的累积时间趋势。这是另一种形式的摩擦，可以改善（例如通过协助刚接触代码库的工程师）。注意：我们认为，各个级别收集到的任何指标都需要直接参与项目的人员根据具体情况来查看。如果传播范围更广，这些指标的评价可能会脱离上下文（具有破坏作用）。
实现价值的速度和时间 - 完成的功能门票 - 循环时间（工作日） - 交货时间（工作日）	速度指标存在自己的问题，但是在做出预测时，关键在于要对已完成门票的趋势（以及每张门票的故事点/价值点）有着深度理解。对周期和交货时间变化的理解也很重要。如果它们在延长，那么做出准确的预测就很困难。
冲刺精度 - 总体完成率（％） - 冲刺总体完成率vs冲刺目标完成率（％）	如果无法实现每两周的冲刺目标，就很难做出较长时间的预测。因此，这些指标对于预测准确性而言至关重要。
量化工程师反馈 - 团队士气 - 冲刺效率 - 门票质量和要求定义 - 业务发起人的投入质量 - 与商定的范围变更相关工作	一些指标平台可以通过协作中心对工程师进行实时调研。这提供了以下定量数据： - 工程师对士气和流程效率的看法；和 - 业务发起人的需求定义和持续投入的影响 - 团队负责人对业务的利益相关方在原始范围之外添加的故事的反馈。

收集重要的交付指标

关键交付指标需要从众多来源收集数据，包括：工作流程管理工具、代码仓库和CI/CD工具——以及从工程团队本身（通过协作中心）收集的定量反馈。

数据的复杂性和来源的多样性使人工收集此类数据的工作非常耗时，需要端到端的交付指标平台来大规模收集。

可行的交付指标平台由以下内容组成：一个数据层，用于整理和编译来自多个数据源的指标；一个灵活的UI层，用于创建自定义仪表板，以所需格式显示指标。

使用根本原因RAG报告来改进你的交付预测和改善计划

如果我们使用一些指标来跟踪和分析影响项目进度的六大逻辑驱动因素，就能获得更清晰的项目实际进度图。也就是说：

更现实的交付预测
如果预测结果落后于时间表，我们可以致力于明确的改善计划。

改进的预测和相关的改善措施可以在红色、琥珀色和绿色（RAG）根本原因进度报告中一起显示。

根本原因RAG报告要比传统的RAG进度报告有效得多，传统的RAG进度报告通常很少说明（具有所需上线日期）的项目落后于计划的实际原因，以及需要做什么才能回到正轨。

与传统的RAG方法相比，根本原因RAG报告（请参见以下示例）清楚地显示了：

我们最新的交付预测
支持我们预测的交付指标
我们的改善措施（基于驱动项目进度的逻辑六杠杆）——例如，需要减少用于维护的时间来增加生产时间；需要解决开发流程中的障碍（例如质量检查等待时间）来提高流程效率；或需要改进利益相关者的投入（如量化工程师的反馈所示）
为了交付已确定的改善措施，在开发团队和利益相关者之间分配责任的情况

能做得好的话，根本原因RAG报告可以是一种非常有效的方式，以利益相关者可以理解的方式呈现我们的（更准确的）预测，因此可以成为减少延迟并使技术团队与内部客户联系更加紧密的重要步骤。

但正如所讨论的那样，它依赖于对导致项目延迟的实际指标的理解，以及收集这些指标的方法。

根本原因RAG报告示例

作者介绍

Charlie Ponsonby在发展中国家开始了他的经济学家生涯，随后加入了安德森咨询公司。他直到2007年一直担任Sky的市场总监，然后在2007年离开公司，创立了Simplifydigital。Simplifydigital在《星期日泰晤士报》科技追踪百强榜中三度登榜，并成长为英国最大的宽带比较服务。它于2016年4月被Dixons Carphone plc收购。2017年10月，Ponsonby和Dan Lee共同创立了Plandek。Plandek是端到端交付指标分析和BI平台。它从交付团队使用的工具集中挖掘数据（例如Jira、Git和CI/CD工具），以提供端到端交付指标来优化软件交付预测、风险管理和交付有效性。Plandek的客户遍及全球，其中包括Reed Elsevier、News Corporation、Autotrader.ca和Secret Escapes。

原文链接：

Agile and Late! End-to-End Delivery Metrics to Improve Your Predictability

创作场景

论敏捷与延迟：项目延迟六大原因，该如何避免？