2020 Scrum权威指南：游戏规则(简体中文版)

Posted 2021-04-25 ShineScrum捷行

和我们一起探讨

2020Scrum指南

版权声明，©2020 Scrum 指南的版权属Ken Schwaber和Jeff Sutherland所有。ShineScrum 捷行组织志愿者精心翻译，邀请多位专家评审，保证中文简体版的质量，与原版英文内容的高度一致性。欢迎Scrum 实践者指出不足之处，给出反馈或如有转载，请联系我们。

Scrum指南的意图

我们于90年代早期开创了Scrum。2010年，我们撰写了第一版Scrum指南，帮助世界各地的人们理解Scrum。从那时起，我们一起演进这本指南，实施了数次小的、功能性更新。我们是Scrum指南的后盾。

Scrum指南涵盖Scrum的定义。框架的每个元素都有特定的意图，对Scrum的整体价值和Scrum实现的成果都必不可少。改变Scrum的核心设计或想法，省略元素，或不遵守Scrum的规则，就会掩盖问题，并限制了Scrum的收益，甚至可能使Scrum没有用处。

在这个愈来愈复杂的世界中，Scrum的应用也愈发广泛。我们谦虚地发现，除了Scrum起源的软件产品开发行业之外，还有许多在本质上含有复杂性工作的领域，也采用了Scrum。Scrum的应用扩展到开发人员，研究人员，分析人员，科学家等其他专业人士的工作。在Scrum中，我们使用“开发人员”的说法是一种简化，而不是排除他人。如果你从Scrum中获得了价值，那么你可以认为自己就是其中的一员。

伴随着Scrum的实施，人们发现、应用和设计出了一些模式、流程和洞察，它们与这本指南中描述的Scrum框架可能会契合。然而，由于这些实践与背景情况相关，并且在Scrum使用中差异很大，所以超出了这本Scrum指南的意图。这样的战术在Scrum框架中的用法千差万别，其他地方有相关描述。

Ken Schwaber & Jeff Sutherland 2020年11月

Scrum定义

Scrum是一个轻量级的框架，用于帮助个人、团队和组织，通过为复杂问题提供适应性的解决方案，从而产生价值。

简言之，Scrum要求Scrum Master营造如下的环境，以便：

      1. 产品负责人将复杂问题所需的工作排序为产品待办列表。

      2. Scrum团队在一个Sprint中，将选定的工作转化为价值增量。

      3. Scrum团队与相关干系人检视结果，调整下一个Sprint。

      4. 重复。

Scrum很简单。按原样尝试一下，确定它的哲学、理论和结构是否可以帮助你实现目标和创造价值。Scrum框架仅仅提供了实施Scrum理论所必须的部分，其不完整性是有意为之。Scrum是由实践者的集体智慧共创所形成。Scrum的规则并不是提供详细的行事说明，而是指导人们的关系和互动方式。

在框架之下，有很多的流程、技巧和方法可以使用。Scrum可以将现有的实践囊括进来，也可以将不必要的实践排除出去。Scrum将当前的管理、环境和工作技术的相对功效暴露可见，以便实施改善。

Scrum理论

Scrum建立在实验主义论和精益思想之上。实验主义主张知识来自经验，应根据观察结果做出决策。精益思想则强调消除浪费、聚焦于本质。

Scrum使用迭代、增量式的方法，来优化可预测性和控制风险。Scrum让一组集体上具备工作所需的全部技能和专业知识的人们参与进来完成工作，并根据需要分享和获取这些技能。

Scrum包括四个正式事件，用于检视和调整。这四个事件本身又包含在Sprint这个容器事件之中。这些事件落实了实验型的Scrum三大支柱，即透明、检视和调整，因此才会有效。

透明

涌现的流程和工作必须对工作的实施方和接收方都可见。使用Scrum，重要的决定是基于三个正式的工件的感知状态而做出的。如果工件透明度不足，做出的决定就会降低价值，增加风险。

透明度使检查成为可能。没有透明，检视会误导，浪费时间。

检视

 

必须经常地、严谨地检视Scrum的工件及其相对于目标的进度，查明潜在的不利偏差或者问题。为了帮助检视，Scrum提供五个事件的形式保证了一定的节奏。

