Scrum指南 (中文版，LeSS版)

下载英文版PDF

Craig Larman & Bas Vodde (原先版本由Ken Schwaber & Jeff Sutherland提供) 2024年7月

Scrum指南的目的

Scrum是一个开发、交付和维持产品的框架。这份指南包含了Scrum的定义。这个定义由Scrum角色、事件、工件，以及将它们绑在一起的规则组成。框架的每个元素服务于特定目的，这些目的对通过Scrum实现整体价值和结果都至关重要。改变Scrum的核心设计和想法、舍弃一些元素、或者不遵循Scrum规则会掩盖问题并限制Scrum的好处，可能甚至让它失效。

Ken Schwaber和Jeff Sutherland引领了Scrum框架的发展。

LeSS（大规模Scrum）是一个从将Scrum应用于多团队产品开发的结果中演进出来的组织系统。LeSS规则定义了LeSS。LeSS规则假设团队内采用Scrum结构，并在整体产品层面运用Scrum概念（如本指南中所定义）。

为什么有Scrum指南的这版更新？最近版本的Scrum和LeSS并行演进，这导致了在大规模Scrum中假设的Scrum是不同Scrum版本的组合，由此产生不一致，以及潜在导致一个在多团队场景下更为复杂且不够适应的组织。

这个版本的指南描述了LeSS中假设的Scrum。Craig Larman和Bas Vodde在Ken Schwaber的Scrum指南基础上发展了LeSS和这个版本的指南。

本出版物根据知识共享（Creative Commons）的署名-相同方式共享（Attribution Share-Alike）许可协议提供许可，可在以下网址访问https://creativecommons.org/licenses/by-sa/4.0/legalcode并以摘要形式描述于https://creativecommons.org/licenses/by-sa/4.0/。通过使用本Scrum指南，您承认并同意您已阅读并同意受知识共享的署名-相同方式共享许可条款的约束。

Scrum定义

Scrum是一个轻量级的框架，它解决复杂的适应性问题，帮助组织高效并创造性地交付一个具有最高可能价值的产品。

简而言之，Scrum规定：

一个产品负责人对用以增量地创建一个产品的想法进行排序。
团队把选择的这些想法转变成一个有价值的产品增量。
团队、产品负责人和干系人一起检视结果并调整下一个迭代。
重复。

Scrum框架有意不完整。它提供了一个壳，需要使用它的人的集体智慧来填充。它让当前管理、环境和工作技能的相对有效性变得透明，以使产品、团队以及工作环境的持续改进能够发生。

Scrum是简单的。Scrum规则没有给人提供详细的指令，而是将角色、事件和工件绑在一起，管理它们之间的关系和交互。Scrum规则被贯穿在本文档中加以描述。

Scrum理论

Scrum基于经验主义。经验主义认为知识来自经验以及根据观察到的情况做决定。Scrum采用迭代、增量的方法来优化适应性，并尽早暴露风险。

经验主义有三个支柱：透明性、检视和适应。

透明性

Scrum既支持又要求透明性。它通过定义检视-适应节点来实现透明性。但它也要求涌现的过程和产品对执行工作的人和接收产品的人都是透明的。透明性使检视成为可能；没有透明性的检视是误导且浪费的。

检视

必须经常认真地检视进度和过程，以发现潜在改进和新的机会来提高价值交付、适应性、有效性和工作满意度。为了帮助检视，Scrum以四个事件的形式来提供节奏。

检视使适应成为可能。没有适应的检视被认为是毫无意义的。Scrum事件被设计用来引发改变。

适应

如果发现潜在改进或新的机会，则可以调整所使用的流程和/或生产的产品。调整必须尽快，以最大化价值交付。

当相关人员没被授权或没有自管理时，适应会变得更加困难。

Scrum价值观

Scrum的成功使用取决于人们越来越能践行五个价值观：

承诺、聚焦、开放、尊重和勇气

团队承诺不断改进和相互支持。他们的主要焦点是迭代中的工作，以取得最佳进展。团队、产品负责人及其干系人对工作和挑战持开放态度。团队成员相互尊重对方是有能力且独立的人，也因此受到与他们一起工作的人的尊重。团队成员有勇气做正确的事，解决棘手的问题。

这些价值观为工作、行动和行为提供了方向。做的决定、采取的步骤以及Scrum的使用方式都应该强化这些价值观，而不是削弱或破坏它们。当这些价值观体现在团队和他们一起工作的人身上时，Scrum的经验支柱——透明性、检视和适应——就会变得生动起来，建立信任。

Scrum角色

Scrum由一个Scrum Master，一个产品负责人和一个团队组成，所有角色都关注产品愿景。

团队规模既要足够小以保持灵活性，又要足够大以在迭代内完成有意义的工作，通常为10人或更少。一般来说，我们发现规模较小的团队沟通更好，效率更高。如果团队变得太大，他们应该考虑重组成多个内聚的团队，每个团队都专注于同一产品。因此，他们应该共享同一产品愿景、产品待办列表和产品负责人。

