5.2 敏捷 vs. 瀑布
你怎麼跑一個專案,對結果的影響至少不亞於你做出什麼。
最有名的兩種做法,就是瀑布與敏捷。
沒有哪一個是放諸四海皆準的「比較好」——選哪一個,要看專案的性質、規模,以及你需要吸收多少變化。這一節我們會走過它們各自的特徵、適合用在什麼時候,以及怎麼把兩者結合起來用。
什麼是瀑布模型?
瀑布按階段走——需求 → 設計 → 開發 → 測試 → 上線——以線性、單向的方式往下流。每一步都要被完成、被核可,才會進入下一步。
主要特徵
- 流程清楚,容易管理與監控
- 線性流動:不容易跳過或重做某一步
- 適合範圍清楚、變動容忍度低的專案
最適用的情況
- 需求固定、變動少的專案(例如內部 IT 基礎建設)
- 需要嚴謹文件或法規遵循的產業(例如金融、醫療)
- 多廠商環境、職責切分清楚的場景
什麼是敏捷做法?
敏捷把專案切成小週期(迭代),在小迴圈裡建造、測試與調整。
Scrum 與 Kanban 是最常見的框架。
主要特徵
- 對變化的適應力高
- 能早一點、頻繁地交付可運作的部分成果
- 團隊與利害關係人之間溝通密切
最適用的情況
- 需求會演化的專案(例如新產品開發)
- 需要快速整合回饋
- 需要頻繁與利害關係人對齊
瀑布 vs. 敏捷:對照表
| 面向 | 瀑布 | 敏捷 |
|---|---|---|
| 工作流程 | 線性循序 | 反覆、漸進 |
| 需求處理 | 事前固定、難以變動 | 有彈性、可中途演化 |
| 交付時機 | 最後一次性發布 | 可以提早部分發布 |
| 溝通風格 | 文件多、正式審查 | 每日站立會議、即時討論 |
| 排程管理 | 偏重事前規劃、里程碑驅動 | 有彈性、以衝刺為單位規劃 |
混合做法:用瀑布規劃、用敏捷執行
實務上,大多數現代團隊會把兩者混著用——混合模型——而不是選邊站。
常見的搭配方式包括:
- 里程碑用瀑布規劃,實際工作用敏捷跑
- 文件走瀑布,測試走敏捷
- 階段層級用瀑布結構,團隊層級用敏捷執行
這種彈性在大型或多團隊專案上最重要,因為單一方法論很少能適合整個組織的每一塊。
AB 對方法的彈性支援
AB 讓你能自然地把兩種做法混在一起:
- 用類似瀑布的 WBS 結構規劃任務
- 在敏捷式看板檢視裡,讓任務在狀態之間流動
- 在甘特檢視裡看大時程,但內部仍然自由迭代
這份彈性讓你能根據團隊的成熟度與專案的特性,設計自己的做法。
結論:讓專案決定方法
敏捷與瀑布不是對手——它們是