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

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

相對于重量級方法，軟件業(yè)一直有另一種聲音在，那就是輕量級方法（LightWeight），其目標是以較小的代價獲得重量級相當?shù)男Ч?P>

最負盛名的輕量級方法是XP。XP是ExtremeProgramming的縮寫，從字面上可以譯為極端編程。但是，XP并不僅僅是一種編程方法，也不是中文中理解的那種不可理喻的“極端”化做法。實際上，XP是一種審慎的（deliberate）、有紀律（disciplined）的軟件生產方法。XP（ExtremeProgramming）植根于上個世紀80年代后期的Smalltalk社區(qū)。90年代，KentBeck和WardCunningham把他們使用Smalltalk開發(fā)軟件的項目經驗總結和擴展，逐步形成了一種強調適應和以人為導向的軟件開發(fā)方法。

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

2001年2月，在美國猶他州的一個滑雪場，17位輕量級軟件開發(fā)方法的創(chuàng)始人和專家，包括KentBeck（ExtremeProgramming）、AlistairCockburn（CrystalMethodologies）、JimHighsmith（AdaptiveSoftwareDevelopment）等等，共同發(fā)布了“TheManifestoforAgileSoftwareDevelopment”（敏捷軟件開發(fā)宣言）。這表明，在軟業(yè)經歷了無數(shù)次的項目失敗之后，人們開始反思軟件開發(fā)的工程特性，反思計劃和控制的有效性，反思過去對于不確定性的態(tài)度和反應。敏捷終于為這個行業(yè)，以及這個行業(yè)中的一些人所認識、理解和推崇。

與會者之一MartineFowler在其后來的文章“TheNewMethodology”中這樣解釋重量級、輕量級和敏捷：

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

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

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

1.Crystal

Cystal事實上不是一種開發(fā)方法，而是一系列的方法。因為Crystal的發(fā)明人AlistairCockburn認為，不同類型的項目需要采用不同的方法。AlistairCockburn從兩個維度來劃分項目，一是項目規(guī)模，以人數(shù)計算；二是產品發(fā)生錯誤的后果，以嚴重性計算。

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

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

2.ASD

ASD（AdaptiveSoftwareDevelopment）的發(fā)明人JimHighsmith本來是一個傳統(tǒng)開發(fā)方法的工作者，他有多年的預測型方法的研究、教學和實施經驗，但后來，他發(fā)現(xiàn)這些預測型方法根本就存在很大缺陷，尤其不適合當前的軟件業(yè)務。

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

3.SCRUM

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

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

4.FDD

FDD（FeatureDrivenDevelopment）的發(fā)明人是JeffDeLuca和PeterCoad。FDD在OO社區(qū)較為人所知。FDD定義了5個流程，分別是DevelopanOverallModel、BuildaFeaturesList、PlanbyFeature、DesignbyFeature和BuildbyFeature。其中前3個流程是在項目開始就進行的，而后兩個則出現(xiàn)在每次迭代周期中。FDD的迭代周期是兩周。每個流程被劃分為不同的任務和相應的驗證標準。

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

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

來自：共創(chuàng)軟件