团队和产品负责人负责所有与产品相关的活动，包括干系人协作、验证、维护、运营、实验、研发以及任何创建产品可能需要的其它活动。他们由组织建立并授权来管理自己的工作。以一个可持续的节奏按迭代工作可以提高专注力和一致性。

团队

团队由承诺于每个迭代创建一个可用产品增量任何方面的人组成。

该团队具有以下特点：

团队是自管理的，这意味着他们在内部决定谁做什么、什么时候做以及如何做——他们负责监控和管理流程和进度。
团队是跨职能的，团队成员拥有或可以获得创建产品增量所需的所有技能。
团队里面没有与测试、架构、运营、用户体验或业务分析等主题相关的子团队。
团队成员可能有专业技能和专注领域，但责任属于整个团队。
团队不以团队成员拥有的限制其职责的头衔或角色进行区分。

团队成员所需的具体技能通常很广泛，并且会因工作领域而异。但是，团队成员始终负责：

为迭代制定计划，即迭代待办列表；
通过遵守完成的定义来注入质量；
每天调整计划以达成迭代目标；并且，
作为专业人士相互问责。

产品负责人

产品负责人负责使团队工作产生的产品价值最大化。如何做到这一点可能因组织而异。

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

制定并明确传达产品愿景；
添加产品待办条目，并清楚地传达它们是如何实现产品愿景的；
给产品待办条目排序；并且，
确保产品待办列表透明且被理解。

产品负责人可以自己完成上述工作，也可以将责任委托给他人。无论如何，产品负责人仍需担责。

为了使产品负责人取得成功，整个组织必须尊重他们的决定。这些决定透明在产品待办列表的内容和顺序上，以及通过迭代评审中的可检视增量。

产品负责人是一个人，而不是一个委员会。产品负责人可能会在产品待办列表中代表许多干系人的需求。想要更改产品待办列表的人可以通过说服产品负责人来达成。

Scrum Master

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

Scrum Master负责一个运作良好的团队和产品负责人，还要让组织理解Scrum并使用它来帮助价值交付和适应性。他们通过支持改进来做到这一点。

Scrum Master是真正的领导者，为团队、产品负责人和更大的组织服务。Scrum Master以多种方式服务于团队，包括：

辅导团队成员进行自管理和跨职能；
帮助团队聚焦创建符合完成定义的高价值增量；
消除阻碍团队进展的障碍；并且，
确保所有Scrum事件都发生，并且是积极的、富有成效的，以及控制在时间盒内。

Scrum Master以多种方式服务于产品负责人，包括：

帮助找到有效的技术来定义产品愿景和管理产品待办列表；
帮助产品负责人和团队理解清晰简洁的产品待办条目的必要性；
帮助建立用于复杂环境的经验型产品规划；并且，
根据请求或需要引导干系人合作。

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

在Scrum导入中带领、培训和辅导组织；
在组织内规划和建议Scrum导入；
帮助员工和干系人理解并制定用于复杂工作的经验型方法；并且，
消除干系人与团队和产品负责人之间的障碍。

迭代

迭代是Scrum的核心，想法在迭代里被转化为价值。

迭代固定为一个月或更短的长度，以保持一致性。新的迭代在前一个迭代结束后立即开始。

实现产品愿景所需的所有工作，包括迭代计划、每日站会、迭代评审、迭代回顾以及产品待办列表梳理，都发生在迭代内。

迭代期间：

不进行任何可能危及迭代目标的变更；
不牺牲质量；
随着了解更多，可以与产品负责人澄清并重新协商范围。

迭代建立了一种节奏，并确保对实现产品愿景的进展加以检视和适应。可以采用更短的迭代来生成更多的学习周期，并将成本和精力的风险限制在更短的时间范围内。每个迭代都可以被视为一个简短的项目。

有各种预测进展的做法。虽然有时需要预测，但预测实践并不能取代经验主义的重要性。在复杂的环境中，会发生什么是未知的。只有已经发生的事情才可以被用于向前决策。

如果迭代目标过时了，迭代可以被取消。只有产品负责人有权取消迭代。

Scrum事件

Scrum中的每个事件都是一个正式的检视和适应机会。这些事件是为实现所需的透明性专门设计的。未能按规定进行任何事件都会导致失去检视和适应的机会。Scrum中使用事件来建立规律，并最小化对Scrum中未定义会议的需求。理想的情况是所有事件都在同个时间和地点举行，以降低复杂度。

迭代计划

迭代计划通过规划迭代要执行的工作来开启迭代。由此产生的计划是团队和产品负责人协作创建的。其他人可能会被邀请参加迭代计划以提供建议。

产品负责人确保与会者准备好讨论最重要的产品待办条目以及它们如何帮助实现产品愿景。

迭代计划涉及以下主题：

