瀑布法是一種線性、按部就班的專案管理方法，專案會穩步地向下流動，依序經過明確、預先決定的階段。每個階段都必須百分之百完成，下一個階段才能開始；如果沒有重新啟動流程，團隊無法輕易回到上一個階段。
與敏捷式專案管理靈活迭代的特性不同，瀑布法高度依賴大量的初期規劃、嚴格的文件和固定的時程。
瀑布法的 6 個經典階段
傳統的瀑布式專案嚴格按照以下連續階段進行： [11]
- 需求：在專案開始時收集並記錄專案的每個細節、功能和限制。
- 系統設計：架構師根據固定的需求規劃技術解決方案、選擇程式語言或建立藍圖。
- 實施（開發）：團隊成員編寫軟體程式碼或建構實體產品的實際建置階段。
- 整合與測試：將完成的產品組裝起來並嚴格測試，以找出並修復缺陷。
- 部署：將最終、完全完成的產品正式發布給市場、客戶或終端使用者。
- 維護：產品上線後，持續提供支援、修補錯誤和進行小型更新。
瀑布法的關鍵特性
- 循序漸進：進度是透過從一個設限階段到下一個階段來衡量。
- 大量文件：在生產開始之前，每個步驟、需求和設計選擇都會被仔細記錄。
- 低彈性：在專案中期更改需求需要正式且通常成本高昂的變更管理流程。
- 價值延遲：直到整個專案完成後，使用者才能看到或接觸到產品的運作版本。
瀑布模型優缺點
優點：
- 期望明確：成本、時間表和最終交付物從一開始就明確定義。
- 易於追蹤：里程碑清晰可見且易於追蹤，因為截止日期是固定的。
- 有紀律的結構：階段之間清晰的分隔，便於不同團隊之間的交接（例如，設計師與開發人員）。
缺點：
- 難以變更：如果市場需求或客戶目標在專案進行到一半時發生變化，則調整極其困難。
- 測試延遲：在專案結束前的測試階段發現關鍵架構缺陷，修復成本非常高昂。
- 高風險：如果初始需求有缺陷，團隊可能會花費數月時間卻建置出錯誤的產品。
何時使用瀑布法而非敏捷式
儘管現代軟體開發高度傾向於敏捷式方法，但瀑布法仍然是以下專案的業界標準：
- 固定的、不可更改的預算和截止日期。
- 嚴格的法規和合規要求（例如，醫療設備、航空航太工程）。
- 無法迭代的實體依賴關係（例如，建造橋樑或摩天大樓）。
- 技術已成熟，且團隊之前曾多次建置完全相同的產品。