為什麼大家唾棄瀑布Waterfall，擁抱敏捷Agile？
其實Waterfall開發在傳統製造業，是相對普遍的，而最常被詬病的，是在軟體專案的瀑布。
Waterfall瀑布開發是最原始的產品開發的方式之一，主旨是將專案活動拆解(breakdown)成線性、有順序性的階段，每階段的input/output有相依性。
起初主要是源於傳統製造業、營建業等等，這些產業的特色就是無法輕易接受一點點的倒退，主要是因為這些硬體製造的成本巨大，必須要非常詳細的分析計畫後，才會去執行，不太輕易回頭修正。
稍微分析一下瀑布開發，看看為甚麼適合製造產業：
waterfall是一個很線性、相依性高的模型，大概可以區分成這幾個階段
- 需求分析
- 設計
- 實作、生產
- 測試
- 運營、維護
p.s. 其實這些就是對應到PMP知識框架的專案五大流程: 起始、計畫、執行、監控、結案。
對於“製造出一個實體產品”的產業，瀑布開發是相對適合的，從以下瀑布開發得優點，不難看出端倪：
- 更詳細的計畫需求與撰寫規格、文件: 畢竟無法回頭修正，事前的準備必須要更謹慎。
- 組織成員可以預先了解時程和被指派的任務。
- 任務容易拆分，達成直觀的專案管理，即使是非工程背景也可以理解和管理專案。
- 客戶可以輕易掌握專案時程、花費等狀況，有利於計畫其他商業活動。
- 容易去評估專案狀況，通常看個甘特圖就大致了解進度。
- 更謹慎（好？）的設計，基於瀑布相依性特性，設計必定會更加謹慎，任何狀控都會考慮周詳
如前所述，製造出一個實體的產品，需要的器具、機械、人力等等，相對於軟體產品，是非常巨大的，事前的詳細準備，有益於減少成本，且現在全球供應鏈的特性，一個產品的各個料件，可能都來自不同的工廠，瀑布開發使得客戶和供應商之間的合作，更易於管理。
必須要補充，製造業中使用waterfall並非就完全不走回頭路，而是在規劃的時候，就會把這些重複驗證的工作納入考量
比如說，一個產品被製造出來，可能會經過以下階段：設計、數次prototype、設計驗證、製程驗證、小批量生產、大批量生產…
可以容許初期的的幾次“有預期”的回頭，但是，這些大都是以最初想定的規格、功能去逼近，而非小週期獲得市場feedback而迭代。這呼應了第六點，我認為瀑布式開發的設計會更謹慎，但是否真得是好設計，是持保留態度的。
Waterfall sucks. But Why?
現在來討論一下軟體產業。為什麽瀑布式開發是很容易被吐槽的。
一樣，我們可以由下瀑布開發的缺點來得到結論
- 不回頭，缺乏彈性
- 初期需求分析階段的影響甚巨
- 各專案活動相依性極高，容易因為其中一環節出錯而影響整個專案
- QA測試通常太晚進場導致其feedback無法提早被開發端採納，且容易為了趕時程，壓縮測試品質。
- 客戶常常不知道自己需要什麼，可能到了專案結束，才發現做了個垃圾。
- 最前頭的產品端，常常和開發端距離已經太遠，其認知的落差容易產生非預期的錯誤，且難以補救。
軟體產品，成本是相對於硬體低廉的，且常常產品是面向市場、人們的服務，因此偏向adaptive的專案管理模型就非常適合，SCRUM就是現在的熱門代表，相對於這種擁抱變化的方式，Waterfall則是屬於predictive的模型，然而，通常一個成功存活的新產品，都是經過反覆的市場驗證、數次的轉折(pivot)，才成型的，很少能夠一步到位，光是這點，就已經重傷Waterfall在軟體開發的地位。
且因Waterfall給人相對傳統、僵化的印象，也讓大家開始唾棄這種專案管理模型，大型的傳統公司開始轉型、新創也都一概號稱使用敏捷式開發。
瀑布軟體開發真的沒有價值嗎？
其實不然，其實還是很多狀況適合使用Waterfall的。如以下狀況
- 範疇(scope)、需求、預算固定
- 可以精準預估、無風險
- 無法負擔迭代開發的成本
簡言之，當清楚了解產品最終的模樣且確定可以賺錢，且未來不太會去更新，那就很適合使用Waterfall來做breakdown，這種常常就是屬於接案、內部系統開發、合約案。反之，當產品最終長什麼模樣都不確定時，或者是可能需要頻繁更新，那使用敏捷式的的開發會適合很多，例如：新產品開發、新創。
瀑布、敏捷，傻傻搞不清楚？
當大家持續的吐槽Waterfall時，我們可以仔細看看當前所謂的敏捷式開發，把它拆解一下，可以發現，敏捷式開發的每一個迭代(iteration)，其實可以看成是一個個的小Waterfall，敏捷與否，主要差異在於：用戶是否預期一次到位，抑或是有數次的迭代，當客戶預期有更多次的迭代，就代表著客戶有計劃更高頻地參與產品的開發，而所謂敏捷(agile)，就是希望客戶持續的參與。嚴格來說，迭代型的敏捷式開發，嚴格來說是沒有跳脫傳統專案管理的框架的。
文化決定一切
瀑布裡可以是敏捷，敏捷也可以跑的很瀑布，一切的一切，都決定在組織、團隊的文化風氣，敏捷講究的是面對面溝通、緊密的合作，如果一個團隊，專案管理方式就是拉拉甘特圖、做做micro management、不專注在產品輸出，只在意人的稼動率，即使嘗試著導入敏捷工具，也很容易跑成讓人詬病的僵化管理方式。現在不少企業，因為舊有專案管理方式深根蒂固，也無法快速適應新的管理工具，而造成很多偽敏捷、偽SCRUM的現象，有時甚至為了便於無法適應變化的專案經理方便，讓開發端做了很多虛工。
才會有人說，為什麼導入了敏捷，開發卻慢成這樣？敏捷不是萬靈丹，重要的是整個組織、團隊的文化。
