Scrum Guide 問世至今已經超過 15 年。到了 GenAI 與 coding agents 時代，Scrum 算不算過時？

我傾向先把問題換個方式問。AI 改變的主要不是 Agile 的核心，而是它的流程外殼。尤其是那些建立在人類口頭同步上的做法，會先鬆動。真正值得看的，是當 AI 已經能查 repo、寫 ticket、開 PR、跑測試之後，哪些工作還是得由人承擔，哪些做法則得改成機器也用得上。

現在很多團隊碰到的，不是工作自己做完了，而是塞車的位置換了。

你讓 agent 跑了一整晚。隔天早上，GitHub 上可能已經躺著幾個有待 review 的 PR、兩三種看起來都說得通的重構方向、一些測試全綠卻仍讓人不安的修改，外加幾個碰了系統邊界卻未必自知的變更。Peter Steinberger 談 OpenClaw 時，也提過自己曾讓系統跑上數小時，甚至隔夜處理重構；他甚至認為 “prompt requests” 也會變成新的日常。¹

這裡真正變快的，是程式碼產出。沒有一起變快的，則是審查、驗收、風險辨識、責任承擔和後續決策。表面上看起來像是寫得更快，實際上常常只是把瓶頸往後推。

這也是為什麼，接下來 Agile 最先被改寫的，通常不是短回饋本身，而是團隊怎麼同步、怎麼協作、怎麼把資訊往前整理。很多原本得靠人類口頭交換的內容，現在可以先由機器整理、摘要、比對、補齊，甚至先展開幾種可能方案。

很多人在正式會議前，本來就會先和 AI 討論，再把整理過的結論帶進會議。既然這件事早就在發生，那差別往往只剩下：團隊要不要正式承認它。說穿了，就是要不要把那隻早就在場外跑著的龍蝦 (OpenClaw)，正式接進協作流程裡。

OpenClaw 作者 Peter Steinberger 接受 36Kr Europe 訪談時提到，多數程式碼其實很無聊，很多時候做的只是把一種資料形狀轉成另一種。這不是他真正關心的事。 ¹

這句話有點刺耳，但也把一件事講得很坦白：很多工程安排用久了，就會從成本與取捨，慢慢變成預設，變成僵化的教條，沒有人過問它是否還有價值。

現在 LLM 與 coding agent 已經開始直接參與 repo 級搜尋、修改與驗證。很多原本被視為理所當然的做法，也該再檢查一次。分層是不是還在隔離風險，抽象是不是還在縮小修改半徑，某些 interface、mapper 和轉發層，到底在承擔工作，還是只是在延續習慣。

以前這些東西就算有點多、有點繞，通常也還撐得過去。工程師會靠經驗補上下文，靠默契避開麻煩，再把額外成本默默吞下來。

但 agent 介入之後，很多原本人類可以硬撐過去的地方，會直接變成搜尋成本、理解成本，最後讓修改失去準頭。

這篇想處理的問題很直接：今天系統裡哪些結構還在管理複雜性，哪些只是在維持形式？

很多人會把這一輪 AI 寫程式的進展，直接講成「語言模型正在取代軟體工程師」，甚至進一步講成「語言模型正在取代軟體工程」。

這樣講不算全錯，但沒有對準焦點。軟體工程沒有消失，變的是成本最高的地方不一樣了。過去 SDLC 昂貴的部分，常常落在寫程式、處理低階細節、人工重構。現在語言模型可以很快產生候選實作，原本集中在實作端的成本，就開始往別的地方移。用高德拉特的 Theory of Constraints 來看，這其實就是瓶頸轉移。

接下來比較值得看的，不是軟體工程還在不在，而是瓶頸轉去哪裡了。那些新的瓶頸，比以前好處理，還是更難處理？

軟體工程的典範確實在變，但工程紀律沒有因此結束。比較貼近現況的說法是：抽象層往上拉了，驗證負擔在重分配，治理形式也得跟著調整。

幾個月前，我在社群媒體看到一張裁員通知書的截圖。底下有一行說明：「公司說是因為導入 AI 工具，現有的人力已經足夠應付產出需求。」

這類貼文底下很快就會吵成一團。有人說 AI 終於開始搶工作了；有人說這根本是景氣問題，不要什麼都怪 AI；也有人說，這只是管理層找的藉口。

如果把問題問得精確一點，真正值得分析的，其實不是口號式的「AI 會不會取代人類工作」，而是更窄、也更接近企業實際決策的問題：

如果公司導入 AI，並且希望用它減少一部分人力，那麼這個人力縮減比例，在理論上有沒有上限或下限？

這篇想做的，就是先用一個盡量簡單的模型，把這件事的骨架抽出來。

傳統上，複雜的軟體專案，除了程式設計師之外，還會搭配系統設計師，甚至系統分析師，確保領域知識及商業邏輯都有朝對的方向前進。

生成式 AI 既然會寫程式，下一個問題就是：它也會做系統分析嗎？

理論上來說，應該是的。畢竟我們在前一篇文章都親眼看過，AI 既然能理解規格、潤飾需求、撰寫程式碼，甚至生成測試案例，那麼系統分析 (SA) 和系統設計 (SD) 這類「中間產物」，確實也難不倒它。畢竟，系統分析本質上就是資訊的整理、建模與推理，而這些都是 AI 擅長的領域。

我認為，SA/SD 也應該納入 AI 協作。尤其是從 SA/SD 擅長的建模角度，能夠協助我們及早確認領域知識及商業邏輯，檢查需求規格是否有矛盾、遺漏或模稜兩可的地方，甚至提出改善建議，幫助系統分析師更快定位問題，減少後期開發的返工成本。譬如說，透過 AI 生成的狀態轉移圖，也有助於規劃黑箱測試，提高測試覆蓋率，進而提升系統的穩定性與可靠性。

接下來就是現實問題了：讓 AI 產生的狀態圖，真的比人工畫得更好嗎？能省多少時間？

這就要實測了！現在，就讓我們拿前一篇文章的規格作為引子，看看 AI 生成的狀態圖表現如何吧！