當團隊處于分布式協同工作時，溝通是最大的問題，也是我們需要盡最大努力去改進的區域。

• 會議開銷最小化。團隊成員應該能夠便捷地加入電話會議或網絡會議。共享桌面的網絡會議是非常有用的。視頻會議中讓相互間都能看到工作白板，也是一個非常不錯的選擇。

• 免提耳機、網絡攝像頭、IM客戶端、應用程序共享軟件和電子郵件等工具，都是用來幫助溝通的好工具。關鍵是讓大家養成使用它們的習慣。

• 團隊間的溝通方式可能需要作出適當的改變以支持分布式開發。非正式的口頭溝通可能需要更換為更正式的書面溝通。舉例來說，使用電子郵件或者優選使用任務跟蹤工具來更新任務的狀態，而不是等待其他團隊成員來問。這對于跨時區協作的分布式團隊尤其有效，因為在任何時候都可以得到相關信息。

• 有意識地讓異地的遠程團隊成員加入進來，并讓他們主持電話會議。

• 規范會議形式很有必要。為了避免每日立會變得冗長和浪費時間，可以采用類似停車場系統的規則。在會議上提出的問題，可以先擱置，等會后相關人員再進行討論。

• 配對編程這樣的工作可以通過桌面共享軟件來完成，而無需在分配時考慮地理分布。經常性的代碼審查可以取代配對編程，或根據需要對其進行補充。此外，代碼在未被審查前不應該上傳到服務器，團隊成員應該認真對待審查工作。

• 白板在設計會議中是至關重要。如果可能，最好將白板內容通過網絡攝像頭共享，或者將頭腦風暴的信息通過Mind Map等共享。圖片也可以采取通過統一的Wiki來獲取和共享。理想情況下，Wiki系統最好能和跟蹤工具集成使用。持續性的系統測試，持續性的系統測試，

• 面對面的溝通是無可替代的。尤其是在項目關鍵節點的時候。關鍵節點應著重關注項目的第一個和最后幾個迭代。如果項目周期很長，可以在項目中期節點召開會議，也是非常有用的。

• 充分利用分布式團隊之間重疊的工作時間。如果你是離岸式分布團隊并且相互的時區相隔很大，以至于沒有重疊的工作時間，那就需要采用新的策略來促使不同團隊間的協同工作。各分團隊在每天工作開始前召開自己的每日立會，其中有一個分團隊留得晚一點或者早上提早一些到公司，以迎合整體會議的時間。另一種辦法是兩個隊分別指定一個代表或者選定兩個隊都信賴的代表，由他們在每個團隊開始和結束工作的時候進行交接溝通。代表的主要目的是了解每個團隊狀況并相互反饋，并傳達會議期間發生的決策。

• 不對稱的團隊分布結構可能是最難應對的。比如，電話會議中突然有一個人撥打進來，而其他人此時都在會議中，這種情況可能會讓大家因此錯過某些關鍵信息。對此，應該讓每個人都先接入電話會議，這樣大家就能獲得對稱的信息。另外，相對于在固定的會議室開會，而讓大家牢記應當偶爾撥打下手機來參加會議是一件特別困難的事情。

• 為團隊指定一個教練，并讓他幫助團隊堅持實踐活動來改善溝通。這些實踐活動往往很容易被放棄，因為它們通常不容易操作。切記，教練并不是實踐活動的執法者。他們的主要目的是幫助并提醒團隊意識到緊密溝通的價值，即使分布式團隊讓實踐操作變得更加困難。

• 避免讓遠程團隊變得只“注重功能”。例如遠程的測試團隊。這可能會導致工作被來回推脫，也會極大降低效率，并最終讓團隊變得格格不入。團隊的重點是專注完成他們名下的功能，而不是專注交付某個Story。敏捷團隊通常能最大化地發揮跨職能部門的成員，如開發和測試人員。

• 如果每個團隊間都必須獨立工作，那就指定一個代表，讓他在每個團隊工作的時候都在線。他們將和測試人員溝通已完成的開發工作，反之也會和開發溝通已完成的測試工作。

• 不要按地理位置分配開發任務。這樣做會隨著時間的推移產生負面影響。這樣的任務組織架構將會讓團隊的地理分布變得越來越分離(引述Conway’s Law [1])。團隊應該考慮他們的工作是在不添加功能組件的情況下完成用戶故事。單個Story相關聯的開發任務應當分布到整個團隊，而不是按照地域進行劃分。這對分布式團隊來說是最具挑戰性的領域之一，因為它需要團隊能跨地域密切合作，但這同時也將會為團隊帶來一致性的用戶體驗，并減少各組件之間的功能性差異。

• 過于特殊的地理位置分布和機構等跡象表明，你的團隊會因為迫于分布式團隊帶來的溝通障礙而對產品進行變更，以此來滿足他們的開發，而不是出于對客戶需求的真正考慮。

• 保持耐心。建設一支優秀的團隊，并具備融洽關系，良好的工作習慣和節奏是需要時間的。