Scrum 团队的发布规划：实用操作指南
《Scrum 指南》有意地只讲到 Sprint 为止。它定义了 Sprint、Sprint 规划、Sprint 目标和产品待办列表，却从未规定“发布计划”。这是刻意为之：Scrum 是一个框架，而非项目计划。但大多数团队仍需要向某人回答“大概什么时候能好？”。发布规划就是让你诚实作答的方式，而不假装拥有并不存在的精确度。
2021 年初，团队分散在各自的居家办公室，供应链在疫情后仍不稳。当时的诱惑要么是过度规划（一张没人相信的庞大甘特图），要么是根本不规划。有用的中间路线，是一份轻量、定期刷新、基于团队自身数据的发布预测。
发布计划到底是什么
发布计划是一份预测，而非承诺。它将产品待办列表中一段有序的工作对应到一个大致的时间范围，使利益相关者可以据此决策——市场、培训、合同、监管申报。它归产品负责人所有，后者负责待办列表及其排序，并随着不断学习在每个 Sprint 重建。
如何制定
定义发布目标。 用一句话说明发布应交付的成果——而非功能清单。“让新客户无需电话即可自助开通”胜过“交付第 1 至 9 个页面”。目标让你日后能删减范围而不丢掉要点。
朝该目标排序待办列表。 产品负责人把价值最高、风险最高的工作排在靠前。发布计划的好坏，取决于其下的排序。
粗略估算工作量。 使用团队现有的估算方式——故事点、适当拆分，或简单统计条目数。近期条目应比远期更清晰。
用真实速率预测。 取近几个 Sprint 的平均吞吐量，最好还有其区间（低与高）。用剩余工作除以该区间，得到一个 Sprint 数的区间，而非单一的虚假日期。
以区间表达。 告诉利益相关者“3 到 5 个 Sprint”，或“很可能在第三季度末，也可能拖到第四季度”。诚实传达的区间比会落空的精确日期更赢信任。
每个 Sprint 重新预测。 每次 Sprint 评审时，更新速率、重排待办列表、滑动发布时间线。计划是一个由真实证据不断刷新的活的产物。
常见陷阱
把预测当成承诺，然后在现实与估计不符时惩罚团队。
按峰值速率而非平均速率规划——这几乎必定赶不上进度。
忽视团队之外的依赖。尤其在 2021 年，硬件交货周期或第三方集成可能远超开发工作；把它们作为明确的条目或风险呈现出来。
同时锁死范围、日期和质量。选择哪一项可以伸缩——通常是范围——并明说出来。
做得好的发布规划不会拖慢 Scrum 团队。它为团队周围的人提供了可供规划的时间线，同时保护团队在每个 Sprint 检验与适应的自由。随着发布临近，预测会越来越准——这正是诚实估算应有的表现。
如果贵组织正在建立敏捷交付，需要领导层真正可以信赖的预测，XNM 的计划与项目交付咨询 可以帮你落地这一实践。