我正在開發一個軟件項目，其中有幾個成員在家工作，其他人是兼職人員。我們至少每個月至少有一次見面。我們主要通過電子郵件進行交流我們的源代碼庫（mercurial）位於我們共享的叢林磁盤（工作組）上。如何在地域分佈的團隊中使用敏捷工具/方法
我們有一個工作產品和一個客戶。但是，我們不夠敏捷（即：代碼中的一個更改有時會破壞別的東西，我們沒有單元測試，代碼沒有記錄等）。我想使用敏捷方法來協調我們的工作並跟蹤我們的進展。我也想使用TDD。
團隊沒有使用敏捷方法（或其他方法）的經驗。
在地域分佈的團隊中使用敏捷方法的最佳方法是什麼？哪種方法最適合那種團隊？如何以最小的阻力有效地實現它？
謝謝！
我已將這作爲分佈式XP團隊的一部分，共享3個站點的源代碼和故事，每個站點相隔12小時（西雅圖，伯恩茅斯英國和新加坡）。
下面是我們做了什麼，一些寫起坐：
我們發現，它有助於得到大家身體一起在開始項目建立標準和建立關係。
我們還發現，它有助於擁有「大使」 - 在團隊之間運送不同的人以傳播知識並建立信任。
我們很幸運地擁有三個相隔12小時的網站 - 所以我們可以在早上做第一件事，晚上做最後一件事。我們稱他們爲「交接會議」，並通過視頻會議在即將到來的團隊和即將離任的團隊之間進行。
我們還發現遠程結對編程工作 - 當地對和遠程對（即4人份）之間，但它很激烈，排水和最佳僅供很短的時間完成時，它的真正關鍵看其他人正在做什麼遠程。
旁白：Kent Beck的使用Eclipse遠程對人的忠告：http://www.threeriversinstitute.org/blog/?p=584
不錯的聯繫和良好的模式（我們爲分佈式項目做了非常類似的事情，並且會議人員將人際關係人性化，並且擁有「大使」來傳播知識當然是強制性的）。 – 2010-03-02 23:45:35
嗯，我首先想到的，給你指定什麼：
單元測試添加到您的源代碼！
沒有單元測試，大多數敏捷方法並不是那麼有用。敏捷是關於輕量化並能夠快速響應變化 - 單元測試是使其發揮作用的主要因素之一。沒有單元測試，你將永遠無法自由地進行更改，而不會冒着重大破壞的風險。
當你添加測試時，我會記錄你的代碼。這也是能夠改變事情的關鍵，當團隊分發時更是如此。
一旦完成，您可以開始實施其他方法。就我個人而言，我會讓整個團隊都這樣做，並開始每天/每週的站立（通過電話會議等方式與分佈式團隊合作），每個人都會描述他們測試過的內容，以及他們如何進展等
這將至少讓你正確的軌道上......
開始持續集成（自動生成）。我使用了CruiseControl.Net。我建立了兩個版本：1）每次簽到後自動構建，2）根據需求構建測試版本。
你必須改善你的溝通方式。是的，工程實踐很重要，但敏捷的關鍵在於溝通。電子郵件並不是協調敏捷項目的最有效的工具，但不存在可以提供幫助的工具。
我們在Skype（主要是下午，也是普通手機）方面取得了巨大的成功，並且還使用了像MS SharedView這樣的工具，可以跨網站進行演示甚至配對。
一旦你開始有效地溝通，並覺得自己像一個團隊，其餘的將隨之而來。敏捷是關於檢查和適應，所以嘗試一下並且玩得開心。從每天站起來並從那裏開始。定期回顧將幫助您識別問題並改善。
如果你到工具：爲了能夠做到結對編程或同步代碼審查遠程，你可以嘗試的Eclipse插件Saros，這使協作編輯（包括支持驅動程序/觀察員角色和通過代碼後的用戶）。
（聲明：Saros是柏林自由大學工作組的一個項目）
社區wiki也許？ – falstro 2010-03-02 18:54:44
我同意獐子 - 很好的問題和主題，但我懷疑有一個正確的答案。 – 2010-03-02 18:58:15
我第二次（或事實上，「第三次」）對CW的建議。這是非常有趣的，但方式廣泛和主觀！ – mjv 2010-03-02 19:02:26