從瀑布模型、極限編程到敏捷開發

從瀑布模型、極限編程到敏捷開發

--- 軟件開發管理者思惟的變化

Jack zhai

 

軟件開發是一種對人類智慧的管理，對人大腦思惟的「工廠化」管理。人是有感情的、有情緒的、變化的、相對獨立的工做單元，這與冰冷的機器是不可比的，因此在中國的歷史上，管理人是最難的工做；「學而優則仕」的觀點就是讓最聰明的人應該選出來作官，作官就是管理人的。軟件開發不只是代碼編程，而是人員的有效組織，如何既發揮人的主觀能動性，避免情緒變化對工做的影響，又可讓你們有效的交流，讓多個大腦的思路統一，快速完成目標呢？多年來軟件企業的管理者一直在不斷地探索。

另外有一個問題一直是軟件開發管理人員的心病：軟件是工具，開發的是客戶業務的應用，但客戶不瞭解軟件，開發者不瞭解業務，如何有效溝通是軟件質量的重大障礙。把開發者變成客戶業務的專家是個沒有辦法的辦法，讓軟件企業付出的代價也是昂貴的。

瀑布模型、極限編程、敏捷開發是有表明性的開發模式，在對開發者、客戶、最終的產品的關注上的變化，體現了軟件開發管理者在管理模式上的變化。

 

1、瀑布開發

瀑布模型(Waterfall Model)是Royce在1970年提出的，他把大型軟件開發分爲：分析與編程，象工廠流水線同樣把軟件開發過程分紅各類工序，而且每一個工序能夠根據軟件產品的規模、參與人員的多少進一步細分紅更細的工序。該模型很是符合軟件工程學的分層設計思路，因此成爲軟件開發企業使用最多的開發模型。

瀑布模型的特色：

一、               強調文檔，前一個階段的輸出就是下一個階段的輸入，文檔是個階段銜接的惟一信息。因此不少開發人員好象是在開發文檔，而不是開發軟件，由於要到開發的後期，才能夠看到軟件的「模樣」。

二、               沒有迭代與反饋。瀑布模型對反饋沒有涉及，因此對變化的客戶需求很是不容易適應，瀑布就意味着沒有回頭路。

三、               管理人員喜歡瀑布模型的緣由是把文檔理解爲開發的速度，能夠方便地界定不一樣階段的里程碑。

瀑布模型的用戶不少，也有一些反對的意見：

第1、瀑布模型不適合客戶需求不斷變化的軟件開發，尤爲是客戶的業務管理的軟件，業務隨着市場變化，而軟件初期的設計可能已經大大變化，然後期的需求更改爲本是開始的10倍基數。在ERP盛行的軟件市場裏，一方面市場帶動需求變化，另外一方面初期客戶對需求描述不清楚，都爲瀑布模型的使用團隊帶來困難。

第2、瀑布模型是一種軟件文檔的開發，把開發者變成流水線上的機器，大量重複性的工做讓編程人員提不起興趣，工做很枯燥，沒有激情，編程成了一種沒有創意的機械勞動，這讓一貫以高科技爲標誌的高級程序人員大爲惱火。

在這種背景下，極限編程(extreme Programming, XP)帶來了新鮮的空氣。

 

2、極限編程

極限編程誕生於一種增強開發者與用戶的溝通需求，讓客戶全面參與軟件的開發設計，保證變化的需求及時獲得修正。要讓客戶能方便地與開發人員溝通，必定要用客戶理解的語言，先測試再編碼就是先給客戶軟件的外部輪廓，客戶使用的功能展示，讓客戶感受到將來軟件的樣子，先測試再編碼與瀑布模型顯然是背道而馳的。同時，極限編程注重用戶反饋與讓客戶加入開發是一致的，讓客戶參與就是隨時反饋軟件是否符合客戶的要求。有了反饋，開發子過程變短，迭代也就很天然出現了，快速迭代，小版本發佈都讓開發過程變成更多的自反饋過程，有些象更加細化的快速模型法。固然極限編程還加入了不少激勵開發人員的「措施」，如結隊編程、40小時工做等。

極限編程是一種開發管理模式，它強調的重點是：

