比較兩種常見的模式——Waterfall 把變更視為威脅而力求凍結（剛性），Agile 把變更視為原料而擁抱流動（柔性）；附多維度對照與實務上對外瀑布、對內敏捷的混搭觀察。
專案管理方法與精神
前面的筆記我們認識了專案與產品的差異，接下來我們來看看在專案管理中，兩種常見的模式：Waterfall(瀑布式) 與 Agile(敏捷式)。
Waterfall（瀑布式）
階段清楚、文件齊全、前期規劃重、變更成本高。 適合需求穩定、合規要求高、或對交付物有明確規範的專案(例如:政府標案、ERP 導入、金融系統)。 所以大部分「專案」會採用瀑布式方法。
Waterfall 這類的執行方法我們稱之為 SDLC（Software Development Life Cycle，軟體開發生命週期）模型，雖然名字裡有「軟體開發」，但其實不只軟體專案，其他類型的專案也常借用這兩種方法論來規劃執行。
Agile（敏捷式）
迭代交付、擁抱變化、強調溝通與反饋。 適合需求不明確、需要快速試錯、市場變化快的產品(例如：消費型 App、SaaS 產品)。 「產品」因為需要快速回應市場與用戶反饋，通常會採用敏捷式方法。
完整對照如下表，方便一次掃讀全部面向：
| 面向 | Waterfall 瀑布 | Agile 敏捷 |
|---|---|---|
| 交付方式 | 階段一次性交付 | 迭代增量交付 |
| 需求變更 | 成本高、抗拒變更 | 成本低、擁抱變化 |
| 文件 | 前期齊全、文件驅動 | 精簡夠用即可 |
| 規劃時機 | 前期規劃重、一次定案 | 持續滾動、隨迭代調整 |
| 溝通反饋 | 里程碑階段審查 | 高頻、持續反饋 |
| 適用情境 | 需求穩定 / 合規（政府標案、ERP 導入、金融系統） | 需求不明 / 快速試錯（消費型 App、SaaS 產品） |
個人經驗
實務上很少有純瀑布或純敏捷，尤其是敏捷模式，如果有人說他們完全遵循敏捷精神，就跟他說他完全懂量子力學一樣 🤡， 再加上現在 AI Coding 的風氣，以前這些都是讓「人」按特定模式執行的方法，在有了 AI 後，就幾乎不可能完全照著某一套方法論走了，因為 AI 的介入改變了專案執行的節奏和方式。
但是我覺得這兩種方法論的核心精神和原則還是很有參考價值的，理解它們的差異和適用情境，對於我們在實務中靈活運用、甚至混搭，都是很有幫助的。
最重要的事，如果老闆是傻逼，可以把這些工具當成約束工具或說服工具，讓他們知道這樣做的風險和代價，爭取更多的彈性和資源。
下面的這個示意圖，其實就是混合了瀑布和敏捷的元素，對外可以用瀑布式的里程碑和階段來定義專案的範疇和交付節點，對內則用敏捷式的 Sprint 迴圈來推進團隊的工作， 這樣就能兼顧外部的管理需求和內部的執行效率。