Scrum指南银年纪念版解析 | 真北敏捷

Posted 2021-04-25 真北敏捷

本文既会关注Scrum指南2020版与2017版的差异点，但也并不以关注差异点为目的。目的是加深对Scrum的理解。

本文的体例是：

• Scrum指南原文部分加背景色，如本行所示。

• 解析部分不加背景色。
  

以下开始解析：

Scrum 的定义

Scrum Definition

简而言之，Scrum 需要 Scrum Master 营造一个环境，从而：

1. 一名 Product Owner 将解决复杂问题所需的工作整理成一份 Product Backlog。

2. Scrum Team 在 一个 Sprint 期间将选择的工作转化为价值的 Increment。

3. Scrum Team 和利益攸关者检视结果并为下一个 Sprint 进行调整。

4. 重复

In a nutshell, Scrum requires a Scrum Master to foster an environment where: 

1. A Product Owner orders the work for a complex problem into a Product Backlog.

2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

4. Repeat

这一部分对ScrumMaster赋予重大责任。一个组织中谁是定拍器是一个有争议的问题，是一个哲学问题。有的认为是架构师，有的认为是产品经理。Scrum开宗明义，ScrumMaster是这个定拍器。Scrum的高速公路由此入口，你上不上？

在 Scrum 框架中，可以使用各种不同的过程、技术和方法。Scrum 可以将一些已有的实践包装进 来，也可以甄别出非必须的实践。Scrum 可以凸显当前管理、环境和工作技术的相对成效，以便 可以进行改进。

Various processes, techniques and methods can be employed within the framework. Scrum wraps around existing practices or renders them unnecessary. Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.

这一段并无更新，强调出来的理由是：Scrum的创新之处在于，是一个系统性的暴露系统性问题的机制。尽管不一定非得是Scrum来成为这个机制，但别人也没说有这个机制。

Scrum 理论

Scrum Theory

Scrum 基于经验主义和精益思维。经验主义主张知识源自实际经验以及根据当前观察到的事物作 出的判断所获得。精益思维减少浪费，专注于根本。

Scrum 采纳一种迭代和增量的方法来优化对未来的预测性并控制风险。Scrum 让一群共同拥有所 有技能和专长的人员参与进来完成工作，并根据需要分享或获得所需技能。

Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials. 

Scrum employs an iterative, incremental approach to optimize predictability and to control risk. Scrum engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed.

这一段，一是明确说出了精益思想是Scrum的理论基础之一。这是Scrum的科学性的来源。二是明确说激励一群人。这一点，知之不易，行之惟艰。

当所涉人员没有得到授权或不能自管理（self-managing）时，则适应将变得更加困难。在通过检 视学到任何新东西时，Scrum Team 会做出相应调整。

Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.

Scrum三大支柱的前提是，得到授权和能够进行自管理。科学的东西每每被权力压制。背后需要从权力型组织变为生机型组织。孙逸仙医师说：世界潮流，滚滚向前。

Scrum Team

Scrum 的基本单位是小团队，称为 Scrum Team。Scrum Team 由一名 Scrum Master，一名 Product Owner 和 Developers 组成。在 Scrum Team 中，没有子团队或层次结构。Scrum Team 是具有凝聚 力的专业团体，一次专注于一个目标，即 Product Goal。

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

这一段，第一是用Scrum Team取代了Team和Development Team。第二是提出了Product Goal的说法。大致对应到Procuct Vision + MVP或Epic。

Developers

Developers 所需的特定技能通常很广泛，并且会随着工作领域的不同而变化。但是， Developers 始终要负责：

● 为 Sprint 创建计划，即 Sprint Backlog；

● 通过遵循 Definition of Done 来注入质量；

● 每天根据 Sprint Goal 调整计划；和， 

● 作为专业人士对彼此负责。

The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for: 

● Creating a plan for the Sprint, the Sprint Backlog; 

● Instilling quality by adhering to a Definition of Done; 

● Adapting their plan each day toward the Sprint Goal; and, 

● Holding each other accountable as professionals.

对开发人员的职责重新进行了简洁明了的描述，消除模棱两可。

Product Owner

Product Owner 还负责对 Product Backlog 进行有效管理，包括：

● 开发并明确地沟通 Product Goal ；

