1991年秋，在美國勒海大學亞科卡學院的一份研究報告《21世紀美國製造業的戰略：一個工業主導的觀點》中，首次提出了敏捷競爭的概念。何謂敏捷（Agility）？對於企業而言，敏捷意味著企業能夠在顧客機會不斷變化、難以預測的競爭環境中贏利運營；對於個人而言，敏捷指在企業對難以預測的顧客機會做出反應，不斷重組其人力和技術資源的過程中，個人能夠對贏利底線做出貢獻，提高企業的淨收入。因此，敏捷可以看作是對變化和不確定的全面反應。

變化和不確定，對於軟體業來說，是多麼熟悉而又讓人煩惱的名詞。軟體工程自誕生以來，一直試圖透過技術和管理的手段來降低軟體專案的不確定性。在這個美好的願景指導下，專家們發明了結構化、發明了物件導向、發明了CMM，這些新的技術和方法的確有助於“軟體危機”的解決，促進了軟體業的發展；然而，超支、超時、低質量的老問題並未得到根本解決。為了對抗不確定，軟體開發越來越複雜，越來越龐大，傳統的重量級（Heavy Weight）方法的副作用也越來越明顯——組織臃腫、辦事低效、官僚主義...

相對於重量級方法，軟體業一直有另一種聲音在，那就是輕量級方法（Light Weight），其目標是以較小的代價獲得重量級相當的效果。

最負盛名的輕量級方法是XP。XP是Extreme Programming的縮寫，從字面上可以譯為極端程式設計。但是，XP並不僅僅是一種程式設計方法，也不是中文中理解的那種不可理喻的“極端”化做法。實際上，XP是一種審慎的（deliberate）、有紀律（disciplined）的軟體生產方法。XP（Extreme Programming）植根於上個世紀80年代後期的Smalltalk社群。90年代，Kent Beck和Ward Cunningham把他們使用Smalltalk開發軟體的專案經驗總結和擴充套件，逐步形成了一種強調適應和以人為導向的軟體開發方法。

XP的核心是四大價值，即改善溝通（communication），尋求簡單（simplicity），獲得反饋（feedback）和富有勇氣（courage）。在此基礎上，XP總結出了軟體生產的十餘條做法（practice），涉及軟體設計、測試、編碼、釋出等各個環節。與其它輕量級方法相比，XP獨一無二的突出了測試的重要性，甚至將測試作為整個開發的基礎，每個開發人員不僅要書寫軟體產品的程式碼，同時也必須書寫相應的測試程式碼；所有這些程式碼透過持續構建和整合（Continuous Build & Integration）為下一步的開發打定了一個高度穩定的基礎平臺。有了這樣的基礎平臺的保證，XP就可以實施軟體設計的再造（Refactoring）。XP的設計理念是，在每次迭代週期僅僅設計這次迭代所要求的產品功能，上次迭代週期中的設計透過Refactoring形成此次的設計。

2001年2月，在美國猶他州的一個滑雪場，17位輕量級軟體開發方法的創始人和專家，包括Kent Beck（Extreme Programming）、Alistair Cockburn（Crystal Methodologies）、Jim Highsmith（Adaptive Software Development）等等，共同釋出了“The Manifesto for Agile Software Development”（敏捷軟體開發宣言）。這表明，在軟業經歷了無數次的專案失敗之後，人們開始反思軟體開發的工程特性，反思計劃和控制的有效性，反思過去對於不確定性的態度和反應。敏捷終於為這個行業，以及這個行業中的一些人所認識、理解和推崇。

與會者之一Martine Fowler在其後來的文章“The New Methodology”中這樣解釋重量級、輕量級和敏捷：

輕量級與重量級的差異來自於人們對兩種方法的文件數量的直觀感受，即輕量級方法較少產生和依賴於龐大的文件，但這只是一個表面現象；在諸多的輕量級方法之間存在著很多相通的地方，敏捷更恰當的表達了這些輕量級方法的最根本之處。

