本文是Taskcity（一個提供敏捷管理工具以及為敏捷外包提供支援的公司）對敏捷外包的一些看法，對於理解敏捷的一些基礎概念還是有一些幫助的。

Agile，敏捷開發被越來越多的開發企業和團隊所接受。敏捷恰當，可以顯著提高開發效率和產品的開發週期。問題是，“敏捷”方法是否能適用到軟體外包行業，這個爭論 由來已久，各有說辭。最典型的爭論就是，作為外包的一個顯著特點，使用者和開發團隊是相對遠端，甚至開發團隊內部也存在遠端的問題。如果一個團隊不能身處一室，其中強調的溝通和互動是否能夠得到有效的執行，是一個大問題。

傳統的外包商業環境，是客戶和服務提供方達成一個長期的合同，基於一個相對較長的階段，提供穩定的外包服務支援。現在，越來越多的企業客戶開始考慮將外包 專案劃分為小的可執行單位。風險可控，操作靈活。而服務提供方相對也達成了這個共識。其實，這兩種情況，如果通過敏捷的開發模式，在一個長期的合作過程 中，大家會發現，Agile不僅可行，而且的確能形成一個雙贏的局面。一起來看看我們的發現吧。

方法恰到好處

如果我們追求看到一個專案完成的效率和效果，敏捷開發其實優於傳統的開發模式，即便對於初次接觸這個概念的發包客戶亦如此。我們大家都知道，在很多情況 下，發包客戶和服務提供方在涉足將專案外包出去開發之前，都擁有自己比較熟悉的開發模式和方法。敏捷開發或者說增量開發，可以讓雙方很輕易的統一到一個介面。傳統的開發方法基本上都是基於一個反覆推敲的合同，合同中對於功能設計以及權利義務定義原則上都進行了仔細的定義。但是，根本的問題是，很多使用者在項 目開始前，甚至開始的初期都沒有一個明確的，或者說準確的描述。這樣，很多時候，客戶為了保護自己的利益，會盡可能多的新增功能到這個專案書中。而開發服 務提供方考慮的是如何在自己的成本控制內得到儘可能多的盈利。在一開始，其實就為雙方日後的糾紛埋下了種子。我們能看到，在傳統的開發外包中，相當比例的 專案最後，即便完成交付，完成支付，最後雙方的心情都是不太好。敏捷開發強調了階段性交付，增量開發，使用者互動。最後的交付物有時和原始的設計已經有了很 大的出入，但是客戶貫穿了整個開發的週期，瞭解了所有的變動以及緣由，其滿意度甚至超過一個100%吻合的交付結果。使用者的滿意度和開發完成的程式碼量不是 直接的因果關係。而在軟體外包行業中的同行們都知道，一個滿意的客戶意味著可能的後續專案，而這也是服務提供方最希望看到的結果。

溝通的威力

肖伯納有一句名言“England and America are two countries divided by a common language。”意思是英國和美國是被一個相同的語言所分隔的兩個國家。這裡不是指的地理上的分隔，而是文化溝通上的差異，即便他們都說一種語言。英 美尚如此，何況作為一個典型東方文化代表的中國和我們的歐美客戶呢？不同的時區，不同的文化，不同的工作方法和原則，導致溝通成為了我們進行海外外包的一 個瓶頸。敏捷開發既強調了溝通，又為順暢的溝通提供了方法和指導。其中持續的交付實際是在用實實在在的形式進行了專案的溝通，從而降低了最後的交付風險。 想想吧，作為傳統開發模式，比如一個瀑布式的開發，六個月後，客戶才能第一眼看到自己想要的產品，這裡面能產生錯愕的概率有多大，大家可以想象一下。

迭代是趨於完美的過程

羅馬不是一天建成的。不要嘗試對完美的一步到位，除非你的使用者願意犧牲寶貴的進入市場的時機。外包開發不象是一個公司內部的開發團隊的 管理模式，對於離岸外包而言，雙方遠隔萬里。所以我們的建議就是，只用盡最大可能不斷地從客戶那裡得到程序中的反饋，進而對開發加以修正，才不會出現最終 和使用者意願的大偏差。在雙方可以接受的情況下，定義一個一個短促有效的迭代過程，第一時間發現問題，放到下一個迭代中去解決。一個典型的迭代包括計劃-設 計-反饋-執行（PDCA）。

勇於面對改變

需求變更在整個軟體開發的生命週期中是一個永恆的話題。也是客戶與服務提供方最糾纏不清之所在。改變的導火索可以來自方方面面，既有可 能是一覺醒來後的靈光一現，也有可能是來自客戶外部商業環境的改變。既然是現實，就接受它吧。當然，處理得當，這種變化可能協助雙方得到一個更優秀的軟 件，也能讓客戶對你的快速應變產生好感。否則，如果固守原始的設計稿件，或者永遠作為一個新功能要求追加資金，有可能得到一個Case，卻失去一個使用者。 另外，我們總是陷在一個自己預設的陷阱裡，客戶的要求改變永遠是對功能的增加。其實，一個過程中的再設計，有可能會降低開發的成本。

質量保證，真的嗎？

聽起來像是玩笑。敏捷開發這種快速交付，還能保證質量，象是天方夜譚。其實不然。快速交付，讓使用者能夠儘快試用你的功能，儘快發現問 題，就整個開發週期而言，整體質量一定會得到提升。在傳統開發模式中，我們都會或多或少遇到這樣的情況，因為開發時間的拖延（總是會拖延，這不可是玩 笑！），測試時間永遠是第一個被壓縮的階段。結果可想而知。更多的迭代引入了更多的測試周期和時間。

事實上敏捷開發，敏捷外包都是可行的，甚至大型專案中應用敏捷也是可行的。欲更多瞭解敏捷開發，可參考51CTO的初探敏捷開發專題。