[收藏]在離岸軟體開發中採用敏捷過程並從中獲利

作者：Andrew Filev

摘要：通過以下兩種趨勢可在現代軟體開發中付出更少、獲利更多：敏捷開發和離岸外包。讓我們看一下如何以及何時成功結合這兩種趨勢以增強企業的競爭力。

本頁內容

 在後泡沫時代，IT 預算被大量削減，造成預算供不應求，於是經理們不得不尋求更具有成本效率的解決方案。在這樣的情況下，流向新興市場國家的外包軟體開發（離岸開發）的趨勢開始增強。經濟驅動力並不是造成這種趨勢的唯一動力。最近由通訊基礎結構的進步所帶來的迅猛增長也發揮了重要作用。

無論是傳統的分布式團隊還是特別的離岸外包，都可使用 網際網路通訊協定 (IP) (VoIP) 軟體、即時通訊軟體、電子郵件用戶端和 wiki 更方便的進行線上通訊。而且，現在人們更加傾向於使用 wiki 等線上工具而不是進行個人通訊，因為這些工具不但能夠傳達資訊，還有助於組織和儲存資訊。這些工具還可以有效地將資訊分發給大量接收者。

這些可在全球範圍內使用的快速 網際網路連線同樣增強了其他工具的功能，這也是加速離岸外包的原因之一。通過建模工具，分布式團隊更容易理解文檔。錯誤跟蹤器、原始碼控制伺服器、入口網站和線上協作工具都有助於協調分布式項目。終端服務和虛擬機器簡化了遠程測試和管理。

在 Internet 的影響下，新興市場國家也開始發展高科技。Internet 跨越了政治邊界，在俄羅斯和中國等發展中國家，成千上萬的年輕人可通過它來學習最先進的技術並提高他們的英語水平。這種通過在 Internet 上接受教育來成為軟體工程師的新浪潮也加劇了離岸外包的趨勢。

但是離岸外包的飛速增長也引起了政治辯論。這場討論假設離岸開發的存在具有現實意義，而且我們將著眼於最大化外包聘用所帶來的回報。政治因素不會影響我們的決定，不過我們會參考 McKinsey Global Institute 經研究後提供的資源清單，因為這裡量化了外包為美國經濟帶來的益處，同時也駁斥了一些關於外包的神話。

敏捷式軟體開發 (Agile Software Development)趨勢

現在來討論一下國內的情況。在國內，很多經理和工程師都在深思現在出現的另一個趨勢：敏捷式軟體開發 (Agile Software Development)。在當今不斷變化的商業環境中，緩慢的“重量型”方法無法滿足要求。現在需要用更少的投入產生更大的利潤，而且官僚作風再也不是獲得投資回報 (ROI) 的最佳方法。敏捷方法的優勢在於它的協作、靈活性，以及它對軟體的商業價值作出的貢獻，這體現在“敏捷宣言”的核心原則中：在過程和工具的基礎上獨立工作和互動、在綜合文檔的基礎上使用軟體、在合約談判的基礎上進行客戶協作以及在遵循計劃的基礎上對變更做出響應（請參閱資源）。

敏捷方法在很大程度上滿足了基於 Internet 的新型創業（通常稱作 Web 2.0）。某些新型創業通過敏捷式軟體開發 (Agile Software Development)可以付出更少、獲利更多，而且可以通過小型團隊以很小的預算完成大型項目。這種短迭代和工作軟體原則反映在一種稱為“不斷測試”(constant beta) 的實踐中，該名稱源於一些 Google 產品（其徽標中包含了“beta”一詞）。

然而，敏捷方法不是“通用型”的方法。該方法最適合小型的、同一地點的團隊用來應對飛速變化的情況。

圖 1. 點對點和服務匯流排整合

儘管在某些情況下應用敏捷式軟體開發 (Agile Software Development)會遇到問題（例如將其應用於使用離岸外包的分布式開發中），但是在過去的五年中，我成功地將敏捷開發的原理應用到了分布式團隊中，這說明只要使用得當，這種開發方式也可帶來巨大的回報。

圖 2. 三個整合層

