书籍详情
Nexus规模化Scrum框架
作者：库尔特·比特纳（Kurt Bittner），帕特丽夏·孔（Patricia Kong），戴夫·韦斯特（Dave 著，李建昊 陆媛 徐东伟 译
出版社：机械工业出版社
出版时间：2018-10-01
ISBN：9787111609582
定价：¥59.00
购买这本书可以去
内容简介
本书从一个简单的Nexus应用开始，描述了Nexus在日益复杂情况下的应用。作者阐述了环境的复杂性及其所导致的问题，以及如何应用Nexus来解决这些问题。作者把想法与案例研究结合起来。本书也是由《Nexus指南》的知识体系所支持的。
作者简介
Kurt Bittner是Scrum.org企业解决方案副总裁，拥有超过35年的从业经验，曾作为程序员、产品经理/产品负责人、业务分析师，以及组织变革代理人，帮助许多团队在短周期反馈驱动的条件下交付软件。他曾出版过其他3本软件工程方面的书籍，写过许多博客和文章，并经常出席会议发表演讲。Patricia Kong是Nexus框架和基于事件管理框架的主要贡献者，Scrum.org企业解决方案产品负责人（包括Nexus框架）。她曾在几家初创公司领导过产品开发、产品管理和市场营销团队。Dave West是Scrum.org公司的CEO和产品负责人，经常在主要的行业会议上发表主题演讲，并是一个拥有广泛读者的书籍、博客、文章和研究报告的作者。他曾领导过跨国公司的产品开发和咨询部门。
目录
译者序
序
前言
第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
序
前言
第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
猜您喜欢
