2015 年,Alistair Cockburn 有一份簡報,標題是「Heart of Agile meets Risk Reduction 2.0 (Disciplined Learning)」。十年後回頭看,這份簡報裡最核心的幾個論證,對今天用 AI 寫程式的團隊來說,比當年更切身。
這篇文章先整理簡報的主要內容,後半段再從 AI coding 的角度重新檢視這些論證。文中標註的頁數對應原始投影片。
簡報來源:https://confadmin.trifork.com/dl/scrum/Alistair%20The%20Heart%20of%20Agile%20Slides.pdf
軟體開發在做的三件事(第 2 頁)
Cockburn 把軟體開發拆成三個同時進行的活動:發明、溝通、決策。
溝通這條線有兩層困難疊在一起。人們要表達的,是他們自己也還沒完全理解的東西,而且這個東西一直在變。更麻煩的是,最終的接收者是「一個對錯誤毫不寬容的解譯器」——電腦。人跟人溝通可以靠語境和默契補足,電腦少一個分號就是不動。
決策這條線,他只講了兩句話:每個決策都有經濟後果,資源有限。這兩句話是後面整套論證的地基。決策既然有經濟性,就可以用經濟學的工具來分析——庫存、佇列、批量。
宣言留下的漏洞(第 3 頁)
Cockburn 是 Agile Manifesto 的共同起草人之一,他很清楚宣言每一條怎麼被歪讀:
「個人與互動重於流程與工具」被讀成「耶!我再也不用遵守那些愚蠢的流程了!」「可用的軟體重於詳盡的文件」被讀成「把文件全丟掉!」「與客戶合作重於合約協商」被讀成「我做完就是做完,永遠不用承諾時間!」「回應變化重於遵循計畫」被讀成「不要計畫!不要專案經理!不要架構師!」
這種版本的敏捷,當然人人搶著加入,因為它把所有紀律都免除了。Cockburn 用 wimpy-ness 形容這個現象:宣言的「A over B」句式在語言上留了漏洞,它說的是更重視 A,卻很容易被讀成 B 不重要。
這份簡報後面的內容,其實就是在把紀律裝回去。裝回去的方式很硬:排隊理論、風險經濟學。
守破離,然後是「心」(第 4–6 頁)
技能發展的四個階段(第 4 頁):守,學一招,照做;破,收集多種技法,知道每招的適用場合;離,自創與融合,方法已經內化到說不清楚自己在用什麼;心(Kokoro),回歸簡單。
他畫了一條曲線,橫軸是熟練度,縱軸是複雜程度。初學者的世界很簡單(code-and-deliver!),中段的方法收藏家最複雜——Scrum、XP、DSDM、Lean、Kanban 全都在這一段——真正的大師又走回簡單。起點和終點的簡單並非同一種:一邊是無知的簡單,一邊是通透之後的簡單。
Heart of Agile 就是 Cockburn 給自己的 Kokoro 答案。整個敏捷,壓縮成四個動詞:
Collaborate、Deliver、Reflect、Improve。(第 5 頁)
合作、交付、反思、改進。如果團隊真的做到這四件事,就是敏捷的,不管有沒有站立會議、有沒有 Sprint。反過來,儀式全套照跑但這四件事沒發生,那只是敏捷劇場。
需要細節時,四個字各自往外展開(第 6 頁)。Collaborate 拆成合作(傾聽、主動站出來)與信任(允許失敗、放手讓別人做)。Deliver 拆成學習與收入——交付的產出除了收入,還有學習:商業假設對不對、技術可不可行、成本估得準不準。Reflect 拆成向外檢視(目標與結果的落差)與向內省視(把情緒納入,聚焦向前)。Improve 拆成實驗(前提是情緒安全感)與改變(具體、限制變更數量,但積極地做)。
Deliver 底下那兩個關鍵字,學習(Learning)與佇列(Queues),埋了整份簡報兩大主題的種子。
每一行程式碼都是一個決策(第 7–10 頁)
對已過入門階段的人,Cockburn 提出五個看待敏捷開發的理論透鏡(第 7 頁):合作賽局、工匠專業、流動管理、知識獲取、自我覺察。這份簡報深入其中兩個,先談流動管理(第 8 頁)。
從開發現場的抱怨鏈看起(第 9 頁)。UI 設計師在想:真希望他們趕快決定要什麼風格。程式設計師在想:真希望 UI 設計趕快定案。業務分析師在等用戶決定要什麼功能。測試人員在抱怨:真希望他們寫程式前多想一下。
表面上大家在等文件、等設計稿、等程式碼。Cockburn 說穿了:大家在等的都是決策。然後是整份簡報最重的一句:
每一行程式碼都是一個決策。
旁邊還補了一刀:「想想測試人員一次被塞多少行程式碼!」——也就是一次被塞多少個待驗證的決策。
「軟體開發像製造業」這個類比被講了幾十年,也被罵了幾十年,因為軟體沒有實體零件、沒有重複生產。Cockburn 的修正是:類比可以成立,但庫存必須定義對。Inventory = Decisions(第 10 頁)。 在製品既非程式碼行數,也非功能數,是「已經做出、但還沒被下游驗證的決策」。
這個定義一換,精實製造的整套工具箱——批量、佇列、瓶頸、拉式系統——就能合法地搬進軟體開發。
依賴網路決定你的流程(第 11 頁)
Cockburn 畫了三個團隊的決策依賴網路,紅圈標出決策堆積的位置。
團隊一:用戶夠、分析師少、程式設計師很多,但只有一個孤軍奮戰的資料庫設計師。決策全堆在 DBA 前面,瓶頸在下游。團隊二:分析師很多、程式設計師不夠,決策堆在開發前面。團隊三:用戶與贊助者缺席,決策堆在最上游,整條下游都在等一個不在場的人。
三個團隊如果套同一套流程,必死。最佳流程取決於決策堆在哪裡、誰在等誰。這也解釋了為什麼照抄別家的敏捷導入經常失敗——瓶頸位置不同,藥方就不同。
排隊理論:1,000 行還是 100 行(第 12–15 頁)
接著是兩張要對照著讀的圖(第 12–13 頁)。橫軸是時間,縱軸是累積數量,上面那條線是「到達」,下面那條線是「被服務」。兩線之間的區域,垂直量下去是某一時刻的佇列長度,水平量過去是某個項目在佇列裡等待的時間。
大批量轉移:東西一次大量湧入,兩條線張得很開,佇列長、每個項目等很久,而且系統行為難以預測。小批量轉移:兩條線貼得很近,佇列短、等待短、流動平順可預測。
然後落地到一個每天都在發生的選擇(第 14 頁):一次交給測試人員 1,000 行程式碼,還是 100 行?
1,000 行的版本,每一行程式碼(每個設計決策)在測試佇列裡躺很久才被驗證或推翻。這段等待期間,程式設計師繼續在這些未驗證的決策上面疊新的決策——如果底下的決策錯了,上面蓋的全部重工。等待越久,錯誤決策的利息滾越大。
100 行的版本,決策快速進、快速被驗證,錯了馬上知道,重工範圍小。
Cockburn 的提示只有三個字:Prefer 100。這就是持續整合、小 PR、頻繁交付背後的數學。整段的結論(第 15 頁):減少流動中的決策數量,平衡整條流,把塞車變成連續流。
設計就是獲取知識(第 16–18 頁)
簡報的第二個主軸,從一句話開始(第 16 頁):Design is Knowledge Acquisition。設計活動的產出是知識——關於「這樣做行不行得通」的知識。這個框架一立,專案管理的問題就變成:你打算什麼時候取得知識?
Big-Bang 整合是一種晚學習策略(第 17 頁)。成本那條線穩定往上爬,知識曲線卻幾乎全程貼地,直到最後整合的 moment of truth 才垂直飆升。錢一直在燒,但你到最後一刻才知道系統能不能動。前面整段時期幾乎不產生知識,也不降低風險,所有的風險押在最後一注。
早期持續整合則讓知識曲線從一開始就以小步階往上爬(第 18 頁)。每次整合都是一次小的 moment of truth,買到一塊知識。曲線前段陡(風險快速下降),後段趨平,進入「開發順序對知識而言無所謂」的區域——該學的都學到了。
注意他的用詞:pay to learn。早期整合有成本,搭鷹架、建管線、切小塊都要錢。但你付的錢買到了知識;Big-Bang 付一樣的錢,什麼都沒買到。
Risk、Value、Tail(第 19–21 頁)
策略講完整就是(第 19 頁):專案前期,刻意挑知識密度高的項目做——最能消除不確定性的,而未必是最有價值的。要降的風險四類:商業(有人要買嗎)、社會(這群人能合作嗎)、技術(做得出來嗎)、成本與時程(估得準嗎)。風險降下來之後,切換模式,按商業價值排序衝刺。
於是專案自然分成三段:Risk、Value、Tail(第 20 頁)。每個 backlog 項目都可以打三個分數:風險降低量、價值、尾巴程度。風險分高的排前面,價值分高的排中間,尾巴項目(可有可無的打磨)排最後。
Tail 階段的策略叫 Trim-the-Tail(第 21 頁),這是整套方法的兌現時刻。因為最不重要的東西被留在最後,接近交付日時,手上有一個真正的選擇權:砍掉尾巴,準時甚至提早交付;或刻意延後,換更多更好的東西。由價值或日期做決定,而非由恐慌做決定。對比傳統專案的結尾——最難、風險最高的整合工作堆在最後,交付日只能延,沒得選。這個選擇權,是早期降風險買來的。
簡報最後附了一條半開玩笑的公式(第 23 頁):
專案交付時間 = 業務負責人與程式設計師的距離(log)× 用戶與程式設計師之間的人數 × 程式設計師人數(log)
三個變數裡,中間人數是線性項,殺傷力最大。用戶跟程式設計師之間每多一層轉述,決策傳遞就多一站佇列、多一次失真。想快,拿掉中間人比控制團隊規模更重要。
從 AI coding 的角度重讀這份簡報
以上是 2015 年的內容。接下來把每個論證放到今天的 AI coding 現場,逐一檢驗。
庫存的定義沒變,湧入的速率變了
Inventory = Decisions 這條定義,在 AI coding 時代完全成立,而且威力更大。
AI 改變的是決策的「產生成本」。過去一個決策(一行程式碼)要人腦想過、手打出來,產生速率天然受限於人的思考速度。現在 agent 一個下午可以產出幾千行——也就是幾千個決策——湧進驗證佇列。
回頭看第 14 頁那張圖:1,000 行 vs 100 行。2015 年,一次塞 1,000 行給測試人員是一個「壞習慣」,團隊可以選擇改掉。2026 年,這是 AI coding 的預設輸出模式。你請 agent 實作一個功能,它交回來的就是一大包。大批量轉移從壞習慣變成了工具的預設行為。
排隊理論本身沒有變。到達線暴衝、服務線不動,兩線之間的面積就是暴增的等待——每個未驗證決策在佇列裡的滯留時間。差別只在於,以前到達速率跟服務速率是同一群人決定的,現在到達速率被工具解放了,服務速率還是綁在人身上。
WIP 限制應該掛在哪裡
這直接推出一個 Kanban 板設計的結論。傳統的 WIP 限制掛在 Doing 欄,限制的是「同時開工的項目數」,因為當年的稀缺資源是開發產能。
Cockburn 的框架給了更精確的說法:WIP 限制真正該管的是「流動中的未驗證決策總量」。當 AI 把產出端的產能放大十倍,稀缺資源移到了 review、測試、驗收——也就是把決策從「未驗證」變成「已驗證」的那幾個欄位。板子上的限制若還掛在 Doing,等於在管一個已經不稀缺的資源,而真正的堰塞湖在 Review 欄堆成山,板子卻顯示一切正常。
「每行程式碼都是決策」在這裡還有一個更細的推論:AI 產出的 1,000 行,決策密度跟人寫的 1,000 行不一樣。人寫的程式碼,每個決策至少被作者本人想過一次,算是半驗證品。AI 產出的程式碼,每個決策對團隊來說都是全新的、零驗證的。同樣行數,湧入佇列的未驗證決策量更大。
Big-Bang 的還魂
第 17 頁那張晚學習曲線,值得再看一眼。
敏捷社群花了二十年把 Big-Bang 整合打死:小步交付、持續整合、頻繁回饋。結果 AI coding 讓它換了個形式回來。「請 agent 做完整個功能再來看結果」在結構上就是 Big-Bang:成本(token、時間)持續投入,知識曲線貼地,直到你打開那包程式碼的 moment of truth。
vibe coding 的典型失敗模式,用這張圖可以完整解釋:前八成的過程爽快無比,因為你一直在產出但從未驗證,所有風險都被推遲到最後。等到最後整合、上線、或需求方實際使用的那一刻,貼地的知識曲線垂直起飛——通常以災難的形式。
解法也是舊的:把 pay-to-learn 搬進 agent 工作流。逼 agent 小批量交付,每一小批都過驗證關卡再繼續。這會慢,而且感覺上「浪費了 AI 的速度」。但 Cockburn 早就說過,早期整合本來就是付費買知識,重點是你付的錢有沒有換到東西。讓 agent 全速跑完再驗收,付的錢一樣多,買到的知識是零。
Knowledge Acquisition 的斷裂:程式碼有了,知識沒進來
Design is Knowledge Acquisition 這一條,在 AI coding 時代出現了一個 2015 年不存在的斷裂。
過去,寫程式的過程本身就是獲取知識的過程。你踩過的坑、試錯的路徑、最後為什麼這樣設計,這些知識隨著寫碼進到你腦裡。程式碼和知識是同一個過程的兩個產出。
AI 把這兩個產出拆開了。agent 交付了程式碼,但獲取知識的是 agent 的 context window,session 結束就蒸發。團隊拿到了設計的「結果」,沒有拿到設計過程中產生的「知識」。用 Cockburn 的話說:設計發生了,knowledge acquisition 沒有發生在人身上。
這就是認知負債的理論根源。系統裡的決策數量暴增,團隊腦中對這些決策的理解沒有等比增加,兩者的差距就是負債。等到要改、要修、要對系統負責的時候,負債連本帶利討回來。
所以驗證在 AI 時代有雙重功能。第一重是傳統的:確認決策正確。第二重是新的:review 和驗收是知識從程式碼回流到人腦的唯一管道。跳過驗證,你失去的除了品質保證,還有團隊對系統的理解本身。
距離公式的新變數
最後看那條交付時間公式。中間人數是線性項,每多一層轉述,多一站佇列、多一次失真。
AI agent 在這條公式裡是什麼?樂觀的講法:AI 消滅了中間人,業務可以直接「跟程式碼對話」,N(u..p) 趨近於零。
但依 Cockburn 的定義檢查一下:中間人的傷害在於轉述造成的決策失真。AI 恰好是一個轉述者——它把你的自然語言意圖轉譯成程式碼決策,而且轉譯的忠實度沒有保證。你說的和它理解的之間有落差,它理解的和它產出的之間又有落差。從決策失真的角度看,AI 是插進 N(u..p) 的一個新節點,只是這個節點轉述得飛快,失真卻默默發生。
要讓 AI 真的減少距離,條件是失真可以被便宜地偵測。這就繞回規格的問題:意圖用可執行的實例寫清楚,轉譯的失真才有辦法在每一小批交付時被抓出來。規格模糊,AI 就是一個高速失真的中間人;規格清楚,它才接近那個「消滅中間層」的樂觀版本。
收尾
這份簡報十年前的原始論證,一條都不用改:每行程式碼都是決策、未驗證的決策就是庫存、大批量讓系統不可預測、晚學習把風險押在最後一注。AI coding 改變的只有參數——決策的產生成本趨近零,湧入速率暴增,而驗證產能還是人的產能。
參數變了,結論反而更尖銳。2015 年,Prefer 100 是一個好建議;2026 年,它是讓 AI coding 不翻車的生存條件。
參考來源
Alistair Cockburn, “Heart of Agile meets Risk Reduction 2.0 (Disciplined Learning)”, 2015. https://confadmin.trifork.com/dl/scrum/Alistair%20The%20Heart%20of%20Agile%20Slides.pdf
發表迴響