TL;DR
當軟體開發還是一門工程學
1970 年代，當軟體開發還是一門新興學科時，人們自然地從傳統工程領域借鑒經驗。
蓋房子需要藍圖、造橋需要設計圖，那麼開發軟體當然也需要完整的規格文件——這個看似合理的類比，開啟了長達數十年的瀑布式開發時代。
有趣的是，瀑布式開發 - Waterfall 這個名詞首次出現在1970年 Winston Royce 的論文中
但 Royce 其實只是點名在當時的主流方法，並且給這種方法一些批評與建議。
只是產業界選擇性地抓住了 Buzz Word ”Waterfall” 並將其奉為圭臬，而忽略了他的警告。
當然這也不是第一次業界扭曲軟體工程理論的原意。
瀑布模式的黃金年代
流程的確立
瀑布式建立起一套看似完美的流程：
需求分析 → 系統設計 → 實作 → 測試 → 部署 → 維護
就像接力賽跑，一棒接一棒，每個階段都有明確的交付物和把關者。
需求分析階段產出厚達數百頁的需求規格書（SRS, Software Requirements Specification），
系統設計階段則有高階設計（HLD, High-Level Design）和低階設計（LLD, Low-Level Design）文件。
這些文件不只是參考，而是具有合約效力的承諾。
當時的人相信，只要文件夠詳細，開發就是照著做而已。
甚至 UML 也在那個時代應運而生。
角色分工的確立
這個時期也確立了軟體開發的專業分工：
- PM（專案經理）負責管理時程與資源，通常不懂技術
- SA（系統分析師）負責理解業務需求，把業務語言翻譯成技術語言
- SD（系統設計師）負責技術架構，畫一堆UML圖
- PG（程式設計師）負責編碼實作，被視為「碼農」
- QA（品質保證工程師）負責測試驗證，專門找碴
這種分工暗示著「思考」和「執行」是可以分離的。
會思考的人負責設計，會打字的人負責coding。
這種階級觀念到今天都還沒完全消失。
為什麼瀑布式曾經如此成功？
無法失敗的時代背景
在1980年代，一套企業系統可能要價數百萬美元，開發週期動輒2-3年。
IBM的System/360開發耗資50億美元（相當於今天的400億），這種規模的投資容不得失敗。
瀑布式提供了管理層最需要的東西：控制力(或許只是幻覺)。
每個階段都有文件、有簽核、有人負責。出事了可以調出文件來看是誰的錯。
這種「可究責性」讓高層睡得安心。
適合當時的技術限制
當時的開發環境是什麼樣子？
- 沒有 Git，版本控制用 CVS/RCS 等集中式系統，或原始的複製資料夾
- 早期沒有 IDE，主要用 vi 或 Emacs，90年代才有原始的 IDE
- 編譯大型專案可能要等數小時
- 測試主要靠人工，自動化測試工具原始且昂貴
- 部署要半夜停機，通過實體媒介發布
在這種環境下，改一行code的成本可能是現在的100倍。
「想清楚再動手」不只是最佳實踐，而是唯一選擇。
[個人經驗補充區]
瀑布式的內在矛盾
文件與現實的落差
最大的問題在於：軟體是看不見、摸不著的。
建築師可以做模型，讓客戶看到未來的大樓長什麼樣子。
但軟體呢？畫了100張UML圖，客戶還是不知道系統用起來是什麼感覺。
更慘的是，需求文件寫著「系統應支援多使用者同時操作」，但什麼叫「多」？
10個？1000個？每個人心中都有不同的數字，直到系統上線當機才發現認知落差。
溝通的斷層
瀑布式假設資訊可以無損地傳遞，但現實是每一次傳遞都會失真，每一層次轉換都是風險：
客戶說：「我要一個簡單的購物網站」
PM聽成：「要有會員系統、商品管理、訂單處理、金流串接…」
SA寫成：「系統應提供使用者友善的介面以利商品選購」
SD設計成：「採用三層式架構搭配MVC模式」
PG實作成：「if-else地獄加上全域變數」
最後客戶看到成品：「這不是我要的！」
變更的成本
瀑布式最致命的假設是：需求是可以預先確定且不會改變的。
但現實是，客戶看到系統之前，根本不知道自己要什麼。
網路時代的衝擊
指 dot com 泡沫到 web 2.0 的時代。
產品生命週期從年變成月
競爭對手不是隔壁公司，而是地球另一端的車庫創業
當你的競爭對手每週更新，而你還在等三個月後的UAT（使用者驗收測試），市場早就不見了。
搶佔市場的思維，改變了軟體工程，敏捷成為主流，我們之後再說。
但某些領域仍然需要瀑布式：
- 醫療設備軟體：FDA要求完整的文件追蹤，一個bug可能害死人
- 航太系統：NASA的軟體開發依然遵循嚴格的階段審查
- 金融核心系統：當你處理的是別人的錢，「快速失敗」不是選項
這些領域的共同點是：錯誤的成本遠大於延遲的成本。
更深層的影響是，瀑布式留下的不只是流程，更是一種思維模式。
即使號稱敏捷的團隊，實際上仍在執行小瀑布
下一篇，我們將探討敏捷如何試圖解決這些問題，以及為什麼「敏捷」為什麼也失敗。
參考
(fin)