瀑布式開發與敏捷開發的差異：進行方式、計畫、因應變更、測試與適合的開發比較
瀑布式模型是把需求定義、設計、程式撰寫、測試等流程由上游依序進行，原則上在前一個流程的產出物確定後，才進入下一個流程的開發模型。由於一開始就擬定整體計畫，進度與費用容易管理；但在後面的流程才發現需求錯誤時，返工會很大。敏捷開發是反覆進行數週左右的短期迭代，每次都做出可運作的軟體並採納使用者的意見，配合變化的需求修正計畫之進行方式的總稱，代表性的方法有Scrum與極限編程（XP）。需求明確且不易變動時適合瀑布式，需求容易變動、想及早提供可用功能時適合敏捷。
| 項目 | 瀑布式模型 | 敏捷開發 |
|---|---|---|
| 流程的進行方式 | 需求定義 → 設計 → 程式撰寫 → 測試，由上游依序各進行1次 | 反覆進行多次包含規劃、設計、實作、測試的短期迭代（Scrum中稱為衝刺） |
| 計畫的擬定方式 | 一開始就決定整體的範圍、時程與費用，依該計畫進行 | 決定大致的方向，每次迭代時從優先順序高者開始修正計畫 |
| 對需求變更的因應 | 前一流程的產出物確定後的變更，返工很大。需經過變更管理的程序進行 | 以變更為前提，容易納入下一次迭代的計畫 |
| 可運作軟體完成的時期 | 主要在開發的後期。完成測試後一次交付 | 每次迭代都會完成可運作的軟體（Scrum中稱為增量） |
| 測試的時期 | 程式撰寫之後，依序進行單元測試、整合測試、系統測試、驗收測試（以V模型與設計流程對應） | 每次迭代都進行。多以自動化測試與持續整合，在每次變更時確認 |
| 文件 | 每個流程都撰寫需求規格書、設計書等，並以審查確定 | 重視可運作的軟體，文件多半只寫必要的部分 |
| 使用者（委託方）的參與方式 | 主要在一開始的需求定義與最後的驗收測試 | 每次迭代都檢視成果並提供意見。Scrum中由產品負責人決定要做之事物的優先順序 |
| 進度管理 | 以流程的完成與產出物衡量。容易以工作分解結構（WBS）或甘特圖管理 | 每次迭代以已完成且可運作的功能衡量 |
| 適合的開發 | 需求明確且不易變動的開發、需要與硬體一起及早確定規格的開發、需要以合約事先決定範圍與費用的開發 | 需求容易變動的開發，或想一邊開發一邊確認使用者反應的新服務開發 |
數值為具代表性的大致參考值，會因世代或產品而異。