Scrum Patterns:Sprint 计划会 (译)

关注

发布于: 2021 年 01 月 24 日

正文

在开始 Sprint 计划会之前，团队已经定义并细化了产品待办事项列表，产品待办事项列表项(PBIs)仍然只代表潜在的价值。只有当开发团队使之成为现实时，它们才能产生价值(即移动到价值流的末尾)。您已经准备好开始一个 Sprint，选择开发一个或多个 PBIs 来创建一个潜在的可交付的产品增量。

✥ ✥ ✥

一个 Sprint 应该产生一个潜在的可交付产品增量。然而，简单地将 PBIs 从产品待办事项列表中移除，并不一定会创造出最大得价值; 在符合 Sprint 时间盒子内完成工作也不一定能产生产品增量。

如果能始终从产品待办事项列表的顶部开始工作，而不用担心工作顺序，那就太好了，但是有几个原因通常不会发生。PBIs 的大小并不统一，团队必须在 Sprint 的时间范围内创建可交付的产品增量。所以团队必须弄清楚什么是大小适合的，他们可能需要调整 PBI 顺序，甚至可能调整一些 PBI 内容。

Tasks 通常是相互依赖的，并且考虑到团队对当前产品状态和领域的了解，团队可能会意识到，在特性 Q 之前开发特性 P，或者在 Task Y 之前完成 Task X，可以节省时间。

Scrum 团队作为一个整体，如果对 PBIs 的理解通常不够详细，那么就无法说出将如何实现它们。但是在现实实践中，将 PBIs 设计到这个详细程度是一种浪费，因为 PBIs 可能会在未开发的情况下排队等待一段时间，而业务场景和团队知识可能会随着时间的推移而变化，这使得您投入到细化 PBIs 中的所有工作都变得无用了。与此同时一些 PBI 可能会进入产品 Backlog，也可能会无限期推迟一些 PBI。一些设计思考是为了让开发人员考虑他们将如何实现一个给定的 PBI。如果他们做得太早，这些计划可能变的过时了，同时团队也不想一切计划得太晚。

开发团队成员可能需要在 Sprint 期间调整他们的工作计划，因为他们开始更多地了解业务需求和技术约束。在实现大型单个 PBIs 时，这是很困难的。

因此:

在每个 Sprint 的开始阶段，Scrum 团队(或所有共同交付产品增量的团队)会聚在一起，计划如何在 Sprint 中创造价值。团队同意 Sprint 目标，并为开发团队将开发什么以及如何开发制定计划。这要求 Scrum 团队对解决方案进行足够详细的设计，以对如何构建产品有高度的信心，并要求团队成员觉得他们可以在 Sprint 期间完成他们的工作计划。

Sprint 计划会是 Sprint 中的初始活动。它构建起产品 Backlog 和开发团队的工作计划之间的价值流。

在 Sprint 计划过程中，Scrum 团队创建迭代目标，并生成 Sprint Backlog 的初始版本。附带的输出是更新的产品待办事项列表(PBIs)。如果产品待办事项列表在 Sprint 计划会的开始前还没有被梳理过(可能因为产品负责人在上次和和团队梳理之后又往待办事项列表的顶部附近增加了新项目),然后 Scrum 团队通过讨论、估算、分解、排序等为新 PBIs 制定计划，看是否能够放入即将到来得 Sprint 中。

Sprint 计划的主要活动是团队确保产品待办事项列表已经就绪(Definition of Ready DoR);在 Sprint 目标上达成共识;团队预测在本次 Sprint 中可以交付的 PBIs;并计划如何做这些工作项并实现 Sprint 目标。大多数团队发现最好同时进行这些活动。例如，弄清楚如何进行工作可以帮助您理解其范围和所需的工作量(团队速度可以有效地预测开发团队在一个 Sprint 中能够完成的工作量)。当然，这也会影响到开发团队在一个 Sprint 中能够完成多少内容。

Sprint 计划会最重要得一个地方是允许用足够的时间来对 Sprint Backlog 进行讨论，从而达成一致。但是计划会应该是有时限的。经验法则是，一个为期两周的冲刺时间不应超过 4 小时，较短的冲刺时间应相应地减少。如果它需要更长的时间，那么就使用更长的时间——但是要寻找改善的机会来减少计划的时间，并相应地增加花在构建产品上的时间。

如果产品负责人没有为开发团队解释清楚 PBI，团队无法将其细化成为 Sprint Backlog，那么开发团队就不应该在 Sprint 中接受它为工作项。不明确的 PBIs 是工作量膨胀和 Sprint 失败的主要原因。Jeff Sutherland 建议：一个 Scrum 团队可以有一个规则，如果 PBIs 没有得到充分的说明，那么整个团队都去海滩度假吧。(这向产品负责人发出了，关于产品待办事项列表 DoR 标准的清晰信息!)

Sprint 计划会的一个关键输出是：开发团队应该能够解释清楚他们将如何完成当前得 Sprint 目标。如果他们能够解释他们的工作，这是一个好迹象，表明团队经过讨论对需求的理解已经达到到一个很好的水平，这同时也提高了团队在他们估算时间内完成工作的可能性。团队可能会认为这正是对计划会有效性的一种衡量。

如上所述，Sprint 计划会产生了 Sprint Backlog 的初始版本。这是开发团队在 Sprint 中的最初计划，并在每天的每日站会中细化和调整。每日 Scrum 主要是一个每日重新规划的活动。

✥ ✥ ✥

Sprint 计划会的质量好坏直接影响着随后每日站会活动的成功。如果 Sprint 目标和 Sprint Backlog 被很好的定义和理解，开发团队就可以有持续高效得每日站会，同时任何需要的重新计划都将是清晰的。一个糟糕的 Sprint 计划会可能会成为 scrum 团队得负担，尤其是多团队开发场景会更突出。

Sprint 计划会的主要输出是 Sprint Backlog 和 Sprint 目标。此外 Sprint 计划会也加强了目标的统一，它帮助开发团队和产品负责人更好地理解彼此的需求和动机。这加强了整体的信任，并让信任生根发芽。

经过团队梳理得 backlog 不仅是为了追求价值最大化，也增加了团队对产品的自豪感。

Picture credits: Image Provided by PresenterMedia.com.

Bruce 有话说

最近在和团队一起工作的过程中，发现大家对 Sprint 计划会的作用不是很明确。正好翻译这篇文章描述了计划会的作用和目的。这篇文章给我带来如下几点启发：

启动会是 PO 和团队一起明确 Sprint 目标的时刻。这也是让团队将 Sprint 任务和商业价值连接起来的一个关键所在。
之前虽然有梳理会对 PBIs 进行细化和说明，不过随着时间的推移可能由于环境变化和团队经验的积累会有新的变化。启动会可以对这些内容进行调整。让 PO 和团队达成一致。
PO 可能会有新的 PBIs 加入，需要团队做评估。
团队确定 PBIs 符合 DoR(Definition of Done)，并产出 Sprint Backlog。以此来说明团队有信心在当此迭代完成 PBIs 的承诺。
每日站会可以根据 Sprint Backlog 作为依据，每天进行检视、调整持续改进当次迭代的计划,以实现 Sprint 目标。
计划会之后产出的新的调整后的 Product Backlog 增进了 PO 和团队的彼此信任，也增加了团队对产出产品的自信心和自豪感。