全新Nexus规模化Scrum框架(德)库尔特·比特纳 等9787111609582

译者序

序

前言

章规模化敏捷概述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.2Nexus扩展了Scrum11

.Nexus集成团队12

2.4Nexus事件15

2.4.1梳理16

2.4.2NexusSprint计划17

2.4.3Nexus每日Scrum站会18

2.4.4NexusSprint评审19

2.4.5NexusSprint回顾20

2.4.6NexusSprint回顾中要问的问题21

2.5Nexus工件22

2.5.1产品待办事项列表22

2.5.2Nexus目标22

2.5.3NexusSprint待办事项列表22

2.5.4集成增量

2.5.5工件透明

2.5.6Nexus中的“完成”定义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..为什么Nexus中只有3～9个Scrum团队38

3.3建立Nexus集成团队39

3.4Nexus如何工作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..可选实践：将产品待办事项列表条目与价值交付互相关联64

4.2.4构建NexusSprint待办事项列表和Scrum团队待办事项列表65

4.3结束语69

第5章在Nexus中运行Sprint71

5.1Nexus每日Scrum站会71

5.2在Nexus内部和外部提供透明75

5.2.1可选实践：产品待办事项列表树形图77

5.2.2可选实践：可视化产品待办事项列表燃尽图和速度78

5.3NexusSprint评审80

5.3.1可选实践：使用“博览会”形式进行NexusSprint评审81

5.3.2可选实践：使用离线评审技术进行NexusSprint评审82

5.4NexusSprint回顾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再谈NexusSprint计划104

6.7再谈Nexus每日Scrum站会105

6.8再谈NexusSprint评审106

6.9再谈NexusSprint回顾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三谈NexusSprint计划124

7.2.1引导大规模分布式Sprint计划会125

7.2.2软硬件开发混合的Nexus127

7..按不同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.4Scrumble141

7.5Nexus（伪）Sprint评审和回顾144

7.6结束语145

第8章Nexus旅程中的回顾147

8.1哪些做得好148

8.1.1Nexus每日Scrum站会148

8.1.2Nexus集成团队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..技能提升156

8.2.4透明和信任157

8.3下一步是什么160

8.4结束语162

术语表164

我们写作本书的目的很简单：向熟悉Scrum的人提供一种简单而强大的方法，从而当需要多个团队共同努力进行产品开发时，可以继续应用他们所熟悉的同一套Scrum概念。每天有超过1200万人使用Scrum，其中很多人都在进行大型多团队协作。Nexus就是为了满足这些人的需要而发展起来的，虽然许多组织都在使用它，但还没有对它进行描述的书籍出现。我们希望本书的读者能够应用Nexus来扩展，甚至是提升他们的Scrum实践的能力。正如我们想说的，“规模化的Scrum仍然是Scrum”。谁应该阅读本书任何使用Scrum的人都会从阅读本书中获益，因为有时你会发现，一个单独的Scrum团队已经不以付产品了。虽然增加团队听起来很容易，但是团队间的依赖关系很难管理，而且会快速冲垮这个单薄的Scrum方法。本书将帮每个团队成员更好地理解Nexus。在Scrum团队之外，Scrum团队的利益相关者将发现本书有于理解多团队工作所面临的挑战，这也将帮他们更好地支持与之进行合作的团队。本书是如何组织的本书设你已经熟悉Scrum框架，并通过介绍如何使用Nexus来扩展Scrum进行大型产品的开发，从而建立起这种知识体系。章介绍了在一个项目需要多个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