检视是调整的前提。没有检视，调整毫无用处。Scrum事件的设计旨在引发改变。

调整

如果流程的任何方面偏离了外界可接受的限度，或者产生的产品不能被接受，那么所使用的流程或者生产出的内容必须做出调整。应尽快做出调整，以避免发生更多的偏差。

如果团队没有被授权，或不是自我管理的，他们去做调整会较为困难。检视中一旦学习到任何新情况，Scrum团队有望就可立即做出调整。

Scrum价值观

能否成功实施Scrum，取决于团队是否可以出色地践行五个价值观：承诺、专注、开放、尊重，勇气。

Scrum团队承诺完成目标，并且互相支持。他们的首要专注点是完成Sprint的工作，向着目标取得最大的进展。Scrum团队和相关干系人互相开放工作内容和挑战。Scrum团队成员尊重彼此的能力和独立性，也能得到其他共事团队的尊重。Scrum团队有勇气去做正确的事情，去解决难题。

这些价值观指导Scrum团队的工作、行动和行为。团队所做出的决定，所采取的步骤，和实施Scrum的方式，都应当强化这些价值观，而不是削弱和破坏它们。Scrum团队成员通过Scrum事件和工件，学习和探索这些价值观。当Scrum团队以及他们所共事的团队都能够身体力行这些价值观，那么实验型的Scrum的三大支柱，即透明、检视和调整就有了生命，铸就了信任。

 

Scrum团队

Scrum的基本单位是一个小团队，也就是Scrum团队。Scrum团队包括一位Scrum Master，一位产品负责人，以及开发人员。Scrum团队内部没有子团队，也没有阶层之分。它是一个专业人士组成的，有凝聚力的群体单元，在一个时间里专注于一个目标，也就是产品目标。Scrum团队是跨职能的，意味着成员具备在每个Sprint创造价值所必须的技能。他们也是自我管理的，意味着他们内部决定谁做什么，什么时候，如何做。

Scrum团队的规模要足够小，才能保持灵活性，也要足够大才能完成Sprint的重要工作。通常不超过10人组成。一般来说，我们发现团队越小，沟通越有效，生产效率也更高。如果Scrum团队太大，应考虑重新组织，成为多个有凝聚力的Scrum团队，所有团队都专注于同一个产品。因此，他们应该享有共同的产品目标，产品待办列表，以及产品负责人。

Scrum团队对所有的产品相关活动负责，包括相关干系人协作，验证，维护，运营，试验，研发，以及其它可能需要做的事情。团队的结构以及组织的授权使得他们可以管理自己的工作。在Sprint事件容器里以可持续的步调工作，提高了团队的专注度和一致性。整个Scrum团队负责在每个Sprint创造有价值和有用的增量。Scrum定义了三个特定的Scrum团队职责：开发人员、产品负责人和Scrum Master。

开发人员

Scrum团队中的开发人员承诺在每个Sprint创建某个方面的可用增量。

开发人员所需要的特定技能通常范围很广，并且会随着工作领域而变化。

但是开发人员需要一直对以下负责：

     · 创建Sprint计划，即Sprint待办列表；

     · 通过遵循完成的定义为产品注入质量；

     · 围绕Sprint目标，调整每日的计划；并且，

     · 作为专业人士，彼此有担当。

产品负责人

产品负责人负责最大化来自Scrum团队工作产生的产品价值。在不同的组织、Scrum团队和个人之间，如何完成这些工作可能有很大差异。

产品负责人负责有效的产品待办列表管理，包括：

     · 创建并明确沟通产品目标；

     · 创建并清晰沟通产品待办列表的事项；

     · 对产品待办列表事项进行排序；并且，

     · 确保产品待办列表是透明、可见，被理解的。

产品负责人可以自己做以上的工作，也可以将责任委派给其他人。无论何种方式，产品负责人承担责任。

组织的所有人必须尊重产品负责人的决定，他们才能成功。这些决定是可见的，体现在产品待办列表的内容和排序中，还有Sprint评审的可检视增量中。

