前言：建築師的藍圖 vs. 探險家的地圖

在專案管理的領域中，我們總是在尋找最適合的執行方法。其中，Waterfall (瀑布式) 與 Scrum (敏捷開發) 代表了兩種截然不同的世界觀。

Waterfall 像是一位建築師，堅持在動工前必須畫好每一張精確的藍圖，按圖施工，一步都不能錯；而 Scrum 則像是一位探險家，他有一張標示了最終目的地和已知地點的地圖 (Product Backlog)，但實際路徑需要邊走邊探索，隨時應對途中的變化。

在我們的實務經驗中，資料專案的高度不確定性與複雜性，讓 Waterfall 的管理方式越來越窒礙難行。

專案管理哲學：一表看懂 Waterfall vs. Scrum

這兩種方法論各有其擁護者與適用情境。
為了讓大家快速理解，以下用一張表格直接比較兩者的核心差異：

從上表可以看出，兩者最大的差異在於對「變化」的態度。而這一點，正是資料專案管理的核心關鍵。

資料專案越來越不適合用 Waterfall 來管理？

資料專案的範圍橫跨整個資料生命週期，其核心是「探索未知」與「發現洞見」，這與 Waterfall 要求「事先定義一切」的本質完全相悖。我們很難在專案初期就預測所有細節，更多時候是「摸著石頭過河」。

1. 高度的不確定性：專案開始前，你無法預知資料的品質、裡面藏著什麼關聯性，也無法保證最終模型的準確度。為此制定一份不變的藍圖，根本不切實際。
2. 需求的演化性：資料專案的過程是「提問 -> 分析 -> 發現 -> 提出新問題」的循環。當你給客戶看了第一版分析圖表，他們幾乎總會說：「喔！很有趣，那你可以再幫我分析 X 和 Y 的關係嗎？」在 Waterfall 中，這是災難性的「需求變更」；在 Scrum 中，這只是 Backlog 中一個新的、高優先級的項目。
3. 對快速回饋的依賴：團隊需要快速做出初步成果交付給客戶，來驗證方向是否正確。若依照 Waterfall 規劃，等到一個月後才交付「完美」報告，卻發現方向從一開始就錯了，輕則專案延期、成本浪費，重則專案失敗，甚至讓公司面臨違約風險。

結論：為你的資料專案，選擇地圖而非藍圖

Waterfall 的紀律在特定情境下有其價值，但面對資料專案的探索天性（甚至是快速變動的 AI 時代），它的適用性正變得越來越低。

選擇 Scrum，就是選擇了一張能隨時標記新發現、調整路線的活地圖。它承認我們無法預知未來，並賦予我們應對變化的能力。這才是帶領資料專案走向成功的關鍵。