估算与计划：故事点、速度与发布规划
一、估算的目的与局限
估算用来支持决策：排期、承诺、资源分配、范围取舍。目的不是「猜对天数」，而是在不确定下给出可用的相对或区间判断。局限也很明显：软件工作依赖理解、依赖变化、依赖人，早期估算误差大；把估算当承诺会带来压力与博弈（报大报小）。所以估算应相对化（比 A 大还是小）、区间化（如 3～5 点）、定期更新（随着信息增加重估），并明确「估算是预测不是承诺」。
估算适合用来
- 排优先级（大的可拆或后排）
- Sprint 与发布规划（能做多少）
- 预测与沟通（大致节奏）
- 暴露认知差异（估不准的往往需求不清）
估算的局限
- 早期信息少，误差大
- 当承诺会引发博弈与压力
- 绝对人天易被误解为「必须那天完成」
- 需随信息增加重估、用区间表达不确定
二、故事点与相对估算
故事点（Story Points）是相对规模单位：不直接对应「几天」，只表示「比另一项大还是小、大约几倍」。常用数列 1、2、3、5、8、13（斐波那契）或 1、2、4、8，避免纠结「4 还是 5」——差一档即可。做法是相对估算：选一个基准故事（如「登录页」= 2 点），新故事与之比较——差不多就 2，明显大就 3 或 5，明显小就 1。团队一起估（如 Planning Poker），能对齐理解、暴露歧义。故事点只在本团队内有意义，不要跨团队比「点数」。
三、速度与预测
速度（Velocity）是团队在一个 Sprint 内完成的故事点总和（只算「完成」的，进行中不算）。历史几轮 Sprint 的速度取平均或中位数，可作为「下一 Sprint 大概能做多少点」的参考；Backlog 按优先级排，用总点数除以速度，可粗算「还剩几个 Sprint 能做完这批」。注意：速度是观测值，会随需求复杂度、人员、干扰变化；不要用速度去「考核」团队，否则会扭曲估算（故意估小）。预测要带区间（如「按当前速度约 2～3 个 Sprint」），并随实际更新。
| Sprint | 完成点数 | 备注 |
|---|---|---|
| Sprint 1 | 18 | — |
| Sprint 2 | 22 | — |
| Sprint 3 | 20 | — |
| 平均速度 | 20 | 下轮规划参考 |
四、发布规划与路线图
发布规划把「要发布什么、何时发布」与 Backlog 对齐：按优先级从 Backlog 取条目，结合速度估算需要几个 Sprint，定出目标日期或里程碑；发布前可留缓冲、可做范围取舍（必须 vs 可选）。路线图（Roadmap）是更高层的时间轴视图：季度或年度的大目标、主题、里程碑，不写死细节，随反馈调整。发布规划与路线图都要定期更新：每 Sprint 或每发布后回顾，根据实际速度与优先级重排。
发布规划与路线图要点
- 发布规划：Backlog 优先级 + 速度 → 需要几个 Sprint、目标日期；可设「必须/可选」范围应对延期。
- 路线图：大目标与里程碑的时间轴，不锁死细节；用于对外沟通与资源规划。
- 两者都随实际速度与优先级定期更新，避免计划与执行脱节。
五、何时重估、如何应对不确定性
何时重估：需求澄清后（从模糊到可开发时）、范围或依赖变化时、做完一部分发现剩余差异大时。不必每个 Sprint 都重估所有项，但对「要排进下一轮」的项尽量保持估算新鲜。应对不确定性：用区间而非单点（如 5～8 点）；发布规划里留缓冲或「可选范围」；大项拆小再估（小项误差相对小）；明确「估算会变」、用速度与回顾持续校准。目标是在不确定下仍能做合理承诺与沟通，而不是追求虚假的精确。
一句话： 估算为排期与预测服务，有局限、宜相对与区间化。故事点表相对规模，用数列（1,2,3,5,8,13）和基准比较；速度是每 Sprint 完成点数，用于预测与发布规划。发布规划把 Backlog 与里程碑连起来；路线图是大目标时间轴。要重估（需求澄清、范围变、差异大时）、用区间与缓冲应对不确定性。
六、小结
估算目的在排期与预测，有局限、宜相对与区间。故事点表相对规模，相对估算、团队共识。速度为每 Sprint 完成点数，用于预测与发布规划。发布规划与路线图把 Backlog 与里程碑、大目标连起来，需定期更新。重估在需求澄清与范围变化时；用区间、缓冲、拆小应对不确定性。下一章讲团队角色与沟通，把产品、开发、测试、运维的协作与沟通说细。