大规模Scrum（LeSS）方法创始人撰写，Stephen Denning作序推荐
多团队合作、大型组织敏捷转型必备参考
一切伟大的真理都以亵渎神灵开始。
—萧伯纳
欢迎来到LeSS世界，在这里，组织的复杂性被简单的结构所取代，不只是人，还有人们的学习也成为组织的关注点。对一些人来说，LeSS可能看起来是浪漫的，并且充满无可救药的理想主义。但事实并非如此，它在当今许多产品组织中已确确实实存在！
为什么要写这本书？
我们的前两本LeSS书出版后，收到了许多反馈，克雷格在思考这些反馈时，认为这两本书里的想法太多而基础观点太少，所以他问巴斯是否想再写一本。巴斯回绝了，因为他当时正在急切地等待着他第二个儿子的降生。不屈不挠的克雷格最终还是让巴斯同意一起写这本书，并让其相信这是一本内容相对简单的书。但克雷格错了。
我们最初的目的是为前两本LeSS书写一本初级读物，但我们最终收获的却是一本截然不同的书，因为我们在探讨具体的基础观点时，对大规模的最基本要素进行了更为系统的推敲。结果呢？便是为读者呈现的LeSS规则、LeSS 指南，以及这本书。
LeSS规则和指南至关重要，但它们不是规模扩展时唯一要考虑的因素。在进入LeSS之前，我们要强调另外两个应当持续关注的要点：卓越技术和试验思维。
读者对象
本书是为产品开发中所涉及的每一个人而编写的。阅读本书唯一的先决条件是读者需具有基本的Scrum知识。如果没有这方面的知识，我们建议读者从阅读《Scrum指南》和《Scrum简章》（scrumprimer.org）开始。本书每一章的开始都将快速重温与其主题相关的Scrum。
章节结构
各主要章节的结构如下：
单团队Scrum
概述一个团队时采用的Scrum，为学习LeSS做准备。
LeSS
涵盖LeSS基本框架。这一节的结构如下：
导言及LeSS相关原则。
LeSS规则。
LeSS指南。
巨型LeSS
结构与LeSS部分相同。
组织有关的术语
大多数术语在首次使用时给出了定义。然而，由于不同的公司可能会使用不同的术语，在与组织有关的术语方面我们遇到了一些困扰。这里我们介绍了书中使用的一些术语，它们对有些读者来说显而易见，而对另外一些读者来说可能是晦涩难懂的。
产品组
参与产品创建的所有人员。公司经常使用“项目”（project）来指代所有参与开发的人，但是本书避免使用这个术语，因为它经常强调的是产品的开发。因此，本书使用产品组。
直线组织
通常是组织架构图中所描述的正式组织结构。直线组织通常参与对员工的评估、员工的雇用、解雇和能力发展。公司中也可能存在矩阵式项目组织（在LeSS中不存在）和工作人员或支持组织。
直线经理和一线经理
直线组织中员工向上报告的经理。一线经理是员工向上报告的直属经理。
高级经理或高管
在组织高层工作的经理。在大型组织中，他们往往不属于产品组。
产品管理或产品营销
产品组织中探索市场并决定产品内容的职能。这通常与团队没有直线报告关系。
产品组领导
领导整个产品组的管理者，产品组中的所有人员都以直线关系向其报告。
项目/项目群经理
传统意义上负责产品发布时间表的角色。这通常与团队没有直线关系，因为它是一个短期临时的角色。这些角色在LeSS组织中不应存在。
职能组织
基于职能性技能（如开发、测试或分析）的直线组织。在LeSS组织中不应存在。
致谢
有非常多的人参与了对本书的评论。下面列出对一章以上的内容做过评论的人：Janne Kohvakka, Hans Neumaier, Rafael Sabbagh, Ran Nyman, Ahmad Fahmy, Mike Cohn, Gojko Adzic, Jutta Eckstein, Rowan Bunning, Jeanmarc Gerber, Yi Lv, Steve Spearman, Karen Greaves, Marco Seelmann, Cesario Ramos, Markus Ga?rtner, Viktor Grgic, Chris Chan, Nils Bernert, Viacheslav Rozet, Edward Dahllo?f, Lisa Crispin, Mike Dwyer, Francesco Sferlazza, Nathan Slippen, Mika Sjo?man, Tim Born, Charles Bradley, Timothy Korson, Erin Perry, Greg Hutchings, Jez Humble, Alexey Krivitsky, Alexander Gerber, Peter Braun, Jurgen De Smet, Evelyn Tian, Sami Lilja, Steven Mak, Alexandre Cotting, Bob Schatz, Bob Sarni, Milind Kulkarni, Janet Gregory, Jerry Rajamoney, Karl Kollischan, Shiv Kumar Mn, David Nunn, Rene Hamannt, Ilan Goldstein, Juan Gabardini, Mehmet Yitmen, Kai-Uwe Rupp, Christian Engblom, James Grenning, Venkatesh Krishnamurthy, Peter Hundermark, Arne Ahlander, Darren Lai, Markus Seitz, Geir Amsj?, Ram Srinivasan, Mark Bregenzer, Aaron Sanders, Michael Balle?, Stuart Turner, Ealden Escan?an, Steven Koh, Ken Yaguchi, michael james, Manoj Vadakkan, Peter Zurkirchen, Laszlo Csereklei, Gordon Weir, Laurent Carbonnaux, Elad Sofer。
最后特别感谢Bernie Quah的艺术渲染力和Terry Yin对几乎所有请求的支持。也感谢Addison-Wesley出版社的Chris Guzikowski，在这个比预定时间更长的图书项目中他表现出了无限的耐心。
计算机\软件工程
LeSS真正把Scrum的精髓应用到了大规模产品开发中。无论你是否应用LeSS，只要你是多个团队共同开发一个产品，就能从读这本书中受益匪浅。该书是围绕LeSS框架中的规则和指南展开的，相比于之前两本书中包含的诸多实验，它对导入LeSS从何处着手提供了更为实际的指导。作为重点推荐，建议特别关注以下实践：产品方面采用一个产品负责人和一份产品待办事项列表；结构方面采用特性团队作为组织的基本单元；迭代方面采用多团队联合迭代活动和分布式跨团队协调集成。
—— 吕毅 Odd-e敏捷教练
在本书中，克雷格·拉尔曼 （Craig Larman）和巴斯·沃代（Bas Vodde）融合他们十多年采用LeSS所累积的经验，全面系统地阐释了如何打造简单高效的组织，提供更低的复杂度、更大的灵活性，交付更少的浪费、更多的价值，实现更简的规则、更高的目标。
本书专门针对参与大规模开发的人员，以开门见山、直入主题的方式，详细讲解如何通过LeSS实现大规模敏捷，具体包括以下几个方面：
采用LeSS框架
构建以客户价值为目标的大型开发组织
澄清管理层和Scrum Master角色
定义产品是什么及其背后的原因
成为杰出的产品所有人
专注于整体产品开发的多个特性团队在同一Sprint中合作，生产出可交付的产品
团队之间的协调与整合
多地点团队之间的协作
为什么要拥抱敏捷？企业为什么要转型？
作为领导者，你需要问自己一个简单的问题：内部组织调整和重新配置的决策速度能否赶上市场和技术变化的速度？如果答案是否定的，那么这个不可调和的矛盾将会严重影响你的商业业绩。在这个互联网和人工智能的数字化时代，组织规模越大、官僚层级越多，各职能部门越容易形成孤岛，从而导致决策流程长，决策效率低。因为背负着太多的“组织债”，对内调整战略和决策缓慢，对外难以响应市场客户和技术的变化，更不要说创新了。
这是一个充满变化的时代，风险与机遇并存，适者生存。传统的计划驱动的项目管理和确定性管理已经不再适用，边前进边学习才是唯一的应对之道。
诺基亚西门子通信公司（简称诺西，即现在的诺基亚通信）从2005年开始尝试导入Scrum框架进行敏捷转型，本书作者之一Bas当时正是诺西的雇员，而Craig和其他几位敏捷宣言的签署者受聘担任敏捷教练。本人在从2007年加入诺西的几年时间内，有幸经历了完整的转型过程，历任开发团队成员、Scrum Master、R&D Manager等，和组织一起摸索着前行并成长。
Scrum是一个解决复杂问题的框架，也是各个遵循2001年敏捷宣言的流派中，目前流传和应用最广的一个，全球大约70%的企业转型认可并采用Scrum框架。《Scrum指南》作为Scrum的权威定义，对多个团队协作方式提到的不多。然而，以诺西的产品为例，人们打一通电话要经过一个通信网络中的数十个网元设备。而一个网元的研发工作，也需要数百人共同协作来完成。既然没有规模化转型的银弹，那就摸索着前进吧，无论如何是不能回头了。整个转型过程就是痛并快乐着。这种大型组织的转型，是一个打破旧世界，并在混乱中建立新秩序的过程。有痛点才有驱动力，作为一个当时陷入行业危机的通信企业，在生存危机面前，没有什么是不能改变的。
8年前本人有幸读过Craig Larman和Bas Vodde早期总结的《精益和敏捷开发大型应用指南》及对应的实践一书，里面提供了思考工具和组织设计工具。在经历诺西的大规模实验之后，两位作者逐渐总结出LeSS框架，后又在JP Morgan、BMW等多家企业进行打磨。而本书正是基于他们最新经验的升级版。
本人接触敏捷和Scrum刚好十年，近年来培训和指导过很多不同的企业。今年春天在美国参加了Craig的LeSS培训课程，对我来说，这相当于一次复习，也让我重新理解了Scrum和系统思考在组织设计中的运用，比起框架本身，思考的过程让我的收获更大。
自进入工业时代以来，管理理论一直以“分”作为主脉络并延伸至今，从“分工”到“分权”再到“分利”，紧紧围绕着如何提升管理效率（包括资源利用率）展开，并取得了明显的绩效结果。然而我们也看到，即使组织掌握相同的管理知识，拥有相同的管理结构，仍然会取得不同的绩效。研究发现，绩效背后的原因恰恰不是因为“分”，而是因为“合”，也就是综合整体、职能协同、系统合一，关键是要把企业和组织看成一个“整体”，而非分割状态。本人对LeSS设计的理解是停止局部优化，从全局改进点出发进行系统思考，根据多因果回路推导出框架和规则。当然，如果组织优化的出发点并不是自适应性（adaptiveness，即响应变化的能力），那么得到的可能是另一套做法，而不是LeSS框架。
LeSS的设计遵循了Scrum原则、规则及实验性过程，并扩展到多团队协作。框架的作用是给大家一个启动的指导和共同理解。逐步做减法，轻装上阵，才能获得可持续的适应性和生存能力。不论是Scrum还是LeSS都暗示着：组织和个体的行为受组织结构的深刻影响，因此先期的组织结构调整是在为建立敏捷文化铺平道路。另一个转型的阻碍就是受限于工程能力，因此，对技术卓越和工程实践的实施，也是提高整体敏捷性的关键。
整个LeSS体系分为4个层面：原则处于核心位置，并从中推导出框架，然后给出一些具体的、固定的指南和规则，最后是可变的部分—做试验。面对不确定性，导入的方式也是千变万化，多个团队的协作也并没有单一固定的实践，所以更多是试验。用敏捷的方式来导入敏捷，同时保持系统思考和全局视角，化繁为简，LeSS is More嘛。在LeSS框架中，处处体现着敏捷原则第十条：简单。
本书主要介绍LeSS框架和规则，分为LeSS结构、LeSS产品和LeSS Sprint等三个部分。期望读者在读完本书后可以开始上手尝试，并理解背后的一些设计理念。
申健
优普丰敏捷学院全球合伙人，首席敏捷教练
Certified Scrum Trainer (CST), Certified Team Coach (CTC), LeSS-Friendly Scrum Trainer (LFST), CPCP
个人博客：www.JackyShen.com
2018年5月
推荐序
序
前 言
第1章 以少为多 1
第2章 LeSS 3
2.1 LeSS概述 4
2.1.1 背景 4
2.1.2 试验、指南、规则、原则 5
2.1.3 LeSS原则 7
2.1.4 两个框架：LeSS和巨型LeSS 8
2.2 LeSS框架 9
2.2.1 LeSS框架概述 9
2.2.2 LeSS故事 10
2.2.3 LeSS故事：团队的流动 10
2.2.4 LeSS故事：功能条目的流动 21
2.3 巨型LeSS框架 25
2.3.1 需求领域 25
2.3.2 领域产品负责人 26
2.3.3 领域特性团队 26
2.3.4 巨型LeSS框架概要 27
2.3.5 巨型LeSS故事 28
2.3.6 巨型LeSS故事：新的需求领域 28
2.3.7 多地点团队：术语与提示 34
2.3.8 巨型LeSS故事：多地点团队 34
2.4 继续前进 36
第一部分 LeSS结构
第3章 采用 38
3.1 LeSS采用 39
3.1.1 LeSS规则 39
3.1.2 指南：三个采用原则 39
3.1.3 指南：启动 42
3.1.4 指南：文化跟随结构 46
3.1.5 指南：工作安全，而不是角色安全 47
3.1.6 指南：组织的完美愿景 47
3.1.7 指南：持续改进 48
3.1.8 指南：扩大采用范围 50
3.2 巨型LeSS 51
3.2.1 巨型LeSS规则 51
3.2.2 指南：逐步增量式采用 51
3.2.3 指南：一次一个需求领域 52
3.2.4 指南：并行组织 52
第4章 围绕客户价值组织 53
4.1 在LeSS中团队按客户价值组织 54
4.1.1 LeSS规则 54
4.1.2 指南：建立团队型组织 54
4.1.3 指南：了解特性团队 56
4.1.4 指南：特性团队采用路线图 61
4.1.5 指南：客户领域专门化优先 65
4.1.6 指南：LeSS组织结构 66
4.1.7 指南：LeSS多地点 68
4.2 巨型LeSS 69
4.2.1 巨型LeSS规则 69
4.2.2 指南：需求领域 69
4.2.3 指南：需求领域的动态性 71
4.2.4 指南：向特性团队转型 72
4.2.5 指南：巨型LeSS组织 73
第5章 管理 76
5.1 LeSS管理 77
5.1.1 LeSS规则 77
5.1.2 指南：了解泰勒和法约尔 78
5.1.3 指南：Y管理理论 79
5.1.4 指南：经理是可选项 80
5.1.5 指南：LeSS组织 81
5.1.6 指南：现场观察 84
5.1.7 指南：经理是老师和学习者 85
5.1.8 指南：领域和技术能力 86
5.1.9 指南：LeSS度量 87
5.1.10 指南：管理图书阅读清单 88
第6章 Scrum Master 89
6.1 LeSS Scrum Master 90
6.1.1 LeSS规则 90
6.1.2 指南：Scrum Master的关注点 90
6.1.3 指南：Scrum Master的五个工具 93
6.1.4 指南：大型群组会议引导 94
6.1.5 指南：促进学习和倡导多面技能 94
6.1.6 指南：社区工作 95
6.1.7 指南：Scrum Master生存指南 96
6.1.8 指南：Scrum Master阅读清单 98
6.1.9 指南：特别注意…… 98
6.2 巨型LeSS 99
第二部分 LeSS产品
第7章 产品 102
7.1 LeSS产品 103
7.1.1 LeSS规则 103
7.1.2 指南：产品是什么 103
7.1.3 指南：定义产品 107
7.1.4 指南：扩展产品定义 110
7.1.5 指南：产品优先于项目或
计划 110
7.2 巨型LeSS 111
第8章 产品负责人 112
8.1 LeSS产品负责人 113
8.1.1 LeSS规则 113
8.1.2 指南：谁应该成为产品负责人 113
8.1.3 指南：选择临时伪产品负责人以尽早启动采用 116
8.1.4 指南：那些用户/客户是谁 116
8.1.5 指南：优先级确定胜过澄清 117
8.1.6 指南：不要做这些 117
8.1.7 指南：产品负责人帮手 118
8.1.8 指南：五种关系 119
8.1.9 指南：客户协作胜过…… 123
8.1.10 指南：至少每个Sprint都有交付 124
8.1.11 指南：不必太友好 125
8.1.12 指南：松手 125
8.1.13 指南：不要让未完成工作毁掉自己 126
8.1.14 指南：LeSS会议 126
8.2 巨型LeSS 127
8.2.1 巨型LeSS规则 127
8.2.2 指南：巨型LeSS产品负责人 127
8.2.3 指南：领域产品负责人 128
8.2.4 指南：由Scrum Master协助PO团队 128
第9章 产品待办事项列表 129
9.1 LeSS产品待办事项列表 130
9.1.1 LeSS规则 130
9.1.2 指南：不要“管理依赖关系”，而要最小化约束关系 130
9.1.3 指南：切分出小功能块 133
9.1.4 指南：处理父条目 134
9.1.5 指南：处理特殊条目 136
9.1.6 指南：大型产品待办事项列表的管理工具 138
9.1.7 指南：更少输出，更多成果 140
9.2 巨型LeSS 142
9.2.1 巨型LeSS规则 142
9.2.2 指南：领域待办事项列表 142
9.2.3 指南：最多三层条目 146
9.2.4 指南：巨型新需求领域 146
9.2.5 指南：处理巨大需求 147
第10章 完成的定义 151
10.1 LeSS完成 152
10.1.1 LeSS规则 152
10.1.2 指南：创建完成的定义 152
10.1.3 指南：完成定义的演进 159
10.2 巨型LeSS 160
第三部分 LeSS Sprint
第11章 产品待办事项列表梳理 162
11.1 LeSS产品待办事项列表梳理 163
11.1.1 LeSS规则 163
11.1.2 指南：产品待办事项列表梳理类型 164
11.1.3 指南：总体PBR 165
11.1.4 指南：多团队PBR 166
11.1.5 指南：多地点PBR 167
11.1.6 指南：初始PBR 167
11.1.7 指南：条目分解 171
11.1.8 指南：大规模估算 178
11.2 巨型LeSS 179
第12章 Sprint计划 180
12.1 LeSS Sprint计划 181
12.1.1 LeSS规则 181
12.1.2 指南：Sprint计划一 181
12.1.3 指南：多团队Sprint计划二 184
12.1.4 指南：拒绝Sprint待办事项列表软件工具 185
12.2 巨型LeSS 186
第13章 协调与集成 187
13.1 LeSS协调与集成 187
13.1.1 LeSS规则 188
13.1.2 指南：交谈 188
13.1.3 指南：有利于协调的环境 189
13.1.4 指南：用代码交流 192
13.1.5 指南：持续地集成 193
13.1.6 指南：社区 194
13.1.7 指南：跨团队会议 197
13.1.8 指南：多团队设计研讨会 198
13.1.9 指南：现行体系结构研讨会 200
13.1.10 指南：组件导师 200
13.1.11 指南：开放空间 201
13.1.12 指南：旅行者 202
13.1.13 指南：侦察员 203
13.1.14 指南：也许不需要Scrum of Scrum 204
13.1.15 指南：领头羊团队 204
13.1.16 指南：混合与匹配技巧 204
13.2 巨型LeSS 205
第14章 评审与回顾 206
14.1 LeSS Sprint评审和回顾 207
14.1.1 LeSS规则 207
14.1.2 指南：尽早且经常地调整产品 208
14.1.3 指南：评审集市 208
14.1.4 指南：全体回顾 210
14.1.5 指南：改进系统 211
14.2 巨型LeSS 214
14.2.1 巨型LeSS规则 214
14.2.2 指南：多领域评审与回顾 215
第四部分 少即是多
第15章 下一步 218
附录A LeSS规则 219
