20世紀60年代開始的軟件危機引發了人們對軟件開發的思考，并由此誕生了《軟件工程》這門學科。它將軟件開發分為需求分析、設計、編碼、測試、維 護等幾個階段的瀑布式開發軟件方法至今仍然在大多數軟件開發組織沿用。然而，《軟件工程》學及其瀑布式開發方法并沒有徹底解決軟件危機。如何滿足不斷變化 的軟件需求一直就是傳統軟件開發方法無法解決的難題。

　　而敏捷開發正是為了解決上述問題而提出，從2001 年敏捷開發方法正式出現以來，越來越多的開發人員開始接受這一方法，市場也出現了一批以敏捷開發為主要方法的軟件開發和咨詢服務公司。 ThoughtWorks公司就是其中的佼佼者，日前，本報記者專訪了ThoughtWorks公司中國區總經理郭曉，請他就如何實施敏捷開發等問題進行 介紹。

　　顛覆傳統軟件開發方法

　　敏捷開發作為一種開發方法始于2001年，當時全球非常有名的10多位軟件開發的大師集中在一起，對當時出現的一些新的編程方法進行歸納，并用敏捷這個詞來概括這幾種類似的方法流程。

　　“只要你的軟件開發方法遵循敏捷的四條原則（即個體和交互勝過過程和工具、工作的軟件勝過面面俱到的文檔、客戶合作勝過合同談判、響應變化勝過遵循計劃）， 就算是敏捷一類的開發方法。比如ThoughtWorks自身的實踐就集成了Scrum和極限編程，是這兩種方法的組合體。” 郭曉告訴記者。

　　郭曉從20世紀90年代開始接觸極限編程等敏捷開發方法，其后的10多年一直從事敏捷開發，后來又從事軟件開發的管理工作，這使得他可以從更高的層次上來看敏捷這種對大多數程序員仍然比較陌生的開發方法。郭曉認為，敏捷宣言最為核心的思想有兩點。

　　一個是人比流程重要。敏捷和傳統的開發方式最大的不同點在于，傳統的軟件開發方式遵循了20世紀大規模工業化生產的思路: 每個人在這個流水線上負責一項工作，只要流程設計得完美，人就不重要，這也是《軟件工程》學所追求的一種境界。而實際上，軟件開發是一個知識性、創造性的 工作，是不可能完全模仿流水線的。敏捷開發強調一批有軟件開發能力的人組成一個團隊，至于團隊使用哪種敏捷方法，完全由團隊根據自己的特點來決定。它強調 流程是為人服務的，重視發揮人最大的創造力。

　　另一個是能夠工作的軟件其價值要比文檔重要。傳統的軟件開發 方法分為需求分析、設計、編碼等不同的階段，分別由不同的人負責，文檔在其中扮演驅動力的角色，不同角色通過文檔來進行知識傳遞和交互。而敏捷開發認為文 檔是為軟件服務的，強調通過快速迭代和持續集成，讓各種不同角色的人員可以基于目前已經開發出的軟件進行直接溝通交流。這就帶來了兩個好處: 快速反饋和緊密的協作。

　　“重視交付、緊密協作、快速反饋正是敏捷的特殊之處，這些特點保證了敏捷開發能夠滿足變化的需求。”郭曉說，“而用傳統的軟件開發方法開發出的軟件成功與否很大程度上建立在需求分析是否有足夠的遠見，能把未來的需求都考慮在內，而實際上，這幾乎是不可能的。”

　　結對編程有必要嗎？

　　說起敏捷開發也就不能不提到它的結對編程，敏捷開發要求代碼的編寫應該同時有兩人參與，兩人共同使用同一臺電腦、一個鍵盤和一個鼠標。在采訪過程中，記者特意向郭曉提出了這一疑問: 結對編程有必要嗎？

　　郭曉告訴記者，結對編程在大多數情況下是適合的。在正常情況下，一個程序員并不是整天都在敲鍵盤輸代碼，他要思考，實際上真正敲鍵盤的時間只有 20%～30%。因此，兩個人共同使用同一套電腦，并不意味著效率下降。敏捷開發要求一個人在編寫代碼的同時，另一個人對這個代碼進行評審，評估代碼是否 正確、是否有更佳的編寫方法，然后相互溝通交流。這樣寫出的代碼質量要遠遠高于單個人寫。

