瀑布式開發方法的兩大基本原則是：

（1）採用階段式開發：這是產品經理最熟悉的用的最多的方法，即軟體開發過程被事先分為固定的幾個階段：撰寫書面的需求說明文件，設計高層軟體架構，設計底層細節，編寫程式碼，測試，部署。

（2）採用階段式評審：每個階段結束後，對該階段提交的成果進行評審，評審通過後才進入下一階段。

  瀑布式開發使用最廣，並且經久不衰的原因：

  瀑布式開發的流程具有可預測性，所以比較受管理層的歡迎，只要能準確理解需求和技術，而且需求不再改變，開發團隊就能為大規模的專案指定精確的開發計劃。並且在每個階段結束時都會提交書面材料，這會讓人比較放心，在一定程度上增強人們對專案的信心。

  但是使用瀑布式開發也有缺點：

（1）產品驗證嚴重滯後：產品經理必須要等到軟體開發的尾聲，才能看到可以執行的軟體，也就是說，在投入大量人力和資金之前，軟體的可用性無法得到驗證。

（2）變更計劃價格不菲：在瀑布式開發過程中，任何對前期決策的修改都會打亂開發流程，大量工作需要從頭來過，嚴重延誤開發進度。然而產品經理負責跟蹤客戶和使用者的需求，如果需求發生變化，修改產品是不可避免的。

（3）無法適應快速的市場變化：瀑布式開發方法嚴重依賴文件和流程，即使是一點小小的改動都要花費不少的功夫，這就使產品經理壓力倍增，即要儘量確保提交的產品設計通過了驗證，沒有缺陷，另一方面，產品釋出後產品經理仍然提心吊膽，隨時準備以最快的速度修補產品。

  所以，瀑布式開發方法過於理想化，除非是規模很小的專案，否則瀑布式開發方法很難順利執行。

  所以這就不難理解為什麼要改用Scrum和極限程式設計這類敏捷方法了。