再談敏捷開發(fā)的好處及敏捷外包的前景
本文是Taskcity（一個提供敏捷管理工具以及為敏捷外包提供支持的公司）對敏捷外包的一些看法，對于理解敏捷的一些基礎(chǔ)概念還是有一些幫助的。
Agile，敏捷開發(fā)被越來越多的開發(fā)企業(yè)和團(tuán)隊所接受。敏捷恰當(dāng)，可以顯著提高開發(fā)效率和產(chǎn)品的開發(fā)周期。問題是，“敏捷”方法是否能適用到軟件外包行業(yè)，這個爭論 由來已久，各有說辭。最典型的爭論就是，作為外包的一個顯著特點，用戶和開發(fā)團(tuán)隊是相對遠(yuǎn)程，甚至開發(fā)團(tuán)隊內(nèi)部也存在遠(yuǎn)程的問題。如果一個團(tuán)隊不能身處一室，其中強(qiáng)調(diào)的溝通和互動是否能夠得到有效的執(zhí)行，是一個大問題。
傳統(tǒng)的外包商業(yè)環(huán)境，是客戶和服務(wù)提供方達(dá)成一個長期的合同，基于一個相對較長的階段，提供穩(wěn)定的外包服務(wù)支持?，F(xiàn)在，越來越多的企業(yè)客戶開始考慮將外包 項目劃分為小的可執(zhí)行單位。風(fēng)險可控，操作靈活。而服務(wù)提供方相對也達(dá)成了這個共識。其實，這兩種情況，如果通過敏捷的開發(fā)模式，在一個長期的合作過程 中，大家會發(fā)現(xiàn)，Agile不僅可行，而且的確能形成一個雙贏的局面。一起來看看我們的發(fā)現(xiàn)吧。
方法恰到好處
如果我們追求看到一個項目完成的效率和效果，敏捷開發(fā)其實優(yōu)于傳統(tǒng)的開發(fā)模式，即便對于初次接觸這個概念的發(fā)包客戶亦如此。我們大家都知道，在很多情況 下，發(fā)包客戶和服務(wù)提供方在涉足將項目外包出去開發(fā)之前，都擁有自己比較熟悉的開發(fā)模式和方法。敏捷開發(fā)或者說增量開發(fā)，可以讓雙方很輕易的統(tǒng)一到一個接口。傳統(tǒng)的開發(fā)方法基本上都是基于一個反復(fù)推敲的合同，合同中對于功能設(shè)計以及權(quán)利義務(wù)定義原則上都進(jìn)行了仔細(xì)的定義。但是，根本的問題是，很多用戶在項 目開始前，甚至開始的初期都沒有一個明確的，或者說準(zhǔn)確的描述。這樣，很多時候，客戶為了保護(hù)自己的利益，會盡可能多的添加功能到這個項目書中。而開發(fā)服 務(wù)提供方考慮的是如何在自己的成本控制內(nèi)得到盡可能多的盈利。在一開始，其實就為雙方日后的糾紛埋下了種子。我們能看到，在傳統(tǒng)的開發(fā)外包中，相當(dāng)比例的 項目最后，即便完成交付，完成支付，最后雙方的心情都是不太好。敏捷開發(fā)強(qiáng)調(diào)了階段性交付，增量開發(fā)，用戶互動。最后的交付物有時和原始的設(shè)計已經(jīng)有了很 大的出入，但是客戶貫穿了整個開發(fā)的周期，了解了所有的變動以及緣由，其滿意度甚至超過一個100%吻合的交付結(jié)果。用戶的滿意度和開發(fā)完成的代碼量不是 直接的因果關(guān)系。而在軟件外包行業(yè)中的同行們都知道，一個滿意的客戶意味著可能的后續(xù)項目，而這也是服務(wù)提供方最希望看到的結(jié)果。
溝通的威力
肖伯納有一句名言“England and America are two countries divided by a common language。”意思是英國和美國是被一個相同的語言所分隔的兩個國家。這里不是指的地理上的分隔，而是文化溝通上的差異，即便他們都說一種語言。英 美尚如此，何況作為一個典型東方文化代表的中國和我們的歐美客戶呢？不同的時區(qū)，不同的文化，不同的工作方法和原則，導(dǎo)致溝通成為了我們進(jìn)行海外外包的一 個瓶頸。敏捷開發(fā)既強(qiáng)調(diào)了溝通，又為順暢的溝通提供了方法和指導(dǎo)。其中持續(xù)的交付實際是在用實實在在的形式進(jìn)行了項目的溝通，從而降低了最后的交付風(fēng)險。 想想吧，作為傳統(tǒng)開發(fā)模式，比如一個瀑布式的開發(fā)，六個月后，客戶才能第一眼看到自己想要的產(chǎn)品，這里面能產(chǎn)生錯愕的概率有多大，大家可以想象一下。
迭代是趨于完美的過程
羅馬不是一天建成的。不要嘗試對完美的一步到位，除非你的用戶愿意犧牲寶貴的進(jìn)入市場的時機(jī)。外包開發(fā)不象是一個公司內(nèi)部的開發(fā)團(tuán)隊的 管理模式，對于離岸外包而言，雙方遠(yuǎn)隔萬里。所以我們的建議就是，只用盡最大可能不斷地從客戶那里得到進(jìn)程中的反饋，進(jìn)而對開發(fā)加以修正，才不會出現(xiàn)最終 和用戶意愿的大偏差。在雙方可以接受的情況下，定義一個一個短促有效的迭代過程，第一時間發(fā)現(xiàn)問題，放到下一個迭代中去解決。一個典型的迭代包括計劃-設(shè) 計-反饋-執(zhí)行（PDCA）。
勇于面對改變
需求變更在整個軟件開發(fā)的生命周期中是一個永恒的話題。也是客戶與服務(wù)提供方最糾纏不清之所在。改變的導(dǎo)火索可以來自方方面面，既有可 能是一覺醒來后的靈光一現(xiàn)，也有可能是來自客戶外部商業(yè)環(huán)境的改變。既然是現(xiàn)實，就接受它吧。當(dāng)然，處理得當(dāng)，這種變化可能協(xié)助雙方得到一個更優(yōu)秀的軟 件，也能讓客戶對你的快速應(yīng)變產(chǎn)生好感。否則，如果固守原始的設(shè)計稿件，或者永遠(yuǎn)作為一個新功能要求追加資金，有可能得到一個Case，卻失去一個用戶。 另外，我們總是陷在一個自己預(yù)設(shè)的陷阱里，客戶的要求改變永遠(yuǎn)是對功能的增加。其實，一個過程中的再設(shè)計，有可能會降低開發(fā)的成本。
質(zhì)量保證，真的嗎？
聽起來像是玩笑。敏捷開發(fā)這種快速交付，還能保證質(zhì)量，象是天方夜譚。其實不然?？焖俳桓?，讓用戶能夠盡快試用你的功能，盡快發(fā)現(xiàn)問 題，就整個開發(fā)周期而言，整體質(zhì)量一定會得到提升。在傳統(tǒng)開發(fā)模式中，我們都會或多或少遇到這樣的情況，因為開發(fā)時間的拖延（總是會拖延，這不可是玩 笑?。?，測試時間永遠(yuǎn)是第一個被壓縮的階段。結(jié)果可想而知。更多的迭代引入了更多的測試周期和時間。
事實上敏捷開發(fā)，敏捷外包都是可行的，甚至大型項目中應(yīng)用敏捷也是可行的。欲更多了解敏捷開發(fā)，可參考51CTO的初探敏捷開發(fā)專題。
【編輯推薦】
