本书的目的是向熟悉Scrum的人提供一种简单而强大的方法，从而当需要多个团队共同努力进行产品开发时，可以继续应用他们所熟悉的同一套Scrum的概念。每天有超过1200万人使用Scrum，其中很多人都在进行大型多团队协作。Nexus就是为了满足这些人的需要而发展起来的，虽然许多组织都在使用它，但还没有一本书对它进行描述。我们希望本书的读者能够应用Nexus来扩展甚至是提升他们的Scrum实践技能。

1

我们写作本书的目的很简单：向熟悉Scrum的人提供一种简单而强大的方法，从而当需要多个团队共同努力进行产品开发时，可以继续应用他们所熟悉的同一套Scrum概念。每天有超过1200万人使用Scrum，其中很多人都在进行大型多团队协作。Nexus就是为了满足这些人的需要而发展起来的，虽然许多组织都在使用它，但还没有对它进行描述的书籍出现。我们希望本书的读者能够应用Nexus来扩展，甚至是提升他们的Scrum实践的能力。正如我们想说的，“规模化的Scrum仍然是Scrum”。
谁应该阅读本书
任何使用Scrum的人都会从阅读本书中获益，因为有时你会发现，一个单独的Scrum团队已经不足以交付产品了。虽然增加团队听起来很容易，但是团队间的依赖关系很难管理，而且会快速冲垮这个单薄的Scrum方法。本书将帮助每个团队成员更好地理解Nexus。在Scrum团队之外，Scrum团队的利益相关者将发现本书有助于理解多团队工作所面临的挑战，这也将帮助他们更好地支持与之进行合作的团队。
本书是如何组织的
本书假设你已经熟悉Scrum框架，并通过介绍如何使用Nexus来扩展Scrum进行大型产品的开发，从而建立起这种知识体系。
第1章介绍了在一个项目需要多个Scrum团队参与的情况下，如何使用敏捷。
第2章主要关注Nexus背后的基本原则和概念，包括何时需要Nexus，以及启动Nexus所需要的准备。
第3章主要关注如何围绕产品建立一个Nexus，即使该产品仍然只是一个构想，尚未组建起团队也没有关系。对于已经存在的产品和团队，我们将描述在创建Nexus时如何增加团队。我们还将描述如何在Nexus中组织Scrum团队，以及如何识别（并最小化）产品待办事项的依赖关系。
第4章主要关注如何组织Nexus的工作：针对业务目标对于大型待办事项列表的收集、梳理和验证，设定目标，计划Sprint。
第5章主要关注Sprint中的Nexus工作：执行Nexus Sprint待办事项列表中的任务，运行Nexus每日Scrum站会，开展Nexus Sprint评审，以及实施Nexus Sprint回顾。
第6章主要关注如何管理Nexus，包括报告进度、提升绩效和吞吐量，以及消除瓶颈。
第7章主要关注Nexus如何帮助组织克服规模化过程中的典型挑战，包括帮助分布式团队更好地协同工作，应对挑战，保持团队的有效合作。
第8章展示了当团队和组织扩展Scrum时所经历的典型旅程。它着眼于Nexus元素在旅程中的作用，团队和组织所面临的典型挑战，以及他们如何克服这些挑战。同时，也展望了团队和组织可以做些什么，从而持续提升交付复杂应用程序的能力。
致谢
我们在写作本书时得到了很多帮助和支持。首先，我们要感谢Ken和Christina Schwaber的支持、鼓励，以及他们提供的Nexus如何从Scrum演进而来的视角。其次，要感谢Ken Schwaber和Jeff Sutherland创造Scrum框架，该框架是Nexus的基础。Nexus框架之所以存在，是因为相互协作的团队成员聚集在一起，将他们的经验转化为《Nexus指南》的形式并分享给大家。
我们也感谢专业Scrum培训（PST）社区，社区成员利用他们宝贵的时间，通过他们深思熟虑的建议和严谨的评审帮助提升本书的质量。我们对本书最大的贡献者们表示最诚挚的感谢，他们是Peter GRalph Jocham、Mikkel Toudal Kristiansen、Rob Maher、Jeronimo Palacios和Steve Porter。我们还要谢谢Eric Naiburg，他用作家睿智的目光帮助我们更有效地表达思想，以及Sabrina Love，她设计了本书的封面。
最后，如果没有Pearson/Addison-Wesley出版社团队的支持就没有本书的出版，特别是我们的编辑Chris Guzikowski、策划编辑Chris Zahn、生产编辑Julie Nahil、文字编辑Stephanie Geels，他们都帮助我们完成了本书的完善和出版。

