Story points vs 小时
发布: (2026年2月18日 GMT+8 00:23)
7 分钟阅读
原文: Dev.to
请提供您希望翻译的完整文本内容，我才能为您进行简体中文翻译。
软件开发任务估算
用小时估算的问题
“毫无疑问，大家都曾被要求或将来会被要求对某项任务进行估算。自然地，脑中浮现的下一个想法就是用小时来估算——毕竟，我们都知道一件事需要多长时间，这是一种我们日常生活中所有人都会使用的度量。”
在软件开发中，用 小时 进行估算可能导致：
- 个人压力：当汇总团队成员的估算时，平均的时间可能低于我们实际需要的时间。
- 不信任感：如果未能在平均时间内完成，我们会觉得自己不够好，并担心这会被解读为绩效问题。
故事点：是什么以及为何有帮助？
- 不衡量时间，而是衡量 相对工作量和复杂度（以及后文会提到的不确定性）。
- 当我们说一个任务有 5 点 时，指的是它 比 1 点的任务复杂五倍。
- 由于是相对的，估算不太依赖 谁来做，这有助于达成 共识。
使用故事点达成共识
假设我估算为 3 点，而玛丽估算为 2 点。我们可以不去直接取平均或随意选择，而是：
- 讨论任务的不确定性。
- 若仍有疑虑，提升至 3 点；若不确定性似乎更小，则保持在 2 点。
- 记住我们随时可以在以后 细化估算（见 重新估算 小节）。
努力与不确定性的表示
| 规模 | 描述 |
|---|---|
| T恤尺码 | XS、S、M、L、XL、XXL——精度较低，易于校准。适用于团队新建或信息不足的情况。 |
| 2的幂 | 1、2、4、8、16——每个值相对于前一个翻倍，体现更大的不确定性。 |
| 斐波那契序列 | 1、2、3、5、8、13——随着增长，表示不确定性提升。 |
| 短线性尺度 | 1‑5 或 1‑10——当不确定性看似较低时很诱人，但可能引发对中间值的争论（例如，6 与 7）。 |
Source: …
我了解的估算策略
- T恤尺码 (XS‑XXL)。
- 2的幂 (1, 2, 4, 8, 16)。
- 斐波那契 (1, 2, 3, 5, 8, 13)。
- 线性刻度 (1‑5 或 1‑10)。
每种方法都有其优点和缺点；选择取决于领域信息的成熟度以及团队的成熟度。
校准冲刺 (Sprint 0)
- 目标：验证所选规模在 第 1 级 实际任务中的有效性。
- 过程：团队挑选一些小任务，完成后将 实际工作量 与最初估计进行比较。
- 结果：根据获得的经验，调整剩余待办事项的估计。
任务重新估算
| 时机 | 操作 |
|---|---|
| 计划前 | 在仪式的前 15 分钟 内，细化将进入下一个冲刺的任务（不需要临时会议）。 |
| 接近冲刺的任务 | 如果团队认为任务与新基准差距很大，则重新估算。 |
| 积压中较远的任务 | 现在不需要重新估算；在被执行前它们可能会改变范围。 |
团队速度
- 速度 = 每个冲刺完成的平均点数。
- 示例：如果速度是 30 点/冲刺，我们可以通过累计功能的大致 story points 来预测需要多少个冲刺。
Story points 与个人生产力
- 不要 将每个冲刺结束的 story points 用作个人生产力的衡量指标。
- 原因：
- 任务在复杂度和上下文上各不相同。
- 这些点数是 团队的估算，而不是个人绩效的衡量。
在示例公司中，比较玛丽亚完成了20 点而胡安完成了10 点，导致对他们绩效的错误结论。
结论
- Story points 允许以 相对 的方式进行估算，降低了必须满足预先设定工时数字的压力。
- 对不确定性和复杂性达成 共识 是关键。
- 校准冲刺 和 持续再估算 能保持待办事项的准确性。
- 团队速度 是用于规划的有用度量，而不是基于点数的个人生产力。
本文概述了使用 story points 进行估算的主要观点以及敏捷团队的最佳实践。
使用故事点进行估算
“或个人的。”
虽然我并不为此感到自豪，但我记得当时一些开发者（包括我自己）开始夸大估算以保护自己。正是在这里，使用 story points 的估算工具失去了作用。
估算就是猜测。 这不是一门精确的科学。不过，目标是尽可能做好估算，以便业务能够对产品交付作出承诺。
反思问题
- 如果你看到这里，你对我所说的有什么看法？
- 你使用过故事点吗？
- 还是更喜欢其他估算系统？
- 为什么？