告別敏捷開發

背景

本文探討了軟體開發領域中「敏捷開發」（Agile）的衰落與轉型。作者指出敏捷宣言自 2001 年誕生以來，其定義始終模糊不清，且許多被視為創新的概念早在 1970 年代的瀑布模型研究中就已存在；隨著大型語言模型（LLM）的興起，開發者重新發現了「規格說明驅動開發」（Spec-Driven Development）的價值，認為詳盡的文檔才是生成正確程式碼的關鍵。

社群觀點

在 Hacker News 的討論中，社群對於敏捷開發的現狀呈現出兩極化但普遍帶有批判性的看法。許多開發者對「大寫的敏捷」（Capital-A Agile）深惡痛絕，認為它已演變成一種僵化的官僚體系。有留言指出，敏捷開發在許多企業中已淪為一種「表演藝術」，充滿了便利貼、站立會議與規劃撲克等形式主義，卻忽視了核心的開發效率。這種現象被形容為一種「指標交付系統」，管理層透過追蹤故事點與速率來獲得掌控感，導致產品本身反而成了數據指標下的副產品。更有資深工程師分享，在功能失調的敏捷環境中，優秀的開發者往往被迫採取「超前開發」的策略，在衝刺開始前就先完成工作，以確保指標上的完美達成，這讓敏捷流程顯得格外諷刺。

然而，也有觀點為敏捷辯護，認為問題不在於敏捷本身，而在於執行者的誤解。支持者強調，敏捷宣言的初衷是為了解決規格不完整且難以預測的問題，透過快速迭代讓客戶在看到運作中的軟體後，能更精確地修正需求。針對文章提到的 LLM 趨勢，部分評論者持懷疑態度，認為規格驅動開發並非新鮮事，且 LLM 並未真正解決需求模糊的核心問題。他們擔心年輕一代的開發者可能會在 LLM 的推動下，重新發明一套換湯不換藥的敏捷流程。此外，社群中出現了一個有趣的共識：敏捷往往被當作一種「不可質疑的信仰」，當專案失敗時，擁護者總會歸咎於「執行不夠徹底」或「不是真正的敏捷」，而非反思框架本身的缺陷。

最後，關於規格說明的討論引發了深層的反思。有留言者指出，雖然 LLM 讓撰寫規格變得更廉價且高效，但軟體開發的瓶頸往往不在於程式碼撰寫，而在於商業邏輯的混亂與發布限制。如果企業文化本身不追求靈活性，無論採用敏捷還是規格驅動開發，最終都會走向變相的瀑布模型。這種討論反映出軟體工程界對於流程工具的疲態，以及對回歸工程本質、減少管理干擾的渴望。

延伸閱讀

• Winston W. Royce (1970) 關於瀑布模型的原始論文：探討了迭代開發的早期概念。
• Bell and Thayer (1976) 論文：首次定義瀑布模型並指出需求定義的困難。
• Compound Engineering：一種介於規格驅動與迭代開發之間的折衷方案。
• Fred Brooks 的《沒有銀彈》（No Silver Bullet）：探討軟體工程複雜性的經典文獻。
• Boehm 的螺旋模型（Spiral Model）：另一種早於敏捷宣言的迭代開發模型。