McKinsey & Company 的 Martin Harrysson 與 Natasha Maniar 在 AI Engineer Code Summit 上，以調查 300 家企業的數據為基礎，探討 AI 時代下敏捷開發模式的瓶頸與轉型方向。他們指出多數大型企業僅看到 5-15% 的生產力提升，遠低於 AI 工具的真正潛力，關鍵在於企業需要徹底改變團隊結構、角色定義與工作流程，從「兩個披薩團隊」轉向更小的 3-5 人 Pod，並建立 AI 原生的工作模式。

原影片連結：https://www.youtube.com/watch?v=SZStlIhyTCY

影片重點

• 大多數企業雖然導入了 AI 工具，但整體生產力提升僅 5-15%，存在巨大的落差
• AI 帶來的生產力提升高度不均勻——某些任務效果驚人，某些則不然
• 傳統敏捷模式（8-10 人團隊、兩週衝刺）已成為 AI 時代的瓶頸
• 頂尖企業導入 AI 原生工作流程的可能性是一般企業的 7 倍
• 團隊應從「兩個披薩」縮小為 3-5 人的「一個披薩 Pod」
• 角色需要重新定義：工程師從執行者轉為協調者，PM 直接用程式碼建立原型
• 某銀行客戶實驗中，Agent 使用量增加 60 倍，程式碼合併量增加 51%
• 變革管理是規模化的最大關鍵，需要同時做對 20-30 件小事

詳細內容

[00:00] AI 時代的典範轉移

Martin 開場回顧了過去數十年軟體開發方法論的演變。每一次重大技術突破都伴隨著開發範式的轉變——從瀑布式到敏捷，而現在 AI 正帶來下一次典範轉移。他回憶近 20 年前自己作為入門工程師時，親歷公司從傳統模式轉向敏捷的巨大變革：導入看板、站立會議和各種敏捷儀式。如今 AI 在軟體開發領域的影響，正預示著另一次同等規模的變革即將到來。

[02:30] 個人生產力 vs 組織生產力的落差

雖然 AI 工具在個人層面展現了驚人效果——過去需要數天的工作現在幾分鐘就能完成，但 McKinsey 對約 300 家企業的調查顯示，整體組織層面的生產力提升往往只有 5-15%。這個「潛力」與「現實」之間的巨大落差，源自一系列新瓶頸的出現：團隊協作方式沒有跟上速度變化、大量新生成的程式碼仍依賴人工審查，以及 Carnegie Mellon 研究指出的 AI 生成程式碼正在放大技術債務的問題。

[05:30] 工作分配與審查的瓶頸

Martin 指出兩個主要的速率限制器。第一是工作分配：AI 和 Agent 的效果高度不均——某些任務效果極佳，某些則否；團隊成員的 AI 使用經驗也參差不齊。這使得工程主管很難有效地分配工作和資源。第二是工作審查：Agent 收到的需求描述往往模糊不清，驗收標準不夠明確，導致產出的程式碼不符預期，最終只能依賴大量人工審查來把關，反而增加了手動工作量。

[08:00] 不同場景需要不同的運作模式

團隊指出改造產品開發生命週期（PDLC）並非一體適用。不同類型的工程任務需要不同的人機協作模式。例如：現代化遺留程式碼庫需要高度的程式碼上下文理解，但產出明確，適合採用「Agent 工廠」模式——人類提供初始規格和最終審查，中間由 Agent 自主完成。而全新功能開發則可能受益於非確定性的產出和更多變化，適合採用「迭代循環」模式，讓 Agent 作為共同創作者提供更多選項，促進更快的回饋循環。

[10:00] 頂尖企業的特徵：AI 原生工作流程與角色

McKinsey 的 300 家企業調查發現，頂尖表現者有明顯的共同特徵。他們導入 AI 原生工作流程的可能性是一般企業的 7 倍——這意味著在軟體開發生命週期中擴展超過四個 AI 用例，而非僅限於程式碼審查或輔助編碼。他們擁有 AI 原生角色的可能性是 6 倍——以更小的 Pod、不同的技能組合和全新角色來運作。這些轉變帶來了 5-6 倍的上市速度和交付速度提升，以及更高品質、更一致的產出。

具體來說，AI 原生工作流程意味著從季度規劃轉向持續規劃，工作單位從用戶故事驅動轉為規格驅動開發，PM 與 Agent 共同迭代規格而非撰寫冗長的產品需求文件（PRD）。

[12:30] 從「兩個披薩團隊」到「一個披薩 Pod」

在人才模型方面，AI 原生角色意味著從傳統的 8-10 人「兩個披薩團隊」縮減為 3-5 人的「一個披薩 Pod」。不再區分 QA、前端和後端工程師，而是整合為更全面的角色——「產品建造者」負責管理和協調 Agent，具備全端能力，並深入理解程式碼庫的完整架構。PM 開始直接用程式碼建立原型，而非反覆修改冗長的 PRD。