● 创建并清晰地沟通 Product Backlog 条目（items）；

● 对 Product Backlog 条目进行排序；和， 

● 确保 Product Backlog 是透明的、可见的和可理解的。

The Product Owner is also accountable for effective Product Backlog management, which includes: 

● Developing and explicitly communicating the Product Goal; 

● Creating and clearly communicating Product Backlog items; 

● Ordering Product Backlog items; and, 

● Ensuring that the Product Backlog is transparent, visible and understood.

对PO的职责重新进行了简洁明了的描述。

Scrum Master

Scrum Masters 是真正的领导者，服务于 Scrum Team 和作为更大范围的组织。

Scrum Master 以多种方式服务于 Scrum Team ，包括：

● 作为教练在自管理和跨职能方面辅导 Scrum Team 成员；

● 帮助 Scrum Team 专注于创建符合 Definition of Done 的高价值 Increment；

● 促使移除 Scrum Team 工作进展中的障碍；和， 

● 确保所有 Scrum 事件都发生并且是积极的、富有成效的，并且在时间盒（timebox）内完 成。

Scrum Master 以多种方式服务于 Product Owner，包括：

● 帮助找到有效定义 Product Goal 和管理 Product Backlog 的技巧；

● 帮助 Scrum Team 理解为何需要清晰且简明的 Product Backlog 条目；

● 帮助建立针对复杂环境的基于经验主义的产品规划（empirical product planning）；和， 

● 当需要或被要求时，引导利益攸关者协作。

Scrum Master 以多种方式服务于组织，包括：

● 带领、培训和作为教练辅导组织采纳 Scrum；

● 在组织范围内规划并建议 Scrum 的实施；

● 帮助员工和利益攸关者理解并实施针对复杂工作的经验主义方法（empirical approach）；和， 

● 消除利益攸关者和 Scrum Teams 之间的隔阂。

这一段，第一是明确指出ScrumMaster是一个真正的领导者。第二是，简洁描述了ScrumMaster对团队、PO和组织的职责。

但也留下了续集（也许不会有）的伏笔：到底啥是真正的领导者？是要把真正的领导者干掉，才能成为真正的领导者吗？还是真正的领导者之外，另有真正的领导者？

The Scrum Master serves the Scrum Team in several ways, including: 

● Coaching the team members in self-management and cross-functionality; 

● Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done; 

● Causing the removal of impediments to the Scrum Team’s progress; and, 

● Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox. 

The Scrum Master serves the Product Owner in several ways, including: 

● Helping find techniques for effective Product Goal definition and Product Backlog management; 

● Helping the Scrum Team understand the need for clear and concise Product Backlog items; 

● Helping establish empirical product planning for a complex environment; and, 

● Facilitating stakeholder collaboration as requested or needed. 

The Scrum Master serves the organization in several ways, including: 

● Leading, training, and coaching the organization in its Scrum adoption; 

● Planning and advising Scrum implementations within the organization; 

● Helping employees and stakeholders understand and enact an empirical approach for complex work; and, 

● Removing barriers between stakeholders and Scrum Teams. 

Scrum 事件

Scrum Events

Sprint 

Sprint 是 Scrum 的核心，在这里创意（idea）转化为价值。

Sprints are the heartbeat of Scrum, where ideas are turned into value.

这一段非常简洁，同时特别强调将创意转化为价值是迭代的核心目的。

存在各种各样的实践来预测进展，例如，燃尽图（burn-downs）、燃起图（burn-ups）或累积流 图（cumulative flows）。尽管被证明是有用的，然而这些实践并不能用来取代经验主义的重要 性。在复杂的环境中，未来将要发生什么是未知的。只有已经发生的事情才能用来做前瞻性的决 策。

Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.

这一段并非新增，只是换了位置。强调这一段是想说明，什么是Scrum不可变通的部分，什么是Scrum可以变通的部分。

Daily Scrum

Developers 可以选择他们想要的任何举行 Daily Scrum 的结构和技术，只要他们专注于实现 Sprint Goal 的进展，并为下一工作日的工作制定可行的计划即可。这可以创建专注点并改进自管理。Daily Scrum 改善沟通，发现障碍，促进快速决策，从而消除其他会议的需要。Daily Scrum 并不是唯一一次允许 Developers 调整计划的时间。他们可以在一天中任何时间碰面， 详细讨论如何调整适应或重新规划 Sprint 的剩余工作。

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management. Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings. The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.