　　結對編程的另一個好處是降低了項目風險。現代軟件開發分工很細，每個軟件開發人員獨立負責一部分，一旦程序員離職或者換崗對于軟件開發會很不利。而結對編程時，每段代碼都至少有兩個人了解，人員變動給項目帶來的風險要低得多。

　　結對編程還有一個好處是有助于傳、幫、帶。通過結對編程，項目新來者可以很容易地融入進來，而這個過程不損失代碼數量，還能夠帶來知識的共享等好處。

　　郭曉補充說，雖然敏捷開發強調敏捷編程，但并不是機械地要求任何代碼都要結對完成。對于一些很簡單、眾所周知的代碼，也可以只由一個人負責。

　　實際上，記者曾參觀過ThoughtWorks公司的軟件開發現場。記者看到，在大多數公司常見的格子間不見了，取而代之的是一個個長方形的大圓桌。這里的 開發人員以兩個人為一組，雖然兩個人面前各有一個顯示器，但都接在同一個主機上，其中一個人在編代碼，另一個在進行評審。

　　“我們的實際經驗也證明了這種方法的先進性。我們有員工反映說，結對編程增加了他們的工作壓力，因為結對時，兩人幾乎不再會做與工作無關的事情了。” 郭曉笑著說。

　　敏捷開發能走多遠？

　　敏捷作為一種軟件開發方法其先進性和合理性毋庸置疑，但是這種方法的適用范圍如何？它適合大型軟件開發組織采用嗎？

　　“敏捷開發從2001年正式提出來的時候就有人提出，它不適合于大型軟件開發團隊、不適合于周期長的項目。事實上，這些年來，這些說法正在不斷地被突破。”郭曉說，“當然敏捷本身也在不斷擴展，從而能夠適應越來越廣的領域。”

　　郭曉介紹說，ThoughtWorks公司自己就曾在100人的項目上采用過敏捷開發。實際上，ThoughtWorks就是因此才和敏捷開發結緣的。

　　1999 年的ThoughtWorks還只是一個從事軟件開發的公司。當時有一個100多人參與的大項目陷入了被動，不得已請來了業界頗負盛名、后來被稱為敏捷開 發“教父”的Martin Fowler和Ward Cunningham來做咨詢工作。他們通過引入敏捷開發讓公司擺脫了困境。這也讓ThoughtWorks感受到敏捷開發方法的魔力。另一個例子是英國 電訊（BT），它在印度有一個1.8萬人的開發團隊，在英國本土和其他地方也有幾萬人的開發團隊，它現在幾乎所有的軟件項目都是用敏捷的方法來開發的。

　　當然，敏捷開發作為一種軟件開發方法也并不是萬能的，也存在一些局限。換句話說，要保證敏捷開發成功需要一些前提條件。

　　郭曉說: “敏捷開發要和客戶緊密地溝通，才能夠不斷地獲得客戶的反饋。而實際上，通常客戶很忙，抽不出這么多時間。另外，還有一些產品開發依賴于產品經理來了解需求，而他其實并不是真正的客戶，這給敏捷開發帶來困難。”

　　此外，客戶對開發方的充分信任也是敏捷開發成功很有必要的一個條件。敏捷開發最佳的應用場景是用戶不斷提出新的需求，而項目合同價格也隨著需求不斷調整。郭 曉說，這在實際開發過程就是一個問題，特別是第一次合作時，客戶就會很擔心項目的最終成本。而如果是公司自己的開發隊伍，這將不是問題。從這個角度上說， 敏捷開發最大的市場是公司內部的開發團隊。

　　“不管怎么說，這幾年我們已經明顯感受到接受敏捷開發思想的人越來越多，從要求我們提供咨詢服務的客戶數量可以看出這種趨勢。我們相信，敏捷開發一定會確立自己在軟件開發領域的一席之地的。”郭曉信心十足地說。