軟件開發模式：瀑布與敏捷對比

在軟件開發時，常常面對的第一個項目實現決策是「咱們應該使用哪一種開發方法?」這是一個引發不少討論(和激烈辯論)的話題。若是您之前沒有使用過這種方法，那麼適當瞭解開發方法和理論是必要的;簡單地說，這是一種組織軟件開發工做的方法。這與項目管理的風格或特定的技術方法無關，儘管您常常會聽到這些術語混在一塊兒或互換使用。最流行的兩種基本方法是:瀑布開發和敏捷開發。這兩種方法都是可用的、成熟的方法。

如今，提及敏捷開發（Agile Model）和瀑布開發（Waterfall Model）模式，不少人認爲敏捷開發是將來的項目實施的趨勢，瀑布實施太老土已通過時了。另外確實一些跨國企業如索尼，聯想也在使用敏捷的方式實施一些項目。但實際上咱們看到絕大多數公司仍是依然在採用瀑布的方式實施項目。本文主要簡單介紹敏捷和瀑布的區別和優劣。

敏捷開發和瀑布開發

一、瀑布模型
瀑布模型是一種項目分解爲有限的階段來開發軟件的方法。只有在審查並驗證其前一階段時，開發纔會應進入下一階段。在瀑布模型中，階段不重疊。在這種方法中，事件的順序是這樣的:

• 收集和記錄需求
• 設計
• 代碼和單元測試
• 執行系統測試
• 執行用戶驗收測試(UAT)
• 解決任何問題
• 交付成品
  
  對於瀑布的開發模型來看，彷佛依然具有很可靠的工做邏輯，一個工程或項目分爲多個階段，每個階段都投入相應的資源，來完成本階段的工做。每個階段到下一個階段，都有明確的輸入輸出產物，不一樣的階段根據本身所需的輸入，進行工做活動以後，產生本身階段的產出，投入到下一個階段的工做中。若是不放心的話，每個階段還能夠增長一個審批環節，讓每個環節均可以通過可靠的審批以後，再投入到下一個環節當中。
  
  SDLC瀑布模型通常用於這些狀況：要求穩定且不常常更改；應用程序很小；沒有不明白或不明確的要求；環境穩定；使用的工具和技術是穩定的；不是動態的；資源可用。

二、敏捷模型
敏捷是一種迭代的、基於團隊的開發方法。這種方法強調以完整的功能組件快速交付應用程序。全部的時間都被「固定時間盒」劃分爲「衝刺（一般稱迭代）」階段。而不是建立任務和時間表。每一個迭代週期都有一個定義的持續時間(一般以周爲單位)，其中包含在迭代開始時計劃的可交付成果的運行列表。交付物根據客戶肯定的業務價值進行優先級排序。若是迭代中全部計劃的工做都不能完成，那麼工做將被從新排序，這些信息將用於將來的迭代計劃。當工做完成時，項目團隊和客戶能夠經過每日構建和迭代演示對其進行審查和評估。敏捷依賴於整個項目中很是高水平的客戶參與，特別是在這些評審期間。

在敏捷看來，不少狀況下面，咱們都沒法去了解到所有的內容，或者即便是瞭解到，咱們也不能保證這些內容是不會變化的。因此先根據主路徑，完成主要功能後，咱們再經過不斷地迭代，去完善咱們的工做，這樣當咱們產生變化的時候，咱們推翻的工做量也是少許的，能夠很快的去完成新的需求變動。經過這樣的不斷地變動、重構，咱們能夠得到一個相對客戶滿意的產品。

不少支持敏捷的同窗會說，與瀑布方法相比，敏捷風險的風險要小得多。由於其專一於交付通過充分測試的獨立、有價值的小功能。所以分散了風險——若是一個功能出錯了，它不該該影響另外一個功能。在這一方面，咱們仍然在迭代中計劃咱們的工做，而且咱們仍然會在每次迭代的末尾發佈。而瀑布缺少與業務的溝通和迭代次數，因此若是在項目的後期才發現要更改需求的話，則項目可能會失敗或須要從新啓動。這張圖好像也解釋了瀑布開發常常所面臨的困境。

在高舉效率與擁抱變化的大旗之下，彷佛敏捷模式，就是最好的開發模式。與之相比的是瀑布模式，在這樣的呼喊之中，顯得有些沒法跟得上步伐，體現的是陳舊、死板的。

「瀑布」對「敏捷」的駁斥

敏捷自己不是項目管理框架，也不是「方法論」。它是一套與產品開發相關的原則和價值，特別是互聯網產品常常會採用敏捷的方法來進行開發。可是，有一些基於敏捷原則的方法，這些方法是產品開發方法，而不是項目管理框架。

說到需求變動，瀑布也能夠走需求變動，提變動申請，按照環節一步一步走，去規劃工做量。雖然比敏捷是要慢一些，可是我整個流程是可靠的！爲何就說瀑布是死板的，不符合時代的呢？