这一段去掉了每日站会的三个问题，仅说明每日站会的目的。另外，说明了每日站会和站会之外的沟通可以结合。

Sprint Review

Sprint Review 的目的是检视 Sprint 的成果并确定未来的适应性。Scrum Team 向关键利益攸关者展 示他们的工作结果，并讨论 Product Goal 的进展情况。在 Sprint Review 期间，Scrum Team 和利益攸关者将评审在这次 Sprint 中完成了什么，以及环境发 生了什么变化。基于这些信息，与会者可以就下一步的工作进行协作。Product Backlog 也可能会 进行调整以适应新的机会。Sprint Review 是一个工作会议，Scrum Team 应避免将其仅限于展示。Sprint Review 是 Sprint 的倒数第二个事件，Sprint Review 是有时间盒限定的，以一个月的 Sprint 来 说，最多为 4 个小时。对于更短的 Sprint，Sprint Review 通常所需的时间更短。

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation. The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

这一段去掉了旧版中迭代评审的检查列表，而重在说明目的。

Sprint Retrospective 

Sprint Retrospective 的目的是规划提高质量和效能的方法。

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

这一段非常明确迭代反思的目的就是为了质量和效能，而不像旧版中说的偏于抽象。效能把敏捷和DevOps贯穿起来，从某种意义上来说，敏捷和DevOps就是效能。

Scrum 工件

Scrum Artifacts

每个工件都包含一个承诺，以确保它提供可增强透明度并聚焦于可度量进展的信息：

● 对于 Product Backlog 而言，它是 Product Goal。

● 对于 Sprint Backlog 而言，它是 Sprint Goal 。

● 对于 Increment 而言，它是 Definition of Done。

这些承诺的存在是为了强化经验主义和 Scrum Team 及其利益攸关者的 Scrum 价值观。

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured: 

● For the Product Backlog it is the Product Goal. 

● For the Sprint Backlog it is the Sprint Goal. 

● For the Increment it is the Definition of Done. 

These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.

这一段给每个工件加了一个承诺物，可增加透明性、专注可度量的进度、强化经验主义、让价值观有下手处和落脚处。

承诺：Product Goal

Commitment: Product Goal

Product Goal 描述了产品的未来状态，可以作为 Scrum Team 制定计划的目标。Product Goal 在 Product Backlog 中。Product Backlog 的其余部分涌现，用来定义“做什么”将实现 Product Goal。产品是传递价值的载体。它具有明确的边界、已知的利益攸关者和定义明确的用户或客 户。产品可以是一种服务、实体产品或其他更抽象的东西。Product Goal 是 Scrum Team 的长期目标。他们必须先实现（或放弃）一个目标，然后再开始下一 个目标。

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal. A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract. The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.

产品列表背后的承诺物是产品目标。

承诺：Sprint Goal

Commitment: Sprint Goal

Sprint Goal 是 Sprint 的单个目标。尽管 Sprint Goal 是 Developers 的承诺，但它为实现该目标所需 的确切工作方面提供了灵活性。Sprint Goal 还创造了连贯性和专注点，鼓励 Scrum Team 一起工作 而不是分开独自行动。Sprint Goal 在 Sprint Planning 事件中确定，然后添加到 Sprint Backlog 中。当 Developers 在 Sprint 期 间工作时，他们将 Sprint Goal 铭记在心。如果需要做的工作与预期的不同，他们将与 Product Owner 协作，在不影响 Sprint Goal 的情况下，协商本次 Sprint Backlog 的范围。

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives. The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

迭代列表背后的承诺是迭代目标。

承诺：Definition of Done

Commitment: Definition of Done

