曲正平，现就职于滴滴出行公司，从事质量管理工作，日常需要协调多个团队进行质量改进。在此之前就职于ThoughtWorks，参与和主导过大量的项目测试和交付工作，客户遍布美国、澳大利亚、英国及国内许多地方。对建立分布式团队的沟通计划、分布式敏捷协作、质量保证流程以及敏捷实践有非常深刻的理解。除了项目交付，还曾为多家传统企业提供敏捷实践方面的咨询服务。

这是一本在市面上找不到类似内容的书，里面
的内容几乎全部来自于实战的再总结。如果你是新
手，想了解什么是离岸交付，那么你应该去网上查
找一些入门资料；如果你正身处项目之中，或刚脱
离项目，要进入下一个项目，阅读本书你会收获颇
丰，可以理解其中很多概念、方法、工具甚至套路
。本书除了站在客户视角看离岸管理，还站在不同
角色的视角对离岸团队给出建议。如果你既做过测
试，也做过开发，还做过项目经理，你会随着阅读
切换思路进入不同的空间。
——李瑞洋 东软集团智能应用事业部开发部
长
本书关注的是外包软件交付在沟通边界走向某
些极限状态下的应对套路和思考方式。在若干年的
敏捷软件交付咨询过程中，我发现沟通的磨练是软
件交付过程中任何团队都必须经历的过程。就如同
极限编程把一些实践推向极限的做法一样，我建议
你把本书中的很多实践技巧作为项目沟通过程中的
极限实践加以使用。把任何一个团队都当成是一个
分布式团队来管理，这样项目才更有可能走向成功
。希望这本经验与思考铸就之书能引发软件人更多
的思考……
——王宇 专业敏捷教练、敏捷顾问
软件项目外包模式存在已久，而其研发质量与
效率一直是管理者的关注点。2015年Chaos Report
表明，失败或者遭遇困境的软件外包项目占比仍高
达71%。本书系统地讲解了如何正确使用分布式团队
研发管理模式，并通过大量示例详细说明了具体的
方法和技巧，具备很强的指导性和实战性，对于希
望提高分布式软件研发质量与效率的读者一定会大
有裨益。
——乔梁 持续交付专家、《持续交付2.0》作
者、《持续交付》译者

在写本书的过程中，我明白了一个道理。
以前经常听说，演员从来不看自己演的戏。同
样的道理，我花了6个月的时间把书从0写到90%，结
果又花了6个月的时间才完成最后10%，反复地斟酌
、推敲、修改，到最后，看到自己写的东西就有一
种反胃的感觉。所以我相信，一个游戏软件的测试
工程师肯定也不会玩自己测试的游戏软件。
如果对你来说不存在上述问题，说明你的意志
力超级强大，能轻易战胜自我。你甚至可以轻易地
独立完成敏捷实践中团队的回顾会议，因为对你来
说，与团队一起的回顾只是为了沟通信息而已。
离岸交付这个主题值得我们给予足够的重视，
因为在技术服务这个大背景下，它涉及的技巧会起
到意想不到的效果，但难以量化，所以常常被忽略
。这也是我的动力，离岸交付这个领域在过去十几
年中给了我太多东西，该是我回馈社会的时候了，
所以即使是反胃也必须克服。
离岸交付是全球化的一部分，一开始是全球化
的采购和生产，即简单的采购和供货的方式，随着
时代的变迁和创新的发展，这些合作形式已经显得
落伍，我们需要能够突破时间和空间的局限性开始
全球协作。并且，我们都相信，真正的全球化分布
式协作的浪潮才刚刚开始。
本书没有颠覆性的创新，没有开创性的理论和
观点，有的只是作者从经历过的数十个项目中汲取
的营养，日常工作的点点滴滴，长达十年的坚持不
懈，才有了这些细小的技巧和总结。
作为国内软件离岸交付的早期从业人员，我非
常不希望现在的从业人员重复我们的历史、重复我
们的故事，你们应该可以踩着我们的肩膀去做更有
价值的事情，而不是每天纠缠于离岸交付这种形式
。这正是作者的十年坚持不懈，希望看到的结果。
好了，调整好靠背，收起小桌板，开始去追求离岸
交付下的用户价值、商业创新吧！

