異地分布式敏捷式軟體開發 (Agile Software Development)(Distributed Agile Software Development)

異地分布式敏捷式軟體開發 (Agile Software Development) (Distributed Agile Software Development)

異地分布式軟體開發（Distributed Software Development）是指由多個位於不同地理位置的團隊進行同一個軟體項目的開發過程。這個詞越來越頻繁的出現在各種技術媒體中。

異地分布式軟體開發不同於外包，它建立在平等關係的兩個團隊之間。通常是一個公司的不同分公司或辦公室間的協作，他們之間大多不存在博弈的合約關係。而外包是指一個公司將其軟體系統的開發委託給另一個公司或組織完成。二者之間是合約的甲乙方關係。

但無論是異地分布式軟體開發或是外包，可以接觸到實際客戶的一端一般稱為on-site，另一端可相應的稱為off-site，他們可以根據地理位 置分為三類：on-shore（在岸，指在同一個國家或同一個時區內），near-Shore（近岸，在接近的國家和地區中）和off-Shore（離 岸，通常在時差8小時以上）。如下表。

offsite	on shore	near shore	off shore
Distributed Development	北京辦公室 - 西安辦公室之間	印度分公司 - 中國分公司	矽谷總公司 - 中國或印度分公司
Outsourcing Development	北京某公司 – 廣州另一公司	東京某公司 - 大連另一公司	歐洲某公司 - 中國另一公司

異地分布式開發的組織方式

異地分布開發的組織方式有很多種。最常見的一種是公司將完整的團隊組織圖分布在兩地，每個團隊都有本地專案經理，需求分析師，開發人員以及測試。同時公司設定項目總負責人角色，負責兩地的溝通與協調。

有的公司將需求分析人員放在on-site一端，開發人員、測試人員和專案經理在off-site一方，同時在本地也保持常規的需求分析師。也有公司將測試人員和開發人員分放在不同地方，一方面開發，另一方面利用時差，在夜間測試並在第二天及時反饋測試結果。

各種組織方式都有其不同的適用場合。然而他們的共同點在於，都是注重micro-management，即加強在本地團隊中專案管理和協調，而不是由一個人同時直接管理兩地的活動。同時，也盡量保證團隊兩邊都具有項目協調人、本地專案經理、需求分析師等背景工作角色。

基本原則：極盡交流之能事

異地分布軟體開發面臨的最大問題是交流問題。隨著人員距離的增加，交流效率將大大降低（參見Alistair Cockburn的文章），同時交流成本將極大提高。很多時候on-site一端團隊不能把正確的需求傳遞到off-site一端，這直接造成產品品質的下降。

為了使避免這種情況，應盡量採用一切手段來提高交流的效果。例如，專案經理和團隊成員都需要瞭解其他人的工作狀態，一個技巧是可以將你的MSN或Y!名稱尾碼寫上你在做哪一塊的需求。並可以隨時和同事通過IM進行交流。

交流頻度和價值圖，Vincent Massol，2004

每天的定時會議將成為很重要的一個很重要的交流方式。如果團隊的人數較少，大家可以按照站立會議的方式在電話會議系統中說明自己的情況和遇到的問 題。如果人數較多，一種可替代的方式是每個團隊自己進行每日例會，並由個項目的專案經理和需求分析人員進行另外的會議以便協調工作。

如果兩個團隊時差較大，例如中國北京時間和美國東部時間時差12-3小時，想要進行直接的電話會議交流很困難。如果遇到3個處於不同時區的團隊，更 是經常不可能找到一個合適的時間來進行任何的會議。在國際化的公司中，起早貪黑的進行幾地的電話會議很常見，但這卻不適用於整個Team Dev。對這種情況，每 日的開發狀態郵件是很有用的。每日開發結束後由專案經理或成員來根據團隊的情況來撰寫一天的總結，並發送給遠端的團隊。

交流的障礙經常發生在陌生人之中，如果兩地的開發人員互不熟悉，可以考慮將雙方人員的照片貼在牆上，以增加熟悉感。可行的話，進行可視會議和當面的會談。盡量減少陌生感，使交流效果提升。