Definition of Done 是当 Increment 符合产品所需的质量度量标准时对其状态的正式描述。当一个 Product Backlog 条目符合 Definition of Done 时，就会产生一个 Increment。Definition of Done 通过使每一个人对作为 Increment 的一部分、什么样的工作算是已完成的工作有 一个共同的理解来创建透明。如果一个 Product Backlog 条目不符合 Definition of Done ，那么它就 不能发布，甚至不能在 Sprint Review 中展示它。相反，它返回到 Product Backlog 中以供将来考 虑。如果 Increment 的 Definition of Done 是组织标准的一部分，那么所有 Scrum Team 都必须以此为最 低标准来遵守。如果它不是组织标准的一部分，那么 Scrum Team 必须制定适合于该产品的 Definition of Done 。Developers 需要遵守 Definition of Done。如果有多个 Scrum Team 在同一产品上一起工作，那么他 们必须一起制定并遵守同样的 Definition of Done 。

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born. The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration. If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product. The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

增量背后的承诺是DoD。

承诺到底是不是军令状呢？

承诺有三种：轻易做出的承诺、压力之下的承诺、深思熟虑的承诺。轻诺必寡信，压力之下无承诺，Scrum的承诺是第三种。Scrum是一种组织气质。

Scrum 指南历史

Scrum Guide History

Scrum 指南记录了 Jeff Sutherland 和 Ken Schwaber 在 30 多年间对 Scrum 的开发、演进和维护。此 外，其他一些资源在模式、过程和见解方面为 Scrum 框架提供了补充。这些可能可以提高生产 力、价值、创造力和对结果的满意度。

The Scrum Guide documents Scrum as developed, evolved, and sustained for 30-plus years by Jeff Sutherland and Ken Schwaber. Other sources provide patterns, processes, and insights that complement the Scrum framework. These may increase productivity, value, creativity, and satisfaction with the results.

这里想说明的是，Scrum的扩展，在模式、流程、洞见。其目的是生产力、价值、创造性、和对结果的满意度的提升。

以下部分只有中文版，没有英文版：

从 2017 版到 2020 版指南的变更 

规定性更低 

这些年来，Scrum 指南开始变得越来越有规定性。2020 版旨在通过删除或淡化规定性语言，使 Scrum 重新成为最低限度的框架。例如删除了 Daily Scrum 三个提问，淡化了关于 PBI 属性的相关 描述，淡化了 Sprint Backlog 中改进项的相关描述，删除了“取消 Sprint”一节更改为更为简单的描 述 ，等等。

一个团队，专注于一个产品 

我们的目标是消除导致 PO 和 Dev 团队（Dev Team）之间出现“代理”或“我们与他们”行为的团队中 独立团队的概念。现在只有一个 Scrum Team 专注于同一目标，有三种不同的职责：PO、SM 和 Developers。

Product Goal 介绍 

2020 版 Scrum 指南引入了 Product Goal 的概念，为 Scrum Team 提供了一个更具价值的目标的专注 点。每个 Sprint 都应使产品更接近整体的 Product Goal。

给 Sprint Goal 、 Definition of Done 和 Product Goal 安了家 

之前版本的 Scrum 指南描述了 Sprint Goal 和 Definition of Done ，但是没有真正赋予它们一个身 份。它们不是完全意义上的工件，而是在某种程度上依附于工件。随着 Product Goal 的增加， 2020 版对此提供了更为清晰的说明。现在，三个工件中的每一个都包含一个相应的的“承诺”。对 于 Product Backlog，它是 Product Goal ，对于 Sprint Backlog 则是 Sprint Goal ，而 Increment 则是 Definition of Done （现在，Done 不再加引号）。它们的存在是为了带来透明度，并专注于每个工 件的进展。

自管理胜过自组织 

之前版本的 Scrum 指南将开发团队（ Development Team） 称为自组织，选择谁和如何做。2020 版更关注 Scrum Team，强调一个自管理的 Scrum Team，选择谁、如何做以及做什么。

三个 Sprint Planning 话题 

Sprint Planning 的话题除了“什么”和“如何”之外， 2020 版 Scrum 指南还强调了第三个话题“为什 么”，即 Sprint Goal 。

为更广泛的受众而全面简化语言 

2020 版 Scrum 指南着重于消除冗余和复杂的陈述，以及删除所有与 IT 工作相关的推断（例如，测 试、系统、设计、需求，等等）。现在， Scrum 指南不到 13 页。

今晚敏捷宣言联合作者、Java Design合著者、领域建模与架构大师做客破马张飞。

我们也与他探讨了Scrum。他的回答可关注B站回放。

Scrum指南原文可在scrumguides.org官网获取，真北敏捷星球也放了一个副本：