第1章 分布式团队的现状
1.1 分布式团队介绍
1.1.1 分布式团队的快速发展
1.1.2 客户为何如此看重CMMI认证
1.1.3 分布式团队的类型
1.1.4 什么样的团队可以称为分布式团队
1.2 服务外包行业的现状
1.3 离岸团队的组建
1.3.1 组建分布式团队的原则
1.3.2 组建分布式团队
1.3.3 建立一个离岸团队的投入和效益
1.3.4 分布式团队需要注意的问题
1.4 软件外包服务大方向的变化
1.4.1 人才战争已经打响
1.4.2 战略合作的成果—建立离岸交付中心
1.4.3 客户衡量外包服务的方式在发生变化
第2章 分布式团队的沟通
2.1 管理客户的期望值
2.1.1 了解客户
2.1.2 保障客户的知情权
2.1.3 维护客户的期望值
2.1.4 超越客户期望值
2.1.5 L项目的案例
2.1.6 拆屋效应
2.1.7 项目的成败是由客户的期望值决定的
2.2 沟通是分布式团队最大的挑战
2.2.1 分布式团队最基本的沟通方式：电子邮件
2.2.2 常规意义上的沟通：异步沟通和实时沟通
2.2.3 工具的利与弊
2.2.4 主动的沟通
2.2.5 沟通中的冲突
2.2.6 同理心
2.2.7 清楚而坦诚的沟通
2.2.8 成功的离岸团队还需要关注的
2.3 会议的组织
2.3.1 典型的会议
2.3.2 离岸团队的会议技巧
2.3.3 小结
2.4 常驻代表和短期面对面的访问
2.4.1 常驻代表
2.4.2 短期面对面的沟通
2.4.3 一次访问客户现场之后的复盘
2.4.4 小结
2.5 虚拟交流工具
2.5.1 知识分享类
2.5.2 即时沟通类
2.5.3 工作协作类
2.5.4 流程控制类
2.5.5 融合即时沟通和知识分享的工具类
2.5.6 小结
2.6 沟通失败的案例
2.6.1 麦道飞机DC-10重蹈覆辙发生空难的教训
2.6.2 某大型能源企业的一次集成失败
2.6.3 L项目首次用户测试失败
2.6.4 小结
第3章 分布式团队的协作
3.1 团队协作初识
3.1.1 沟通与协作的关系
3.1.2 意见统一是协作的前提
3.1.3 协作更强调行动—执行力
3.1.4 对协作有益的方法
3.1.5 伤害协作的行为
3.1.6 带动客户
3.1.7 协作技巧
3.1.8 关键的协作点
3.1.9 Scrum of Scrums会议
3.1.10 团队内部的协作
3.1.11 小结
3.2 提升离岸团队协作的水平
3.2.1 使用假设
3.2.2 双向沟通
3.2.3 使用业务语言和实例
3.2.4 建立离岸团队的规律性
3.2.5 持续提升离岸团队的协作水平
3.2.6 小结
3.3 规范化提升分布式团队协作
3.3.1 需求分析的规范化
3.3.2 技术的规范化
3.3.3 测试的规范化
3.3.4 规范化自动化测试
3.3.5 小结
第4章 可视化的应用
4.1 可视化的目的
4.1.1 展示项目的状态
4.1.2 消除需求的理解偏差
4.1.3 反馈软件的质量
4.1.4 代码的测试覆盖率
4.1.5 描述复杂的业务流程
4.1.6 理解项目全景
4.1.7 帮助团队思考的思维导图
4.2 可视化的方法
4.2.1 项目状态的展示之看板
4.2.2 项目状态的展示之燃尽图和燃起图
4.2.3 业务流程的展示
4.2.4 项目需求的全景展现
4.2.5 需求故事的表达
4.2.6 思维导图的使用
4.2.7 数据可视化
4.3 使用可视化度量我们的工作
4.3.1 开发和测试工作的度量
4.3.2 对团队工作度量的建议
4.4 团队协作可视化工具的介绍
4.4.1 Mingle的基本介绍
4.4.2 Trello的基本介绍
4.5 小结
第5章 分布式团队中的浪费
5.1 人的因素造成的浪费
5.2 团队协作中的浪费
5.2.1 浪费来自哪里
5.2.2 浪费解决之道
5.2.3 小结
5.3 流程中产生的浪费
5.3.1 缩短流程
5.3.2 简化复杂的环节
5.3.3 加快进度的重要途径
5.3.4 过度设计也是一种常见的浪费
5.4 信息处理中的浪费
5.4.1 组织结构产生的浪费
5.4.2 知识管理中的浪费
5.4.3 信息过多造成的浪费
5.4.4 解决信息处理造成的浪费
5.5 隐性浪费
5.5.1 给丈母娘送海参的故事
5.5.2 快速试错消灭浪费
5.5.3 识别隐形浪费需要一点点洞察力
5.5.4 隐性浪费之不清楚进度
5.5.5 技术债和需求债
5.5.6 缺少优先级
5.5.7 分布式团队中的隐性浪费
5.5.8 隐性浪费带来的后果
5.6 不要把BDD变成团队中的浪费
5.7 小结
第6章 自我管理的离岸团队
6.1 传统文化对团队的影响
6.2 团队的驱动力
6.2.1 驱动源自何处
6.2.2 建立扁平化的组织
6.2.3 人，才是组织的核心
6.2.4 扁平化的团队需不需要领导力
6.2.5 传统组织如何向自组

