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