关于敏捷开发:Sprint目标Scrum-Pattern-IDCF

2次阅读

共计 4016 个字符，预计需要花费 11 分钟才能阅读完成。

你曾经为 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 指标。

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”，以便在事件发生变化时可能放弃专一。

杰夫. 萨瑟兰（Jeff Sutherland）补充说，除了让团队放弃专一外，Sprint 指标还会促成簇拥模式（Swarming，Scrum Pattern 之一，将在独自的文章中介绍）的应用。咱们能不能让大家一起做一件事？他说道：

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

咱们花了一个下午的工夫来清理 Product Backlog，清晰地展现出了高层级故事和合成进去的较低层级故事之间的分割。当开发人员理解到 Sprint 的指标是将网络操作系统的性能进步 10% 时，他们就有能源去实现低层级的故事，速度也复原了失常。

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

Sprint 指标通常与产品价值无关。团队也能够用过程指标来定义 Sprint 指标 — 例如，通过结对编程来实现所有的编程，或者准时加入每日 Scrum 会。

重复推动 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.