Kurt, Patricia和Dave

计算机\软件工程

本书非常有价值。书中从一个简单的Nexus应用开始，描述了Nexus在日益复杂情况下的应用。作者阐述了环境的复杂性及其所导致的问题，以及如何应用Nexus来解决这些问题。 ——　Ken Schwaber，Scrum联合创始人

Nexus框架是一种简单、有效的方法，可以在横跨多个团队、地点和时区上规模化应用Scrum，它是由提供Scrum培训和认证的先进组织Scrum.org所创建的，而该组织又是由Scrum的联合创始人Ken Schwaber创立的。Nexus框架可帮助大家利用几十年的经验来解决团队聚集在一起、共享工作，以及管理和减少依赖关系所面临的独特挑战。

本书简明扼要地展示了Nexus如何帮助团队在既不牺牲一致性和质量，也不增加不必要的复杂性，更不偏离Scrum核心原则的前提下，在短时间、频繁的周期中交付复杂的、多平台的、基于软件的产品。本书作者通过使用一个扩展的案例研究，解释了Nexus如何帮助团队解决常见的规模化挑战，比如减少跨团队的依赖、保持团队的自组织和透明性，以及确保履行相应的责任。

本书包括如下内容：
理解由多个团队来交付工作、集成产品增量时所面临的挑战，以及利用Nexus如何解决这些挑战
围绕新产品或已有产品建立一个Nexus框架，并学习Nexus是如何设定目标和计划工作的
在一个Nexus中运行Sprint，为进展提供透明性，进行有效的Nexus Sprint回顾，并利用Nexus Sprint回顾进行持续改进
克服分布式团队协作所面临的挑战

[德] 库尔特·比特纳（Kurt Bittner） 帕特丽夏·孔（Patricia Kong）戴夫·韦斯特（Dave West） 著：Kurt Bittner是Scrum.org企业解决方案副总裁，拥有超过35年的从业经验，曾作为程序员、产品经理/产品负责人、业务分析师，以及组织变革代理人，帮助许多团队在短周期反馈驱动的条件下交付软件。他曾出版过其他3本软件工程方面的书籍，写过许多博客和文章，并经常出席会议发表演讲。

Patricia Kong是Nexus框架和基于事件管理框架的主要贡献者，Scrum.org企业解决方案产品负责人（包括Nexus框架）。她曾在几家初创公司领导过产品开发、产品管理和市场营销团队。

Dave West是Scrum.org公司的CEO和产品负责人，经常在主要的行业会议上发表主题演讲，并是一个拥有广泛读者的书籍、博客、文章和研究报告的作者。他曾领导过跨国公司的产品开发和咨询部门。

