本文要点
敏捷团队通常会参与交付业务的重大里程碑，这种里程碑是业务在特定时间点所期望的，相关的预算也是商定好的。所以团队需要做好预测，否则就可能会被指责"敏捷却迟到"。
根据逻辑，项目延迟有六大可能的原因——也就是“逻辑六成因”。其中的三条因素是在技术团队控制下的：低估工作量；缺乏可用的人才；并且缺乏团队生产力。另外三条是发起人控制的：需求不明确；范围变更；并且缺乏所需的持续投入。
有一些指标针对的就是这六条潜在的延迟原因——测量这些指标以提高预测的准确性是至关重要的。
这些指标需要从多个数据源中总结出来，因此需要端到端的交付指标/分析平台，否则这些指标就很难评价。
然后可以使用这些指标创建红色/琥珀色/绿色（RAG）根本原因进度报告——与发起人共享更准确的预测和明确的改善措施，并分配责任来实施已确定的改善措施。
我们合作的敏捷团队有着多种多样的规模和形态，而可预测性几乎是所有主题的重中之重——因为“敏捷”和“可预测”这两个词并不总是相辅相成的……
那么开发团队如何才能保持敏捷并提高交付的可预测性呢？做到这一点，当利益相关方问到关于可预测性的问题“我们是不是在如期推进？”，他们才可以给出一个有意义的回答。
典型的敏捷团队预测方法
基于产品的敏捷软件开发团队会频繁交付小幅度的增量改进，可能很少花时间来操心预测的话题。
但是，敏捷团队往往需要交付一些重大里程碑，这些里程碑是业务在特定时间点所期望的，相关的预算也是商定好的；因此团队需要有效地预测，否则就可能被指责为“敏捷却迟到！”。
根据我们的经验，敏捷团队的预测往往很不准确，并且通常仅基于团队本身对积压、速度和口头保证的简单观察结果。
我们认为，真正有意义的预测需要更广泛的经验数据集，以反映会导致项目延迟的所有潜在因素。
像这样的“项目”环境中是否适合使用敏捷软件开发方法，还有另一场争论，但这就是另一个话题了
“逻辑六成因”——项目延迟的六大原因
逻辑表明项目迟到可能有六条成因——也就是所谓的“逻辑六成因”。六成因中的三条是由技术团队直接控制的：
任务的大小和复杂性被低估了
计划中符合需求的工程师小组并不可用
交付团队的交付效率不及预期。
其他三条由与技术团队互动的业务发起人控制。这些是：
需求定义不清晰——内部客户对他们实际想要的东西不够清楚
范围变更——业务目标内容变化（变更/新需求或优先级改变）
持续的投入——在需要的地方/时间缺乏利益相关者的投入而延迟了开发过程。
我们认为，你需要收集跟踪所有这六条杠杆的指标，否则你将永远无法真正准确地预测，并提升交付的可预测性。
只有做到这一点，你才能真正了解一个项目是否可能“迟到”，以及需要做什么才能使其回到正轨上。
"逻辑六成因"——项目延迟的六大根本因素
通过分析重要的交付指标来挑战团队的预测结果
那么，与项目延迟的六大成因相关的测量指标都有哪些，它们对于交付的可预测性和预测准确性的提升是至关重要的吗？
下表显示了我们在每个领域中最喜欢的一些指标。我们鼓励交付主管在与交付团队负责人合作，重点关注这些指标，以做出更现实的预测。
概括来说，这些指标有：
人员可用性——显然很关键。如果我们没有所期望的工程师，我们将迟到。
团队生产力涉及：
生产时间——另一大关键指标，考虑了工程师必须专注于编写新功能的时间比例
流程效率——开发流程中的摩擦会破坏最佳的交付计划。因此，真正了解这种摩擦的趋势及其成因是关键
实现价值的速度和时间——了解我们的吞吐量和实现价值的时间如何随着项目的进行而变化，是我们预测中的另一个决定性变量
估计精度——如果我们采用基于 Scrum 的方法，则冲刺的完成水平是衡量我们预测能力的很好指标。如果我们无法达到每两周的冲刺目标，那么我们就不太可能有效地估算工作量并进一步预测未来
可以使用从协作中心（如 Slack）收集的量化工程师反馈来跟踪需求定义、利益相关者的输入和范围变更。我们在内部经常使用这种方法来改进我们的预测，因为它利用了实际工作人员的定量观察能力。它通常会为原本只在理论上的交付预测增添信心，并使人看清楚“逻辑六成因”中的三条（需求定义、利益相关者的投入和真实范围变更）。
跟踪导致项目延迟的逻辑六杠杆的关键指标
收集重要的交付指标
关键交付指标需要从众多来源收集数据，包括：工作流程管理工具、代码仓库和 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
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论