瀑布式與敏捷式，是專案管理裡最常被拿來對比的兩種取向。它們的差別，遠不只是「先規劃好」與「邊做邊調」的流程差異——背後其實是對「如何面對不確定性」兩種根本不同的假設。一個相信未來可以被充分規劃，另一個相信未來只能被逐步探索。搞懂這層假設，你才不會人云亦云地追潮流，而能依專案的真實性質做出對的選擇。這篇會先各自說清楚它們的來歷與精神，再逐面向拆解差異，接著用一個具體情境對照兩種走法，最後談談如何選、常見迷思，以及如何聰明地混用。
瀑布式是什麼
瀑布式（Waterfall）是一種線性、階段接續的做法：需求、設計、開發、測試、部署依序進行，每個階段完成並確認後，才進入下一階段，像水由上往下流、不回頭。它源自製造業與營建業的工程思維，這些領域的共同特徵是——改動的代價極高，地基灌好了就很難重來。因此瀑布式把大量心力投在前期：把需求釐清、把設計定案、把計畫寫詳盡，力求「一次做對」。它的核心假設是「需求可以在前期充分掌握」；一旦計畫定案，後續就照表操課，強調紀律與可預測。
敏捷式是什麼
敏捷式（Agile）不是單一流程，而是一套價值觀，由 2001 年的《敏捷宣言》奠定：重視可用的成果勝於詳盡的文件、回應變化勝於墨守計畫、與客戶協作勝於合約談判。Scrum、看板都是它的具體實踐。它誕生於軟體世界，正因為軟體的需求極不穩定、又相對容易修改。它的核心假設與瀑布式相反——「需求無法在前期完全預知」，所以與其押注一份完美計畫，不如快速做出一小部分、拿到真實回饋、再修正方向，用一次次短迭代把不確定性逐步收斂。
關鍵差異，逐面向比較
規劃方式
瀑布式在專案前期做一次詳盡規劃，把範圍、時程與資源一次定清楚，後續盡量不動；敏捷式採滾動式規劃，只把近期的迭代看清楚，遠期保持粗略，隨著每次交付的學習逐步細化。前者像出發前就把整條路線畫死，後者像每到一個路口才決定下一步。
對變更的態度
瀑布式視變更為風險，會透過正式的變更控制流程審慎評估、盡量避免；敏捷式視變更為常態甚至機會，設計上就預留了每個迭代重新排序待辦的空間。這不是誰對誰錯，而是反映了兩者對「計畫的價值」有不同看法。
交付節奏
瀑布式通常在專案末端一次交付完整成果，中途看得到的多半是文件與階段報告；敏捷式每個迭代（常為一到四週）都交付一小塊可用的增量，讓價值提早流動，也讓利害關係人更早看到真東西。
客戶與使用者的參與
瀑布式的客戶參與集中在頭尾——前期確認需求、後期驗收成果，中間較少介入；敏捷式則要求客戶或其代表（產品負責人）持續參與，每個迭代都提供回饋，讓方向不斷校準。
角色與溝通
瀑布式的角色與責任分工明確、層級清楚，溝通多依賴文件與正式節點；敏捷式強調跨職能、能自主決策的團隊，靠站會、迭代規劃與回顧等頻繁的面對面互動維持節奏，文件則退居輔助。
文件
瀑布式重視完整、可稽核的文件，作為階段交接與日後維護的依據；敏捷式主張「剛好夠用」的文件，把心力更多放在可運作的成果上——但這常被誤解為「不寫文件」，實際上是「不寫沒人會讀的文件」。
風險出現的時點
這是最關鍵、也最常被忽略的差異：瀑布式因為整合與測試都排在後段，問題往往到接近驗收才浮現，此時修正代價最高、可迴旋的空間最小；敏捷式讓問題在每個短迭代就暴露，得以及早發現、及早轉向，把「大失敗」拆解成許多「小修正」。
進度的衡量
瀑布式以「完成了哪些階段與文件」衡量進度，容易出現「文件都做完了、東西卻還不能用」的假象；敏捷式以「交付了多少可用的成果」衡量，進度更貼近真實價值。
成本與時程的可預測性
瀑布式因為前期就鎖定範圍，理論上成本與時程較好預估、也較好對外承諾；敏捷式的範圍是浮動的，換來的是彈性，但也讓「總共要多少錢、多久做完」較難在一開始就給出精確答案。這一點，常是採購與合約端最在意的差異。
團隊的自主性
瀑布式偏向由上而下的指派與把關；敏捷式把更多決策權下放給團隊，相信離問題最近的人最懂怎麼解，管理者的角色也從「指揮」轉為「排除障礙」。
一個具體情境：同一個專案，兩種走法
假設你要為公司做一套新的內部請假系統。
走瀑布式：先花數週訪談各部門、寫出完整需求規格與設計文件，經主管簽核後才開工；開發團隊照規格一次做完所有功能，最後統一測試、上線。好處是每個環節都有白紙黑字、責任清楚；風險是——如果訪談時漏掉了某個部門的特殊流程，往往要到上線測試才發現，屆時牽一髮動全身。
走敏捷式：先做出「能送出申請、主管能核准」的最小可用版本，兩週後就給一個部門試用、收集回饋；再逐步加上代理人、額度計算、行事曆整合等功能，每兩週交付一塊。好處是很早就能發現「原來大家最在意的是自動計算特休」；代價是專案初期較難對老闆說死「總共何時全部完成」。
哪一種比較好？取決於這個系統的需求有多穩定、公司能不能接受漸進上線——這正是選擇的核心。
各自適合的時機
選瀑布式，當：需求穩定明確、範圍變動小、法規要求嚴謹的可追溯性、成果必須整體完工才有意義（如營建、硬體製造、部分公部門與醫療專案），或是對外合約已把範圍與交期寫死。
選敏捷式，當：需求會隨市場與使用者回饋演化、能切成增量持續交付、團隊跨職能且能緊密協作、且組織文化容許漸進調整（如多數軟體與數位產品開發、行銷活動、新創產品探索）。
三個常見迷思
迷思一：敏捷就是不做計畫。 恰恰相反，敏捷是「一直在做計畫」——只是把一次性的長期規劃，換成持續的滾動式規劃。
迷思二：瀑布式已經過時。 在需求穩定、稽核嚴格的領域，瀑布式依然是更負責任的選擇。方法沒有新舊，只有適不適合。
迷思三：選了一種就不能碰另一種。 多數成熟團隊其實是混用的，差別只在於有沒有「有意識地」混。
其實，你可以兩者混用
現實中的專案，很少是純粹的一種。常見的「混合式」做法，是用瀑布式規劃整體的大階段與里程碑，確保對外的承諾與稽核；在每個階段內部，則用敏捷迭代推進日常開發。例如硬體產品：規格凍結與量產排程走瀑布，但韌體與 App 的開發走敏捷。關鍵不在於選邊站，而在於有意識地為專案的不同層次，選用最合適的做法。
用 Meegle 同時支援兩種節奏
瀑布與敏捷之爭，很多時候被工具放大了——因為工具往往只擅長其中一種，逼團隊遷就工具。Meegle 以可自訂的視覺化工作流為核心：需要階段把關的流程，可以用線性節點與里程碑管理；需要迭代的開發，可以用看板視圖與衝刺管理；兩者還能透過工作項的相依關係彼此串接。同一個專案裡，戰略層走瀑布、執行層走敏捷，資訊落在同一個平台上，不必在兩套工具之間來回同步。
結語
瀑布式與敏捷式不是對錯之爭，而是對不同情境的不同回應。瀑布式擅長可預測的世界，用紀律換取確定性；敏捷式擅長不確定的世界，用彈性換取適應力。真正成熟的團隊，不會盲目效忠一方，而是讀懂專案的性質——需求穩不穩、能不能漸進交付、組織容不容許調整——選對取向，甚至聰明地混用，讓方法論成為助力，而不是枷鎖。