從瀑布模型到敏捷開發——認識論決定行爲

   技術交流會中，讓我印象最深的是：大勇學長和丹姐在切磋實際項目中用到的「敏捷開發」，後來由向陽學長對比兩人的觀點發問「敏捷開發和瀑布模型的優缺點？人員要求？流程？」最終由咱們敬愛的米老師作高層次的總結。

 

    下面，本人根據學長們的建議，並參閱網上資源對「敏捷開發和瀑布模型作對比分析」

 

軟件開發模型的由來

    20實際60年代中期，人們在軟件開發過程和維護中所遇到的問題被稱做是「軟件危機」。

    1968年，在德國召開的NATO（北大西洋公約組織），首次提出「軟件工程」的概念，但願能用工程化的原則和方法來克服軟件危機。

    在此以後，人們開展了軟件模型、軟件方法、工具與環境的研究，提出了瀑布模型、演化模型、螺旋模型和噴泉模型等開發模型，出現了面向數據流方法、面向數據結構的方法、面型對象的開發方法，以及一批CASE（計算機輔助的軟件工程）工程和環境。

 

瀑布模型

    1970年WinSTon Royce提出了著名的"瀑布模型"，將軟件生命週期劃分爲制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，而且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。

   

      瀑布模型的特色：

一、各階段劃分很明確，便於項目經理對進度的把控，可是缺少靈活性。

二、適用於需求很明確的項目，所以對於客戶需求的變化很難適應。

三、以文檔做爲驅動，做爲每一階段審覈的標準，同時極大地增長了工做量。

四、強調了每一個階段的嚴格性，只有前一階段經過審覈才能進入下一階段的設計。開發前期良好需求說明，是最終系統正確性和完整性的保證。

五、因爲開發模型是線性的，早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果。

六、用戶只有等到末期才能見到開發成果。

 

由瀑布模型引入敏捷開發

    敏捷開發是一種從1990年代開始逐漸引發普遍關注的一些新型軟件開發方法，是一種應對快速變化的需求的一種軟件開發能力。相對於"非敏捷"，更強調程序員團隊與業務專家之間的緊密協做、面對面的溝通（認爲比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、可以很好地適應需求變化的代碼編寫和團隊組織方法，也更注重作爲軟件開發中人的做用。

 

什麼是敏捷開發？

    一羣開發經驗豐富和才華橫溢的開發人員經過關注其餘公司和別的開發團隊而且結合自身的項目經驗，建立了敏捷開發宣言，讓軟件開發工做變的更容易更輕鬆：

 

1. 我的和交互重於流程和工具
2. 有效的軟件重於全面的文檔
3. 客戶合做重於合同談判
4. 因時制宜重於按步就班

 

 

  敏捷開發的優點？

一、以客戶滿意度爲主。客戶會看到產品設計的每一步並在此基礎上作出反饋，這時候你須要迅速的作出調整。

二、擁抱變化。客戶最關心的是設計出的軟件可以知足其需求便阿虎，所以這就須要開發人員從客戶那裏獲得什麼

三、就要迅速實現什麼。這樣軟件的每一個子項目都會根據需求進行調整，並不會對其它子項目產生很差的影響。

四、頻繁交付。從幾周到幾個月應該交付更新，時間越短越好。及時交付客戶維繫好的客戶關係，並根據客戶反饋的信息，並做出相應的調整。

五、面對面的交流。因爲領域的區別，客戶只是業務瞭解，而軟件開發人員只對軟件熟悉，這就可能致使溝通之間出現理解誤差，由於經常在一塊兒工做顯得很必然。

 

瀑布模型和敏捷開發對比分析圖：

 總結：

     「敏捷」就是快，是一種新的思路。極大地發揮人的創造力，只有快才能夠適應社會的節奏。而對於需求明確的大型軟件的應用開發，文檔的管理與銜接做用是不可替代的。

     至於選擇哪種開發模型，這取決於項目的規模、開發的工期、領導者的素質……。瀑布模型和敏捷開發思想並非兩者只選其一的關係，還可能把敏捷開發的思想融入到「流水線工廠式」的管理中。

      只有認真分析環境因素（外界+人員素質自己）的變化，纔可以選擇最適宜的開發方式。要知道，最適合的纔是最好的。這就是米老師常說的「認識論決定一我的的行爲，決定你的將來發展方式，會不會少走彎路」。