【Scrum模式语言15】发布计划（Release Plan）

译者导读：

这篇文章，让我想到了全局观，应该是作为产品负责人具备的基本素养，不仅给产品以愿景，给团队以方向，同时也能帮助产品负责人与干系人很好的进行沟通。而发布计划应该是这种素养的可视化的表述之一。发布计划向上衔接面向管理层的产品愿景和路线图，向下衔接面向团队的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

【Scrum模式语言15】发布计划（Release Plan）相关推荐

极限编程 (Extreme Programming) - 发布计划 (Release Planning)
编写用户故事后,您可以使用发布计划会议来创建发布计划.发布计划指定将为每个系统版本实现哪些用户故事以及这些版本的日期.这给出了一组用户故事供客户在迭代计划会议期间进行选择,以便在下一次迭代期间实施. ...
敏捷项目管理敏捷工作之发布计划
发布计划发布:指发布出来用于生产的一组可用的产品特性.无需包含所有的路线图的功能,至少要包括最小的可上市的特性集. 计划发布:确定下一组最小可上市的特性集,并确认团队能够行动起来将最迫切的产品推出的 ...
硝烟中的Scrum和XP-我们如何实施Scrum 12)发布计划 13)组合XP
12 怎样制定发布计划, 处理固定价格的合同一次只计划一个sprint的事情会显得提前量不足, 提前做计划是个好习惯; 尤其是签了固定价格的合同之后, 不得不预先计划好, 防止无法按期交付的危险情况 ...
Scrum指南新版发布，再添新概念—Product Goal
北京时间2020年11月18日晚11点,在Scrum诞生25周年之际,Scrum两位创始人Dr. Jeff Sutherland和Ken Schwaber联袂发布了新版<Scrum指南2020& ...
php 5.4.5,PHP 5.4.5 和 5.3.15 发布
PHP 5.4.5和5.3.15发布. 上个版本是2012-06-15的5.4.4/5.3.14修正了30多个Bug以及几个安全漏洞.经过1个RC. This release fixes over 3 ...
【Scrum模式语言8】Scrum白板
译者序:本文说到的Scrum白板是一个重要的Scrum工具,是以物理或电子的方式展示当前Sprint范围及其状态.在Sprint计划期间,当前Sprint计划的产品增量被分解为可执行任务.Scrum白 ...
Symbian软件发布计划及更新(组图)
当前所有模块的软件开发团队正在致力于Symbian平台的工作中,将他们的模块发布到平台版本当中.Symbian平台的发布计划是:每年将有两次软件平台版本发布.下图将为我们展望明后年的计划. Symbi ...
Eclipse Jetty 9.4.15 发布，建议使用 JDK 12
Eclipse Jetty 9.4.15 发布了,此版本包含大量的 bug 修复和改进,要点: Java 11 有一个有问题的 TLS 实现.目前 Jetty 团队建议使用 JDK 12,直到 JDK ...
TFS发布计划发送到钉钉消息群
由于工作中需要用到钉钉,每天都要和钉钉打交道:上下班打卡.出差请假流程.各种工作讨论组,不一而足,工作已然和钉钉绑在了一起,难怪有广告词: 微信是一个生活方式,钉钉是一个工作方式. 我们是钉钉机器人内 ...

【Scrum模式语言15】发布计划（Release Plan）

【Scrum模式语言15】发布计划（Release Plan）相关推荐

最新文章

热门文章