精簡瀑布式開發章節，強調網路時代的衝擊與敏捷思維的興起，刪除冗長內容以提升可讀性

Author: marsen

source/_posts/2025/sdd_spec_kit_water_fall.md

@@ -123,73 +123,37 @@ IBM的System/360開發耗資50億美元（相當於今天的400億），這種
 
 但現實是，**客戶看到系統之前，根本不知道自己要什麼。**
 
-就像買衣服，不試穿怎麼知道合不合身？
+### 網路時代的衝擊
 
-但在瀑布式的世界裡，改需求要走變更流程、要重新評估、要加錢加時間。
-
-結果就是：不是系統符合需求，而是需求被迫符合系統。
-
-Y2K：瀑布式的最後輝煌與警鐘
-1990年代末的千禧蟲（Y2K）危機，是瀑布式的最後一場大戲。
-面對明確、不可變更的需求（修正日期欄位從2位數改成4位數），瀑布式展現了它的優勢：
-
-需求明確：2000年1月1日是死線
-範圍固定：所有日期欄位都要改
-風險可控：測試案例可以預先定義
-
-全球企業投入6000億美元，有條不紊地完成了系統修正。2000年1月1日，世界沒有崩潰，瀑布式似乎贏了。
-但等等，為什麼當初設計時沒想到？為了省兩個byte的空間，結果花了6000億來補救？這暴露了瀑布式的致命傷：它假設人類可以預見未來。
-
-[個人經驗補充區]
-網路時代的衝擊
-1995年，Netscape上市，網路泡沫開始膨脹。突然間，遊戲規則全變了：
+指 dot com 泡沫到 web 2.0 的時代。
 
 產品生命週期從年變成月
+
 競爭對手不是隔壁公司，而是地球另一端的車庫創業
-使用者期待每週都有新功能
-「永遠Beta」成為新常態
 
-Amazon的Jeff Bezos提出「兩個披薩團隊」理論：團隊要小到兩個披薩就能餵飽。這完全違反了瀑布式的大兵團作戰思維。
-Google更狂，直接在logo上掛著Beta標籤好幾年。Gmail從2004年Beta到2009年，期間不斷推出新功能。如果用瀑布式，大概還在寫規格書的第五版。
 當你的競爭對手每週更新，而你還在等三個月後的UAT（使用者驗收測試），市場早就不見了。
-瀑布式的遺產
-仍然適用的領域
-諷刺的是，即使在2024年，某些領域仍然需要瀑布式：
 
-醫療設備軟體：FDA要求完整的文件追蹤，一個bug可能害死人
-航太系統：NASA的軟體開發依然遵循嚴格的階段審查
-金融核心系統：當你處理的是別人的錢，「快速失敗」不是選項
+搶佔市場的思維，改變了軟體工程，敏捷成為主流，我們之後再說。
 
-這些領域的共同點是：錯誤的成本遠大於延遲的成本。
-文化的延續
-更深層的影響是，瀑布式留下的不只是流程，更是一種思維模式。
-即使號稱敏捷的團隊，骨子裡可能還是瀑布式思維：
+但某些領域仍然需要瀑布式：
 
-Sprint計畫會議開4小時，像極了需求分析會議
-Story Point估算變成了工時評估2.0
-Scrum Master變成了改名的PM
-Retrospective淪為抱怨大會，因為「流程是總部規定的」
+- 醫療設備軟體：FDA要求完整的文件追蹤，一個bug可能害死人
+- 航太系統：NASA的軟體開發依然遵循嚴格的階段審查
+- 金融核心系統：當你處理的是別人的錢，「快速失敗」不是選項
 
-最諷刺的是什麼？很多公司的「敏捷轉型」本身就是用瀑布式規劃的：先導入Scrum、再導入CI/CD、最後導入DevOps。每個階段都有明確的里程碑和KPI。
-結語：理解過去，才能創造未來
-瀑布式開發不是錯誤，而是特定時代的最佳解答。
-它教會了產業很多重要的事：
+這些領域的共同點是：錯誤的成本遠大於延遲的成本。
 
-文件化的價值（雖然常常過頭）
-流程管理的重要（雖然常常僵化）
-品質控制的必要（雖然常常太晚）
+更深層的影響是，瀑布式留下的不只是流程，更是一種思維模式。
 
-但當世界改變，堅持不變就是最大的風險。瀑布式的問題不在於它本身，而在於它假設世界是靜態的、可預測的、可控制的。
-可惜，軟體開發更像衝浪而不是蓋房子。你必須隨時調整平衡，回應每一個浪頭。
-下一篇，我們將探討敏捷如何試圖解決這些問題，以及為什麼「敏捷」最後也變成了另一種「瀑布」。畢竟，人類就是這麼喜歡把動詞變成名詞，把精神變成教條。
+即使號稱敏捷的團隊，實際上仍在執行小瀑布
 
-註：本文部分數據來源於IEEE Software History、Computer History Museum資料庫。Y2K投入成本數據來自Gartner 2000年報告。
-[待補充個人經驗區塊]RetryClaude can make mistakes. Please double-check responses. Opus 4.1
+下一篇，我們將探討敏捷如何試圖解決這些問題，以及為什麼「敏捷」為什麼也失敗。
 
 ## 參考
 
 - [以前的程序员，除了敲代码，还得会画画【让编程再次伟大#42】](https://www.youtube.com/watch?v=RyGA6zBHcJg)
 - [RUP 統一軟體開發過程](https://zh.wikipedia.org/zh-tw/%E7%BB%9F%E4%B8%80%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E8%BF%87%E7%A8%8B)
 - [序列圖，UML 給軟體開發帶來的唯一好處](https://docs.mermaidchart.com/blog/posts/sequence-diagrams-the-good-thing-uml-brought-to-software-development)
+- [我们都只是在假装着做Agile【让编程再次伟大#43】](https://www.youtube.com/watch?v=vJGoQigiXAE)
 
 (fin)