随着科技的发展和社会的进步，软件在这个时代发挥的作用越来越大。软件正在改变世界，也正在创造未来。
“海不辞水，故能成其大。”自软件诞生伊始，人们就开始探索有效的软件开发方法，从最初的作坊式、增量式、瀑布式、迭代式，一直演进到敏捷开发的方法。自2001年敏捷联盟成立，敏捷宣言发表，到现在已近20年了。这些年来，敏捷开发的理念开放包容、兼收并蓄；敏捷开发的实践持续演进、不断突破。敏捷开发帮助大量的研发团队成功地进行了产品交付，敏捷的价值得到了广泛的认可。
如果说10年前，大家还在谈论要不要做敏捷的问题，那么今天我们讨论的焦点已经变成了如何把敏捷做好这个问题。团队级的敏捷开发取得了很好的成果，但是在小团队中已经验证有效的敏捷实践，一旦扩展到大组织层面，就会面临各种各样的挑战。
作为Scrum框架的联合创始人（同时也是敏捷宣言的17位起草人之一），敏捷大师Ken Schwaber先生基于Scrum框架在大组织实践中进行了扩展，于2015年提出了Nexus框架（可从Scrum.org下载《Nexus指南》）。随后，本书的几位作者作为Nexus的核心实践者，逐渐细化了Nexus在日益复杂情况下的应用，详细总结了如何将Nexus应用于多个Scrum团队处理同一个产品或问题，提供了利用Nexus提高生产率和解决故障的补救技术，并于2018年出版了本书。Nexus为规模化敏捷的企业级应用提供了一种新的、有效的可选方案。
本书首先介绍了为什么要进行规模化敏捷，并解释了Nexus的基本原则和概念，包括什么时候需要Nexus，以及启动Nexus时需要做哪些准备。从第3章开始，基于案例描述了如何建立一个Nexus；第4～5章详细介绍了如何在Nexus中进行计划、运行Sprint（包括Scrum每日站会、开展Nexus Sprint评审，以及实施Nexus Sprint回顾等）；第6～7章分析了如何管理演进过程中的Nexus，以及当Nexus处于困境时（也就是应急模式下），如何应对挑战并保持有效合作；第8章作为全书的总结，对Nexus的整个旅程进行了回顾。全书简明扼要，重点突出，阅读起来十分轻松。
正如Ken Schwaber所说，Nexus可以被看作一种“外骨骼”，“简单是进行规模化的关键”。Nexus可以通过简化和管理团队之间的连接和依赖，以及通过透明的自下而上的方式来洞察团队如何协同工作，保护和强化这些Scrum团队。通过将Scrum进行扩展，从而支持那些更加复杂的产品有效地进行交付，使多个Scrum团队致力于将单个产品组合成一个更大的单元，并称之为Nexus，而使用的框架依然是Scrum。
在这个观点上，我与Ken的理念完全吻合。世界上不存在一种可以直接套用的规模化敏捷框架，SAFe不是、LeSS不是、Nexus也不是，敏捷实践者需要做的是持续地实践，用发展的眼光，动态地探索和解决问题。而在这个过程中，简单永远是进行规模化的基石！
最后，感谢陆媛、徐东伟两位资深敏捷专家在翻译过程中的深度参与，感谢机械工业出版社的领导和关敏老师的大力支持，感谢所有规模化敏捷框架的实践者，正是因为大家的共同努力和贡献，不断地向规模化敏捷注入活力，才能持续地从Scaled 走向Scaling，持续地延伸和扩展，超越敏捷……

李建昊
2018年9月

