在敏捷和Scrum方法论的领域中，很少有概念会像速度一样，常常引起极大的困惑和焦虑。它经常被管理层视为绩效评分卡，或被团队当作僵化的目标。这一指标常常偏离了其最初的意图。速度是团队的工具，而不是经理手中的鞭子。正确理解时，它能提供关于团队容量和可预测性的洞察；而一旦误解，就会扭曲行为并破坏信任。
本指南探讨了速度的真实本质，它在Scrum框架中的运作方式，以及保持其健康状态的关键边界。我们将深入技术定义，分析导致误解的常见陷阱，并探讨如何利用数据提升流程效率，同时不损害心理安全感。
🧩 Scrum中的速度是什么？
从根本上说，速度是Scrum团队在单个Sprint中能够承担的工作量的度量。它并非传统意义上的速度，也不是衡量生产力的通用标准。相反，它是基于团队自身历史表现得出的相对度量单位。
- 它是回顾性的： 它基于过去Sprint中完成的工作来计算。
- 它是团队特定的： 它反映了特定团队的独特能力、技能组合和上下文环境。
- 它是规划辅助工具： 它的主要目的是帮助团队预测未来可以承诺的工作量。
速度起到稳定器的作用。随着时间推移，如果团队在‘完成定义’和估算技术上保持一致，速度数值往往会趋于稳定。这种稳定性有助于更准确地进行产品预测。然而，将这一数值视为固定目标，反而会引发摩擦。
⚙️ 速度如何计算
理解计算机制对于理解该指标的局限性至关重要。速度通常通过故事点来得出。故事点是一种相对估算技术，用于衡量用户故事的工作量、复杂性和风险。
计算公式
计算过程虽然简单，但输入数据需要严格的纪律：
- 识别Sprint中完成的所有用户故事。
- 确保每个项目都满足‘完成定义’（DoD）标准。
- 将这些已完成项目所分配的故事点相加。
- 所得总和即为该Sprint的速度。
至关重要的是，已经开始但未完成的工作不计入。而后期添加并完成的工作则计入。这一区别对于保持准确性至关重要。
- 已完成的工作： 只有完全满足验收标准的项目才计入得分。
- 部分完成的工作： 未完成一半的故事在计算中被忽略。
- 探针（Spikes）： 限时研究冲刺通常不会计入速度，除非它们产生了可交付的增量。
- 技术债务： 重构任务如果满足完成定义（DoD），则会贡献于速度，但必须与功能工作保持平衡。
🚫 速度的常见误用
危险不在于指标本身，而在于外部利益相关者如何应用它。当速度脱离上下文被使用时，它就变成了压力的来源，而非规划工具。以下是该指标被误用的最常见方式。
1. 团队之间的比较
最具有破坏性的错误之一，就是将团队A的速度与团队B的速度进行比较。这种比较本质上是错误的，因为：
- 估算尺度不同：团队A可能将一个故事估算为5点，而团队B则根据自身的校准将同一故事估算为8点。
- 复杂性不同：一个团队可能在具有高技术债务的遗留系统上工作，而另一个团队则在全新的项目上工作。
- 团队构成：拥有资深架构师的团队与由初级开发人员组成的团队，其运作方式会截然不同。
根据速度对团队进行排名会鼓励内部竞争，抑制协作。它暗示数字越高越好，从而激励团队虚报点数。
2. 设定目标
管理层常常试图设定速度目标，例如“我们需要你们每冲刺完成40点”。这会将一个描述性指标转变为一个规定性目标。当速度变成目标时，以下行为就会出现：
- 虚报估算：团队成员可能会虚报故事点数，以确保达到目标。
- 削减范围：团队可能会将功能拆分成更小的块，以人为地增加数量。
- 牺牲质量：重点从交付价值转向达成数字，可能导致跳过测试或文档编写。
3. 向利益相关者预测日期
仅根据单个冲刺的表现，使用速度向客户承诺具体的发布日期是危险的。速度是波动的。团队可能因为假期、病假或未预见的技术障碍而出现低速冲刺。仅用一个数据点来承诺日期，会造成不切实际的期望。
4. 衡量个人绩效
速度是团队指标。将其分解为个人绩效，违反了Scrum原则。敏捷依赖于跨职能协作。如果一个开发人员完成了5点，另一个完成了8点，进行比较会忽略任务的复杂性以及它们之间的依赖关系。
✅ 速度的正确应用
正确使用时，速度服务于团队的自我管理。它是一面镜子，而不是一把锤子。以下是有效利用它的方法。
1. 冲刺规划
速度最恰当的用途是在冲刺规划中。通过查看过去三到五个冲刺的平均速度，团队可以确定下一个冲刺的合理容量。
- 平均值计算：将最近3-5个冲刺的积分相加，再除以冲刺的次数。
- 承诺：团队将工作拉入冲刺，直到总估算积分与该平均值对齐。
- 缓冲区：为了应对中断或意外工作，建议将计划略低于平均值。
2. 发布预测
速度有助于回答这个问题：“产品何时可以完成？”通过将剩余的产品待办事项总积分除以平均速度，团队可以估算出完成工作所需的冲刺次数。
- 范围，而非具体日期：将预测以范围形式呈现（例如：“第10到第12个冲刺之间”），而不是具体日历日期。
- 滚动更新：随着新信息出现或待办事项列表发生变化，定期更新预测。
- 透明度：与利益相关者公开分享预测，以便他们理解范围与时间之间的关系。
3. 识别趋势
跟踪速度随时间的变化，可以揭示团队或流程中的健康状况指标。
- 持续下降：持续下降可能表明团队倦怠、技术债务增加，或团队构成发生变化。
- 持续上升：突然上升可能表明之前的估算过于保守，或团队找到了更高效的流程。
- 波动性：高波动性表明流程或完成定义存在不稳定性。
📉 速度 vs. 容量
必须清楚区分速度和容量，混淆两者会导致过度承诺。
- 容量：指团队可用于工作的可用时间（以小时为单位），包括假期、会议和支持工作。
- 速度：指完成的工作量（积分），反映了团队的速度和效率。
一个团队可能拥有高容量（大量可用小时），但速度低（难以应对复杂性）。相反，一个团队可能容量低（会议较多），但速度高（效率高）。规划需要平衡两者。
| 指标 | 度量单位 | 主要目的 | 谁应该使用它 |
|---|---|---|---|
| 速度 | 故事点 | 预测与规划 | Scrum团队 |
| 容量 | 小时 | 排程可用性 | Scrum团队与Scrum主管 |
| 燃尽图 | 小时/点数 | 跟踪进度 | 利益相关者与团队 |
🧠 指标的心理学
指标会影响行为。这是组织心理学的基本原则。如果你衡量X，人们就会针对X进行优化。当速度成为成功的主要衡量标准时，团队会优化速度，而不是价值。
心理安全感
为了使速度准确，团队必须感到安全，能够坦白工作受阻或估算错误的情况。如果团队担心低速度会导致惩罚，他们将会：
- 低估风险。
- 隐藏障碍。
- 避免承担复杂任务。
这会导致进展的假象。在恐惧文化中，高速度数字往往是功能失调的迹象，而非效率的体现。
持续改进
速度应在回顾会议中讨论，但不应作为关键绩效指标。相反，应讨论导致速度的流程导致速度的流程。
- 为什么这次冲刺比平时慢？
- 我们是否受到了太多干扰？
- 完成的定义是否过于严格或过于宽松？
通过关注流程，团队能够改进底层系统，从而自然地使速度在时间推移中趋于稳定。
🔄 处理波动与异常情况
并非所有迭代都完全相同。速度的波动是正常且常常可以预期的。理解这些波动发生的原因，是正确解读数据的关键。
1. 团队变动
如果一名开发人员离开或有新成员加入，速度很可能会发生变化。新成员存在学习曲线，他们可能需要更长时间完成任务，或者以意想不到的方式做出贡献。不要期望速度能立即与之前的数值持平。
2. 范围蔓延
如果利益相关者在迭代中途增加工作，速度可能会下降，因为团队用于完成承诺事项的时间减少了。另一方面，如果团队成功吸收了这些变更，速度可能保持稳定，但这会带来倦怠的风险。最好拒绝范围变更，或将它们移至待办事项列表中。
3. 技术债务
随着技术债务的积累，速度通常会下降，因为需要投入更多精力才能进行更改。这是一个信号，表明应专门安排迭代进行重构。忽视这一点会导致性能缓慢下滑。
📊 总结：建议与禁忌
为了确保速度始终是一个有用的工具，请遵循以下准则。
| 建议 ✅ | 禁忌 ❌ |
|---|---|
| 仅用于内部规划。 | 用它来比较团队。 |
| 基于已完成的工作来计算。 | 计算部分完成的工作。 |
| 在回顾会议中讨论趋势。 | 将其设定为绩效目标。 |
| 关注相对估算。 | 关注工时或个人产出。 |
| 接受波动为正常现象。 | 惩罚速度的下降。 |
| 定期更新待办事项列表。 | 长时间锁定范围。 |
🚀 可持续增长的最终考量
速度是健康系统的副产品。如果系统健康，速度将趋于稳定；如果系统出现问题，速度将剧烈波动或下降。目标不是最大化速度，而是最大化价值交付。
当管理层理解速度是一种规划约束而非生产力引擎时，局面就会发生变化。团队能够基于证据自主设定节奏。利益相关者学会基于范围而非承诺来管理期望。焦点重新回归到交付能够解决用户问题的高质量软件上。
请记住，指标是用于检查与调整的工具，它们本身并不是目的。始终将团队置于对话的核心。让数据为决策提供依据，但让人类判断来引导战略方向。
🔍 常见问题
速度可以无限增加吗？
不行。团队能够吸收的工作量存在生理和认知上的限制。随着复杂性的增加，速度通常会趋于平稳或下降。速度持续增长通常表明估算标准正在松懈，而不是生产力在提高。
如果我们不使用故事点呢？
速度可以用其他单位来计算，比如小时或理想天数，尽管故事点因其脱离时间的抽象性而更受青睐。无论使用何种单位，原则都是一样的：根据过去的表现来衡量已完成的工作量。
速度是否考虑了缺陷？
只有当修复缺陷符合完成的定义时才会计入。如果修复缺陷是一个新增到待办事项列表的任务，那么一旦完成，其对应的点数就会计入速度。如果这是已交付工作中的缺陷，则通常作为单独事件处理。
我们应该平均多少个冲刺？
至少三个冲刺可以提供一个基准。五到十个冲刺能提供更稳定的趋势线。应使用最新数据，因为它反映了团队当前的状态和背景。
通过尊重速度的细微差别，团队可以避免陷入以指标为导向的管理陷阱。指标应服务于团队，而不是相反。这种对齐创造了可预测性和质量共同发展的环境。