一、              角色定位：極限編程把客戶很是明確地加入到開發的團隊中，並參與平常開發與溝通會議。客戶是軟件的最終使用者，使用是否合意必定以客戶的意見爲準。不只讓客戶參與設計討論，並且讓客戶負責編寫擁護故事(User Story)，也就是功能需求，包括軟件要實現的功能以及完成功能的業務操做過程。用戶在軟件開發過程當中的責任被提到與開發者一樣的重要程度。

二、              敏捷開發：敏捷開發追求合做與響應變化。迭代就是縮短版本的發佈週期，縮短到周、日，完成一個小的功能模塊，能夠快速測試、並及時展示給客戶，以便及時反饋。小版本加快了客戶溝通反饋的頻率，功能簡單，在設計、文擋環節大大簡化。極限編程中文擋再也不重要的緣由就是由於每一個版本功能簡單，不須要複雜的設計過程。極限編程追求設計簡單，實現客戶要求便可，無需爲擴展考慮太多，由於客戶的新需求隨時能夠添加。

三、              追求價值：極限編程把軟件開發變成自我與管理的挑戰，追求溝通、簡單、反饋、勇氣，體現開發團隊的人員價值，激發參與者的情緒，最大限度地調動開發者的積極性，情緒高漲，認真投入，開發的軟件質量就大大提升。結對編程就是激發隊員才智的一種方式。

 

    極限編程把軟件開發過程從新定義爲聆聽、測試、編碼、設計的迭代循環過程，確立了測試->編碼->重構(設計)的軟件開發管理思路。

極限編程的12個實踐是極限編程者總結的實踐經典，是體現極限編程管理的原則，對極限編程具備指導性的意義，但並不是必定要徹底遵照12個實踐，主要看它給軟件過程管理帶來的價值。

一、              小版本。爲了高度迭代，與客戶展示開發的進展，小版本發佈是一個可交流的好辦法，客戶能夠針對性提出反饋。但小版本把模塊縮得很小，會影響軟件的總體思路連貫，因此小版本也須要整體合理的規劃。

二、              規劃遊戲。就是客戶需求，以客戶故事的形式，由客戶負責編寫。極限編程不講求統一的客戶需求收集，也不是由開發人員整理，而是採起讓客戶編寫，開發人員進行分析，設定優先級別，並進行技術實現。固然遊戲規則可進行屢次，每次迭代完畢後再行修改。客戶故事是開發人員與客戶溝通的焦點，也是版本設計的依據，因此其管理必定是有效的、溝通順暢的。

三、              現場客戶。極限編程要求客戶參與開發工做，客戶需求就是客戶負責編寫的，因此要求客戶在開發現場一塊兒工做，併爲每次迭代提供反饋。

四、              隱喻。隱喻是讓項目參與人員都必須對一些抽象的概念理解一致，也就是咱們常說的行業術語，由於業務自己的術語開發人員不熟悉，軟件開發的術語客戶不理解，所以開始要先明確雙方使用的隱喻，避免歧異。

五、              簡單設計。極限編程體現跟蹤客戶的需求變化，既然需求是變化的，因此對於目前的需求就沒必要過多地考慮擴展性的開發，講求簡單設計，實現目前需求便可。簡單設計的自己也爲短時間迭代提供了方便，若開發者考慮「通用」因素較多，增長了軟件的複雜度，開發的迭代週期就會加長。簡單設計包括四方面含義：1、經過測試。2、避免重複代碼。3、明確表達每步編碼的目的，代碼可讀性強。4、儘量少的對象類和方法。因爲採用簡單設計，因此極限編程沒有複雜的設計文檔要求。

六、              重構。重構是極限編程先測試後編碼的必然需求，爲了總體軟件能夠先進行測試，對於一些軟件要開發的模塊先簡單模擬，讓編譯經過，到達測試的目的。而後再對模塊具體「優化」，因此重構包括模塊代碼的優化與具體代碼的開發。重構是使用了「物理學」的一個概念，是在不影響物體外部特性的前提下，從新優化其內部的機構。這裏的外部特性就是保證測試的經過。

七、              測試驅動開發。極限編程是以測試開始的，爲了能夠展現客戶需求的實現，測試程序優先設計，測試是從客戶實用的角度出發，客戶實際使用的軟件界面着想，測試是客戶需求的直接表現，是客戶對軟件過程的理解。測試驅動開發，也就是客戶的需求驅動軟件的開發。