产品负责人是一个人，而不是一个委员会。产品负责人可以代表产品待办列表中的许多利益干系人方面的需求。那些想要更改产品待办列表的人可以通过试图说服产品负责人来实现。

 

Scrum Master

Scrum Master负责根据Scrum指南的定义建立Scrum。他们通过帮助Scrum团队内部和组织中的每个人来理解Scrum理论和实践来做到这一点。

Scrum Master为Scrum团队的效能负责。他们通过促进Scrum团队在Scrum框架中改善实践来实现这一点。

Scrum Master是真正的领导，为Scrum团队和更大的组织服务。

Scrum Master服务Scrum团队的方式包括：

     · 在自我管理和跨职能的方面，教练团队成员；

     · 帮助Scrum团队聚焦于创建高价值增量，并满足完成的定义；

     · 移除阻碍Scrum团队前进的障碍；并且，

     · 确保执行所有的Scrum事件按时发生，积极正向、富有成效，并且在时间盒之内。

Scrum Master服务产品负责人的方式包括：

     · 帮助找到有效的产品目标定义和产品待办列表管理的技能；

     · 帮助Scrum团队理解对清晰简明的产品待办列表事项的需求；

     · 帮助建立复杂环境下实验型的产品规划；并且，

     · 在被请求或需要的时候，引导相关干系人协作。

Scrum Master服务组织的方式包括：

     · 为组织采用Scrum提供领导、培训和教练；

     · 为组织实施Scrum提供规划和建议；

     · 帮助组织的雇员和相关干系人理解和制定解决复杂工作的实验型的方法；并且，消除相关干系人和Scrum团队之间的隔阂。

Scrum事件

Sprint是所有其它事件的容器。每个Scrum事件都是一次正式的检视和调整Scrum工件的机会。这些事件的特别设计就是为了确保所需的透明。

若无法操作规定的任一事件，会导致失去检视和调整的机会。Scrum的事件用来创建一种规律性，最大程度地减少对Scrum中未定义的会议的需求。

理想情况下，所有的事件都在相同的时间和地点举行，以降低复杂性。

 

Sprint 

Sprint是Scrum的心跳，在这里，创意转化成价值。

他们是固定长度的事件，为期一个月或者更短，以保持一致性。上一个Sprint结束后立即开始一个新的Sprint。

完成产品目标所需的全部工作都发生在Sprint期间，包括Sprint计划会议，每日站会，Sprint评审会，以及Sprint回顾会。

在Sprint期间：

     · 不做会损害Sprint目标的变更；

     · 质量不能降低；

     · 产品待办列表根据需要进行梳理；并且，

     · 随着了解更多信息，可以与产品负责人澄清和重新谈判范围。

由于Sprint保证了至少每个月都会根据Sprint目标，对工作进度进行检视和调整，工作的可预测性成为可能。当Sprint的跨度过长，Sprint目标可能会失效，复杂度可能会上升，风险也增加了。使用较短的Sprint，可以产生更多的学习周期，成本和投入的风险控制在较小的时间范围内。每个Sprint都可以当作一个短的项目。

有很多预测进度的实践，比如燃尽图，燃起图，或者累积流量图。尽管都被证明有用，他们并不能取代实验主义的重要性。在复杂环境中，没人知道会发生什么。只有那些已经发生的事情可以被用来做为前瞻性的决策依据。如果Sprint目标过时了，可以取消Sprint。只有产品负责人有权取消Sprint。

Sprint计划会议

Sprint计划会议安排当前Sprint需要执行的工作，从而启动Sprint。这份计划是由整个 Scrum 团队共同协作完成的。

产品负责人要确保所有参与者准备好讨论最重要的那些产品待办列表事项，以及它们该如何映射到产品目标。Scrum团队可以邀请其他人来参加Sprint计划以提供建议。

Sprint 计划会议要解决以下几个议题：

议题一：为什么当前的Sprint是有价值的？

产品负责人建议产品如何在当前的Sprint中增加其价值和实用性。然后，整个Scrum团队将共同制定一个Sprint目标，以此向相关干系人传达当前Sprint是有价值的原因。Sprint计划会议结束之前，必须确定Sprint目标。

