Scrum Patterns: 冲刺目标 (译)

关注

发布于: 8 小时前

Bruce 有话说

2020 年新版 Scrum 指南中引入了冲刺目标（Sprint Goal）。作为团队对 Sprint 的一个承诺，理解好承诺的作用和目的，而不是仅仅当作一个文字游戏，才能够理解 Scrum 的精髓。这其实就是我们经常说的要 Being Agile，而不要停留在 Doing Agile 上面。最近在辅导团队的时候，总能发现 Team 还是停留在 Doing，Sprint 计划会像是走形式，而 Sprint Backlog 的创建和管理也很随意。每日 Scrum 开不开都可以。这是为什么呢？Scrum 框架本身很简单，如何能团队真的理解并有热情去用好 Scrum 呢？当看到 Scrum Pattern 这篇文章的时候，我眼前一亮。小到工作的目的，大到人生的目标，Goal 是能够唤起我们内驱力的最重要的一个东西。明确的目标自然会给人们带来使命感。Sprint Goal 作为团队实际工作中的目标。他是 Scrum Team 在 Sprint 级别的承诺。他也会在如下方面帮助我们：

理清楚 PIBs 和 SBIs 之间的关系？
Sprint Goal 可作为团队内部对齐的一个手段。避免团队每个人眼里只有独立的一个一个任务而没有整体目标，拒绝合作。
当 Sprint 的计划会因为团队工作中涌现新的想法，而导致工作量的变化，从而需要重新计划的时候，如何保证调整是正确的呢？Sprint Goal 就该出场了。
Sprint Backlog 是团队的决定，PO 无从干涉，但是 PO 可以用 Sprint Goal 来影响团队在 Sprint 中的选择和优先级排序。
Sprint Goal 是 sprint 计划会的关键输出之一。团队要能够用来说明如何能实现这个目标，如何证明实现了目标，才能说明团队有信心来完成当次 Sprint。而很多时候我们的 sprint 计划会更多是走一个过场、任务宣读会。而缺少了团队和 PO 之间的一个承诺。
如何能保证 daily scrum 中面对涌现的突发情况做的调整不会跑偏？Sprint Goal 是那个不灭的灯塔。

说了这么多接下来就让我们一起认识一下 Sprint Goal 吧。希望本文能够引发你更多的视角和思考。

正文

你已经准备好开始 Sprint 了，你正在 Sprint planning meeting 中进行计划。

✥ ✥ ✥

Sprint 的目标是向干系人交付价值。然而，简单地遵循 Sprint 待办事项列表(SBIs;例如，任务)不一定会创造最大可能的价值。

因为团队根据单个任务或可交付成果来安排其工作计划，所以很容易在生产阶段挑选单个项目并单独处理该项目。然而，这冲淡了个人之间的互动带来的创新，这些个人之间的互动为工作带来了不同的视角。隔间墙可能成为持续交流见解的障碍，这些洞见不仅对一个开发人员很重要，而且对许多开发人员(开发团队成员)或整个团队都很重要。团队精神受到损害。

团队可能需要部分地重新规划正在进行的 Sprint，以确保团队在 Sprint 结束时向干系人交付价值。新的工作项可能会从团队的最新洞见中涌现出来，团队应该相应地更新其计划。如果团队遵循最初的工作计划，它可能不会创造最大的价值。另一种常见的情况是，在 Sprint 进行到一半的时候，团队显然不会完成 Sprint Backlog 中的每一个 SBI。这通常是因为完成 SBI 所需的工作内容被扩大了。如果可能的话，团队仍然希望交付价值，这可能需要重新规划。而重新规划 Sprint 的工作需要深思熟虑和时间。

另一个场景是，团队需要关于如何实现产品待办列表(PBI)的重要技术知识，以知道如何满怀信心地开发它。开发人员(甚至产品负责人)可能需要一个技术原型来验证建议的架构或学习某些技术的性能特征。虽然 PBI 应该识别这样的工作，但它的不确定性要求团队专注于获取知识，而不是完成所有计划的工作。技术原型成为 Sprint 成功的关键路径项目。

在某些情况下，最大的价值可能不是明确的产品待办事项列表项。举个例子，对团队来说最大的价值是增加每个 Sprint 的收入，团队为此投入了一个产品待办事项列表项目。另一方面，有时 Sprint 的大部分价值很大程度上来自于许多关键 PBI 中的一个。

因此：

Scrum 团队承诺在 Sprint 期间创造一个简短的价值声明。这成为 Sprint 中所有工作的焦点。

整个 Scrum 团队共同创建了 Sprint 目标。产品负责人自然会指导 Sprint 目标的创建，因为他或她对产品愿景的下一步以及如何创造最大价值有着最好的看法。Scrum 团队应该将 Sprint 目标视为可以实现的目标。

开发团队创建一个常规产品增量来满足每个 Sprint 的目标。

✥ ✥ ✥

Scrum 团队可以使用 Sprint 目标来为 Sprint 选择 pbi，但在某种意义上，Sprint 目标甚至比单个 pbi 的总和更重要。Sprint 目标在 pbi 中创建一致性，帮助创建有价值的产品增量。对于产品待定项列表，一个好的初始方法是将其表达为 Sprint 目标列表，产品负责人和开发团队一起将其细化为 PBIs。

