AI 重塑軟體開發:McKinsey 揭示從 Agile 到 AI-Native 的典範轉移
McKinsey 的 Software X 團隊分享了一項針對 300 家企業的研究,揭示了 AI 工具在軟體開發領域的真實影響。
儘管個人開發者使用 AI 工具能將原本需要數小時甚至數天的工作縮短至幾分鐘,但企業整體的生產力提升卻僅有 5-15%。
這中間存在著巨大的落差。
問題的核心在於,當開發速度加快後,卻出現了新的瓶頸。
團隊協作方式沒有改變,程式碼審查仍然採用人工方式,而 AI 產生的大量程式碼也帶來了更多技術債和複雜度。
卡內基梅隆大學的研究報告證實了這一點。
McKinsey 指出,企業仍在用 Agile 時代的約束條件運作:8-10 人團隊、兩週衝刺週期、以 story 為單位的工作分配。
但 AI 的影響是不均勻的,某些任務效果顯著,某些則不然;某些開發者經驗豐富,某些還在學習。
這讓工程主管很難有效分配工作和資源,造成大量效率損失。
頂尖企業的做法完全不同。
研究發現,他們採用 AI-native 工作流程的可能性高出 7 倍,並在整個軟體開發生命週期中實施 4 個以上的 AI 用例,而非僅限於程式碼審查或編碼輔助。
他們也更可能建立 AI-native 角色,機率高出 6 倍,採用更小的團隊(3-5 人的「一片披薩」團隊,取代傳統的「兩片披薩」團隊),並創造新的職位。
這帶來了 5-6 倍的上市速度提升和交付速度,同時提高了產出品質和一致性。
具體的轉變包括:從季度規劃轉向持續規劃,從 story 驅動轉向 spec 驅動開發,PM 與 AI 代理一起迭代規格而非撰寫冗長的 PRD。
在人才方面,產品開發者不再只負責前端或後端,而是具備全端能力,管理和編排 AI 代理。
PM 開始直接在程式碼中創建原型,而非反覆修改 PRD。
McKinsey 以 Cursor 這家 AI-native 新創公司為例,說明了這些轉變如何在實務中運作。
在一家國際銀行的案例研究中,McKinsey 測試了幾項團隊層級的干預措施。
團隊領導使用 AI 代理根據團隊速度和交付歷史來分配工作,與 AI 共同創建多個原型並迭代驗收標準,確保安全性和可觀察性需求一致。
這防止了下游的返工。
團隊依據工作流程重組,一組專注於小型錯誤修復,另一組專注於綠地開發。
AI 代理在背景中檢查潛在的跨儲存庫影響,減少開發者的除錯時間。
PM 直接觀察即時客戶反饋來重新排定功能優先順序,而非等待數據科學家的輸入,加速了待辦事項的處理。
結果顯示,AI 代理使用量增加了 60 倍以上,程式碼合併量增加了 51%,同時提高了效率。
另一家科技公司的案例則展示了角色轉變的重要性。
儘管約 70% 的企業尚未改變職位定義,頂尖企業卻已經在重新定義角色。
McKinsey 幫助一家客戶從傳統的兩片披薩團隊模式轉向更小的團隊,整合了原本由不同角色執行的任務。
在維持相同人數的情況下,創造了更多團隊,每個團隊的表現與之前相當甚至更好,程式碼品質有所提升,輸出速度顯著加快。
然而,McKinsey 強調,擴展到整個組織才是關鍵挑戰。
許多企業有數百個團隊和數千甚至數萬名員工。
頂尖企業與停滯在 10% 改進幅度的企業之間,最大差異在於變革管理的執行方式。
成功的變革管理需要同時做對 20-30 件小事:溝通方式、激勵機制、培訓方法等都必須到位。
McKinsey 舉例說明,某科技公司在推出 AI 工具後,使用率起伏不定且效果不彰。
他們必須重新設定期望、提供手把手的培訓(包括「帶著你的程式碼來」工作坊和教練支援),並建立測量系統。
特別是在開發者剛開始養成新習慣的前幾個衝刺週期,這些支援至關重要。
另一個客戶的成功因素包括:設立程式碼實驗室、引入新的認證制度來激勵員工改變日常工作方式。
這些看似微小的介入措施累積起來,創造了他們所需的改變。
McKinsey 也強調,健全的測量系統不僅要追蹤採用率,更要優先考量成果。
調查發現,表現最差的企業甚至不衡量速度,只有 10% 衡量生產力。
頂尖企業則建立了全面的測量系統,涵蓋從投入到影響的所有層面:投資金額、培訓資源、工具採用的廣度和深度、開發者滿意度、程式碼品質和韌性(如優先錯誤的平均解決時間)、收入達成時間、成本降低等經濟成果。
McKinsey 提出的願景是:即使 AI 代理的智慧不斷提升、人類對 AI 的運用更加熟練,這個新的軟體開發模型依然適用。
更短的衝刺週期、更小但數量更多的團隊,將為企業帶來長期成功。
McKinsey 的建議很明確:現在就開始。
這是一場人的變革,需要時間,是一段旅程。
每個組織都需要找到適合自己的模式,設定大膽的目標。
