" 評估個體和交互勝過評估流程和工具這一說法是有它背后的原因和意義的。流程和工具是對通用經驗的提煉。隨之而來的，對于一些不常見的經驗，流程和工具就無法適應了。只有人可以。這就是個體和交互介入的時候了——搞清楚如何在不尋常的情況下取得進展。在面對新奇事物時，盲目遵循流程和工具，好比面對常規重復性事務時還堅持多樣、辯論、談判，和創造力一樣是無意義的。"

Kent Beck — 敏捷工具

如果決定將團隊進行分布式管理，那你需要給他們配備一套工具，來讓他們最大限度地提高溝通效率，這將需要一些時間來優化各團隊之間的工作和溝通流程。

雖然工具并不是敏捷團隊的首要關注重點，但是當你選擇了一個正確的工具，它絕對可以讓團隊運作地更加高效、更加靈活，并且不會妨礙團隊原本的工作流程。分布式的敏捷團隊無法依靠便簽紙，任務白板，或燃盡圖來進行項目跟蹤。他們需要一個強大的系統，以便在多個地點間共享這些條目和指標值。應選擇一個能夠支持跨地域分布式環境，并具有良好性能的工具。反之，不好的工具會降低團隊對任務的處理速度，這會導致團隊的挫敗感。團隊成員工作節奏也會變得怠慢，失去積極動力。

結論

分布式敏捷開發讓企業進軍新的全球市場，獲得全球人才，同時又能降低成本成為可能。在做出決定之前，一定要清醒地認識到分布式團隊的風險和回報。敏捷項目中成功的最關鍵因素之一，是團隊成員之間必須保持高水平的溝通能力。如果你的團隊是分布式的，他們必須在流程優化和實踐改進上加倍的努力，以此來彌補在溝通上失去的優勢。

要盡可能地把團隊帶到一起，尤其是在項目進行到關鍵節點的時候。用點時間來培養信任感并加強相互間的合作關系。敏捷開發是有一定難度的，需要很大的紀律性去遵循一些規則，對于分布式團隊來說尤其如此。確保你有一個明確授權的人，來訓練你的團隊，并保證他們處于保持溝通狀態的慣例。

敏捷團隊是基于用戶故事進行工作的，而非功能組件或實施任務。如果使用功能組件或團隊紀律來組織分配團隊工作的話，會很難把關注重點集中在真正重要的事情上。也就是，利益相關者及他們的需求。為分布式團隊配備工具，將盡可能減少分布式過程中遇到的障礙，同時會讓工作變得高效，有助于團隊完成用戶故事。整合的系統將從需求設計，開發及測試，為我們提供完整的可追溯性。最后，使用一個集成的wiki鏈接到任務和故事，來從各種各樣的設計會議中即時轉存成筆記。