🧭 第一部分：完整故事 — 「當 GenAI 開發遇上真實世界」
在 2025 年的春天，TechVision，一家中型的軟體公司，決定在開發流程中全面導入 GenAI 工具，如 Copilot、ChatGPT、AutoML 來提升生產力。當時的氛圍充滿希望與野心——
“如果每個工程師能透過 GenAI 將開發效率提升 30%，那麼整體產能會翻倍，甚至三倍！”
——CTO Leo 在全體會議中的信心喊話
起初，這確實看起來奏效。開發速度明顯加快，功能交付時間從 3 週縮短到 1 週，團隊彷彿解鎖了新的生產力。
然而，不到兩個月，問題接踵而至。
🔥 問題一：程式碼快，但爛
當 GenAI 大量產出程式碼時，團隊也開始疲於應付：
- 代碼風格不一致，不符合團隊慣例。
- 錯誤處理機制常被忽略，邏輯只處理「理想路徑」。
- 測試覆蓋率低，生成的單元測試多是「happy path」。
“AI 幫我生成了整份訂單流程的程式，但我根本不敢 merge 到主幹。”
——資深工程師 Kevin
整合時錯誤層出不窮，技術負債快速堆積，讓團隊回到了「多寫不如少寫」的保守狀態。
🤯 問題二：需求被「自以為」理解了
當 GenAI 根據自然語言生成代碼時，它的「理解」只是文字關聯而非語意深度：
- PO 說：「只要在優惠活動內，滿千就打九折」
- GenAI 產生的邏輯卻是：「滿千就打折，活動期間與否不管」
測試後才發現問題，但已經上線、用戶投訴湧入客服中心。
更嚴重的是，每個團隊對需求的解讀都有差異。即使 PO 寫了看似完整的 User Story，但在 GenAI 幫忙產碼後，不同團隊以不同方式「想像」出相同功能，造成嚴重的功能分裂。
🧱 問題三：跨團隊整合失控
TechVision 採用多個 Scrum 團隊並行開發：
- 團隊 A 開發購物車模組
- 團隊 B 開發付款流程
- 團隊 C 處理優惠與活動邏輯
這些團隊各自用 GenAI 生成模組代碼後，一旦進行整合測試，結果慘不忍睹：
- 資料結構不一致
- API 定義差異巨大
- 錯誤處理方式各自為政
整合測試每週至少掛 3 次，修復時間平均超過 2 天，整個 CI/CD 流水線形同虛設。
“我們用最快的方式，產出最爛的整合。”
——測試負責人 Yvonne 無奈地說
🌀 問題四：需求改了，程式碼改不完
業務變動快速是日常，但每次改動都像重啟世界。
PO 只改了一句話：「優惠券只能在結帳前輸入」，結果：
- GenAI 生成的程式碼無法自動調整流程
- 測試案例沒更新，CI 一直爆紅
- 前端與後端都要重新整合邏輯
變更的成本比從頭開發還高，大家開始懷疑：“我們到底是掌控 AI？還是被 AI 帶著跑？”
🧭 轉機：從混亂中找到方法
CTO Leo 決定重整開發流程。他回頭檢視問題的根源，發現不是 GenAI 工具不好，而是：
“我們讓 AI 解釋不清楚的需求，然後自己再去瞎猜AI在說什麼。而這些猜測，又被我們拿來打造程式。”
——Leo 的覺醒時刻
Leo 與 Agile 教練開始導入兩個關鍵做法：
- Specification by Example (SBE)：讓需求不再只是「說說」
- 每個需求都要以實際範例寫出來
- PO、Dev、QA 三方共創
- 範例轉成自動化測試，作為開發與驗收依據
- Large Scale Scrum (LeSS)：讓多團隊像一個團隊
- 每週一次 Multi-team PBR（共創待辦事項）
- 每 Sprint 開始的 Multi-team Sprint Planning（同步任務分配與依賴）
- 所有團隊使用同一組 SBE 範例作為需求規格來源
🌱 成果轉變：
| 轉變前 | 轉變後 |
|---|---|
| 每週整合錯誤超過 10 次 | 降到 3 次以下 |
| 新需求重工平均 2 天 | 降到 0.5 天 |
| 跨團隊整合會議佔比 20% 時間 | 降到 8% |
| PO、Dev、QA 理解偏差率 >50% | 降至 <10% |
SBE 給了 GenAI「正確的語言」來生成程式碼，LeSS 給了團隊「正確的舞台」來協作。
發表迴響