在軟體開發時，經常面對的第一個專案實現決策是“我們應該使用哪種開發方法?”這是一個引起很多討論(和激烈辯論)的話題。如果您以前沒有使用過這種方法，那麼適當瞭解開發方法和理論是必要的;簡單地說，這是一種組織軟體開發工作的方法。這與專案管理的風格或特定的技術方法無關，儘管您經常會聽到這些術語混在一起或互換使用。最流行的兩種基本方法是:瀑布開發和敏捷開發。這兩種方法都是可用的、成熟的方法。
現在，說起敏捷開發（Agile Model）和瀑布開發（Waterfall Model）模式，很多人認為敏捷開發是未來的專案實施的趨勢，瀑布實施太老土已經過時了。另外確實一些跨國企業如索尼，聯想也在使用敏捷的方式實施一些專案。但實際上我們看到絕大多數公司還是依然在採用瀑布的方式實施專案。本文主要簡單介紹敏捷和瀑布的區別和優劣。
敏捷開發和瀑布開發
1、瀑布模型
瀑布模型是一種專案分解為有限的階段來開發軟體的方法。只有在審查並驗證其前一階段時，開發才會應進入下一階段。在瀑布模型中，階段不重疊。在這種方法中，事件的順序是這樣的:
- 收集和記錄需求
- 設計
- 程式碼和單元測試
- 執行系統測試
- 執行使用者驗收測試(UAT)
- 解決任何問題
-
交付成品
對於瀑布的開發模型來看，似乎依然具備很可靠的工作邏輯，一個工程或專案分為多個階段，每一個階段都投入相應的資源，來完成本階段的工作。每一個階段到下一個階段，都有明確的輸入輸出產物，不同的階段根據自己所需的輸入，進行工作活動之後，產生自己階段的產出，投入到下一個階段的工作中。如果不放心的話，每一個階段還可以增加一個審批環節，讓每一個環節都可以經過可靠的審批之後，再投入到下一個環節當中。
SDLC瀑布模型一般用於這些情況：要求穩定且不經常更改；應用程式很小；沒有不明白或不明確的要求；環境穩定；使用的工具和技術是穩定的；不是動態的；資源可用。
2、敏捷模型
敏捷是一種迭代的、基於團隊的開發方法。這種方法強調以完整的功能元件快速交付應用程式。所有的時間都被“固定時間盒”劃分為“衝刺（通常稱迭代）”階段。而不是建立任務和時間表。每個迭代週期都有一個定義的持續時間(通常以周為單位)，其中包含在迭代開始時計劃的可交付成果的執行列表。交付物根據客戶確定的業務價值進行優先順序排序。如果迭代中所有計劃的工作都不能完成，那麼工作將被重新排序，這些資訊將用於未來的迭代計劃。當工作完成時，專案團隊和客戶可以透過每日構建和迭代演示對其進行審查和評估。敏捷依賴於整個專案中非常高水平的客戶參與，特別是在這些評審期間。
在敏捷看來，很多情況下面，我們都無法去了解到全部的內容，或者即使是瞭解到，我們也不能保證這些內容是不會變化的。所以先根據主路徑，完成主要功能後，我們再透過不斷地迭代，去完善我們的工作，這樣當我們產生變化的時候，我們推翻的工作量也是少量的，可以很快的去完成新的需求變更。透過這樣的不斷地變更、重構，我們可以獲得一個相對客戶滿意的產品。
很多支援敏捷的同學會說，與瀑布方法相比，敏捷風險的風險要小得多。因為其專注於交付經過充分測試的獨立、有價值的小功能。因此分散了風險——如果一個功能出錯了，它不應該影響另一個功能。在這一方面，我們仍然在迭代中計劃我們的工作，並且我們仍然會在每次迭代的末尾釋出。而瀑布缺乏與業務的溝通和迭代次數，所以如果在專案的後期才發現要更改需求的話，則專案可能會失敗或需要重新啟動。這張圖好像也解釋了瀑布開發經常所面臨的困境。
在高舉效率與擁抱變化的大旗之下，似乎敏捷模式，就是最好的開發模式。與之相比的是瀑布模式，在這樣的呼喊之中，顯得有些無法跟得上步伐，體現的是陳舊、死板的。
“瀑布”對“敏捷”的駁斥
敏捷本身不是專案管理框架，也不是“方法論”。它是一套與產品開發相關的原則和價值，特別是網際網路產品經常會採用敏捷的方法來進行開發。但是，有一些基於敏捷原則的方法，這些方法是產品開發方法，而不是專案管理框架。
說到需求變更，瀑布也可以走需求變更，提變更申請，按照環節一步一步走，去規劃工作量。雖然比敏捷是要慢一些，但是我整個流程是可靠的！為什麼就說瀑布是死板的，不符合時代的呢？
似乎瀑布的做法也沒有錯誤，我們何不按照這樣的步驟，來完成我們的工作呢？這樣的過程聽起來是如此的可靠。看，我有明確的階段；看，我有明確的審批；看，我有明確的變更流程。以瀑布模式進行開發的專案有這麼多，已經證明了這是一個有效的實施方法，難道不是麼？
另外被敏捷所詬病的瀑布專案經常失敗通常是發生了非常嚴重的錯誤情況下才會產生。實際上只有在對專案的控制很差的情況下才會發生這種情況。瀑布型專案沒有迭代和使用者的多次反饋也是不正確的 - 很多專案可以透過產品原型圖的方式和業務部門確認操作的流程，只是很多專案中並沒有使用這種方法。
焦點碰撞
敏捷模式，兩週一個迭代，每個迭代都能進行一定功能模組的交付，讓使用者更早的看到交付物，雖然只有部分，也可以讓使用者來提出自己的看法，產生變更的時候，開發人員也可以在下個迭代中進行修改，讓使用者進行再次的確認。
從這樣看來，兩者的碰撞就是在交付的及時性上與面對變更的成本上，所看到有極大的變化。瀑布在交付階段比較靠後，交付的模組比較完整，在面對變更的時候，變更影響範圍就比較大，變更的成本就極大。問題發現的階段越靠後，解決問題所需要付出的成本就更高。這樣，就體現出來了敏捷對瀑布在這樣的情景下面的優勢。
時間和成本，看起來就是敏捷和瀑布在選擇時主要考慮的兩個方面。未來能更好的指導未來的選擇，下面還列出了更詳細的敏捷和瀑布的優劣勢。
敏捷開發的優勢：
• 開發的階段性成果會在開發過程中儘早的進行審查，專案的風險會降低；
• 適用於需求不明確情況，因為需求不明確，所以需要在不斷迭代的過程中來逐步理清需求。
• 靈活性較高，幾乎可以在任何時間進行需求變更；
• 敏捷鼓勵開發人員與業務使用者之間進行多頻次的溝通，業務使用者的不合理需求以及開發人員的錯誤理解都會在這些頻繁的溝通中進行不斷審查和更新，
• 敏捷的協作通常要高得多，通常能開發出更高質量的產品；
• 適用於快速變化的專案，特別是面向前端業務人員的CRM系統專案更容易根據業務的變化而變化。
I 敏捷開發的劣勢：
• 敏捷的概念接受度還不算太高，初次嘗試可能不會非常成功；
• 最終交付的內容無法預測，預期和實際完成的內容經常會有很大差異；
• 敏捷需要高水平的協作以及開發人員和使用者之間的定期溝通。 業務和IT人員在溝通前需要做大量的準備工作，但很多情況下業務的溝通時間無法保證；
• 當存在乙方供應商的情況，敏捷會面臨更大的挑戰性。 客戶通常希望儘早瞭解他們的專案投入。 預估專案時間和成本難度較高；
• 在敏捷專案中，最大的問題可能是業務部門永遠不希望有最終的截止時間。
I 瀑布開發的優勢：
• 在管理良好的專案中，瀑布可以在早期提供交付的信心；
• 專案團隊成員不需要在同一地點頻繁溝通；
• 在需要大量的設計或分析的情況下瀑布是一種更合適的方法；
• 如果在基本產品開發之外存在許多介面和依賴關係，瀑布式專案會使用工具來建模和管理這些介面和依賴關係。
I 瀑布開發的劣勢：
• 許多企業和業務人員確實不容易在前期定義清楚需求，早期計劃中所依據的假設需求可能存在很大風險；
• 溝通的風險要高得多 - 特別是很多專案都是前期單向的溝通，後期專案和業務人員的預期差別很大；
• 瀑布專案的風險一般都很高，因為基於無效假設基礎上的需求可能會讓專案無限度擴大。 所以你會看到很多瀑布專案都出現成本超出預算或延遲的情況。
結論：
敏捷和瀑布的實施方法差別還是很大的。現在，瀑布幾乎可以應用於任何型別的專案，尤其是大型的專案。敏捷方法在這兩年來越來越受歡迎，我們開始看到企業(甚至國防部和聯邦機構)中大量採用各種敏捷方法，尤其是當前SaaS軟體當道，如Salesforce、SAP等這樣自帶開發平臺的SaaS產品可以非常容易的搭建初始原型並進行快速迭代。但總的來說敏捷並不能完全替代瀑布，它只是給了我們另外一種好的選擇。
現在，對於組織來說，將敏捷和瀑布方法結合在一起的混合敏捷方法也很常見。一旦我們決定了使用哪一種基本方法，我們就可以進一步細化過程以最適合我們的專案目標。最後，儘管我們工作的方式很重要，但是交付一個可靠的、可維護的、滿足客戶需求的產品才是最重要的。
如需瞭解更多，歡迎訪問怡海軟體官網