首先，敏捷強調適應，而非預測。重量級方法花費大量的人力物力，試圖制訂詳細的計劃來指導長期的工作，而一旦情況變化，那麼計劃就不再適用。因此本質上重量級方法是抵制變化的，而敏捷方法則強調適應變化。其次，敏捷方法以人為中心，而非以流程為中心（即以事為中心）。敏捷方法強調軟體開發應順乎本心（work with people’s nature ），軟體開發應帶來樂趣。

敏捷流程（Agile Process）汲取眾多輕量級方法的“精華”，更加強調對變化的適應和對人性的關注。除了上面介紹的XP以外，其他知名的敏捷流程包括：

1.Crystal

Cystal事實上不是一種開發方法，而是一系列的方法。因為Crystal的發明人Alistair Cockburn認為，不同型別的專案需要採用不同的方法。Alistair Cockburn從兩個維度來劃分專案，一是專案規模，以人數計算；二是產品發生錯誤的後果，以嚴重性計算。

Crystal方法集也形成於90年代，當時，Cockburn接受了IBM的任務去寫一些關於開發方法的東西。相對而言，Crystal的個人色彩要淡些，因為它不僅來源於Cockburn的個人經驗，而且也來源於Cockburn走訪的很多不同的專案；而Cockburn本人也較為思想開放，樂於接受“異見”。

在以人為導向上，Crystal和其他敏捷方法有些差異。在Cockburn看來，自由是人之本性，要人遵守紀律總是有難度的；因此，要在工作生產率和流程的紀律性之間作一權衡。流程要易於遵照執行，而這是以犧牲生產率為代價的。Cockburn認為， XP的流程規範仍太複雜和難於執行，而採用Crystal雖然生產率不如XP，但開發人員更樂於採用。Cystal也強調在每個迭代後的Review，並以此進行Cystal方法的自身改進。

2. ASD

ASD（Adaptive Software Development）的發明人Jim Highsmith本來是一個傳統開發方法的工作者，他有多年的預測型方法的研究、教學和實施經驗，但後來，他發現這些預測型方法根本就存在很大缺陷，尤其不適合當前的軟體業務。

ASD強調開發方法的適應性（Adaptive），這一思想來源於複雜系統的混沌理論。ASD不象其他方法那樣有很多具體的實踐做法，它更側重為ASD的重要性提供最根本的基礎，並從更高的組織和管理層次來闡述開發方法為什麼要具備適應性。

3. SCRUM

SCRUM同樣也包括了很多具體做法，這些做法並無多少特別之處，但多數有一個“怪異”的名稱。比如，SCRUM將開發過程劃分為30天的迭代週期，每個迭代週期叫做一個Sprint；每天有一個15分鐘的短會，用來決定第二天的任務安排，這樣的短會就叫做scrum。

SCRUM較為有特色的，是它特別強調開發隊伍和管理層的交流協作。每天，開發隊伍都會向管理層彙報進度，如果有問題，也會向管理層要求幫助解決。

4. FDD

FDD（Feature Driven Development）的發明人是Jeff De Luca和Peter Coad。FDD在OO社群較為人所知。FDD定義了5個流程，分別是Develop an Overall Model、Build a Features List、Plan by Feature、Design by Feature和Build by Feature。其中前3個流程是在專案開始就進行的，而後兩個則出現在每次迭代週期中。FDD的迭代週期是兩週。每個流程被劃分為不同的任務和相應的驗證標準。

開發人員被歸為兩種，一種是主程式設計師，另一種是class所有者。主程式設計師不作具體的程式設計工作，但要負責將Feature和Class對應起來，並充當開發協調者、設計者、技術支援和指導者等；class所有者則進行實際的程式設計。

在軟體業，敏捷流程還猶如星星之火，特別是在國內，敏捷流程還鮮為人知。在即將到來的未來，敏捷流程將何去何從，中國的軟體從業者又將在其中扮演何種的角色，套用一句中國的古話，“路漫漫其修遠兮，吾將上下而求索”。 [@more@]

軟體專案管理中的“敏捷流程”（轉）

相關文章