演講者提到他們在文章中研究了一些 AI 原生新創公司，發現它們已經實現了所有這些轉變，包括 Cursor 公司內部的運作方式。

[14:30] 銀行客戶案例：團隊層級的實驗

對於建立在敏捷模式上的大型企業，McKinsey 分享了與一家國際銀行合作的案例研究。他們針對敏捷儀式中的步驟順序、以及 Agent 和人類在衝刺週期中的角色進行了團隊層級的介入。

具體措施包括：團隊主管根據團隊速度和交付歷史數據，使用 Agent 分配衝刺故事；共同創建多個原型，與 Agent 迭代安全性和可觀察性的驗收標準；依工作流程重組小隊（bug 修復和全新開發分開）；使用背景 Agent 分析跨儲存庫影響以減少除錯時間；PM 直接觀察即時客戶回饋來重新排列功能優先序。

結果令人矚目：Agent 使用量增加超過 60 倍，程式碼合併量增加 51%，且交付速度直接與該銀行的業務優先事項掛鉤。

[17:30] 角色重新定義的緊迫性

演講者強調，目前約 70% 的受訪企業完全沒有改變角色定義。企業期待員工用新方式工作，但角色描述和職責理解仍停留在兩年前。實際上，工程師正從單純的程式碼撰寫轉向工作協調和 Agent 管理，產品經理的角色也在根本性地改變。

另一個客戶案例展示了從傳統的「兩個披薩團隊」模型轉向更小 Pod 的實驗。透過整合角色，用相同人數創建更多團隊，每個 Pod 維持原有的產出水準甚至更好，程式碼品質得到維持甚至提升。

[20:00] 規模化的關鍵：變革管理

Martin 指出，從團隊層級擴展到整個組織（往往涉及數百個團隊、數千甚至數萬人）時，最大的差異在於變革管理。那些僅看到 10% 改進的企業與看到顯著改進的企業之間的區別，在於能否同時做對 20-30 件甚至更多的小事——包括溝通方式、激勵機制和技能提升，所有環節必須協調配合。

他分享了一個技術公司的案例：最初推出 AI 工具時，使用率時高時低且效果不佳。團隊不得不進行全面重設——重新設定期望、提供更多實作培訓（帶自己的程式碼來練習）、安排教練陪伴最初幾個衝刺，並建立度量系統追蹤變化。

[23:00] 建立全面的度量體系

Natasha 強調建立優先考量「成果」而非僅關注「採用率」的度量系統至關重要。調查中表現最差的企業甚至沒有在衡量速度，僅 10% 在衡量生產力。

McKinsey 為客戶建立的全面度量體系涵蓋四個層次：投入（工具投資、培訓資源）、直接產出（AI 工具的廣度和深度帶來的速度與產能提升）、開發者體驗（NPS 分數、工作滿意度）與程式碼品質（安全性、韌性、Priority Bug 平均解決時間），以及經濟成果（營收目標達成速度、高品質功能的價格差異化、每個 Pod 的人力成本降低）。

[25:30] 未來展望與關鍵建議

展望未來，即使 Agent 智能持續提升、人類對 AI 更加熟練，他們相信「更短的衝刺週期、更小但更多的團隊」這個模型仍然適用。

Martin 最後給出關鍵建議：第一，立刻開始行動——這是一場關於人的變革，需要時間，也是一段旅程。第二，找出適合自己組織的模式，並設定大膽的目標。

我的想法

這場演講最有價值的觀點在於揭示了一個反直覺的現象：AI 工具明明很強大，但大多數企業的組織層面生產力提升卻很有限。這不是工具的問題，而是人和流程的問題。這讓我想到 Conway’s Law——系統的架構反映組織的溝通結構。當 AI 改變了「誰做什麼」和「怎麼做」，組織結構如果不跟著變，就會成為最大的瓶頸。

「從兩個披薩到一個披薩」的團隊模型值得關注。但這裡有個潛在風險：更小的團隊意味著每個人需要更廣的技能覆蓋，這對人才要求其實更高了。企業在縮小團隊的同時，需要大量投資在人才培養上，否則可能適得其反。

另外值得注意的是，他們提到的「規格驅動開發」取代「用戶故事驅動」，本質上是在說：當 Agent 成為主要的程式碼撰寫者時，給它的指令品質決定了產出品質。這把壓力從「寫程式碼」轉移到了「寫規格」——某種程度上，Prompt Engineering 的思維正在滲透到整個軟體開發流程中。

最後，70% 的企業完全沒有改變角色定義這個數據很驚人。這表明大多數組織仍在用舊框架理解新工具，等於是把跑車開在泥巴路上。對於正在推動 AI 轉型的技術主管來說，改變組織結構和角色定義可能比選擇哪個 AI 工具更重要。