還有其他一些說明敏捷式軟體開發 (Agile Software Development)會帶來問題的案例。這些案例是：大型Team Dev（一個獨立項目有 20 名以上的人員參與）、可預見性至關重要的系統（生命關鍵應用程式）以及官僚環境。我們不會在這裡討論這些案例，而且我們會假設公司已經將敏捷開發融入其企業文化之中，並且打算將這裡列出的觀點應用到不足 20 人的軟體團隊中（這裡的 20 人是指某個特定團隊或項目的人數，而不是整個Team Dev的人數）。我們會討論如何將敏捷方法應用到傳統的分布式開發和特別的離岸外包。

結合趨勢

離岸軟體開發交易中存在各種不同的聘用方式，可從 rentacoder.com 僱用一個國外開發人員，也可與擁有海外分公司的美國公司進行上億美元的交易。不過即使交易的某一方希望採用敏捷式軟體開發 (Agile Software Development)過程，某些交易也不會按照這樣的過程來安排。

要執行敏捷過程，所選的外包模式應該鼓勵通訊和協作，具有靈活性，以及經常發布。能夠在外包交易中採用的標準有很多，不過其中最值得關注的是定價模型。關於最常用的定價模式計劃，請參閱圖 1。

可預測的結果暗示了可預測的過程。圖 2 中列出了按預測自適應等級進行排列的開發過程組。如果使用預測自適應標準和可預測模式（這更靠近等級的左端，請參閱圖 1），則軟體開發過程需要具有更大的可預測性；同時敏捷開發過程會處於軟體開發過程整體的另一邊。

可預測性因素與“固定範圍-固定價格”的聘用方式密切相關。如果在外包交易中採用此類合約，則客戶和供應商都只能採用可預測軟體開發過程及其結果。因此這類合約不適用于敏捷軟體開發。所以在制定外包聘用時，請記住鼓勵採用時間和材料等的定價模型來應對變化，這既為客戶和供應商提供了靈活性，也更適合進行敏捷開發。

處理這項交易時，需要考慮所選模式將如何影響通訊和協作。敏捷開發過程需要開放的環境、聯絡緊密的合作團隊、共同的目標、顯而易見的商業價值和頻繁的溝通。工程師、客戶、使用者、經理和其他股東之間的壁壘越多，進行敏捷式軟體開發 (Agile Software Development)就越困難，這意味著需要減少中間人以在團隊之間最大化透明度和整合性。

重量級人物們通過在其他國家建立分公司來處理這個問題，如果公司希望自己的海外開發中心擁有 100 名以上的工程師，這是很有經濟意義的。工程師的確切數量在很大程度上依賴於其他國家的實際情況，例如該公司是否能輕易地在這些國家招募到人才。

考慮這個選擇時，不要重複一些中小型企業的錯誤，例如低估高層行政時間、旅行預算、當地律師費和其他費用等隱性支出。另外，發展中國家經濟的快速增長引起了人才短缺，這有可能給新到來的小型外國企業帶來更大的壓力。雖然本地企業更容易被本地人所接受，但是大公司的分公司可通過知名品牌、更高的薪水和更完善的社會福利來彌補在這方面的不足。

不過對於只希望在海外聘用 15 個開發人員的小公司來說，幾乎不可能實行這樣的措施。成功的中小型企業往往使用專門的Team Dev、離岸開發中心 (ODC)、建造 - 經營 - 移交 (BOT) 模式、虛擬辦公室、虛擬團隊等模式來克服遠程辦公費用過高所帶來的困難。然而無論這些模式如何變化，它們都有一個共同點：海外供應商更強調向客戶提供硬體、法律、IT 和人力資源基礎結構，而不是直接參与開發過程。在這類交易中，客戶和供應商都對項目交付負有責任。

要從這類交易中充分獲利，必須向客戶指派工程師，而且雙方都必須擁有穩定的團隊。供應商和客戶之間的溝通必須完全透明，其中包括開發人員之間的溝通。所有人員都必須講一種語言，而不需要翻譯。

在成功的合作中，有時遠程辦公室中的人員儘管從供應商處領取工資，但是他們與客戶的聯絡更為密切，而且他們共用供應商和客戶的價值觀和企業文化。

使用正確的實踐和工具

成功的軟體Team Dev所使用的實踐中，眾所周知的有：共同的編碼通訊協定；原始碼控制伺服器；一鍵建立和部署指令碼；連續整合；單元測試；錯誤跟蹤；設計模式；以及應用程式塊。與本地團隊相比，分布式團隊必須以更嚴格的標準應用程式這些實踐。

