预测开发速度

更准确地估算燃尽图表中的速度

燃尽图（Burn-Up Chart）在敏捷开发中非常普遍。对于可能不熟悉的读者来说，它被用来通过可视化已完成的工作与项目在任意时刻应有的进展之间的差异来传达开发进度。然而，传统燃尽图的设计假设开发从一开始就全速启动¹。但由于各种原因（比如团队的实际速度与计划的速度不一致），在实际操作中，这种情况很少见（例如，团队的实际速度与所需速度不符，或者开发人员需要时间来适应新技术或从其他任务中转移）。我们需要一个新的方法。

有许多大型公司因为在程序报告表面上看起来并不特别吸引人而在这一方面苦苦挣扎。简而言之，程序报告只是伴随 TPM（技术项目管理）而来的副产品，它只是在 TPM 讨论图表没有显示的内容时才被关注：实际的开发速度、未来的计划和预期的工作量。我们或我们的利益相关者为什么要为这些事情费劲呢？这会引发部门间的摩擦。预计的开发速度 解决了这个问题。

咱们看看一些图表吧！

经典燃爆图 1.0

经典的燃尽图非常基础，并假设所有开发都是从同一时间开始的，并且整个项目期间开发速度都保持在100%。为了表示这一点，我们采用三组数据系列。

预计开发工作量 — 表示解决方案规模的数字。顺便提一下，领导层常常要求使用已知工作量。我们将在后面的章节中进一步探讨这个概念。

进度（即已完成的工作）。已完成工作的总故事点数（即经过测试并被接受的）。

速度指引—— 每个冲刺周期内平均需要的任务点数。

我们需要看看一些真正的图表，所以让我们先通过一些假设来为我们的讨论打个基础。

假设：

• 交付日期不能调整。
• 不能缩小范围。
• 基础设施设计非常高效。
• 我们不能累积技术债务。
• 现在我们只考虑一个敏捷团队，尽管可以添加更多团队。
• 敏捷团队有8名开发人员。
• 所有的开发人员在同一级别，每个冲刺预计交付5个故事点。
• 团队预计的速度是每冲刺40个故事点。
• 开发窗口是24个冲刺周期。
• 工程主管已经将项目估算为990个故事点。
• 团队已经完成了424个故事点。
• 项目需要每冲刺42个故事点的速度。（990除以24个冲刺等于42）

图1：一个传统的燃尽图（本文中称为“经典1.0”）。请注意，速度提示尚未达到预计的工作。

从图1的例子中，我们可以发现一些情况：

1. 我们已经完成了这个项目的超过一半。
2. 我们本应该完成 562 点，但实际上只完成了 424 点。
3. 项目的启动比预期的慢了一些。
4. 团队的速度只有 40 点，而项目需要 42 点，所以按照目前的资源，团队可能无法完成这个项目。

领导层开始感到担忧，会议也变得艰难。这是因为图表没有显示的是，你为了使项目回到正轨而努力寻找解决方案的工作（在用尽了其他保持预算进度的策略之后，将需要增加承包商的参与）。不幸的是，传统的燃尽图只显示了已完成的工作，无法提供将要完成的工作的见解。为此，我们需要增强经典图表，以增加预测功能。

经典版烧图 1.1：基本预估

尽管我们将要探讨的信息能够提升图表的传达效果，如果流程或合作伙伴不允许进行必要的调查以构建额外的洞察，这只是一个不完整的解决方案。可以将其视为一个公平的中间地带。我鼓励大家通过工具和流程争取更多的数据，以提升合作并更深入地了解项目情况。

经典燃烧图 1.1 增加了两个额外的数据系列来回答“我们什么时候能达到速度目标？”

1. 计划工作 — 下两个冲刺中的故事点(即迭代中的故事点)。

2. 预计进展 — 计划的任务加上上一期的进度。

我们还将扩展我们的假设范围，包括但不限于以下几点，

• 团队正在获得支持，即将开始第25.16次冲刺。
• 我们预计到第25.20次冲刺时，团队的速度会翻倍。

图2展示了灰色柱状图表示的计划努力被加入到已完成的工作中。

图2显示计划的工作追加到进度中，这迅速传达了预测信息。在这个场景中，现在的两个团队计划在未来五个冲刺中完成312个点，这将略高于模型的预期。

领导们会为看到这样的数据而感到兴奋，但我们可以做得更多来传达项目的健康状态并减少棘手的会议。这就带我们来到了预期速度。

预计速度

如前所述，经典燃尽图中的速度指导假设所有冲刺都相同。没有学习曲线、优先级冲突或休假。正因为如此，开发进度常常在项目初期滞后，直到经过多个冲刺才能达到所需的开发速度。预测速度解决了这一问题，通过支持可变的工作量来应对。