1.3.3 建立一个离岸团队的投入和效益
组建分布式团队的目的不外乎以下几种：
降低成本；
开拓本地市场；
搜罗更多的人才。
作为客户，要考虑很多现实的问题，因为建立一个离岸团队而不是采用本土招聘的形式，在行业内一直存在不同的观点。作为支持方，理由是众口一词的，人工成本降低。有时候，分布式方法是交付产品的唯一方法，因为当地没有所需的人才，这也许算是使用分布式团队开发产品最正当的理由。
其实，人工费只是所有成本中的一部分，仅仅盯着人工费是不明智的。我在软件行业摸爬滚打多年，有一点我认识得比较清楚：不同人员的生产力的差异要远远大于他们的薪水差异。离岸团队更会显著地增大这一差异，因为离岸团队的成本除了人工费，还有沟通成本的增加、差旅费的增加，风险也因此远远高于本土团队。
我们先来看看沟通成本。分布式团队面临很多的沟通挑战，距离远而无法面对面沟通、时差、语言能力等。这些都会使我们对需求理解出现偏差，导致做出不正确功能的概率大大增加。我们虽然采用了很多技术手段以及派遣常驻代表，但离岸的风险仍然会对我们的团队造成负面影响。
如果是一个传统工作方式的团队，而不是采用敏捷工作方式，更加不支持团队间太多面对面的直接沟通。我们大多通过电子邮件、通过文档来达成团队间共识。因此，我们是不是就能得到最高的投入产出比呢？其实没这么简单，通过减少直接沟通的方法来达到减少沟通成本的目的，并不能增大团队的交付能力。就像通过节流的方式并不会致富一样，我们需要更多投入开源，投资创造出更多的价值。
回头再看看分布式团队的优势。我们发现，如果离岸团队完全在另一个时区，我们可以通过接力的方式，让一个功能在同一个主线上，24小时不间断地开发出来。这对我们加快上线速度有直接的好处。这是离岸团队特有的串行工作模式，如果团队有技术支持的职能，则能加快问题的解决。我们曾经遇到过这样的问题，我们也使用第三方的平台软件Salesforce，有一个技术问题需要尽快解决。我们首先找到伦敦的技术支持团队，因为北京时间下午晚些时候，他们刚刚上班。在他们下班的时候，只解决了部分问题，他们将我们的工单转交给了Salesforce在加利福尼亚的技术支持中心，继续处理我们的问题，后来他们又交给了悉尼的技术支持部门，最后解决了我们的问题。这样在我们第二天上班的时候，悉尼的客户支持人员给我们交付了他们的解决方案。
最后一个我想说说人才短缺的问题。我们可以在北京、深圳等很多城市找到足够的人才，即使这些人才并没有长期在这些地方生活的计划。在国外则很难找到人才如此集中的地方，而且人们也不愿意为此漂泊他乡。这时候我们更在乎的是工程师的天赋，而不是他们的成本。
1.3.4 分布式团队需要注意的问题
1.分布式团队中的人
现在社会上有一个观点，团队成员都在一起工作，有时候工作效率会降低，这是真的吗？团队成员每天都在一起，拥有最好的沟通条件。但是即使前提条件是最优的，结果就一定是最好的吗？我看不一定。就像一个家境很好的孩子，家长给他创造了最好的学习条件，但并不一定能得到最好的结果。反而是家境一般的孩子，平时要帮父母做事情，自己还要挤时间学习，主观能动性更强，结果反而可能更好一些。这就是为什么很多时候不好的条件反而能激发出更好的主观能动性。
因此，如果你一直奢侈得拥有一样东西，你一定不会认为它有什么特别之处。当这个东西是需要你努力才能得到的，你才会更加珍惜它。应用到沟通这件事情上，分布式团队中的我们更加看重沟通的机会，每次机会都会充分地准备，让沟通的效率更高效，用主观能动性来弥补天然的缺陷。
由此可以得出，人是一个分布式团队取得成功的关键因素之一。找到优秀的人，培养自我管理能力，运用适合的实践，就能把距离对我们的消极影响降到最小。
2.沟通难度的增加会改变团队的沟通习惯
通过以往的实践可以发现，接口难度的增加会产生一个后果，那就是交互的次数会减少，每次交互的内容会增加。例如，如果可以快速找到其他团队的一个人聊一下，确认一个需求或缺陷，我会马上做这件事。但是，如果我需要创建一个会议或者发送电子邮件讨论这件事，我也许不会立刻做这件事。即使我做了，也会花费更长的时间，所以我可能会先积攒更多的问题，然后再一起去讨论。
3.减少远程工作消极影响的方案
远程工作通常会阻碍社会化学习的过程，并增加跨功能团队工作交互的难度，所以我们需要在一些必要的工具上进行投资，如wi—Fi、视频电话、日常沟通的流程等。远程结对，使用共享屏幕软件，拉近距离。在工程实践上的投资，持续集成和自动化测试工具，这对分布式团队尤其重要。
共识要在刚开始的时候就达成，并在以后坚持这些共识。比如，分布式团队之间分配工作的原则、各团队中角色成员的不同会从很大程度上影响分配的结果。

