当团队处于分布式协同工作时，沟通是最大的问题，也是我们需要尽最大努力去改进的区域。

• 会议开销最小化。团队成员应该能够便捷地加入电话会议或网络会议。共享桌面的网络会议是非常有用的。视频会议中让相互间都能看到工作白板，也是一个非常不错的选择。

• 免提耳机、网络摄像头、IM客户端、应用程序共享软件和电子邮件等工具，都是用来帮助沟通的好工具。关键是让大家养成使用它们的习惯。

• 团队间的沟通方式可能需要作出适当的改变以支持分布式开发。非正式的口头沟通可能需要更换为更正式的书面沟通。举例来说，使用电子邮件或者优选使用任务跟踪工具来更新任务的状态，而不是等待其他团队成员来问。这对于跨时区协作的分布式团队尤其有效，因为在任何时候都可以得到相关信息。

• 有意识地让异地的远程团队成员加入进来，并让他们主持电话会议。

• 规范会议形式很有必要。为了避免每日立会变得冗长和浪费时间，可以采用类似停车场系统的规则。在会议上提出的问题，可以先搁置，等会后相关人员再进行讨论。

• 配对编程这样的工作可以通过桌面共享软件来完成，而无需在分配时考虑地理分布。经常性的代码审查可以取代配对编程，或根据需要对其进行补充。此外，代码在未被审查前不应该上传到服务器，团队成员应该认真对待审查工作。

• 白板在设计会议中是至关重要。如果可能，最好将白板内容通过网络摄像头共享，或者将头脑风暴的信息通过Mind Map等共享。图片也可以采取通过统一的Wiki来获取和共享。理想情况下，Wiki系统最好能和跟踪工具集成使用。持续性的系统测试，持续性的系统测试，

• 面对面的沟通是无可替代的。尤其是在项目关键节点的时候。关键节点应着重关注项目的第一个和最后几个迭代。如果项目周期很长，可以在项目中期节点召开会议，也是非常有用的。

• 充分利用分布式团队之间重叠的工作时间。如果你是离岸式分布团队并且相互的时区相隔很大，以至于没有重叠的工作时间，那就需要采用新的策略来促使不同团队间的协同工作。各分团队在每天工作开始前召开自己的每日立会，其中有一个分团队留得晚一点或者早上提早一些到公司，以迎合整体会议的时间。另一种办法是两个队分别指定一个代表或者选定两个队都信赖的代表，由他们在每个团队开始和结束工作的时候进行交接沟通。代表的主要目的是了解每个团队状况并相互反馈，并传达会议期间发生的决策。

• 不对称的团队分布结构可能是最难应对的。比如，电话会议中突然有一个人拨打进来，而其他人此时都在会议中，这种情况可能会让大家因此错过某些关键信息。对此，应该让每个人都先接入电话会议，这样大家就能获得对称的信息。另外，相对于在固定的会议室开会，而让大家牢记应当偶尔拨打下手机来参加会议是一件特别困难的事情。

• 为团队指定一个教练，并让他帮助团队坚持实践活动来改善沟通。这些实践活动往往很容易被放弃，因为它们通常不容易操作。切记，教练并不是实践活动的执法者。他们的主要目的是帮助并提醒团队意识到紧密沟通的价值，即使分布式团队让实践操作变得更加困难。

• 避免让远程团队变得只“注重功能”。例如远程的测试团队。这可能会导致工作被来回推脱，也会极大降低效率，并最终让团队变得格格不入。团队的重点是专注完成他们名下的功能，而不是专注交付某个Story。敏捷团队通常能最大化地发挥跨职能部门的成员，如开发和测试人员。

• 如果每个团队间都必须独立工作，那就指定一个代表，让他在每个团队工作的时候都在线。他们将和测试人员沟通已完成的开发工作，反之也会和开发沟通已完成的测试工作。

• 不要按地理位置分配开发任务。这样做会随着时间的推移产生负面影响。这样的任务组织架构将会让团队的地理分布变得越来越分离(引述Conway’s Law [1])。团队应该考虑他们的工作是在不添加功能组件的情况下完成用户故事。单个Story相关联的开发任务应当分布到整个团队，而不是按照地域进行划分。这对分布式团队来说是最具挑战性的领域之一，因为它需要团队能跨地域密切合作，但这同时也将会为团队带来一致性的用户体验，并减少各组件之间的功能性差异。

• 过于特殊的地理位置分布和机构等迹象表明，你的团队会因为迫于分布式团队带来的沟通障碍而对产品进行变更，以此来满足他们的开发，而不是出于对客户需求的真正考虑。

• 保持耐心。建设一支优秀的团队，并具备融洽关系，良好的工作习惯和节奏是需要时间的。