我们需要再把假设扩展一下：

• 工程主管或Scrum Master提供了考虑了竞争性承诺、带薪休假和知识传递的团队分配比例。

新的计算使我们对数据有了更诚实的解读。让我们来梳理一下我得出这个结论的过程：

1. 技术负责人估算功能、能力。

2. 工程负责人也给出了他们对团队容量的预估，因为在他们抽身于其他工作的时候。

1. 你考虑常见的PTO时间，并把它们算进去。

展示了如何全年衡量团队速度的例子之一。

4. Scrum主管告诉你团队的速率是40.

5. 最后一步，我们将冲刺的容量（即冲刺的规模）乘以团队的速度，并返回图4。

图4显示了对速度的影响。在图1中，团队在开发进度上仅落后了一个冲刺周期。这张图表显示，这个差距会接近7个冲刺周期。

现在变得很清楚，产品范围与可用开发人员数量以及团队构建所需时间之间存在不匹配，不过你有足够的缓冲时间来减轻这种风险。

幸亏自那次分析以来，我们成功地通过供应商增加了人手。招聘、入职等流程需要几个月的时间，因此我们需要将团队规模翻倍以在项目的第二半阶段提升预期的项目速度，如图5所示。

图5. 增加了团队权重以调整输出结果，使其符合您的计划。

这张图表看起来好多了（图6）。你已经成功地向所有相关方传达了初期进展会比较慢的信息，但你通过与一家供应商合作，将他们的团队在第25.16个冲刺周期内完成入职，并在第25.20个冲刺周期内达到100%的生产力水平，从而降低了风险。

图6将团队能力（team capability）叠加在预测的团队速度（Projected Velocity）上，以展示增加团队成员直接导致速度提升。

使用估算的工作量来计算预计的开发速度确实需要更多的前期准备工作。但这能提供一个更干净、更准确的燃尽图，支持你整个项目的全程。这并不意味着已知的工作量不重要，它仍然需要跟踪。

如图7所示，这是已知努力在程序运行过程中累积的情况。只有当额外的工作量超出团队的产出量时，该指标才变得重要。这时你将发现了一个需要立即处理的风险。

图7展示了一个使用高级指标的燃尽图表。

使用Projected Velocity时，进展将更符合你的指导，与相关方的对话将聚焦于保持计划的实施，而不是修复一个表现不佳的进度。

已知的努力，进一步扩展一下

我相信你们中的一些人可能已经开始抱怨我们是否应该用已知的工作量来追踪进度。在确定经典燃尽图中的速度指导方针（注意，预计速度燃尽图依赖于团队的知识和承诺）时，这将是最好的衡量标准；然而，你们遇到了如何解释敏捷原则中相互冲突的理解的难题。但这完全是另一个话题，但根据项目的规模，你们在最初的几次冲刺中可能无法确定85%的工作量。

在敏捷环境中，所有的用户故事在细化过程中可能需要一段时间，你对已知工作量的理解是逐步加深的。因为传统的燃尽图使用这个指标来计算速度基准，随着你对工作量的进一步了解，速度基准也会随之波动，这使得直到项目后期才有可能确认当前的开发人员数量是否合适，而那时调整风险已经比较困难。

图8a展示了在第一次冲刺回顾中，已知的工作量仅为50点时燃尽图的外观。图8b到8d中，已知的工作量逐步增加，这改变了所需的速度，在项目后期产生了负面影响。

_图8_展示了随着更多信息被发现，所需速度从一次冲刺到另一次冲刺如何变化。该项目最初每冲刺需要2个点的速度，经过4个冲刺后，速度增加到每冲刺需要28个点。如果团队一旦识别出工作并立即完成所有工作，到第25个冲刺时，他们将完成50个点；然而，将比计划落后62个点。这种情况有几个麻烦，最主要的是，你将很难调整速度，这将导致很多艰难的对话，并且需要很多努力来缓解风险。

反对和障碍

从与 TPM 的交谈中，我们听到几种对上述（或任何）方法的反对意见：

常用的工單管理軟件（如 Jira）使用標準方法學計算程序的 velocity，也不支持基本許可證的自定義或自定义功能。

对公司支持的软件做出更改几乎是不可能的。不值得为此费劲。这里有一个你可以使用的模板这里。虽然它是手动的，但希望你需要的输入数据很容易获得。一旦配置好，更新应该不会超过几分钟。提示：下载这个文件。

组织并没有很好地利用企业软件。此外，他们也没有意愿去探索和承诺实施这种软件所需的流程调整。

先从小规模做起。由于变革对组织来说可能显得非常令人畏惧，预计最开始可能需要一两个团队手动进行计算，用作概念验证。随着领导者开始看到其中的不同和好处，你会更容易获得在更大范围内推广这一举措的支持。

