Sprint目标：Scrum Pattern | IDCF

你已经为Sprint做好了准备，现在你正在开Sprint计划会，进行迭代计划。

Sprint目标有多重要？

Sprint的目标是为利益相关者交付价值。然而，简单地按照一个SBI（Sprint Backlog Item，Sprint待办事项；例如：任务）清单来做，不一定就能创造出最大的价值。

如果团队按照单个任务或交付物来制定工作计划，就很容易在生产阶段（Production Episode，Scrum Pattern之一，将在单独的文章中介绍）选择单个待办事项，孤立地进行工作。如果这样的话，创新就被稀释了，因为创新是由对工作持有不同视角的个体进行互动而产生的。当工作孤立进行时，就像无形的办公隔间，可能会阻碍大家持续交流各种见解（这些见解不仅对一个开发人员，而且对许多开发人员甚至对整个团队来说都很重要）。没有充分的互动和沟通，团队合作就会受到影响。

团队可能需要部分重新规划正在进行的Sprint，以确保团队在Sprint结束时可以向利益相关者交付价值。随着时间的推移，团队会对工作有新的见解，可能会识别出新的工作，这时团队应该对计划做出相应调整。如果团队还是按照原来的计划行事，可能就无法创造出最大的价值。还有一种常见的情况是，在Sprint中途，团队感觉明显无法完成Sprint Backlog中的每个SBI，这通常是由于完成SBI所需的工作比预想的要多。此时团队仍然希望尽一切所能交付价值，这可能就需要通过重新规划来实现。重新规划Sprint的工作需要深思熟虑，并且需要时间。

另一种情况是，团队需要关于“如何实现一个PBI（Product Backlog Item，产品待办事项）”的重要技术知识，以便之后能够更有信心地开发它。比如开发人员（甚至是产品负责人）可能需要一个技术原型来验证一个建议的架构，或者了解一些技术的性能特点。这样的工作我们也把它做成一个PBI，不过这一类PBI的目标是帮助团队获取更多的知识，而不是完成一项功能。这样的技术原型是一种探索性的工作，耗时存在不确定性，因此它往往会处于Sprint成功的关键路径上，即它的完成与否关系到Sprint目标是否能够达成。（译者注：这样的PBI，我们称之为Spike，即探针。）

在某些情况下，最大的价值可能不是简单地实现一个PBI。例如，对团队来说，最大的价值是增加每个Sprint所能带来的经济收入，而团队只是用一个PBI来实现这个价值。另一方面，有时Sprint的大部分价值主要来自于很多PBI中的一个关键PBI。

因此：

Scrum团队为Sprint期间所要创造的价值书写了简短的声明（译者注：即Sprint目标），并对其做出承诺。这将成为Sprint中所有工作的重点。

整个Scrum团队共同创建Sprint目标。产品负责人自然会指导Sprint目标的创建，因为他或她对实现产品愿景的下一步以及如何能够创造出最大价值最有发言权。Scrum团队应该把Sprint目标当做总是能够触手可及的事物一样做出承诺。（译者注：最后这一句的原文是“The Scrum team should commit to the Sprint goal as something always within reach.”因为这一句关系到对Sprint目标的准确理解，因此标注原文以便对照参考。）

开发团队每个Sprint通过构建产品增量来实现Sprint目标。

Sprint目标怎么用？

Scrum团队可以依据Sprint目标来为Sprint选择PBI，但从某种意义上说，Sprint目标甚至比单个PBI的总和更重要。Sprint目标在PBI之间建立连贯性（译者注：而不是一堆散落的PBI），这有助于创造有价值的产品增量。一个初始化Product Backlog的好方法是就是将其表达为包含许多Sprint目标的列表，由产品负责人和开发团队一起随着时间的推移将其渐渐细化为PBIs。

自主团队的成员必须能够自我管理，以完成他们的目标，而由开发人员进行排序的工作计划（Developer-Ordered Work Plan，Scrum Pattern之一，将在单独的文章中介绍）指出，开发团队必须能够自由地以他们认为合适的方式安排他们生产阶段的工作。Sprint目标是产品负责人用于影响开发团队潜在工作顺序的唯一机制（通过Sprint目标所传达的重要性来推断紧迫性）-- 当然，只有在得到开发人员同意后才可以。