为什么这个迭代有价值？–产品负责人提出产品如何在当前的迭代中增加其价值和效用。然后，团队和产品负责人合作定义迭代目标，以此传达该迭代为什么对干系人有价值以及它如何帮助实现产品愿景。迭代目标必须在迭代计划结束前最终确定。

这个迭代能做什么？–通过与产品负责人的讨论，团队从产品待办列表的顶部选取要放进当前迭代的条目。团队可以在此过程中完善这些条目。

将如何完成所选工作？–对于每个选取的产品待办条目，团队规划将其做成符合完成定义的增量所需的工作。这经常是通过将产品待办条目分解为一天或更短时间的较小任务来实现的。如何完成由团队全权决定。

迭代目标是迭代的唯一目的。就所需的确切工作而言它提供了灵活性。如果工作结果与预期不同，团队将在迭代内与产品负责人合作协商迭代待办列表的范围，而不影响迭代目标。迭代目标还创造了连贯性和聚焦，鼓励团队共同努力，而不是各自为战。

迭代目标、为该迭代选取的产品待办条目以及交付它们的计划统称为迭代待办列表。

对于一个月的迭代，迭代计划的时间限制为最多八小时。对于更短的迭代，事件时长通常也更短。

每日站会

每日站会的目的是检视迭代目标的进展，并在必要时适应迭代待办列表，调整即将到来的计划工作。

每日站会是最长15分钟的团队事件。为了降低复杂度，它在迭代里每个工作日的同一时间和地点举行。

团队可以选择他们想要的任何方式和技术，只要他们的每日站会专注于实现迭代目标的进展，并为未来24小时的工作制定一个可操作的计划。这可以带来聚焦并提高自管理。

每日站会可以改善沟通、识别障碍、促进快速决策，进而消除了对其它会议的需求。

每日站会并不是团队唯一可以调整计划的时机。他们在一天当中经常会碰面就调整或重新规划迭代的剩余工作进行更详细的讨论。

迭代评审

迭代评审的目的是检视迭代的结果并形成未来的适应。团队和产品负责人向关键干系人介绍产品增量，并讨论产品愿景的进展。

在该事件中，团队、产品负责人和干系人评审迭代中取得的成就以及在他们环境里发生的变化。基于这些信息，与会者协商下一步做什么。产品待办列表也可能进行调整，以满足新的机会。迭代评审是一个工作会议，应避免只进行演示。

迭代评审是迭代中的倒数第二个事件，对于一个月的迭代，时间限制为最多四小时。对于更短的迭代，事件时长通常也更短。

迭代回顾

迭代回顾的目的是计划如何提高质量、有效性和乐趣。

团队检视上个迭代在个人、交互、流程、工具及其完成定义这些方面的情况。被检视的部分通常因工作领域而异。识别导致他们跑偏的假设，并探索其来源。团队讨论迭代期间哪些进展顺利，遇到了哪些问题，以及这些问题是如何解决的（或没有解决）。

团队确定最有助于提高其有效性的改变。最具影响力的改进将尽快得到推进。它们甚至可能被添加到下一个迭代的迭代待办列表中。

迭代回顾结束迭代。对于一个月的迭代，时间限制为最多三小时。对于更短的迭代，事件时长通常也更短。

产品待办列表梳理

产品待办列表梳理的目的是确保产品待办列表得到良好维护，为迭代计划做好准备，并与产品愿景保持一致。产品待办列表梳理可以作为持续的活动、迭代计划的一部分或迭代期间的单独事件来进行。

在产品待办列表梳理过程中，产品负责人会强化产品愿景。团队和产品负责人，需要时与干系人一起，将（1）澄清可能被选进即将到来的迭代中的产品待办条目，（2）拆分那些过大且很快将被考虑做的产品待办条目，以及（3）估算新的产品待办条目的大小，或在需要时重估已有的产品待办条目。

产品待办列表梳理通常最多占用迭代10%的时间。

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的完整历史在别处有所描述。为了致敬其首次尝试和验证的地方，我们在此正式认可Individual Inc.、Newspage、Fidelity Investments和IDX（现为GE Medical）。

改编通告

本文档改编来自Ken Schwaber和Jeff Sutherland的原始Scrum指南。Craig Larman和Bas Vodde于2024年对原始文档进行了修改，包括小幅编辑和修改摘要。

LeSS版本的更新摘要

本次Scrum指南更新以2020年版本为基础，但部分内容取自2017年版本。较大的变更有：

重新引入了产品，而不是“解决复杂问题的工作”。
移除了Scrum团队的概念。
将开发人员更名为团队。
把迭代从事件中移除，并将其单列。
将产品目标更名为产品愿景。
从产品负责人部分的待办列表管理中删除了“创建和传达产品待办条目”。
删除了主题1/2/3的术语，就叫为什么做/做什么/怎么做。
在Scrum事件中添加了产品待办列表梳理，但提到它可以作为一个活动而不是一个事件。
删除了对工件承诺的说法。
将迭代目标移到一个地方，在迭代计划中。
介绍完成的定义不作为承诺，而作为约定。