---

什么是 Scrum 发布计划？答案可能让你惊讶！

发布计划展示多个 Sprint 的高层规划，本例通常三到十二个。Sprint 是限时周期，增量是可用成果，一个 Sprint 可产生多个增量。

它反映团队对以下方面的期望：

• 将实现哪些功能，
• 以何顺序、何时实现。

也作为监控项目进展的基准，为生产系统实际部署设定两种目标：

• 项目结束前部署“里程碑交付”，创造价值；覆盖产品负责人、客户及业务相关方商定的部分需求，
• 部署最终交付，包含客户与业务相关方全部已知需求和功能请求。

建立计划前须考虑：

• 已排序、已估算的产品待办列表，
• 已测量的速度 ，来自 Scrum 团队（新团队可先估计，或依据过去类似项目推算），
• 客户规定的成功标准 ，如时间、范围和预算内可用人员。

计划与产品待办列表密切相关，因此由产品负责人管理维护。

根据客户需求和优先级，计划满足以下三类目标之一：

• 基于功能的发布规划
• 基于日期的发布规划
• 兼顾功能与日期的发布规划 （最常见）

基于功能的发布规划

已知： 团队速度、希望交付的功能。
未知： 需要多久交付？

基于功能的计划（详见 Scrum 发布规划）将所需功能故事点总和除以速度，初步预测里程碑或最终交付所需 Sprint 数，向上取整。推进时检查范围与速度假设，据此制定计划。

基于日期的发布规划

已知： 团队速度、期望交付日期。
未知： 截止日前能交付哪些功能？

日期型计划用速度乘发布前 Sprint 数，估计截至该日可交付的故事点，据此规划。

兼顾功能与日期的发布规划

已知： 团队速度、所需功能、期望交付日期。
未知： 团队能否按期交付所需功能？

速度乘可用 Sprint 数，得到估计交付点数。若超过版本功能故事点总和，当前预测说明范围可容纳，但仍有不确定性和变化。

否则应权衡范围、日期和能力。增员不自动提高速度，磨合初期还可能变慢。旧的九人建议不是当前硬上限，团队通常 10 人以下。有效时可另队并行，同一产品仍共享负责人、产品目标、待办列表及 DoD。

像产品待办列表一样，发布计划不是静态的。了解越多，计划越会调整；新增、删除、修改故事及估算都会影响它，因此应定期重访更新。