本书的内容源自作者的实践经历和工作积累。在长期的实践中作者发现，越来越多的离岸交付需要适应敏捷开发的模式。本书结合分布式团队沟通、协作中的痛点，系统地分析了很多离岸项目虎头蛇尾的原因，并给出可供参考的解决方案。对于很多公司和组织头疼的如何让分布式团队推行敏捷的离岸交付的问题，本书给出很多成功经验。此外，本书还系统介绍了建设自组织团队的一些措施和方法。
涉及离岸交付的软件组织以及其他各类存在分布式团队合作的软件组织都能从本书中得到很多有价值的提示。本书适合开发人员、测试人员、需求管理人员或项目经理等参考阅读。
你经历的项目有没有虎头蛇尾的？开始的时候轰轰烈烈，很快就归于平淡，*后在度日如年中草草收场。有没有团队积极性始终无法提高的？任凭你如何呐喊、推动，大家却踟蹰不前。有没有团队很努力但客户却总是不满意的？每次交付不是需求有偏差，就是质量有问题。有没有对与远程团队的沟通感到很无奈的？沟通效率很低，有时候根本不知道另一个团队在做什么，或者发现南辕北辙的时候为时已晚。
如果你对以上问题感同身受，并感到束手无策，请务必仔细阅读本书。本书作者结合自身的经历和实践经验，从交付效率、交付质量、客户满意度等项目交付*重要的着眼点，赋能你和团队，并且有启发、可参考，能够引发你对自身工作的思考，快速提升交付水平。
本书中提到的技巧不仅能够让服务外包的团队服务好企业级交付，也能顺应协助传统企业利用IT技术创新的潮流，让团队之间的协作更加有效，有助于达成团队的技术目标和业务目标。
曲正平，现就职于滴滴出行公司，从事质量管理工作，日常需要协调多个团队进行质量改进。在此之前就职于ThoughtWorks，参与和主导过大量的项目测试和交付工作，客户遍布美国、澳大利亚、英国及国内许多地方。对建立分布式团队的沟通计划、分布式敏捷协作、质量保证流程以及敏捷实践有非常深刻的理解。除了项目交付，还曾为多家传统企业提供敏捷实践方面的咨询服务。
目录
第 1章 分布式团队的现状 1
1.1 分布式团队介绍 1
1.1.1 分布式团队的快速发展 1
1.1.2 客户为何如此看重CMMI认证 2
1.1.3 分布式团队的类型 3
1.1.4 什么样的团队可以称为分布式团队 5
1.2 服务外包行业的现状 5
1.3 离岸团队的组建 7
1.3.1 组建分布式团队的原则 7
1.3.2 组建分布式团队 8
1.3.3 建立一个离岸团队的投入和效益 9
1.3.4 分布式团队需要注意的问题 10
1.4 软件外包服务大方向的变化 11
1.4.1 人才战争已经打响 11
1.4.2 战略合作的成果建立离岸交付中心 12
1.4.3 客户衡量外包服务的方式在发生变化 12
第 2章 分布式团队的沟通 13
2.1 管理客户的期望值 13
2.1.1 了解客户 14
2.1.2 保障客户的知情权 17
2.1.3 维护客户的期望值 19
2.1.4 超越客户期望值 23
2.1.5 L项目的案例 24
2.1.6 拆屋效应 25
2.1.7 项目的成败是由客户的期望值决定的 25
2.2 沟通是分布式团队最大的挑战 26
2.2.1 分布式团队最基本的沟通方式：电子邮件 27
2.2.2 常规意义上的沟通：异步沟通和实时沟通 29
2.2.3 工具的利与弊 32
2.2.4 主动的沟通 32
2.2.5 沟通中的冲突 33
2.2.6 同理心 36
2.2.7 清楚而坦诚的沟通 38
2.2.8 成功的离岸团队还需要关注的 39
2.3 会议的组织 41
2.3.1 典型的会议 43
2.3.2 离岸团队的会议技巧 56
2.3.3 小结 57
2.4 常驻代表和短期面对面的访问 57
2.4.1 常驻代表 58
2.4.2 短期面对面的沟通 61
2.4.3 一次访问客户现场之后的复盘 68
2.4.4 小结 70
2.5 虚拟交流工具 71
2.5.1 知识分享类 72
2.5.2 即时沟通类 72
2.5.3 工作协作类 73
2.5.4 流程控制类 74
2.5.5 融合即时沟通和知识分享的工具类 75
2.5.6 小结 77
2.6 沟通失败的案例 79
2.6.1 麦道飞机DC-10重蹈覆辙发生空难的教训 79
2.6.2 某大型能源企业的一次集成失败 81
2.6.3 L项目首次用户测试失败 81
2.6.4 小结 81
第3章 分布式团队的协作 83
3.1 团队协作初识 83
3.1.1 沟通与协作的关系 84
3.1.2 意见统一是协作的前提 88
3.1.3 协作更强调行动执行力 92
3.1.4 对协作有益的方法 94
3.1.5 伤害协作的行为 98
3.1.6 带动客户 99
3.1.7 协作技巧 104
3.1.8 关键的协作点 105
3.1.9 Scrum of Scrums会议 108
3.1.10 团队内部的协作 112
3.1.11 小结 115
3.2 提升离岸团队协作的水平 115
3.2.1 使用假设 116
3.2.2 双向沟通 117
3.2.3 使用业务语言和实例 118
3.2.4 建立离岸团队的规律性 120
3.2.5 持续提升离岸团队的协作水平 122
3.2.6 小结 129
3.3 规范化提升分布式团队协作 130
3.3.1 需求分析的规范化 130
3.3.2 技术的规范化 134
3.3.3 测试的规范化 137
3.3.4 规范化自动化测试 140
3.3.5 小结 141
第4章 可视化的应用 142
4.1 可视化的目的 143
4.1.1 展示项目的状态 143
4.1.2 消除需求的理解偏差 145
4.1.3 反馈软件的质量 146
4.1.4 代码的测试覆盖率 146
4.1.5 描述复杂的业务流程 147
4.1.6 理解项目全景 148
4.1.7 帮助团队思考的思维导图 150
4.2 可视化的方法 150
4.2.1 项目状态的展示之看板 152
4.2.2 项目状态的展示之燃尽图和燃起图 155
4.2.3 业务流程的展示 165
4.2.4 项目需求的全景展现 168
4.2.5 需求故事的表达 169
4.2.6 思维导图的使用 171
4.2.7 数据可视化 173
4.3 使用可视化度量我们的工作 173
4.3.1 开发和测试工作的度量 173
4.3.2 对团队工作度量的建议 174
4.4 团队协作可视化工具的介绍 174
4.4.1 Mingle的基本介绍 175
4.4.2 Trello的基本介绍 175
4.5 小结 175
第5章 分布式团队中的浪费 177
5.1 人的因素造成的浪费 177
5.2 团队协作中的浪费 180
5.2.1 浪费来自哪里 181
5.2.2 浪费解决之道 183
5.2.3 小结 185
5.3 流程中产生的浪费 186
5.3.1 缩短流程 186
5.3.2 简化复杂的环节 187
5.3.3 加快进度的重要途径 187
5.3.4 过度设计也是一种常见的浪费 187
5.4 信息处理中的浪费 188
5.4.1 组织结构产生的浪费 188
5.4.2 知识管理中的浪费 189
5.4.3 信息过多造成的浪费 190
5.4.4 解决信息处理造成的浪费 191
5.5 隐性浪费 192
5.5.1 给丈母娘送海参的故事 192
5.5.2 快速试错消灭浪费 193
5.5.3 识别隐形浪费需要一点点洞察力 193
5.5.4 隐性浪费之不清楚进度 194
5.5.5 技术债和需求债 194
5.5.6 缺少优先级 194
5.5.7 分布式团队中的隐性浪费 195
5.5.8 隐性浪费带来的后果 195
5.6 不要把BDD变成团队中的浪费 196
5.7 小结 197
第6章 自我管理的离岸团队 199
6.1 传统文化对团队的影响 200
6.2 团队的驱动力 202
6.2.1 驱动源自何处 203
6.2.2 建立扁平化的组织 207
6.2.3 人，才是组织的核心 208
6.2.4 扁平化的团队需不需要领导力 210
6.2.5 传统组织如何向自组织转型 211
6.2.6 扁平化不是万能的 214
6.3 塑造团队的专业性 216
6.3.1 团队的能力建设 216
6.3.2 养成好习惯 217
6.3.3 公司内部的流程标准化对团队的正面影响 218
6.3.4 成为项目中的重要贡献者 219
6.3.5 如何对待文档 219
6.3.6 把简单的事情做好就是专业 220
6.3.7 团队要以业务价值为导向 223
6.4 让信息透明化 223
6.4.1 传统团队中信息流动不畅的问题 224
6.4.2 透明化的挑战 225
6.4.3 高透明度是不可逆转的趋势 227
6.4.4 离岸团队的信息透明化 228
6.5 跳出舒适区 228
6.5.1 找到舒适区 228
6.5.2 为什么要跳出舒适区 229
6.5.3 团队驱动跳出舒适区 229
6.5.4 自我驱动跳出舒适区 230
6.5.5 企业KPI驱动跳出舒适区 231
6.5.6 小结 231
6.6 项目经理做什么 231
6.6.1 传统项目经理的特点 233
6.6.2 自我管理团队的项目经理 234
6.6.3 项目经理之于团队 235
6.6.4 项目经理之于客户 237
6.6.5 成功的项目经理之团队管家 239
6.6.6 成功的项目经理之正确看待领导力 240
6.6.7 成功的项目经理之解决冲突 241
6.6.8 做什么 241
6.6.9 怎么做 243
6.6.10 更多地关注项目风险 246
6.6.11 小结 247
6.7 建立全团队意识 247
6.7.1 需求的全团队参与 247
6.7.2 测试的全团队负责 249
6.7.3 开发实践 251
6.7.4 系统安全意识 252
6.7.5 小结 253
6.8 反馈是分布式团队持续改进的推进器 253
6.8.1 我们为什么要重视反馈 253
6.8.2 做好反馈的要点 254
第7章 服务于客户的离岸团队 257
7.1 建立与客户的互信 257
7.1.1 目标 258
7.1.2 建立信任的客户关系 261
7.1.3 建立和维持客户关系实例 262
7.1.4 小结 262
7.2 当与客户意见相左时 263
7.2.1 处理分歧 264
7.2.2 客户的意见决定交付质量 266
7.3 按人天收费的交付项目 267
7.4 固定金额的交付项目 268
7.4.1 工作量大小和价格的估算 268
7.4.2 固定金额项目的管理 271
7.4.3 商务层面的关切 275
7.4.4 固定金额项目的风险 276
7.4.5 建议、提示和可能的陷阱 276
7.5 与客户的工作衔接 277
7.5.1 项目启动 277
7.5.2 项目进行中 280
7.5.3 项目后期 281
7.5.4 其他 282
7.6 帮助客户敏捷转型 283
7.6.1 能力建设 283
7.6.2 强化敏捷的优势，坚定所有参与人的信念 283
7.6.3 建立跨职能团队/功能团队 287
7.6.4 小结 287
第8章 分布式团队的未来 289
8.1 离岸团队中的人 289
8.1.1 人员变动的应对 289
8.1.2 关注个人绩效 291
8.2 分布式团队仍然面临的问题 292
8.2.1 很多人说，敏捷项目不能外包 293
8.2.2 团队的领域知识管理和提升 294
8.2.3 离岸团队的效能 295
8.2.4 以史为鉴，面向未来 296
8.3 离岸团队的未来 296
8.3.1 聘请远程开发团队的理由 297
8.3.2 国际竞争 298
8.3.3 协助传统行业数字化创新 299
8.3.4 离岸团队的敏捷模型 299
8.3.5 与客户一起创新的实践 300
8.3.6 小结 301
8.4 离岸团队要为技术变革做好准备 302
8.5 低成本的离岸交付是一条不归路 303
8.6 小结 304
后记 305
参考文献 306
书单推荐