如果你对以上问题感同身受，并感到束手无策，请务必仔细阅读本书。曲正平著的《离岸交付(分布式团队协作指南)》作者结合自身的经历和实践经验，从交付效率、交付质量、客户满意度等项目交付最重要的着眼点，赋能你和团队，并且有启发、可参考，能够引发你对自身工作的思考，快速提升交付水平。
本书中提到的技巧不仅能够让服务外包的团队服务好企业级交付，也能顺应协助传统企业利用IT技术创新的潮流，让团队之间的协作更加有效，有助于达成团队的技术目标和业务目标。

2005年对我来说是一个分水岭。
在这之前，我在一家国有企业里从事了3年软件
开发工作。这个时期，软件的好坏完全取决于软件
工程师的个人能力。软件的质量依赖于生产环境负
责联调的人的测试，联调人员同时负责焊接电路板
和测试无线发射信号。
在这之后，我到了一家软件外包公司，由于没
有受过系统的训练，第一个项目就稀里糊涂地以失
败告终。这是一个仓储管理系统，虽然拿到的技术
文档我基本能看懂每个功能是什么，但是说实话，
直到现在我仍然不知道最终用户是如何使用这个系
统的。回顾这段经历，我发现经验不足和缺乏一定
的指导，是造成这一失败的主要原因。首先，我们
对客户期望值的把握并不准确。因为当时考虑要尽
可能按客户的要求把项目做好，所以基本上是客户
说什么，我们照做什么，很少自己做决定。随着项
目的推进，我们的人也一直都很忙，但能够阶段性
交付给客户的东西还是很少。再加上我们与客户的
沟通基本以电子邮件为主，会议沟通只有每周一次
的电话会议，而且会议沟通主要用于解决遇到的问
题和安排下一周的任务，除此之外就再没有其他沟
通了。
上面这个项目失败之后，下来的人马上接手了
一个新项目。还是同样的人，同样服务于海外客户
，最终这个新项目却十分成功。其主要原因是，我
们总结了上一个项目的经验教训，应用了当时刚刚
接触的敏捷开发方式，为了提高沟通效率，我们还
到客户现场做了一次访问。在做访问的过程当中，
我们应用了很多后来被证明非常有效的实践方法，
如每天的早会、测试驱动开发、迭代式开发、尽快
交付客户试用、收集反馈、采用JIRA这样的缺陷管
理系统等。当年这些方法对我们来说都是理论性的
东西，我们是在摸着石头过河。最终，原计划6个月
完成的项目，提前1个月就交付给了客户，当时这在
公司内部引起了轰动。我们按照老思路给工作留出
很多缓冲时间，是特别给交付前测试和缺陷修复工
作预留的。结果发现，最后没有太多的问题需要修
复，这使我们对测试驱动开发第一次有了感性的认
识。不知道当时哪里来的勇气，当领导问我要不要
再测试两周时，我说：“平时都测试到了，而且最
近一段时间缺陷的数量一直呈下降趋势，已经非常
稳定。”一年以后，有一天我意外收到公司总监转
发的邮件，大体是说，这个软件经过一年的上线使
用，用户不但没有报告一个问题，而且表示这是他
们公司最好用的软件之一。
你可能想到了，是的，我陶醉了，即使现在回
忆起这段经历，仍是满满的幸福感。所以，流程的
改进、沟通的加强、持续的反馈确实能够影响软件
的交付，即使用的是离岸团队的同一批人。
后来，我们接触了更多的客户，参与的软件交
付也从交付独立的软件，变成了与客户团队成员紧
密合作，在共同交付软件的过程中，同时向客户团
队传授我们的方式方法。在此过程中，我们也发明
并应用了更多有价值的实践，如项目快速启动方法
、持续集成、持续交付、行为驱动开发（BDD）、精
益、看板等。在践行这些核心实践的过程中，我结
合离岸团队的特点也找到了一些适合分布式团队的
“微实践”。例如，电子邮件沟通的技巧、如何与
客户想法保持一致、远程站会的小游戏、访问客户
现场、平行角色沟通、质量内建、适合分布式团队
的工具、定期开发成果展示、可视化一切、减少分
布式团队的浪费、用同理心思考、处理冲突等。这
些技巧和实践的应用，虽然微小，却能够对分布式
团队的协作起到重要的作用，集中推广的价值也渐
渐显露出来。
中国的软件外包产业经过了十几年的发展，形
成了许多规模很大的外包公司，从业人员的数量也
很多。三五年前，国内这些大型外包公司还常常见
诸报端，他们能够吸引不少高端人才的加入，同时
也积累了很多的行业经验。但是现在，这些公司的
发展仿佛进入了瓶颈，最近几年也逐渐面临转型或
者服务升级的问题。通过对这个行业的观察，我发
现，在外包公司生存周期比较长的项目团队，大多
是大客户的项目，没有技术难度，有独立的交付团
队，只需要按照客户的要求按时做完项目即可。而
一些初创公司或者转型公司的项目团队则有较大风
险，因为要与客户的相关人员深度合作开发或者面
临遗留系统，他们最终的交付往往达不到客户要求
的质量，合作过程磕磕绊绊。这样下去对所处团队
的每个成员的职业成长也非常不利。
并且，最近几年很多公司的外包策略与十年前
相比有了很大的变化。以前，尤其是大企业的IT部
门，要求只是维持公司其他业务运转。现在，赶上
互联网热潮，因为软件更敏捷、更灵活，所以这些
企业希望信息技术能带动整个企业业务创新。他们
越来越重视自己研发团队的能力建设，而不是像以
前那样简单地把任务外包出去。外包公司如果不提
升与客户合作的等级和合作的技术含量，竞争力会
越来越低。你可能会说，客户转型会在意这些细枝
末节的东西吗？我要告诉你的是，发动机固然重要
，但是润滑系统不好、进入的空气不经过滤芯过滤
，是会出大问题的。
市面上的书，大的战略方面的、理论方面的团
队管理、项目管理的倒是有一些，但聚焦离岸团队
协作的却很少。经过这些年的总结，我希望针对离
岸协作这一特殊方式对项目的细节进行一些打磨，
以达到运转顺滑、延长寿命的目的。本书将针对文
化背景、时间、空间都有很大跨越的离岸团队给出
建议。至于是客户在一座城市，团队在另一座城市
，还是跨国公司，团队分布在世界各地，跨越性可
能没那么大，一样可以找到有用的内容。
目标读者
如果你是外包或者交付团队的需求分析师、开
发人员、测试人员、项目经理、产品经理，或者有
志于成为其中之一的任何团队成员，你将能从本书
中学到在一个项目的不同时期可以应用的一些旨在
提高沟通效能、掌握准确需求、提高交付产品质量
、减少协作中的浪费、形成良好工作习惯等一系列
的实践指南。本书的理论很少，如果你已经了解了
理论，读到很多地方肯定会有一种融会贯通，或者
“原来如此”，再或者“原来不过如此”的领悟。
写在前面
本书中提到的每一个主题都可以扩展成一本书
，但是我只做必要的介绍，旨在领你进门，因为我
相信每一个人都能够从其他渠道更好地、更深入地
在本书之外的地方找到答案。
本书中的多数主题单独拿出来，很多人会觉得
很熟悉，甚至是很了解，但在做项目的过程中，多
数人却不会把它们很好地用起来，其实用起来的效
果是很让人惊叹的。
本书中提到的实践、示例基本都是来自工作中
的真实经历，也是我十多年在分布式团队中工作积
累的经验。因为真实故事更容易让读者感同身受，
并且真实是独一无二的，我的真实一定有我的独特
性，而这可能是读者最感兴趣的地方。
正因为你不能经历它们，我才有了写作的动力
，希望通过我的描述让更多的人感受它们。书中记
录的所有问题和实践，都是离岸团队会遇到的，当
然从理论上讲大多数主题不仅限于离岸团队。
希望本书对从事软件外包工作的读者有所启发
。当然，即便没有在软件行业，相信读者也能够从
服务者的角度看问题，通过阅读本书对自己将来的
发展有所促进。经济全球化的发展使几乎所有的公
司都需要不同部门和团队的协作，你完全可以把本
公司的其他团队当成客户来看待。
在我的职业生涯中，大部分时间处于离岸团队
之中，这些年下来积累了不少有价值的东西。随着
积累的东西越来越多，终于到了一个临界点，希望
把这些东西整理出来的意愿越来越强烈，希望它早
日发挥出它应有的价值。
本书主要探究离岸交付的几大痛点，如沟通协
作、需求变更（信息不全更容易产生误解等破坏力
）、团队和客户以及外包容易出现的问题（如质量
低下、交付延期、预算超标）。除了林林总总的问
题，还有如何让成功的离岸交付可持续，找到一些
共性的东西，我见过太多不同的外包团队重复造轮
子的故事。
我们每个人都能比较轻易地得到一些理论知识
，这些理论知识告诉我们的是理想情况下交付的过
程是怎样的。但是在现实工作中很少会遇到理想情
况的案例，我们需要多研究非理想情况下的方法。
如果你读得仔细，一定会发现，本书的内容在
有些地方存在冗余。这是因为，当我们从不同维度
、不同视角考虑问题的时候，总会有一些问题涉及
不同的主题。虽然我可以继续提炼这些话题，减少
冗余，在文字安排方面更加准确，但是这样会不利
于理解。每位读者读完以后真正的收获，是检验文
字的唯一标准，而不是“好多地方没看懂”或者“
每看一遍都有一些新的收获”。
如果你有远程团队需要合作，如果你有本土客
户需要服务，那么你真的需要好好读读本书。

曲正平著的《离岸交付(分布式团队协作指南)》的内容源自作者的实践经历和工作积累。在长期的实践中作者发现，越来越多的离岸交付需要适应敏捷开发的模式。本书结合分布式团队沟通、协作中的痛点，系统地分析了很多离岸项目虎头蛇尾的原因，并给出可供参考的解决方案。对于很多公司和组织头疼的如何让分布式团队推行敏捷的离岸交付的问题，本书给出很多成功经验。此外，本书还系统介绍了建设自组织团队的一些措施和方法。
涉及离岸交付的软件组织以及其他各类存在分布式团队合作的软件组织都能从本书中得到很多有价值的提示。本书适合开发人员、测试人员、需求管理人员或项目经理等参考阅读。