译者序
序
前言
第1章　规模化敏捷概述1
1.1　为什么使用敏捷2
1.2　为什么要用Scrum3
1.2.1　什么是产品3
1.2.2　什么是Scrum4
1.3　为什么要用Nexus6
1.4　简单是进行规模化的关键7
第2章　Nexus概述9
2.1　什么是Nexus9
2.2　Nexus扩展了Scrum11
2.3　Nexus集成团队12
2.4　Nexus事件15
2.4.1　梳理16
2.4.2　Nexus Sprint计划17
2.4.3　Nexus每日Scrum站会18
2.4.4　Nexus Sprint评审19
2.4.5　Nexus Sprint回顾20
2.4.6　Nexus Sprint回顾中要问的问题21
2.5　Nexus工件22
2.5.1　产品待办事项列表22
2.5.2　Nexus目标22
2.5.3　Nexus Sprint待办事项列表22
2.5.4　集成增量23
2.5.5　工件透明性23
2.5.6　Nexus中的“完成”定义24
2.6　要启动Nexus需要做哪些准备24
2.7　结束语25
第3章　建立一个Nexus27
3.1　演进跨职能团队30
3.1.1　实践：开放代码库31
3.1.2　实践：围绕业务价值增量来建立团队33
3.1.3　实践：建立自组织团队35
3.2　发展一个Nexus36
3.2.1　从小开始，不断发展37
3.2.2　使用结对和“实习制”发展Scrum团队38
3.2.3　为什么Nexus中只有3～9个Scrum团队38
3.3　建立Nexus集成团队39
3.4　Nexus如何工作43
第4章　Nexus中的计划45
4.1　巩固和验证产品待办事项列表45
4.1.1　梳理产品待办事项列表48
4.1.2　跨团队产品待办事项列表梳理50
4.1.3　产品待办事项列表条目依赖关系54
4.1.4　可选实践：使用故事地图来了解功能和依赖关系56
4.1.5　可选实践：使用跨团队梳理板来了解依赖关系57
4.2　在Nexus中计划一个Sprint61
4.2.1　建立Nexus目标62
4.2.2　估算和按规模大小排列产品待办事项列表条目62
4.2.3　可选实践：将产品待办事项列表条目与价值交付互相关联64
4.2.4　构建Nexus Sprint待办事项列表和Scrum团队待办事项列表65
4.3　结束语69
第5章　在Nexus中运行Sprint71
5.1　Nexus每日Scrum站会71
5.2　在Nexus内部和外部提供透明性75
5.2.1　可选实践：产品待办事项列表树形图77
5.2.2　可选实践：可视化产品待办事项列表燃尽图和速度78
5.3　Nexus Sprint评审80
5.3.1　可选实践：使用“博览会”形式进行Nexus Sprint评审81
5.3.2　可选实践：使用离线评审技术进行Nexus Sprint评审82
5.4　Nexus Sprint回顾83
5.5　结束语89
第6章　演进Nexus91
6.1　可选实践：围绕特性组织Scrum团队94
6.2　可选实践：像开源项目一样管理代码96
6.3　可选实践：围绕用户画像组织团队98
6.4　扩展Nexus集成团队100
6.5　更新和梳理产品待办事项列表101
6.6　再谈Nexus Sprint计划104
6.7　再谈Nexus每日Scrum站会105
6.8　再谈Nexus Sprint评审106
6.9　再谈Nexus Sprint回顾107
6.9.1　工作太多，进展不足109
6.9.2　日益增加的技术债务110
6.9.3　不能及时出现的产品负责人111
6.9.4　不充分的构建和测试自动化112
6.9.5　制定改进计划113
6.9.6　规模化Scrum的挑战114
6.10　结束语116
第7章　应急模式下的Nexus119
7.1　三谈产品待办事项列表梳理121
7.2　三谈Nexus Sprint计划124
7.2.1　引导大规模分布式Sprint计划会125
7.2.2　软硬件开发混合的Nexus127
7.2.3　按不同Sprint节奏工作的团队128
7.2.4　在Nexus中混合Scrum和瀑布方法130
7.3　三谈Nexus每日Scrum站会131
7.4　当Nexus开始挣扎时，应该做些什么134
7.4.1　应急模式下的Nexus集成团队136
7.4.2　减小规模136
7.4.3　使用健康检查来了解团队情绪139
7.4.4　Scrumble141
7.5　Nexus（伪）Sprint评审和回顾144
7.6　结束语145
第8章　Nexus旅程中的回顾147
8.1　哪些做得好148
8.1.1　Nexus每日Scrum站会148
8.1.2　Nexus集成团队149
8.1.3　发布频率150
8.1.4　生产力151
8.1.5　自组织152
8.2　需要改进的领域153
8.2.1　管理技术债务154
8.2.2　扩展产品负责人155
8.2.3　技能提升156
8.2.4　透明性和信任157
8.3　下一步是什么160
8.4　结束语162
术语表164