议题二：当前Sprint交付的增量中要包含什么内容？

通过与产品负责人的讨论，开发人员从产品待办列表中选择要包含在当前Sprint中的待办项目。Scrum团队可以在此过程中梳理这些事项，从而增加了对这些事项的理解和信心。

选择在Sprint中可以完成多少工作可能会具有挑战。然而，开发人员对他们自身过去的表现、接下来的生产能力以及完成的定义了解得越多，他们对Sprint预测的信心就会越大。

议题三：要如何完成交付增量所选的工作？

对于每个选定的产品待办事项，开发人员来计划构建符合完成的定义的增量所需的工作量。这通常需要将产品待办事项分解为一天或更短的较小工作项来完成。开发人员需要自行决定如何完成这项工作。没有人告诉他们如何将产品待办事项转化为价值增量。

Sprint目标，当前Sprint选择的产品待办列表事项以及交付它们的计划，统称为Sprint待办列表。

对于周期为一个月的 Sprint，Sprint计划会议的最长时限为 8 小时。对于较短的 Sprint，会议时间通常会缩短。

每日Scrum站会

每日Scrum站会的目的是根据Sprint目标检视实施的进度，并根据需要调整Sprint待办列表，以及调整计划中即将进行的工作。

每日Scrum站会是Scrum团队的开发人员以15分钟为限的活动。为了降低复杂性，Sprint中的每个工作日，站会都在同一时间同一地点进行。如果产品负责人或Scrum Master也在积极处理Sprint待办事项，他们将作为开发人员参与站会。

开发人员可以选择他们想要的任何会议结构和技巧，只要他们的站会专注于实现Sprint目标的进度，并为接下来一天的工作制定可执行的计划即可。这样做不仅可以营造团队的专注力，而且增强了团队的自我管理。

每日Scrum站会可以增强交流沟通、识别障碍、促进快速决策，从而消除了召开其他会议的需要。

每日Scrum站会并不是开发人员可以调整计划的唯一机会。在一天中他们经常碰头，对调整或重新计划当前Sprint中剩余的工作进行更详细的讨论。

Sprint评审会议

Sprint评审会议的目的是检视当前Sprint的成果并确定未来的适应方案。Scrum团队向关键相关干系人展示他们的工作结果，并在产品目标的讨论上更进一步。

在这个会议中，Scrum团队和相关干系人将评审该Sprint中取得的成果以及环境中发生的变化。根据这些信息，与会者共同协商下一步的工作。产品待办事项列表也可能会进行调整，来满足新的机会。Sprint评审会议是一个工作会议，Scrum团队应避免将其限于演示文稿。

Sprint评审会议是Sprint中倒数第二个事件。对于周期为一个月的Sprint，评审会议的时限最多为4小时。对于更短的Sprint来说，会议的长度通常会有所缩短。

Sprint回顾会议

Sprint回顾会议的目的是规划提高质量和效能的方法。

Scrum团队针对个人、团队互动、流程、工具以及完成的定义等方面，检视当前Sprint的进展情况。需要检视的元素通常随工作领域的不同而变化。找出误导它们的那些假设，并探究其起源。Scrum团队需要讨论Sprint中哪些是进展顺利的，遇到了哪些问题，以及这些问题是如何被解决（或未解决）的。

Scrum团队找出对提高效能最有帮助的改变。最有影响的改进应该尽可能快地得到处理。它们甚至可以添加到下一个Sprint的Sprint待办列表中。

Sprint回顾会议是当前Sprint的结束。对于长度为一个月的Sprint，会议限时最多为3小时。对于较短的Sprint，会议时间通常会缩短。

Scrum工件

Scrum的工件代表着工作的任务或价值。它们旨在最大化关键信息的透明度。因此，检视它们的每个人在适应时都有相同的依据。

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

     · 对于产品待办列表的承诺是产品目标。

     · 对于Sprint待办列表的承诺是Sprint目标。

     · 对于增量的承诺是完成的定义。

这些承诺的存在是为了加强Scrum团队及其相关干系人的实验主义论和Scrum价值观。

产品待办列表

产品待办列表是一个涌现式的、有序的列表，它包含了产品改进所需的内容。它是Scrum团队进行工作的唯一来源。

