译者序
序
前言
第1章 规模化敏捷概述
1.1 为什么使用敏捷
1.2 为什么要用Scrum
1.2.1 什么是产品
1.2.2 什么是Scrum
1.3 为什么要用Nexus
1.4 简单是进行规模化的关键
第2章 Nexus概述
2.1 什么是Nexus
2.2 Nexus扩展了Scrum
2.3 Nexus集成团队
2.4 Nexus事件
2.4.1 梳理
2.4.2 Nexus Sprint计划
2.4.3 Nexus每日Scrum站会
2.4.4 Nexus Sprint评审
2.4.5 Nexus Sprint回顾
2.4.6 Nexus Sprint回顾中要问的问题
2.5 Nexus工件
2.5.1 产品待办事项列表
2.5.2 Nexus目标
2.5.3 Nexus Sprint待办事项列表
2.5.4 集成增量
2.5.5 工件透明性
2.5.6 Nexus中的“完成”定义
2.6 要启动Nexus需要做哪些准备
2.7 结束语
第3章 建立一个Nexus
3.1 演进跨职能团队
3.1.1 实践:开放代码库
3.1.2 实践:围绕业务价值增量来建立团队
3.1.3 实践:建立自组织团队
3.2 发展一个Nexus
3.2.1 从小开始,不断发展
3.2.2 使用结对和“实习制”发展Scrum团队
3.2.3 为什么Nexus中只有3~9个Scrum团队
3.3 建立Nexus集成团队
3.4 Nexus如何工作
第4章 Nexus中的计划
4.1 巩固和验证产品待办事项列表
4.1.1 梳理产品待办事项列表
4.1.2 跨团队产品待办事项列表梳理
4.1.3 产品待办事项列表条目依赖关系
4.1.4 可选实践:使用故事地图来了解功能和依赖关系
4.1.5 可选实践:使用跨团队梳理板来了解依赖关系
4.2 在Nexus中计划一个Sprint
4.2.1 建立Nexus目标
4.2.2 估算和按规模大小排列产品待办事项列表条目
4.2.3 可选实践:将产品待办事项列表条目与价值交付互相关联
4.2.4 构建Nexus Sprint待办事项列表和Scrum团队待办事项列表
4.3 结束语
第5章 在Nexus中运行Sprint
5.1 Nexus每日Scrum站会
5.2 在Nexus内部和外部提供透明性
5.2.1 可选实践:产品待办事项列表树形图
5.2.2 可选实践:可视化产品待办事项列表燃尽图和速度
5.3 Nexus Sprint评审
5.3.1 可选实践:使用“博览会”形式进行Nexus Sprint评审
5.3.2 可选实践:使用离线评审技术进行Nexus Sprint评审
5.4 Nexus Sprint回顾
5.5 结束语
第6章 演进Nexus
6.1 可选实践:围绕特性组织Scrum团队
6.2 可选实践:像开源项目一样管理代码
6.3 可选实践:围绕用户画像组织团队
6.4 扩展Nexus集成团队
6.5 更新和梳理产品待办事项列表
6.6 再谈Nexus Sprint计划
6.7 再谈Nexus每日Scrum站会
6.8 再谈Nexus Sprint评审
6.9 再谈Nexus Sprint回顾
6.9.1 工作太多,进展不足
6.9.2 日益增加的技术债务
6.9.3 不能及时出现的产品负责人
6.9.4 不充分的构建和测试自动化
6.9.5 制定改进计划
6.9.6 规模化Scrum的挑战
6.10 结束语
第7章 应急模式下的Nexus
7.1 三谈产品待办事项列表梳理
7.2 三谈Nexus Sprint计划
7.2.1 引导大规模分布式Sprint计划会
7.2.2 软硬件开发混合的Nexus
7.2.3 按不同Sprint节奏工作的团队
7.2.4 在Nexus中混合Scrum和瀑布方法
7.3 三谈Nexus每日Scrum站会
7.4 当Nexus开始挣扎时,应该做些什么
7.4.1 应急模式下的Nexus集成团队
7.4.2 减小规模
7.4.3 使用健康检查来了解团队情绪
7.4.4 Scrumble
7.5 Nexus(伪)Sprint评审和回顾
7.6 结束语
第8章 Nexus旅程中的回顾
8.1 哪些做得好
8.1.1 Nexus每日Scrum站会
8.1.2 Nexus集成团队
8.1.3 发布频率
8.1.4 生产力
8.1.5 自组织
8.2 需要改进的领域
8.2.1 管理技术债务
8.2.2 扩展产品负责人
8.2.3 技能提升
8.2.4 透明性和信任
8.3 下一步是什么
8.4 结束语
术语表