任何交流方式都比不上面對面的交流。異地開發時，off-site一端很容易丟失on-site一端與客戶交流的語義上下文和環境。如果情況允許， 公司應該設立常規的出差和輪換制度。讓一部分的團隊成員到另一端，見一見一起工作的同事，瞭解一下客戶的需求和感受一下不同的環境。

敏捷開發過程的改進

般的敏捷過程中，都會有一個初始階段，在這個階段瞭解開發需求和制定發布計劃。要進行這樣的活動，最理想的辦法是讓所有人都出差到on-site一 端，一起瞭解需求和建立共識。這將會對後面的開發有很大協助。如果由於人數或成本不可行，至少要派遣所有的需求分析師和專案經理、協調人以及部分測試人員 到場參與。對於迭代一級的計劃，應該由兩地的專案經理和需求分析師提前進行計劃會議並做出決定。

日常的專案管理工作中，採用卡片牆的方式只適用in-house的開發。在異地開發中，為了使得每個團隊都可以瞭解到團隊任務，至少需要在兩邊開發室都設立卡片牆，並保持同步。可以採用線上工具協助進行項目跟蹤，例如Mingle或Trac，都是適用的線上工具，同時也是線上Wiki或共用知識庫。

項目協調人，應當制定完善的交流計劃和交流機制。例如前文提到的每日的例會和每日開發狀態郵件，每周的需求交流計劃，問題的提出和反應機制等等。這些應當制定成為團隊規則來遵循，並隨著實際情況的變化修訂。交流不怕多，只怕不充分。

一個共用程式碼版本控制系統是必須的。例如在公司內網建立一個SVN並通過VPN來使用。On-site和off-site團隊可建立自己單獨的持 續Integration Environment，但需要保持系統內容的一致。兩方的開發人員都應該保證每日離開辦公室前的提交通過整合。這樣可以避免異地團隊開始開發不至於被失敗的整合所耽 擱。

基本的敏捷時間必不可缺，例如測試，尤其是功能測試。On-site的QA應當在需求確定的時候制定好驗收準則。一個描寫良好的驗收準則會對開發人員有所協助。尤其是在On-site一端不能及時解答問題的時候，會起到很大的作用。

每個迭代結束時，應盡量安排一個兩地同步的示範會議。讓所有人都在電話會議上看到這個迭代的成果。迭代後的總結與回顧也應當兩地一起進行，如果人數和條件不允許，可以分別進行，並互相通報回顧結果和改進方法。

離岸團隊的參與度

多團隊中，處於on-site的成員由於可以接觸到客戶，他們的話語權可能會被放大，使得on-site一邊的人傾向於命令式的訊息傳遞，直接指派 需求和開發進度，而忽視了對需求背景情況和上下文進行介紹。這種情況可能造成off-site一端團隊產生抵觸心裡，從而導致項目的失敗。

解決方案是提高off-site團隊的參與度。如制度性的進行人員輪換，讓兩端的團隊成員有所接觸，並互相熟識。定期組織兩個團隊的共同活動。如果 都處於一個時區，可以考慮進行每周的Learning Lunch，大家在互相能看到視頻的情況下一起吃飯和聽講座。講座內容可以是任何話題，例如一些項目相關的技術決策等等。

不要忽視offsite團隊的任何意見和建議，他們在很多時候能從另一個側面對項目提出見解。鼓勵offsite團隊決策和發起討論，這樣可以提高他們的參與度。

實施異地開發的最初目的是為了降低人力成本和運營成本，一些跨時區的異地開發還可以提高時間利用效率，實現全球24小時開發。然而，異地開發帶來了高昂的交流和管理成本，如果處理不當將直接導致項目或產品的失敗。

近年來隨著國內軟體公司業務的發展，異地開發項目將會越來越多。全球化的進程也會使得外國公司開展更多類似的開發。異地開發項目將會逐漸發展和普遍。可以想像，多年以後，如果一個公司沒有異地開發的團隊，將會是多麼的令人詫異。

 

from： http://icecloud.javaeye.com/blog/90820