只有那些Scrum团队可以在一个Sprint中完成的产品待办事项，才能作为Sprint计划会议中的准备就绪事项。这种透明度通常需要通过“产品待办列表梳理”活动来获得。产品待办列表梳理是将产品待办事项进行拆分，并进一步梳理为更小更精确的事项。这是一项持续不断的活动，用来为产品待办事项补充细节，包括细节描述，排序和评估大小等。添加的细节属性通常随工作领域的不同而变化。

将要执行工作的开发人员负责估算其工作量的大小。产品负责人可以通过帮助团队更好地理解需求，并根据情况权衡取舍来影响开发人员。

 

承诺：产品目标

产品目标描述了产品的未来状态，它可以作为Scrum团队制定计划的目标。产品目标在产品待办列表中。其余的产品待办列表内容涌现，都是用来定义“什么”可以实现产品目标。

产品是传递价值的载体。它具有明确的边界，已知的相关干系人，定义明确的用户或客户。产品可以是服务，物理产品或其它更抽象的东西。

产品目标是Scrum团队的长期目标。他们必须先实现（或放弃）一个目标，然后才能承担下一个。

Sprint待办列表

Sprint待办列表由Sprint目标（为什么），当前Sprint选择的产品待办事项集（做什么）以及可执行的交付增量的计划（如何做）三部分组成。

Sprint待办列表是为开发人员制定的计划，这份计划由他们自己来制定。这是一份高度可见并且实时的工作全貌，它展现了开发人员计划在Sprint期间，为实现Sprint目标而需要完成的工作。因此，随着越来越多的学习了解，更新Sprint待办列表将贯穿在整个Sprint中。Sprint待办列表应该足够的详细，开发团队可以在每日站会中用它来检视进度。

承诺：Sprint目标

Sprint目标是当前Sprint唯一的目标。尽管Sprint目标是开发人员的一项承诺，它在实现目标所需的确切工作上具有一定的灵活性。与此同时，Sprint目标建立了连贯性和聚焦点，它鼓励Scrum团队一起工作，而非各自独立行动。

Sprint目标在Sprint计划会议中创建，并且添加到Sprint待办列表中。在Sprint期间，开发人员工作时要牢记Sprint目标。当工作的结果与预期的不同时，在不影响Sprint目标的情况下，开发人员与产品负责人共同谈判协商当前Sprint待办列表的范围。

增量

增量是实现产品目标的一块坚实的垫脚石。每个增量都是迭加在之前所有的增量之上，它必须经过彻底的验证，以确保所有的增量可以同时起作用。为了提供价值，增量必须是可用的。

一个Sprint中可以创建多个增量。所有的增量总和在Sprint评审会议中展示，从而支持实验主义论的过程。尽管如此，增量可以在Sprint结束之前交付给相关干系人。Sprint评审绝不应该被视为释放价值的关卡。

除非一项工作符合完成的定义，否则它不能被视为增量的一部分。

承诺：完成的定义

完成的定义是对增量达到产品所需的质量度量这一状态的一种正式描述。

当产品待办事项满足完成的定义时，一个增量就诞生了。

完成的定义使每个人对怎样的工作可以作为完成的增量有着相同的理解，从而提高了透明度。如果产品待办事项不符合完成的定义，则该事项不能被发布，甚至不能在Sprint评审会议中被展示。相反，它将被退回到产品待办列表中，供将来进一步斟酌。

如果增量完成的定义是组织标准的一部分，则它是所有Scrum团队都必须遵循的最低标准。如果它不是组织标准，则Scrum团队必须创建一个适合该产品的完成的定义。

开发人员必须遵守完成的定义。如果一个产品有多个Scrum团队共同开发，则他们必须共同制定并遵守相同的完成的定义。

结束语

Scrum是免费的，由本指南来提供。本文概述的Scrum框架是不可改变的。尽管可以只实施Scrum中的某些部分，但由此得到的结果并不是Scrum。只有当Scrum以一个整体的形式存在，才能成为其它技术、方法论和实践的容器进行良好的运作。

 

致谢

 

人们