八、              持續集成。集成的理解就是提交軟件的展示，因爲採用測試驅動開發、小版本的方式，因此不斷集成(總體測試)是與客戶溝通的依據，也是讓客戶提出反饋意見的參照。持續集成也是完成階段開發任務的標誌。

九、              結對編程。這是極限編程最有爭議的實踐。就是兩個程序員合用一臺計算機編程，一個編碼，一個檢查，增長專人審計是爲了提供軟件編碼的質量。兩我的的角色常常變換，保持開發者的工做熱情。這種編程方式對培養新人或開發難度較大的軟件都有很是好的效果。

十、           代碼共有。在極限編程裏沒有嚴格文檔管理，代碼爲開發團隊共有，這樣有利於開發人員的流動管理，由於全部的人都熟悉全部的編碼。

十一、           編碼標準。編碼是開發團隊裏每一個人的工做，又沒有詳細的文檔，代碼的可讀性是很重要的，因此規定統一的標準和習慣是必要的，有些象編碼人員的隱喻。

十二、           每週40小時工做。極限編程認爲編程是愉快的工做，不輕易加班，今天的工做今天作，小版本的設計也爲了單位時間能夠完成的工做安排。

 

3、敏捷開發

極限編程的思想體現了適應客戶需求的快速變化，激發開發者的熱情，也是目前敏捷開發思惟的重要支持者。

2001年，17名編程大師分別表明極限編程、Scrum(「棒球」團隊開發模式)、特徵驅動開發、動態系統開發方法、自適應軟件開發、水晶方法、實用編程等開發流派，發表「敏捷軟件開發」宣言。敏捷軟件開發是一個開發軟件的管理新模式，用來替代以文件驅動開發的瀑布開發模式。敏捷方式也稱輕量級開發方法。敏捷軟件開發宣言內容：

²        個體和交互賽過過程和工具

²        能夠工做的軟件賽過面面具到的文檔

²        可戶合做賽過合同談判

²        響應變化賽過遵循計劃

敏捷開發集成了新型開發模式的共同特色，它重點強調：

1.         以人爲本，注重編程中人的自我特長髮揮。

2.         強調軟件開發的產品是軟件，而不是文檔。文檔是爲軟件開發服務的，而不是開發的主體。

3.         客戶與開發者的關係是協做，不是合約。開發者不是客戶業務的「專家」，要適應客戶的需求，是要客戶合做來闡述實際的需求細節，而不是爲了開發軟件，把開發人員變成客戶業務的專家，這是傳統開發模式或行業軟件開發企業的最大面臨問題。

4.         設計周密是爲了最終軟件的質量，但不代表設計比實現更重要，要適應客戶需求的不斷變化，設計也要不斷跟進，因此設計不能是「閉門造車」、「自我良好」，能不斷根據環境的變化，修改本身的設計，指導開發的方向是敏捷開發的目標。

敏捷開發避免了傳統瀑布方式的弊端，主要是吸取了各類新型開發模式的「動態」特性，關注點從文檔到開發者，管理方式也從工廠的流水線到團隊的自我放鬆式的組織。總結敏捷開發與瀑布模式的不一樣，主要是下面幾個「敏捷」的關注點：

²        迭代。軟件的功能是客戶的需求，界面的操做是客戶的「感受」，對迭代的強調是縮短了軟件版本的週期

²        客戶參與。以人爲本，客戶是軟件的使用者，是業務理解的專家，沒有客戶的參與，開發者很難理解客戶的真實需求

²        小版本。快速功能的展示，看似簡單，但對於複雜的客戶需求，合理地分割與整體上的統一，要很好地兩者兼顧是不容易的。

   

敏捷就是「快」，快才能夠適應目前社會的快節奏；要快就要發揮我的的個性思惟多一些，個性思惟的增多，雖然經過結隊編程、代碼共有、團隊替補等方式減小我的對軟件的影響力，但也會形成軟件開發繼承性的降低，所以敏捷開發是一個新的思路，但不是軟件開發的終極選擇。對於長時間、人數衆多的大型軟件應用的開發，文檔的管理與銜接做用仍是不可替代的。如何把敏捷的開發思路與傳統的「流水線工廠式」管理有機地結合，是軟件開發組織者面臨的新課題。