在Sprint计划会期间，Scrum团队确定他们希望在Sprint结束时实现的目标；简而言之，这就是Sprint目标存在的意义。开发团队使用Sprint Backlog来定义如何完成这个Sprint目标的细节。如果开发团队认为他们不能完成Sprint目标，就应该和产品负责人一起对Sprint目标再次斟酌。Sprint计划会的一个关键产出就是，开发团队应该能够解释如何完成Sprint目标，以及如何知道自己已经实现了这个目标。解释的能力来自于对未来工作的透彻理解，这就提高了团队在Sprint中实现Sprint目标的概率。

开发团队对Sprint目标做出承诺。这个Sprint目标可以帮助开发团队众志成城，并有助于建立利益相关者对团队的信任。

Sprint目标对团队应该是可见的；例如，把它放在Scrum 板或其他信息雷达上。

为支持Sprint目标的实现，在Sprint期间，开发团队要确保Sprint Backlog一直反映最新的工作状况。Sprint Backlog的进展（比如在Sprint 燃尽图上显示的）就像Sprint期间足球场上的进展一样：虽然每一码的进展都会使球更接近终点，但价值是在球门上（译者注：球门和目标的英文是相同的，都是“Goal”，一语双关！）。有时也有可能在没有完成所有SBI的情况下完成Sprint目标（以某种方式）。这有助于团队处理突发事件，并使开发人员在每日Scrum会中灵活地改变他们的工作计划（译者注：在目标不变的前提下）。

举个例子：突发的阻碍会威胁到开发团队交付完整的Sprint Backlog。在这种情况下，团队会自动采用Sprint目标作为 "B计划"，而不需要花费很长的时间重新规划。卡耐基梅隆大学[1]的一项研究报告指出，提前为中断做准备的团队比没有提前准备的团队要好14%。为中断做准备的团队比不做准备的团队完成一个不间断的任务间隔要快43%。这是一种为计划外的事情做准备的心态：当它们发生时，团队可以转到一个新的配置来处理它们，不需要外部辅导。

理论上，在每个Sprint只完成一小部分PBI的情况下，一次又一次地实现Sprint目标也是可能的。不过，这应该是不常见的，因为Sprint Backlog应该与Sprint目标一致；如果不是，就说明价值流存在严重问题。

速率（Velocity）能够帮助团队了解他们是否在正确地做事（我们假设正确地做事速率就会提升）。Sprint目标帮助团队确保他们在做正确的事情。它是关于理解团队正在做的事情的 "Why"，以便在事情发生变化时能够保持专注。

Sprint目标还有其他功效？

杰夫.萨瑟兰（Jeff Sutherland）补充说，除了让团队保持专注外，Sprint目标还会促进蜂拥模式（Swarming，Scrum Pattern之一，将在单独的文章中介绍）的使用。我们能不能让大家一起做一件事？他说道：

2007年在硅谷，Palm正在开发一个网络操作系统，后来被惠普公司收购。前几个Sprint，团队做得很好，但在几个Sprint之后，他们似乎遇到了困难。PBIs没有完成。开发人员的积极性很低，而且很早就回家了。他们请我来，我请产品负责人和Scrum Master花了一个小时来采访团队成员，了解他们为什么没有积极性。我们发现，原因是他们不理解做的这些低层级的PBI要解决什么问题。

我们花了一个下午的时间来清理Product Backlog，清晰地展示出了高层级故事和分解出来的较低层级故事之间的联系。当开发人员了解到Sprint的目标是将网络操作系统的性能提高10%时，他们就有动力去完成低层级的故事，速度也恢复了正常。

理解为什么要实现PBI，对开发人员来说至关重要，特别是对专家级的开发人员来说，如果他们找不到自己工作的理由，就会宁愿去冲浪。

Sprint目标通常与产品价值有关。团队也可以用过程目标来定义Sprint目标 -- 例如，通过结对编程来完成所有的编程，或者准时参加每日Scrum会。

反复推动Sprint目标的实现，可以激励团队达到更高的参与度；反过来，幸福指数可以成为定义或建议Sprint目标的一个有效工具。

Sprint目标的作者是谁？

2001年，Ken Schwaber和Mike Beedle第一次提出了Sprint目标的概念（[2]，第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/0... (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.

来源：徐东伟敏捷教练

翻译：徐东伟；校对：李虎
声明：文章获得作者授权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术同伴，如原作者有其他考虑请联系小编删除，致谢。

IDCF DevOps黑客马拉松，2021年度城市公开赛，11月6-7日，深圳站，企业组队参赛&个人参赛均可，一年等一回，错过等一年，赶紧上车~公众号回复“黑马”加入