译者导读：
这篇文章，让我想到了全局观，应该是作为产品负责人具备的基本素养，不仅给产品以愿景，给团队以方向，同时也能帮助产品负责人与干系人很好的进行沟通。而发布计划应该是这种素养的可视化的表述之一。发布计划向上衔接面向管理层的产品愿景和路线图，向下衔接面向团队的Sprint计划，对产品某次发布有个明确的规划，连接愿景与落地。个人的经验而言，可以让产品负责人与团队一起，结合用户故事地图工具一起来做发布计划。
原文：
2015年4月27日，一架皇家空军C17运输机飞往尼泊尔，装载了人道主义援助和物资。飞机的速度，每个货盘离开C17所花费的时间以及货盘的顺序确定了哪个货盘将降落在哪里……有了愿景，你需要制定计划以整合投资和资源来开发产品。你已经有一个产品待办事项列表，并在使用产品待办事项条目（PBI）用以形成常规的产品增量。你的产品待办事项列表中有了已经估算过的产品待办事项条目，同时，你知道所有团队的速率。
产品负责人需要能与干系人沟通下一个发布的时间以及该版本包含哪些产品待办事项条目。有时候，发布日期是一个重要的约束，而其他时候，发布内容会是主要的约束。当同时约束日期和内容时，难免会引起过度约束带来的风险，产品负责人必须使这种风险透明化。
如果开发团队可以通过明确的常规产品增量看到被承诺的长期方向，那么他们更有可能投入更多的精力去实现这一目标，并且更有可能在实现产品愿景的过程中构建正确的事物。
如果对下一个版本的内容缺乏明确的共识，则可能会给干系人一种印象，即在下一个版本发布之前，范围是可以协商的。结果，发布日期可能会受到功能蔓延的影响，并且团队最终一再推迟交付。
当产品负责人对市场，团队和干系人都熟悉的时候，信任度很高，仅凭概要计划和评估就足够了。从另一方面来说，如果产品负责人是刚开始接触团队，市场或利益相关者，信任度低，或者该计划包含高于正常水平的风险，则可能需要更详细的计划和评估。
产品负责人独自创建发布计划会错失开发团队的智慧和见解。此外，团队不会对计划有责任感，进而他们不太可能对计划中任何预期进行承诺。因此：与开发团队一起创建初始产品待办事项，根据你计划实现的愿景并最大化价值的产品增量顺序进行沟通。也就是说，使用待办事项列表制定发布计划。使用该计划获得必要的投资者承诺和团队预期来开发你的产品。
我们的焦点始终放在产品级别上的进展。如果你有多个开发团队工作中共用同一个产品待办事项列表，那么他们可以使用其历史速率来预测这些团队一起产出的常规产品增量， 但是这种方式要基于当前待办事项列表的排序，而非依赖于将特定的产品待办事项预先分配给各个团队。由于速率各不相同，因此任何一组常规产品增量的预期进度也会有所不同，在任何给定的交货日期，常规产品增量的内容也会有所变化。
发布计划是包含在接下来几个发布中的可交付成果的有序列表。即使团队的速度只有微小的差异，但经过短短的几个Sprint后，交付进度的不确定性变得离谱。根据经验，展望超过三个Sprint，其中的猜测就会多于统计学上合理的预测。
发布计划对使PBI“完成”的所有工作负责，包括固定的工作。对于任何PBI，团队不得将“加固”工作或“质量工作”从其他工作里分离出来。产品负责人会根据对市场和团队速率的最新洞察定期更新发布计划。
从待办事项列表的顶部开始，并用你的方式向下进行，将每个产品待办事项的估算值（例如估算点）相加，直到达到已知团队速率的总和。下一个发布的常规产品增量由这些位于产品待办列表顶部的条目组成。按照待办列表继续往下下，将产品待办列表事项放到常规产品增量中，并将常规产品增量分配给后续的发布。根据此计划更新产品路线图。
例如，假设团队估计先前草图中的每个产品待办列表事项需要10个估计点的工作量。该团队在7月15日之前有6个Sprint的可用时间，我们想知道届时我们将能够交付什么。
团队此前的速率保持在每个Sprint 15至20点之间。所有其他考虑因素都相同，团队将在7月15日之前完成90到120个估算点的工作。我们可以从待办事项的顶部开始计算PBI估算值，在这里，每个条目的估算值是10点，我们相应地预期团队将完成的工作量。在所有其他因素都相同的情况下，他们将完成9到12个产品待办列表事项。
从理论上讲，人们可以采用更缜密的估算方法：例如，规定15-20这个速率范围可以覆盖过去的5个Spint所有速率的2个标准偏差，或者诸如此类。然后，从理论上讲，人们可以声称下一个Sprint的交付预测具有95％的确定性，依此类推，随后的Sprint的确定性会更低。
然而，实际上，速率，团队构成，产品待办事项列表的内容（它会发生变化！）和市场条件等参数变化很大，以至于即使在统计确定性上，外部因素对差异的影响也会从根基上破坏任何预测的尝试。尽管如此，这个方法仍是对未来的一种合理的指示信号，同时也是一种通用的预测方法，就像我们可以或多或少地依赖天气预报员的预测。
一个常见的敏捷短语是建议“将决定推迟到最后一个必须决定的时刻”。某些产品待办事项的目标日期可能会构成一个“必须决定的时刻”（期望的或强制的交付日期），然而，负责任的精益实践会向前拉动决策而不是推迟决策。
发布计划用产品待办事项列表作为框架，以尽可能地拉动决策向前推进（例如，考虑产品待办事项之间的依赖关系，或者以发布日期来对齐产品待办事项或常规产品增量）。在所有其他条件相同的情况下，尽快开始工作很重要，因为设计和实施有助于使紧急需求尽早可见，并为团队提供有关风险的早期数据。推迟工作或推迟驱动工作的决策只会延迟不可避免的事情发生。
使用这种方法，你可以根据团队速率更新评估的发布日期。这个方法在全世界都有广泛的Scrum实践。
产品负责人既可以通过发布计划来定位长期价值，它解释了PBI之间如何相互加强，也可以基于高价值优先的原则，计划一系列项目式的发布。然而，团队不应将此类评估作为一个确切的日期，用于任何给定的产品待办事项，同时没有交付日期可以被认为是具有约束力的承诺。发布计划基于估计，并承认灵活性而非必然性。Scrum保持交付日期固定不变，因此Sprint的结束日期是神圣的，此时团队将尽力而为。敏捷性的代价就是有些不确定性。
在Sprint结束前发布一些产品待办事项也是被认可的，每次发布少量常规产品增量，可以让交付流程更顺畅，并最大程度地减少已完成工作的堆积。
——译者：Leo Yan
校对：Emma Ye
参考资料：
（1）A Scrum Book：48 Release Plan
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/295397.html