淺析離岸軟件開發(fā)項(xiàng)目的成功概率
前言：
軟件開發(fā)項(xiàng)目的成功，取決于很多相互作用、綜合影響的因素，因此我們無法找到一種辦法來保證軟件開發(fā)項(xiàng)目能夠100%獲得成功。
但在軟件開發(fā)領(lǐng)域，通過采取一些特定的做法或?qū)嵺`，可以大大提高軟件項(xiàng)目的成功機(jī)會(huì)，因而我們有必要去發(fā)現(xiàn)并采納這些做法和實(shí)踐。
不管是離岸開發(fā)還是在岸開發(fā)，有很多通用的方法和實(shí)踐都能提高軟件項(xiàng)目的成功概率，但本文的目的不是去說明這些通用的做法。
本文關(guān)心的僅僅是在離岸軟件開發(fā)這個(gè)環(huán)境中，顯得相對(duì)比較突出的問題，或者是相對(duì)比較容易出現(xiàn)問題的部分。
文中所提到的內(nèi)容，大多來自于作者在相關(guān)領(lǐng)域的工作經(jīng)驗(yàn)，希望這些經(jīng)驗(yàn)?zāi)軌驅(qū)Υ蠹耀@得離岸軟件開發(fā)項(xiàng)目的成功，有所幫助。
問題：離岸軟件開發(fā)有什么特別？
離岸軟件開發(fā)過程中所遇到的問題，大多數(shù)都跟在岸開發(fā)相似，但主要因?yàn)榫嚯x上的限制以及時(shí)區(qū)的不同，有幾點(diǎn)跟軟件項(xiàng)目成敗密切相關(guān)的要素變得突出起來：
首先是團(tuán)隊(duì)之間的協(xié)同一致，變得更加困難，這既包括在岸團(tuán)隊(duì)和離岸團(tuán)隊(duì)之間就工作內(nèi)容方面的協(xié)調(diào)一致，也包括兩個(gè)團(tuán)隊(duì)之間就項(xiàng)目進(jìn)展的同步；
其次是溝通的壁壘增加了，這主要包括團(tuán)隊(duì)之間的信息共享和知識(shí)傳遞壁壘，可能的影響是增加了由誤解信息導(dǎo)致的返工和浪費(fèi)；
再則就是位于兩個(gè)不同地點(diǎn)的團(tuán)隊(duì)之間，容易產(chǎn)生不信任的現(xiàn)象，這將影響團(tuán)隊(duì)合作的順利度和有效性，增加很多不必要的成本；
先說團(tuán)隊(duì)之間的協(xié)同問題，在離岸軟件開發(fā)中，大家可能遇到過下面這些問題：
這邊團(tuán)隊(duì)進(jìn)行的改動(dòng)，導(dǎo)致對(duì)岸團(tuán)隊(duì)的代碼編譯失敗，影響了對(duì)方工作的正常進(jìn)展；
這邊團(tuán)隊(duì)check in的內(nèi)容，導(dǎo)致了對(duì)岸團(tuán)隊(duì)的變更丟失，其中一方不得不回滾或者重做相關(guān)的工作；
雙方的代碼整合過程超出了預(yù)期時(shí)間很多，而且充滿痛苦，這引起人員的不滿和系統(tǒng)的不穩(wěn)定；
雙方的工作內(nèi)容出現(xiàn)重復(fù)；
對(duì)方報(bào)告的Bug無法重現(xiàn)；
不難看出這些問題都有一個(gè)共性，就是雙方的協(xié)調(diào)一致沒有到位。就個(gè)人的經(jīng)驗(yàn)，采取以下做法將有助于降低這些問題發(fā)生的概率和影響：
雙方一開始就應(yīng)該建立起公共代碼庫，共同基于這套代碼進(jìn)行開發(fā)，并采取持續(xù)集成的做法經(jīng)常性同步代碼；
建立并遵循共同的規(guī)則，譬如每天Check in，并且check in之后，必須編譯通過才能下班；
盡量使用共同的開發(fā)工具和環(huán)境，譬如相同版本的控件和相同的測試環(huán)境；
經(jīng)常性同步，譬如定期合并Branch和Trunk；又譬如每周共同舉行兩次遠(yuǎn)程站立會(huì)議；
采用相同的實(shí)踐并盡量使其有所交叉，譬如離岸在案團(tuán)隊(duì)都采用2周一次的迭代，在每個(gè)迭代末共同舉行演示會(huì)議等；
離岸環(huán)境下，溝通方面的問題主要在于難以開展面對(duì)面的溝通以及時(shí)區(qū)的差異可能導(dǎo)致兩個(gè)團(tuán)隊(duì)沒有彼此交疊的時(shí)間，常見問題有：
難以在不見面的情況下描述清楚需求，或者難以理解客戶的需求描述；
對(duì)需求文檔的相關(guān)疑惑得不到及時(shí)解答，進(jìn)而影響進(jìn)展；
做出來卻發(fā)現(xiàn)并不是客戶真正想要的；
那么如何去應(yīng)對(duì)這些問題呢？個(gè)人經(jīng)驗(yàn)中比較有效的做法有：
一開始就建立多種溝通渠道，至少要保證雙方都知道彼此的IM，Email和電話；并且計(jì)劃固定的溝通時(shí)間，譬如每周二、周四溝通，每次是下午的13點(diǎn)到15點(diǎn)等；
盡量用有記錄可尋的方法來溝通需求，譬如更多地用書面文件來代替口頭溝通，若口頭溝通，也盡量錄音并留存；
若用文檔傳遞需求，***把格式固定下來，盡量多用圖片和表格，少用文字；User Story和Test Case是很有效的需求溝通辦法；
非文檔類型的需求傳遞，原型是***的方法，最質(zhì)樸的原型就是手工畫的草圖，將其掃描或拍照；一段錄制的視頻資料也可以考慮；
盡量用產(chǎn)品去溝通，譬如每周或者每兩周向客戶演示一次產(chǎn)品并獲取反饋；
建立共同的信息平臺(tái)，譬如Wiki
總之，溝通的順暢度和有效性對(duì)離岸環(huán)境下項(xiàng)目的成敗影響很大，可能首先是一定要確保雙方都能花足夠的時(shí)間在溝通上（因?yàn)榻?jīng)常有些客戶不愿意在這方面花時(shí)間），其次才是采用各種溝通的方法來增強(qiáng)溝通的效果。如果你是發(fā)包方，切忌當(dāng)甩手掌柜的想法，如果實(shí)施者對(duì)產(chǎn)品沒有深入的認(rèn)識(shí)，如何把產(chǎn)品做好呢？
至于信任問題，離岸環(huán)境下也是比較突出的，因?yàn)槌擞行蔚漠a(chǎn)出外，雙方一般都看不到彼此在做些什么，如果共事者之間沒有一定的信任，對(duì)項(xiàng)目的成功將是有害無利的。我遇到過的有兩種情況：
發(fā)包方對(duì)接包者的不信任- 發(fā)包者心里擔(dān)心自己的資源被浪費(fèi)，所以他會(huì)想辦法設(shè)置種種要求和限制，以此確保團(tuán)隊(duì)不會(huì)分心其它事情；實(shí)際上團(tuán)隊(duì)這邊本來是全心投入的，現(xiàn)在為了滿足這些要求和限制，不但增加了很多額外的工作負(fù)擔(dān)，而且團(tuán)隊(duì)成員覺得不被信任，缺乏干勁。
雙方的團(tuán)隊(duì)成員之間互相猜疑- 我遇到過一個(gè)項(xiàng)目，開發(fā)人員之一認(rèn)為對(duì)方的某個(gè)開發(fā)人員需求描述得不夠清楚，一直把需求退回去，而對(duì)方人員認(rèn)為需求已經(jīng)夠清楚了，不愿進(jìn)一步反饋，這就導(dǎo)致有些任務(wù)在需求這個(gè)環(huán)節(jié)被延誤，整體工作進(jìn)展很慢，雙方就是因?yàn)槿狈π湃味辉腹餐献鱽斫鉀Q這個(gè)問題。
我相信這類由于缺乏信任而引發(fā)項(xiàng)目進(jìn)展受阻的現(xiàn)象應(yīng)該還有很多，這也是為什么要進(jìn)行團(tuán)隊(duì)建設(shè)的原因之一。在離岸環(huán)境下如何改善這種情況？以下建議可以參考：
增加雙方見面的機(jī)會(huì)，無論是商務(wù)訪問還是視頻會(huì)議，只要能讓雙方互相看到，感受到對(duì)方個(gè)體的真實(shí)存在，那種感覺會(huì)比只看得到冷冰冰的代碼、文本和屏幕要好很多；
建立共同解決問題的機(jī)制，譬如每個(gè)迭代結(jié)束后，大家一起開會(huì)進(jìn)行總結(jié)回顧，討論共同的問題；
主動(dòng)并有規(guī)律性地進(jìn)行信息共享和披露；
除了上面提到的這些做法，良好的任務(wù)拆分也可提高離岸軟件開發(fā)項(xiàng)目的成功概率，推薦的做法是把工作內(nèi)容按照功能特性進(jìn)行拆分，這樣做的主要目的是避免業(yè)務(wù)邏輯層面的耦合性，以減少不同團(tuán)隊(duì)之間的溝通協(xié)調(diào)需要。如果是把項(xiàng)目外包給個(gè)人或者是能力還未達(dá)到勝任系統(tǒng)級(jí)設(shè)計(jì)的團(tuán)隊(duì)，那么在拆分任務(wù)時(shí)，盡量把任務(wù)分得細(xì)小而明確也是比較有益的做法，因?yàn)樾《鞔_的任務(wù)利于實(shí)施和管理，使得項(xiàng)目更加可控。
以上是在離岸軟件外包環(huán)境下，軟件開發(fā)項(xiàng)目中比較常見的三個(gè)問題及其對(duì)策，歡迎補(bǔ)充和探討。
原文鏈接：http://www.cnblogs.com/cavenran/archive/2011/07/25/
success_in_outsourcing_software_development.html
【編輯推薦】
