《Clean Agile》Podcast 準備稿：計畫遊戲與業務實踐
書名： Clean Agile 敏捷整潔之道（Back to Basics） 作者： Robert C. Martin（Uncle Bob） 系列： Reading Uncle Bob（恩普拉氏） 公開標題建議： Reading Uncle Bob｜Clean Agile．計畫遊戲：用索引卡管理整個專案 (2/6) 涵蓋範圍： 第3章 Business Practices（Planning、Small Releases、Acceptance Tests、Whole Team）
背景速覽
這是《Clean Agile》第二集，進入 Ron Jeffries「Circle of Life」最外圈——面向業務的實踐，大致等同於 Scrum 的範疇。這一章回答一個關鍵問題：業務方和開發團隊之間那道鴻溝，怎麼用具體實踐去填？ 四個工具：Planning（計畫遊戲）、Small Releases（小發布）、Acceptance Tests（驗收測試）、Whole Team（整個團隊）。Kent Beck 在 2001 年說過，敏捷的目標之一就是修復業務與開發的裂痕——這一章就是那把修補工具。
一句話重點
估算永遠是「不精確的猜測」，但敏捷不靠精確取勝——它靠大量模糊估算的加總會趨於穩定（大數法則）、靠 Yesterday’s Weather（昨日天氣）做預測、靠 Acceptance Tests 把「完成」變成一個無可爭辯的客觀事實，從而把業務與開發的關係從「對賭」變成「協作」。
值得討論的重點
1. 估算的哲學：準確不等於精確
這是反直覺、最值得展開的一點。一個估算可以很準確但不精確——關鍵是花最少的時間，找到「仍然準確的最小範圍」。Story Points 不是時間單位，而是相對工作量單位，本身模糊得要命，但靠大數法則，一堆模糊數字加總起來會穩定。估算流程超簡單：挑一個中等複雜度的 Story 當 Golden Story（如 Login = 3 點），其他都跟它比；用 Flying Fingers 或 Planning Poker 做共識估算。對大任務則用三值分析（Best 5% / Nominal 50% / Worst 95%，這是 PERT 的基礎）。這套方法的精神是：別假裝你能精確預測未來，但你可以誠實地框出範圍。
2. INVEST 與「薄的垂直切片」
好 Story 的六條檢驗：Independent（獨立）、Negotiable（可協商）、Valuable（有價值）、Estimable（可估算）、Small（夠小）、Testable（可測試）。最值得講的是兩個地雷：第一，Story 必須是「薄的垂直切片」——橫切 GUI、中間層、資料庫所有層，而不是只做某一層；第二，Refactoring 和 Architecture 永遠不是 Story。為什麼？因為 Story 必須對業務有價值，而「重構」「清理架構」對業務沒有可見價值——它們透過別的方式（藏在日常開發裡）處理。這條常被違反，很多團隊把「技術債清理」排成 Story 然後永遠被砍，就是搞錯了。
3. Velocity 是量測值，不是目標——別對體溫計施壓
這是控制理論的基本功，也是這章最深的管理洞見。對 Velocity 施壓，只會導致點數通膨——團隊會無意識地膨脹估算來顯示「我們更快了」，但其實一點都沒快。Velocity 上升通常不是真的變快，是通膨；Velocity 下降最可能是程式碼品質下滑、技術債累積。解藥是 Golden Story：持續拿新 Story 跟最初那個 Login=3 點比，就能偵測通膨。一句話記憶點：不要對你正在量測的東西施壓。 你不會為了「退燒」去捏體溫計。
4. Acceptance Tests：把「完成」變成客觀事實——以及缺陷黑市
驗收測試的核心理念出奇簡單：需求就是測試。 「使用者輸入正確帳密並點登入，應顯示歡迎頁」——這既是規格也是測試，還能自動化。然後是那條鐵律：Story 在 Acceptance Test 寫出前不算被定義，在通過前不算完成。 這是「完成」的唯一定義，終結了所有「我覺得做完了」的口水仗。最辛辣的是 QA Disease（缺陷黑市經濟）：當 QA 在流程尾端，QA 靠「找到的缺陷數」證明價值、開發者靠「先交付不管品質」趕工期——雙方都從缺陷裡獲益，形成一種沒人明說的共謀。敏捷把 QA 從「尾端守門員」搬到「開頭規格制定者」，就是要拆掉這個黑市。
注意事項
⚠️ 「Refactoring 不是 Story」這條，初聽很容易被理解成「敏捷不重視重構」。完全相反——是因為重構太重要、太日常了，重要到它應該滲透在每一個 Story 的開發過程裡，而不是被切成一個可以被業務砍掉的獨立項目。把它框成 Story，反而是把它推上了斷頭台。
⚠️ Continuous Delivery（每次變更就發布到 Production）對很多團隊聽起來很荒謬——書裡也承認，「歷史慣性是最大阻力」。數天、數週、數月的週期已經深植在 QA、管理層、Stakeholders 的期望裡。所以講這段要溫和：CD 是目標、是漸近線（六個月 → 三個月 → 一個月 → 一週 → …），不是明天就要做到。
⚠️ Whole Team / Co-Location 這段別講成「遠端工作一定不行」。書裡的立場很誠實：Uncle Bob 自己也成功管理過完全遠端的團隊，只是「如果能在同一間房間會更好」。遠端永遠是透過一個「窺視孔」溝通——損失的是偶發性協同（Serendipity）。在 2020 年後的遠端常態下，這個誠實的平衡觀點反而更值得討論。
專家補充
💡 「需求即測試」這個理念，是整個 BDD（行為驅動開發）和 Specification by Example 的源頭。Given-When-Then 格式（FitNesse、Cucumber、SpecFlow 這些工具）就是為了讓業務方能用「較正式但非程式」的語言定義行為。可以接一條線：Gojko Adzic《Specification by Example》把這套做到了極致——驗收測試不只是測試，是「活的需求文件」。
💡 索引卡（index card）這個「低科技」選擇背後有深意：書裡說「太早寫下的細節會變，而且投入太多心力在卡片上會讓卡片無法被丟棄」。這其實是個認知心理學洞見——沉沒成本會讓你捨不得丟掉爛點子。刻意用「廉價、易丟棄」的媒介，是為了保持思想的流動性。這條接得到第6章「物理工具 vs ALM 工具」的辯論。
💡 大數法則（Law of Large Numbers）為什麼能拯救模糊估算？因為個別估算的誤差有正有負，加總起來會互相抵消。這就是為什麼「估 50 個 Story 的總和」遠比「估單一 Story」可靠。這是統計直覺，也是為什麼敏捷敢用模糊的 Story Points——它賭的是「整體會收斂」，而不是「每一個都準」。
討論問題
🎙️ 開場鉤子：「如果我跟你說，管理一個百萬美元專案最好的工具，是一疊可以拿在手上塗塗改改、隨時撕掉的索引卡——你信嗎？今天講的就是為什麼『廉價、易丟棄』反而是優點。」
🎙️ 自問自答：「為什麼敏捷大師說『不要把重構排成 Story』？難道不重視重構嗎？」——剛好相反。因為重構太日常、太核心，把它切成獨立 Story 等於把它送上業務砍刀下的斷頭台。它該藏在每個 Story 裡。
🎙️ 拋給聽眾：「你的團隊有沒有『缺陷黑市』？想想看——你們的 QA 是靠『找到多少 bug』證明價值，還是靠『讓系統可上線』？如果是前者，你們可能正在不知不覺地共謀製造 bug。」
🎙️ 帶走的一題：「下次估算時，試試 Golden Story：先選一個大家都熟的中等任務當『3 點』，其他全部跟它比，而不是各自憑感覺報數字。看看共識會不會更快達成。」
更大範圍關聯
- Reading Uncle Bob 路線：本集是《Clean Agile》的「業務面」，與下一集（Team Practices）、再下一集（Technical Practices）構成 Circle of Life 三同心環。Acceptance Tests 與 Testability 的討論，直接呼應《Clean Code》的測試章與《Clean Architecture》的「可測試性即解耦」。
- 敏捷經典對話：計畫遊戲與 Story 接 Mike Cohn《User Stories Applied》《Agile Estimating and Planning》（估算與計畫的最完整專著）；Acceptance Tests 接 Gojko Adzic《Specification by Example》；Continuous Delivery 接 Jez Humble & David Farley《Continuous Delivery》（這是 CD 的聖經，本章只是序曲）。
- Scrum 對照：本章的 Whole Team 對應 Scrum 的 Product Owner；Iteration Planning 對應 Sprint Planning。可拉 Kenneth Rubin《Essential Scrum》做平行對照——Uncle Bob 用 XP 詞彙，Scrum 用另一套詞彙講相似的事。
- 版本控制思想史：打孔卡 → 磁帶 → SCCS → Subversion → Git 這條「週期大小縮短史」是本章的隱藏寶藏，接得到 DevOps 與《Accelerate》（DORA 指標：部署頻率、前置時間）的整個現代脈絡。
- 在 [軟體工程領域切分藍圖] 的位置：落在「敏捷流程／專案管理」一格，與「版本控制／CICD」一格透過 Small Releases 這段直接接壤。
錄製建議
- 建議時長：約 24 分鐘（本章份量最重的之一）。配比：Planning/估算/INVEST 約 11 分（主菜，例子多）、Small Releases 與版本控制史約 6 分、Acceptance Tests 與 QA Disease 約 5 分、Whole Team 約 2 分。
- 討論策略：用「索引卡管理百萬專案」的反差開場。中段把估算哲學講透——「準確 vs 精確」「大數法則救模糊」是最有 aha 感的點。Velocity 那段用「別捏體溫計退燒」做記憶錨。QA Disease（缺陷黑市）留到後段當辛辣收尾，最有討論性。
- 這集概念密度高，務必多舉例、放慢節奏，必要時可以提醒聽眾：這集是「業務面工具箱」，下一集進團隊面、再下一集進技術面，三集合起來才是完整的敏捷。