如果你想有个好的开端，可以看一下这里的模板这里。提示：这里下载文件。

找到专业的工具知识很难。

我对这句话既同意也不同意。找到具备实际操作知识的 Jira 或其他 CMS 工具的人是个挑战，但这种情况与第二个反对意见直接相关：组织不喜欢改变，让团队接受新流程或工具的使用可能比较困难，因此工具被低效使用，相关知识也因此未能得到发展。

需要有两个承诺：

1. 对于领导层，我们需要你们重新评估标准燃尽图的使用，并承诺支持对流程和工具进行有意义且合理的变更，以获得更清晰的洞察。
2. 从TPMs，我们需要你们承诺通过推进新的或增强的工作流程、报告和工具等，为领导层带来实际可行的洞察，从而提升我们专业的影响力，

合作伙伴们不给出团队人力估算。

真是挺烦人的，不过这还没到天塌下来的地步。

1. 如果有历史团队数据，你可以将团队在预期休假周的速度除以之前几周的平均速度，以得到容量百分比。请确保考虑到主要的日历系统：公司的公共假日以及个人的宗教假日。
2. 如果没有历史团队数据，可以和同事交流或根据自己的判断，但不要过度。如果冲刺期的容量略低于实际情况，只会对你有帮助，因为你比预期做得更好；然而，如果容量设置过低，可能会导致团队规模扩大，进而影响项目预算。

此外，在您确定了数字之后，与您的领导讨论如何在未来获取这些信息。他们应该有获取信息或支持您估算的方法。

总结

好的数据对企业成功很重要。这不是很显然吗？确实如此。你需要知道成本和收入，这样才能算出投资回报率¹⁰。一旦知道哪个产品更赚钱（即性价比更高），你就能知道怎么把赚的钱再投资回去，继续扩大收入。

如果首席执行官依赖于业务运营与策略的ROI计算和统计分析来做出明智的决策，那么当我们讨论提供给实施和产品团队的领导者和利益相关者的数据类型时，我们为什么会有更低的标准呢？坚持使用无法产生有用数据的过程（例如，根据你需要的速度而不是你实际拥有的速度——经典的燃尽图（Burn-Up 图）与预测的团队速度）就是拒绝了TPM或PgM角色的核心目标：持续改进。无论是人员管理、流程管理还是产品管理，都需要有持续改进的愿望、决心和精力。作为TPM，我们肩负的角色是通过改进工具和流程提升合作伙伴关系、员工体验和整体效率，从而降低成本并提高效率。因此，PMO需要引领我们的合作伙伴创新运营效率。

经典的燃尽图非常适合那些专注于每个冲刺表现的工程师。如果需要在开发前进行研究，工程师们会创建一个研究任务或调查工单，然后根据团队的实际速度而不是项目所需的速度，将其分配到合适的冲刺中。结果是敏捷团队的冲刺指标看起来非常理想，但由于开发推迟了一个冲刺，项目现在（稍微）偏离了原定时间表。

因为经常需要在项目评审中查看燃尽图报告，是时候重新设计我们传达准确计划并设定恰当期望的方式了。是时候开始使用预测速度或Projected Velocity了。

聊天开场白：

• 你被要求提供哪些其他指标，你通常怎么展示这些数据？
• 你觉得这种方法有哪些问题？你会怎么解决这些问题？

注释

1. 查看和理解燃尽图, Atlassian, 2024年10月11日 ↑

2. 以通过使用团队配置、承诺和其他变量，为程序提供更可靠的 Velocity 指标，从而预测速度。

1. 工程团队常常会用T恤尺码来估算工作量，例如“大号”或“超小号”。除非你们对T恤尺码的评估标准和开发者的速度目标达成一致，否则这种估算方法是没什么用的。如果你还没有使用类似的估算方式，下面是一个故事或功能的T恤尺码评估准则示例。按照我们的标准，一个开发者在一个冲刺周期里应该能完成大约5个故事点。 ↑

4. 速度 = 当前估计的工作量 / 整个项目中的冲刺总数

5. 可变容量是指由于采用新技术、减少其他承诺的内容或请假等原因导致的预期输出波动。

6. 提供商业价值、满足相关方的需求且能够在规划周期内完成的功能特性。“特性”，Scaled Agile, Inc. 2024年10月11日 ↑

7. 一个为内部或外部客户带来价值的产品、系统或服务等。 “解决方案”，Scaled Agile公司 10/11/2024

8. 已知的投入 = (4+6+12+28) = 50 ↑

9. (完成的冲刺 × 所需速度) — 实际付出 = (4 × 28) — 50 = 62

10. 投资回报。投入的资本和得到的回报。