以連續整合為例進行說明。如果操作人員與原始碼控制伺服器之間的距離非常遠，那麼使用原始碼控制伺服器來獲得突破是非常困難的。對於在另一個辦公室工作的人員而言，這也許沒什麼影響，但是對於追求工作效率和通訊的分布式應用情況而言，這就有可能成為一個主要的問題。只要堅持在團隊中進行連續整合實踐並安裝相應伺服器（例如 Microsoft Team Foundation Server、CruiseControl.NET 和 CruiseControl），就可以最小化這種風險。

在 Microsoft .NET 平台上工作的團隊可以使用 Microsoft Visual Studio Team System 提供的各種新功能。可擷取帶有說明的 Microsoft Solutions Framework for Agile Development 和支援工具。如果團隊需要更多關於在分布式環境中進行敏捷開發的指導，則該產品會非常有用。對於有經驗的團隊而言，這是一個可提供優秀 ROI 的整合解決方案。

另一個為分布式團隊帶來巨大價值的 Microsoft 產品是 Windows SharePoint Services (WSS)。Wiki 能夠有效地協助分布式團隊進行敏捷開發，而且 WSS 的下一個版本計劃在其增強功能中提供 wiki。WSS 同樣緊密整合了 Visual Studio Team System，這使得它成為團隊的 入口網站的最佳選擇。

從 IT 基礎結構的角度來看，我建議使用Virtual Private Cloud (VPN)，這樣團隊就可平等的共用資源。該 VPN 環境不像公用網路那樣嚴格，可在其中使用 Windows Live Messenger 的應用程式共用、視頻和語音電話、遠程協助和白色書寫板。

通訊、通訊、通訊

如果進行遠程工作，小的誤解也會迅速變成大問題。在分布式Team Dev中，經理必須密切注意通訊實踐，他們有時會在本地開發中忽略通訊實踐而不會產生不良後果。要注意的內容包括定期（每日/每周）報告和狀態更新會議，這樣可使團隊成員保持同步、討論成績和暴露問題。經理還應該通過介紹性會議、現場參觀、團隊建設活動和其它方式來在團隊中建立個人人際關係。

在離岸外包交易中，開發經理應該關注由語言、文化和時區所帶來的障礙，而且必須設法克服這些障礙。全球化在緩慢不斷地消除專業環境中的文化差別，但有時文化差異仍然會帶來混亂。這個主題中有很多特定於國家的問題，這裡就不再詳細討論了。語言問題容易發現卻不易克服。如果公司面臨語言障礙，最常用也是最有效方法是公司對員工進行語言培訓。在大多數國家，從事離岸開發的專業人員都願意學習英語，因此這些地方的專業人員通常都接受語言培訓。

時區的變化會使開發過程更加困難。但是在外包產業比較發達的國家，軟體工程師們通常都會調整他們的工作時間表，以便更有效地與國外同行合作。有兩種策略可用來處理時區差異。第一種是按照不同的工作對團隊進行分組；例如，質保和產品經理在國內工作，而開發人員在國外工作。該安排可進行迴圈作業，這樣開發人員可在他們的同行休息時修正程式和實現新需求，反之亦然。當然，也應結合工作時間表（在工作日開始/結束之時）。第二種方法是把項目劃分為多個塊，將每個塊分配給一個地點，給每個地點分配儘可能多的功能。第二種方法要求更有效通訊，因此也能更好的進行敏捷開發，但是兩種方法都是可以的，有時沒有選擇的餘地。

選擇正確的模式同樣很重要，但是這不能保證成功。在分布式環境中，強烈建議交易的雙方中至少有一方具有敏捷開發的經驗。如果缺乏面對面的溝通，那麼由於時間、文化、語言的不同，需要付出更多的人力和財力才能獲得預期的結果。擁有一個優秀的海外夥伴可帶來很多益處，例如節約成本、按需補充人員以及進行與外包基礎結構相關的任務等（這些益處可概括為“付出更少、獲利更多”），這大大優於投資建立生產性關係。沒有通過功能強大的通訊基礎結構（可在全球範圍內通用）所構建的現代工具，就不可能達到這種積極的平衡。