字面上的意思就是如此——因為從來沒有人清楚說明它到底是什麼。
敏捷開發如同海嘯般席捲了我們的產業。但每當有人質疑時，總會有人（或許是從雲層的縫隙中傳來？）反駁說：「啊，但那不是真正的敏捷——宣言中可沒提到每日站立會議，也沒有敏捷教練」。然而，如果你閱讀了《敏捷宣言》（2001），這個我們開明的新時代軟體的源泉，你會發現它實際上並沒有告訴我們太多東西。充其量它只是一系列模糊的陳詞濫調（「客戶合作勝於合約談判」），最糟的情況則是商業上不可行（「歡迎變更需求，即使在開發後期」）。
所以，如果敏捷產業並沒有正確地實踐敏捷，而宣言本身又幾乎沒有意義，那麼它到底是什麼呢？
敏捷開發一直以來主要透過它「不是什麼」來定義——而它不是什麼，就是瀑布式開發。如果你沒有做敏捷，你就是在做瀑布式開發，而瀑布式開發「無效」。
除了我們自 1970 年就知道瀑布式開發無效；而 Winston W. Royce 確切地闡述了原因，並建議我們改為：
所有這些後來都被聲稱為敏捷的創新。事實上，它們是在登陸月球後一年寫下的。
即使在那十年裡，也不是唯一擺脫瀑布式開發的努力。Bell 和 Thayer 在 1976 年的一篇論文——首次創造了「瀑布式」一詞——在實證研究的結尾告訴我們：
在軟體開發專案的生命週期中，需求中偵測到的問題類型會發生變化。系統開發人員經常只在嘗試用設計來滿足需求時，才發現需求不足。
因此，很明顯迭代開發並非新事物，並且在敏捷宣言問世前的幾十年裡，它會持續被進一步完善。在宣言解放我們之前，瀑布式開發並非最先進的技術。而且沒有嚴肅的人懷疑需求和規格的有效性。
無論好壞，透過大量程式碼資料集訓練的廉價大型語言模型（LLM）的可用性，改變了許多人撰寫電腦程式的方式，並可以說改變了軟體的時代精神。
隨之而來一個明確的正面發展是，軟體專業人士又開始撰寫規格了。LLM——就像我們中的許多人一樣——在面對模糊性時表現不佳，而規格化問題被證明是產生正確程式碼的有效工具。《敏捷宣言》告訴我們「可運作的軟體勝於詳盡的文件」。而「規格驅動開發」告訴我們「詳盡的文件創造可運作的軟體」。而且說實話，無論有沒有 LLM，陽光底下沒有新鮮事。Royce 說：
在開始編碼之前，這三個名詞（文件、規格、設計）代表著同一件事。如果文件很差，設計就很差。如果文件還不存在，那麼就沒有設計，只有人們在思考和談論設計，這或許有些價值，但價值不大。
閱讀 1970 年和 1976 年的論文，我們不得不問 2001 年到底帶來了什麼。敏捷開發的定義模糊不清，並被市場推銷為解決了半個世紀前嚴謹工程師們早已解決的問題，而他們的論文比這更有意義。隨著我們的領域不斷變化——我們希望不斷演進——是時候以全新的視角看待事物，並將敏捷開發這個歷史的糟粕丟進歷史的垃圾桶了。
人們不禁想知道，阿波羅導航電腦的程式設計師是如何完成如此壯舉的，他們在沒有故事點（Story Points）的情況下進行程式設計，也不知道「持續關注技術卓越和良好設計能增強敏捷性」。