異地分布式軟件開發（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進行交流。
每天的定時會議將成為很重要的一個很重要的交流方式。如果團隊的人數較少，大家可以按照站立會議的方式在電話會議系統中說明自己的情況和遇到的問 題。如果人數較多，一種可替代的方式是每個團隊自己進行每日例會，并由個項目的項目經理和需求分析人員進行另外的會議以便協調工作。
如果兩個團隊時差較大，例如中國北京時間和美國東部時間時差12-3小時，想要進行直接的電話會議交流很困難。如果遇到3個處于不同時區的團隊，更 是經常不可能找到一個合適的時間來進行任何的會議。在國際化的公司中，起早貪黑的進行幾地的電話會議很常見，但這卻不適用于整個開發團隊。對這種情況，每 日的開發狀態郵件是很有用的。每日開發結束后由項目經理或成員來根據團隊的情況來撰寫一天的總結，并發送給遠端的團隊。
交流的障礙經常發生在陌生人之中，如果兩地的開發人員互不熟悉，可以考慮將雙方人員的照片貼在墻上，以增加熟悉感�？尚械脑�，進行可視會議和當面的會談。盡量減少陌生感，使交流效果提升。
任何交流方式都比不上面對面的交流。異地開發時，off-site一端很容易丟失on-site一端與客戶交流的語義上下文和環境。如果情況允許， 公司應該設立常規的出差和輪換制度。讓一部分的團隊成員到另一端，見一見一起工作的同事，了解一下客戶的需求和感受一下不同的環境。
敏捷開發過程的改進
般的敏捷過程中，都會有一個初始階段，在這個階段了解開發需求和制定發布計劃。要進行這樣的活動，最理想的辦法是讓所有人都出差到on-site一 端，一起了解需求和建立共識。這將會對后面的開發有很大幫助。如果由于人數或成本不可行，至少要派遣所有的需求分析師和項目經理、協調人以及部分測試人員 到場參與。對于迭代一級的計劃，應該由兩地的項目經理和需求分析師提前進行計劃會議并做出決定。
日常的項目管理工作中，采用卡片墻的方式只適用in-house的開發。在異地開發中，為了使得每個團隊都可以了解到團隊任務，至少需要在兩邊開發室都設立卡片墻，并保持同步�？梢圆捎迷诰�工具幫助進行項目跟蹤，例如Mingle或Trac，都是適用的在線工具，同時也是在線Wiki或共享知識庫。
項目協調人，應當制定完善的交流計劃和交流機制。例如前文提到的每日的例會和每日開發狀態郵件，每周的需求交流計劃，問題的提出和反應機制等等。這些應當制定成為團隊守則來遵循，并隨著實際情況的變化修訂。交流不怕多，只怕不充分。
一個共享的代碼版本控制系統是必須的。例如在公司內網建立一個SVN并通過VPN來使用。On-site和off-site團隊可建立自己單獨的持 續集成環境，但需要保持系統環境的一致。兩方的開發人員都應該保證每日離開辦公室前的提交通過集成。這樣可以避免異地團隊開始開發不至于被失敗的集成所耽 擱。
基本的敏捷時間必不可缺，例如測試，尤其是功能測試。On-site的QA應當在需求確定的時候制定好驗收條件。一個描寫良好的驗收條件會對開發人員有所幫助。尤其是在On-site一端不能及時解答問題的時候，會起到很大的作用。
每個迭代結束時，應盡量安排一個兩地同步的演示會議。讓所有人都在電話會議上看到這個迭代的成果。迭代后的總結與回顧也應當兩地一起進行，如果人數和條件不允許，可以分別進行，并互相通報回顧結果和改進方法。
離岸團隊的參與度
多團隊中，處于on-site的成員由于可以接觸到客戶，他們的話語權可能會被放大，使得on-site一邊的人傾向于命令式的消息傳遞，直接指派 需求和開發進度，而忽視了對需求背景情況和上下文進行介紹。這種情況可能造成off-site一端團隊產生抵觸心里，從而導致項目的失敗。
解決方法是提高off-site團隊的參與度。如制度性的進行人員輪換，讓兩端的團隊成員有所接觸，并互相熟識。定期組織兩個團隊的共同活動。如果 都處于一個時區，可以考慮進行每周的Learning Lunch，大家在互相能看到視頻的情況下一起吃飯和聽講座。講座內容可以是任何話題，例如一些項目相關的技術決策等等。
不要忽視offsite團隊的任何意見和建議，他們在很多時候能從另一個側面對項目提出見解。鼓勵offsite團隊決策和發起討論，這樣可以提高他們的參與度。
實施異地開發的最初目的是為了降低人力成本和運營成本，一些跨時區的異地開發還可以提高時間利用效率，實現全球24小時開發。然而，異地開發帶來了高昂的交流和管理成本，如果處理不當將直接導致項目或產品的失敗。
近年來隨著國內軟件公司業務的發展，異地開發項目將會越來越多。全球化的進程也會使得外國公司開展更多類似的開發。異地開發項目將會逐漸發展和普遍�？梢韵胂�，多年以后，如果一個公司沒有異地開發的團隊，將會是多么的令人詫異。
|