自治团队的成员必须能够管理自己以实现他们的目标，而开发人员有序工作计划指出，开发团队必须自由地安排他们的产品阶段性工作，无论他们认为怎样合适。Sprint 目标是产品负责人能够影响开发团队执行其工作的潜在顺序的唯一机制(通过从 Sprint 目标传达的重要性来推断紧迫性)。但是这里需要再次强调，必须得到开发人员的同意。

在 Sprint 计划会期间，Scrum 团队决定他们在 Sprint 结束时想要达到的目标;简而言之，这就是 Sprint 目标的目的。开发团队定义了如何通过创建 Sprint Backlog 来完成这个 Sprint 目标的细节。如果开发团队认为他们无法完成 Sprint 目标，那么应该与产品负责人一起完善 Sprint 目标。Sprint 计划会的一个关键输出是：开发团队应该能够解释如何能够实现 Sprint 目标，以及如何知道已经实现了目标。实现目标的能力来自于对事先工作的全面理解，这提高了团队在 Sprint 中实际实现 Sprint 目标的可能性。

开发团队致力于 Sprint 目标。这个 Sprint 目标可以帮助统一开发团队(参见目的的统一)，并且它有助于建立干系人和团队间的信任。

Sprint 目标应该对团队可见;例如，把它放在 Scrum Board 或其他信息辐射器上。

开发团队在 Sprint 期间持有 Sprint Backlog 为当前状态，以支持实现 Sprint 目标。Sprint Backlog 的进展(如 Sprint Burndown Chart 所示)就像 Sprint 期间在足球场上的进展:尽管每一码的进展都让球更接近终点，但价值来自于目标。不过有时候在没有完成所有 sbi 的情况下完成 Sprint 目标(以某种方式)是可能的。这有助于团队处理突发事件，并让开发人员在每天的每日 Scrum 中灵活地更改他们的工作计划。例如:涌现出来的障碍会威胁到开发团队完成 Sprint Backlog 的交付。在这种情况下，团队自动地将 Sprint 目标作为“B 计划”，而无需花费长时间重新规划。卡内基梅隆大学[1]进行的一项研究报告称，提前做好准备的团队比没有做好准备的团队处理中断的能力强 14%。有准备的团队比没有准备的团队完成不间断任务的速度快 43%。这是一种为计划外的事情做准备的心态:当它们发生时，团队可以转向一个新的配置来处理它们，而无需外部指导。

理论上，在每个 Sprint 只完成一小部分 PBIs 的情况下，重复实现 Sprint 目标是可能的。这应该是不常见的，因为 Sprint Backlog 应该与 Sprint 目标保持一致;如果不是，价值流就有严重的问题。

速率(参见关于速度的注释)有助于团队理解他们做的事情是否正确(假设做的事情正确会增加你的速率)。Sprint 目标帮助团队确保他们正在做正确的事情。它是关于理解团队所做的事情的“为什么”，以便在事情发生变化时保持专注。

Jeff Sutherland 补充道，除了保持团队专注之外，Sprint 目标还鼓励了蜂拥而至(参见 SWARMING):我们能让每个人一起做一件事吗? 他描述道:

2007 年，Palm 在硅谷开发 Web 操作系统，后来被惠普收购。在一开始的 Sprint 到 Sprint 之间，团队一直做得很好，直到他们在几个 Sprint 中遇到了障碍。PBIs 没有完成。开发人员士气低落，早早就回家了。我被请来，让产品负责人和 scrummaster 花了一个小时的时间采访团队成员，询问他们为什么会失去动力。我们发现，他们不明白他们努力工作在低技术水平的 PBIs 的原因。我们花了一个下午的时间来清理 Product Backlog，以显示高层描述和分解层次之间的清晰联系。一旦开发人员明白 Sprint 的目标是将 Web 操作系统的性能提高 10%，他们就会被激励去完成低技术水平的故事，并且迭代速率恢复到正常水平。理解为什么要实现 PBIs 对于开发人员来说是至关重要的，特别是对于那些在看不到工作原因时更喜欢去冲浪的专家级别开发人员来说。

Sprint 目标通常与产品价值有关。团队可以根据过程目标来定义 Sprint 目标——例如，通过结对编程来完成所有编程，或者每天按时参加每日 Scrum。

不断地朝着 Sprint 目标前进能够激励团队达到更高的参与度;相反，幸福指标可以是定义或建议 Sprint 目标的有效工具。

2001 年，Ken Schwaber 和 Mike Beedle 是第一个描述 Sprint 目标的人。([2], p. 48).

[1] Bob Sullivan and Hugh Thompson. Gray Matter. “Brain, Interrupted.” In New York Times, 5 May 2013, page SR12, http://www.nytimes.com/2013/05/05/opinion/sunday/a-focus-on-distraction.html (accessed 2 November 2017).

[2] Ken Schwaber and Mike Beedle. Agile Software Development with Scrum (Series in Agile Software Development). London: Pearson, Oct. 2001, p. 48.

Picture credits: Shutterstock.com.