在千千万万Scrum的贡献者中，我们要特别感谢那些在其最初提供帮助的人们：Jeff Sutherland以及与他一起工作的Jeff McKenna和John Scumniotales。Ken Schwaber以及与他一起工作的Mike Smith和Chris Martin。他们全都在一起工作。许多人在随后的几年中也都作了贡献，没有他们的帮助，Scrum不会像今天这般精炼。

Scrum指南历史

Ken Schwaber和Jeff Sutherland在1995年的OOPSLA大会中首次共同演说Scrum。那次演讲本质上是记录了Ken和Jeff在之前几年中所学到的经验，并且公布了第一版Scrum的正式定义。

《 Scrum指南》记录了由Jeff Sutherland和Ken Schwaber开发，演变和维持30多年的Scrum。

其它一些资料从模式、流程和见解方面为Scrum框架提供了补充。由此为最终成果提高了生产力、价值、创造力以及满意度。

完整的Scrum的历史在别处描述。我们对首批尝试和证明Scrum的公司表示致敬：Individual Inc., Newspage, Fidelity Investments, 以及IDX（现在的 GE Medical）。

2020版Scrum指南与2017版的不同之处

 

更少规定性

过去数年中，Scrum指南逐渐变得带有规定性。这次的2020年版本致力于去除或者弱化规定性的语言，从而让Scrum重归最简充分框架。比如，去掉了每日站会的问题，弱化了关于产品待办列表事项的属性，以及在Sprint待办列表中涵盖回顾工作项的语言，缩短了Sprint取消的部分，等等。

一个团队，专注一个产品

目标是消除团队中的不同团队的概念，因为这样会导致在产品负责人和开发团队之间出现“代理人”或是“我们和他们”的行为。现在只有一个Scrum团队，专注于同一个目标，承担三种不同的责任：产品负责人，ScrumMaster，和开发人员。

 

产品目标的引入

2020版Scrum指南引入了产品目标的概念，为Scrum团队提供了他们需要关注的更大的价值目标。每个Sprint都需要将产品进一步推向总体的产品目标。

给Sprint目标，完成的定义，和产品目标赋予正确的归属

之前的Scrum指南版本尽管描述了Sprint目标和完成的定义，却并未真正赋予它们真正的归宿。它们本身不是工件，但是在某种程度上与工件相联。加上产品目标，2020版提供了更多的清晰阐述。三个工件都各自包含了对它们的“承诺”。产品待办列表对应产品目标，Sprint待办列表对应Sprint目标，而增量对应完成的定义（完成不带引号）。它们的存在，为每个工件的进度带来了透明和专注。

自管理而不是自组织

之前的Scrum指南版本，将开发团队称为自组织团队，可以自行选择团队成员和工作方式。随着对Scrum团队的更多关注，2020版本强调自管理的Scrum团队，可以自行选择团队的成员、工作方式，以及工作内容。

三个Sprint计划的主题

关于Sprint计划主题，在“做什么”和“怎么做”的基础上，2020版Scrum指南把重点放在了第三个主题，“为什么做”，也就是Sprint目标。

整体简化了语言，为更广泛的读者服务

2020版Scrum指南着重于去除冗余和复杂的陈述，以及含有的与信息技术工作相关的论述（例如：测试，系统，设计，需求等）。现有的Scrum指南篇幅还不到13页。（中文译者注：此篇幅数字指英文版。）

关于2020版Scrum指南简体中文版的翻译

2020版Scrum指南的简体中文版的翻译工作由苏洁(Suzzi Su)和叶超(Emma Ye)完成。翻译文本亦有参考2017版Scrum指南(由ShineScrum 捷行翻译)简体中文版本。CST 王军(Jim Wang)指导和最终审核2020版。

© 2020 Ken Schwaber and Jeff Sutherland  

This publication is offered for license under the Attribution Share-Alike license of Creative Commons,accessible at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution

Share-Alike license of Creative Commons.

Daisy: Tel [phone] 

15618369971(微信手机同号)   

Vicky: Tel [phone]

18221078480(微信手机同号)   

联系我们

邮箱：[e-mail]

网址：www.shinescrum.com

       www.shinescrum.cn