书名：专业的Scrum团队  
定价：79.0  
ISBN：9787111721598  
作者：彼得·格茨  
版次：1  

内容提要：  

本书通过一个关于Scrum团队的故事介绍团队成员如何一起面对共同的挑战，从而交付有价值的产品增量。在叙述上，本书结合案例研究与相关讨论，首先介绍 Scrum 团队遇到的特定挑战，然后探索应对该挑战的替代方案。本书可以帮助读者将Scrum框架规则应用到日常工作中，优化团队和个人的表现，改进他们的工作方式和交付有价值的产品，创造更多的价值。

 本书适合所有在Scrum团队工作的人阅读，包括刚接触这个框架的人与经验丰富的Scrum实践者。

目录：  

序

前言

致谢

作者简介

第1章　成为一个高效的Scrum团队　001

1.1　产品负责人与开发团队之间的协作　003

1.1.1　不要把业务和IT分开　005

1.1.2　为有价值的产品负责　006

1.1.3　协助管理产品待办列表　007

1.1.4　Sprint范围不是固定的　008

1.1.5　产品负责人参与　010

1.2　创建Scrum团队的透明度　011

1.2.1　假设驱动的产品待办列表　012

1.2.2　产品待办列表驱动对话　013

1.2.3　着眼于大局　016

1.2.4　产品待办事项需要创造价值　 017

1.2.5　Sprint待办列表不仅仅是一个任务板　019

1.2.6　应该由谁来更新Sprint待办列表　020

1.2.7　Sprint待办列表不应该被隐藏　021

1.2.8　Sprint待办列表作为进度报告　022

1.2.9　工作燃尽图很少是完美的　023

1.2.10　防止Sprint待办列表过时　024

1.2.11　完成代表着可发布　026

1.2.12　度量和验证产品的价值　027

1.3　总结　028

第2章　常见问题　029

2.1　缺少基础知识　031

2.1.1　Scrum的早期失误　032

2.1.2　缺少共同的价值观　034

2.1.3　缺少产品愿景　037

2.1.4　缺少跨职能特质　038

2.1.5　缺少自组织特质　040

2.2　对Scrum的常见误解　041

2.2.1　封闭的Sprint　042

2.2.2　承诺范围　043

2.2.3　会议太多了　045

2.2.4　Sprint评审会中没有利益相关者　047

2.2.5　Scrum不是一种宗教　050

2.3　可以避免的错误　051

2.3.1　只是名义上的Scrum Master　052

2.3.2　太多的产品待办事项　053

2.3.3　舔饼干　055

2.3.4　找不到的产品负责人　057

2.3.5　每周开两次站会　058

2.4　总结　059

第3章　光有Scrum是不够的　060

3.1　战略：顾全大局　061

3.1.1　谁在Scrum中解决战略问题　062

3.1.2　什么是涌现的结构　064

3.1.3　为什么没有文档是个坏主意　067

3.2　策略：从想法到结果　068

3.2.1　产品待办列表的不同抽象层级　069

3.2.2　如何进行有意义的估算　072

3.2.3　当我们有看板时，还需要Scrum吗　075

3.2.4　如何度量成功　077

3.3　如何改进跨职能　079

3.3.1　协作是改进的驱动力　079

3.3.2　每个人都需要做所有的事情吗　081

3.3.3　使用测试先行的方法　084

3.4　应对不断的变更　086

3.4.1　为什么重构是必选项　086

3.4.2　在变成大问题之前解决它们　089

3.4.3　根据原则而不是规则工作　090

3.5　总结　092

第4章　“可发布”小于“已发布”　094

4.1　什么是DevOps　095

4.1.1　它是一个角色……它是一种工具……它是DevOps　096

4.1.2　DevOps与工具有何关系　097

4.1.3　DevOps就够了吗　099

4.2　如何结合Scrum和DevOps　100

4.2.1　DevOps正在取代Scrum吗　101

4.2.2　Scrum允许持续部署吗　102

4.2.3　Scrum原则和DevOps文化是相辅相成的　105

4.2.4　如何使用DevOps改善流动　108

4.3　总结　110

第5章　解决冲突　111

5.1　可以由当事人解决的冲突　112

5.1.1　并非所有的分歧都会导致冲突　112

5.1.2　谁有最终发言权　114

5.1.3　冲突应该由当事人来解决　117

5.2　需要外部干预的冲突　118

5.2.1　升级的健康冲突　119

5.2.2　有些冲突需要暴露出来　123

5.2.3　忠于Scrum团队还是你的部门　125

5.3　需要更强干预的致命冲突　126

5.3.1　给Scrum团队施加压力　127

5.3.2　换一支队伍来保护它　129

5.4　总结　131

第6章　度量成功　133

6.1　朝着目标努力　134

6.1.1　我们需要更快地交付　134

6.1.2　我们是否在交付价值　137

6.1.3　什么是价值　140

6.1.4　实验回路　143

6.2　改进团队成果　146

6.2.1　速率不是绩效　146

6.2.2　如何（不）提升绩效　148

6.2.3　你改进不了你无法度量的东西　152

6.2.4　监控改进，而不是指标　155

6.3　总结　156

第7章　Scrum和管理　157

7.1　Scrum中的管理角色　158

7.1.1　透明不是监视　158

7.1.2　负责不是控制　160

7.2　如何实现自组织　162

7.2.1　领导不是指导　163

7.2.2　自组织并不缺乏管理　164

7.2.3　自组织并不容易　166

7.3　总结　167

第8章　敏捷组织　169

8.1　组织架构既可能帮助Scrum也可能阻碍Scrum　170

8.1.1　新工作，旧环境　170

8.1.2　职能型组织可能阻碍团队发展　172

8.1.3　职能型组织提供了职业发展路径，但要付出代价　173

8.2　复杂的组织需要彻底的简单　176

8.2.1　Scrum可以帮助实现彻底的简单　176

8.2.2　彻底的简单需要彻底的透明　178

8.2.3　用透明取代汇报链和治理流程　179

8.2.4　打破“孤岛”，围绕客户价值进行调整　181

8.3　总结　181

第9章　持续改进永远不会停止　183

9.1　如何持续改进　184

9.1.1　失败：学会的第一步　184

9.1.2　我们已经改进了我们能改进的一切　187

9.1.3　Scrum Master要被淘汰吗　189

9.2　回顾是改进的驱动力　190

9.2.1　强化积极面　190

9.2.2　专注于一个单一的改进　191

9.2.3　随着时间的推移改变组织的文化以提高专注度　192

9.3　Scrum会实现吗　193

9.3.1　我们什么时候才能实现Scrum　194

9.3.2　在产品上线后如何使用Scrum　197

9.3.3　Scrum不需要外部专家的意见　198

9.4　总结　200

参考文献　201