专业的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.