異地分(fēn)布式軟件開發（Distributed Software Development）是指由多(duō)個位于不同地理(lǐ)位置的團隊進行同一個軟件項目的開發過程。這個詞越來越頻繁的出現在各種技(jì )術媒體(tǐ)中(zhōng)。
異地分(fēn)布式軟件開發不同于外包，它建立在平等關系的兩個團隊之間。通常是一個公(gōng)司的不同分(fēn)公(gōng)司或辦(bàn)公(gōng)室間的協作(zuò)，他(tā)們之間大多(duō)不存在博弈的合同關系。而外包是指一個公(gōng)司将其軟件系統的開發委托給另一個公(gōng)司或組織完成。二者之間是合同的甲乙方關系。
但無論是異地分(fēn)布式軟件開發或是外包，可(kě)以接觸到實際客戶的一端一般稱為(wèi)on-site，另一端可(kě)相應的稱為(wèi)off-site，他(tā)們可(kě)以根據地理(lǐ)位 置分(fēn)為(wèi)三類：on-shore（在岸，指在同一個國(guó)家或同一個時區(qū)内），near-Shore（近岸，在接近的國(guó)家和地區(qū)中(zhōng)）和off-Shore（離 岸，通常在時差8小(xiǎo)時以上）。如下表。
offsite on shore near shore off shore
Distributed Development 北京辦(bàn)公(gōng)室 - 西安(ān)辦(bàn)公(gōng)室之間 印度分(fēn)公(gōng)司 - 中(zhōng)國(guó)分(fēn)公(gōng)司 矽谷總公(gōng)司 - 中(zhōng)國(guó)或印度分(fēn)公(gōng)司
Outsourcing
Development 北京某公(gōng)司 – 廣州另一公(gōng)司 東京某公(gōng)司 - 大連另一公(gōng)司 歐洲某公(gōng)司 - 中(zhōng)國(guó)另一公(gōng)司
異地分(fēn)布式開發的組織方式
異地分(fēn)布開發的組織方式有(yǒu)很(hěn)多(duō)種。最常見的一種是公(gōng)司将完整的團隊組織結構分(fēn)布在兩地，每個團隊都有(yǒu)本地項目經理(lǐ)，需求分(fēn)析師，開發者以及測試。同時公(gōng)司設定項目總負責人角色，負責兩地的溝通與協調。
有(yǒu)的公(gōng)司将需求分(fēn)析人員放在on-site一端，開發者、測試人員和項目經理(lǐ)在off-site一方，同時在本地也保持常規的需求分(fēn)析師。也有(yǒu)公(gōng)司将測試人員和開發人員分(fēn)放在不同地方，一方面開發，另一方面利用(yòng)時差，在夜間測試并在第二天及時反饋測試結果。
各種組織方式都有(yǒu)其不同的适用(yòng)場合。然而他(tā)們的共同點在于，都是注重micro-management，即加強在本地團隊中(zhōng)項目管理(lǐ)和協調，而不是由一個人同時直接管理(lǐ)兩地的活動。同時，也盡量保證團隊兩邊都具(jù)有(yǒu)項目協調人、本地項目經理(lǐ)、需求分(fēn)析師等輔助角色。
基本原則：極盡交流之能(néng)事
異地分(fēn)布軟件開發面臨的最大問題是交流問題。随着人員距離的增加，交流效率将大大降低（參見Alistair Cockburn的文(wén)章），同時交流成本将極大提高。很(hěn)多(duō)時候on-site一端團隊不能(néng)把正确的需求傳遞到off-site一端，這直接造成産(chǎn)品質(zhì)量的下降。
為(wèi)了使避免這種情況，應盡量采用(yòng)一切手段來提高交流的效果。例如，項目經理(lǐ)和團隊成員都需要了解其他(tā)人的工(gōng)作(zuò)狀态，一個技(jì )巧是可(kě)以将你的MSN或Y!名(míng)稱後綴寫上你在做哪一塊的需求。并可(kě)以随時和同事通過IM進行交流。
每天的定時會議将成為(wèi)很(hěn)重要的一個很(hěn)重要的交流方式。如果團隊的人數較少，大家可(kě)以按照站立會議的方式在電(diàn)話會議系統中(zhōng)說明自己的情況和遇到的問 題。如果人數較多(duō)，一種可(kě)替代的方式是每個團隊自己進行每日例會，并由個項目的項目經理(lǐ)和需求分(fēn)析人員進行另外的會議以便協調工(gōng)作(zuò)。
如果兩個團隊時差較大，例如中(zhōng)國(guó)北京時間和美國(guó)東部時間時差12-3小(xiǎo)時，想要進行直接的電(diàn)話會議交流很(hěn)困難。如果遇到3個處于不同時區(qū)的團隊，更 是經常不可(kě)能(néng)找到一個合适的時間來進行任何的會議。在國(guó)際化的公(gōng)司中(zhōng)，起早貪黑的進行幾地的電(diàn)話會議很(hěn)常見，但這卻不适用(yòng)于整個開發團隊。對這種情況，每 日的開發狀态郵件是很(hěn)有(yǒu)用(yòng)的。每日開發結束後由項目經理(lǐ)或成員來根據團隊的情況來撰寫一天的總結，并發送給遠(yuǎn)端的團隊。
交流的障礙經常發生在陌生人之中(zhōng)，如果兩地的開發人員互不熟悉，可(kě)以考慮将雙方人員的照片貼在牆上，以增加熟悉感。可(kě)行的話，進行可(kě)視會議和當面的會談。盡量減少陌生感，使交流效果提升。
任何交流方式都比不上面對面的交流。異地開發時，off-site一端很(hěn)容易丢失on-site一端與客戶交流的語義上下文(wén)和環境。如果情況允許， 公(gōng)司應該設立常規的出差和輪換制度。讓一部分(fēn)的團隊成員到另一端，見一見一起工(gōng)作(zuò)的同事，了解一下客戶的需求和感受一下不同的環境。
敏捷開發過程的改進
般的敏捷過程中(zhōng)，都會有(yǒu)一個初始階段，在這個階段了解開發需求和制定發布計劃。要進行這樣的活動，最理(lǐ)想的辦(bàn)法是讓所有(yǒu)人都出差到on-site一 端，一起了解需求和建立共識。這将會對後面的開發有(yǒu)很(hěn)大幫助。如果由于人數或成本不可(kě)行，至少要派遣所有(yǒu)的需求分(fēn)析師和項目經理(lǐ)、協調人以及部分(fēn)測試人員 到場參與。對于叠代一級的計劃，應該由兩地的項目經理(lǐ)和需求分(fēn)析師提前進行計劃會議并做出決定。
日常的項目管理(lǐ)工(gōng)作(zuò)中(zhōng)，采用(yòng)卡片牆的方式隻适用(yòng)in-house的開發。在異地開發中(zhōng)，為(wèi)了使得每個團隊都可(kě)以了解到團隊任務(wù)，至少需要在兩邊開發室都設立卡片牆，并保持同步。可(kě)以采用(yòng)在線(xiàn)工(gōng)具(jù)幫助進行項目跟蹤，例如Mingle或Trac，都是适用(yòng)的在線(xiàn)工(gōng)具(jù)，同時也是在線(xiàn)Wiki或共享知識庫。
項目協調人，應當制定完善的交流計劃和交流機制。例如前文(wén)提到的每日的例會和每日開發狀态郵件，每周的需求交流計劃，問題的提出和反應機制等等。這些應當制定成為(wèi)團隊守則來遵循，并随着實際情況的變化修訂。交流不怕多(duō)，隻怕不充分(fēn)。
一個共享的代碼版本控制系統是必須的。例如在公(gōng)司内網建立一個SVN并通過VPN來使用(yòng)。On-site和off-site團隊可(kě)建立自己單獨的持 續集成環境，但需要保持系統環境的一緻。兩方的開發人員都應該保證每日離開辦(bàn)公(gōng)室前的提交通過集成。這樣可(kě)以避免異地團隊開始開發不至于被失敗的集成所耽 擱。
基本的敏捷時間必不可(kě)缺，例如測試，尤其是功能(néng)測試。On-site的QA應當在需求确定的時候制定好驗收條件。一個描寫良好的驗收條件會對開發人員有(yǒu)所幫助。尤其是在On-site一端不能(néng)及時解答(dá)問題的時候，會起到很(hěn)大的作(zuò)用(yòng)。
每個叠代結束時，應盡量安(ān)排一個兩地同步的演示會議。讓所有(yǒu)人都在電(diàn)話會議上看到這個叠代的成果。叠代後的總結與回顧也應當兩地一起進行，如果人數和條件不允許，可(kě)以分(fēn)别進行，并互相通報回顧結果和改進方法。
離岸團隊的參與度
多(duō)團隊中(zhōng)，處于on-site的成員由于可(kě)以接觸到客戶，他(tā)們的話語權可(kě)能(néng)會被放大，使得on-site一邊的人傾向于命令式的消息傳遞，直接指派 需求和開發進度，而忽視了對需求背景情況和上下文(wén)進行介紹。這種情況可(kě)能(néng)造成off-site一端團隊産(chǎn)生抵觸心裏，從而導緻項目的失敗。
解決方法是提高off-site團隊的參與度。如制度性的進行人員輪換，讓兩端的團隊成員有(yǒu)所接觸，并互相熟識。定期組織兩個團隊的共同活動。如果 都處于一個時區(qū)，可(kě)以考慮進行每周的Learning Lunch，大家在互相能(néng)看到視頻的情況下一起吃飯和聽講座。講座内容可(kě)以是任何話題，例如一些項目相關的技(jì )術決策等等。
不要忽視offsite團隊的任何意見和建議，他(tā)們在很(hěn)多(duō)時候能(néng)從另一個側面對項目提出見解。鼓勵offsite團隊決策和發起讨論，這樣可(kě)以提高他(tā)們的參與度。
實施異地開發的最初目的是為(wèi)了降低人力成本和運營成本，一些跨時區(qū)的異地開發還可(kě)以提高時間利用(yòng)效率，實現全球24小(xiǎo)時開發。然而，異地開發帶來了高昂的交流和管理(lǐ)成本，如果處理(lǐ)不當将直接導緻項目或産(chǎn)品的失敗。
近年來随着國(guó)内軟件公(gōng)司業務(wù)的發展，異地開發項目将會越來越多(duō)。全球化的進程也會使得外國(guó)公(gōng)司開展更多(duō)類似的開發。異地開發項目将會逐漸發展和普遍。可(kě)以想像，多(duō)年以後，如果一個公(gōng)司沒有(yǒu)異地開發的團隊，将會是多(duō)麽的令人詫異。
|