彷佛瀑布的作法也沒有錯誤，咱們何不按照這樣的步驟，來完成咱們的工做呢？這樣的過程聽起來是如此的可靠。看，我有明確的階段；看，我有明確的審批；看，我有明確的變動流程。以瀑布模式進行開發的項目有這麼多，已經證實了這是一個有效的實施方法，難道不是麼？

另外被敏捷所詬病的瀑布項目常常失敗一般是發生了很是嚴重的錯誤狀況下才會產生。實際上只有在對項目的控制不好的狀況下才會發生這種狀況。瀑布型項目沒有迭代和用戶的屢次反饋也是不正確的 - 不少項目能夠經過產品原型圖的方式和業務部門確認操做的流程，只是不少項目中並無使用這種方法。

焦點碰撞

敏捷模式，兩週一個迭代，每一個迭代都能進行必定功能模塊的交付，讓用戶更早的看到交付物，雖然只有部分，也可讓用戶來提出本身的見解，產生變動的時候，開發人員也能夠在下個迭代中進行修改，讓用戶進行再次的確認。

從這樣看來，二者的碰撞就是在交付的及時性上與面對變動的成本上，所看到有極大的變化。瀑布在交付階段比較靠後，交付的模塊比較完整，在面對變動的時候，變動影響範圍就比較大，變動的成本就極大。問題發現的階段越靠後，解決問題所須要付出的成本就更高。這樣，就體現出來了敏捷對瀑布在這樣的情景下面的優點。

時間和成本，看起來就是敏捷和瀑布在選擇時主要考慮的兩個方面。將來能更好的指導將來的選擇，下面還列出了更詳細的敏捷和瀑布的優劣勢。

敏捷開發的優點：
• 開發的階段性成果會在開發過程當中儘早的進行審查，項目的風險會下降；
• 適用於需求不明確狀況，由於需求不明確，因此須要在不斷迭代的過程當中來逐步理清需求。
• 靈活性較高，幾乎能夠在任什麼時候間進行需求變動；
• 敏捷鼓勵開發人員與業務用戶之間進行多頻次的溝通，業務用戶的不合理需求以及開發人員的錯誤理解都會在這些頻繁的溝通中進行不斷審查和更新，
• 敏捷的協做一般要高得多，一般能開發出更高質量的產品；
• 適用於快速變化的項目，特別是面向前端業務人員的CRM系統項目更容易根據業務的變化而變化。

I 敏捷開發的劣勢：
• 敏捷的概念接受度還不算過高，初次嘗試可能不會很是成功；
• 最終交付的內容沒法預測，預期和實際完成的內容常常會有很大差別；
• 敏捷須要高水平的協做以及開發人員和用戶之間的按期溝通。 業務和IT人員在溝通前須要作大量的準備工做，但不少狀況下業務的溝通時間沒法保證；
• 當存在乙方供應商的狀況，敏捷會面臨更大的挑戰性。 客戶一般但願儘早瞭解他們的項目投入。 預估項目時間和成本難度較高；
• 在敏捷項目中，最大的問題多是業務部門永遠不但願有最終的截止時間。

I 瀑布開發的優點：
• 在管理良好的項目中，瀑布能夠在早期提供交付的信心；
• 項目團隊成員不須要在同一地點頻繁溝通；
• 在須要大量的設計或分析的狀況下瀑布是一種更合適的方法；
• 若是在基本產品開發以外存在許多接口和依賴關係，瀑布式項目會使用工具來建模和管理這些接口和依賴關係。

I 瀑布開發的劣勢：
• 許多企業和業務人員確實不容易在前期定義清楚需求，早期計劃中所依據的假設需求可能存在很大風險；
• 溝通的風險要高得多 - 特別是不少項目都是前期單向的溝通，後期項目和業務人員的預期差異很大；
• 瀑布項目的風險通常都很高，由於基於無效假設基礎上的需求可能會讓項目無限度擴大。 因此你會看到不少瀑布項目都出現成本超出預算或延遲的狀況。

結論：

敏捷和瀑布的實施方法差異仍是很大的。如今，瀑布幾乎能夠應用於任何類型的項目，尤爲是大型的項目。敏捷方法在這兩年來愈來愈受歡迎，咱們開始看到企業(甚至國防部和聯邦機構)中大量採用各類敏捷方法，尤爲是當前SaaS軟件當道，如Salesforce、SAP等這樣自帶開發平臺的SaaS產品能夠很是容易的搭建初始原型並進行快速迭代。但總的來講敏捷並不能徹底替代瀑布，它只是給了咱們另一種好的選擇。

如今，對於組織來講，將敏捷和瀑布方法結合在一塊兒的混合敏捷方法也很常見。一旦咱們決定了使用哪種基本方法，咱們就能夠進一步細化過程以最適合咱們的項目目標。最後，儘管咱們工做的方式很重要，可是交付一個可靠的、可維護的、知足客戶需求的產品纔是最重要的。

轉載請註明出處：怡海軟件（http://www.frensworkz.com/）