第 3 / 6 部 待錄

團隊實踐與通用語言

《Clean Agile》Podcast 準備稿：團隊實踐與通用語言

書名： Clean Agile 敏捷整潔之道（Back to Basics） 作者： Robert C. Martin（Uncle Bob） 系列： Reading Uncle Bob（恩普拉氏） 公開標題建議： Reading Uncle Bob｜Clean Agile．把一群人變成一個團隊 (3/6) 涵蓋範圍： 第4章 Team Practices（Metaphor、Sustainable Pace、Collective Ownership、Continuous Integration、Standup）

背景速覽

這是《Clean Agile》第三集，進入 Circle of Life 的中間環——面向團隊的實踐。如果上一集（業務實踐）談的是「團隊與外界（業務方）的關係」，這一集談的就是「團隊成員之間、以及團隊與程式碼之間的關係」。五個主題：Metaphor（隱喻／通用語言）、Sustainable Pace（可持續節奏）、Collective Ownership（集體所有權）、Continuous Integration（持續整合），最後輕輕帶一下 Standup Meetings（站立會議）。這一章的精神是：讓一群各自為政的工程師，真正變成一個「團隊」。

一句話重點

團隊的本質是共享——共享一套語言（通用語言）、共享一份程式碼（集體所有權）、共享一個隨時可運作的主線（持續整合）、共享一個能撐到終點的節奏（馬拉松而非衝刺）；而摧毀團隊最快的方式，就是讓每個人守著自己的孤島。

值得討論的重點

1. Metaphor 其實該叫 Ubiquitous Language（通用語言）

這段有個很誠實的歷史插曲：Metaphor 一度是敏捷裡最尷尬的實踐——連倡導者自己都說不清它是什麼，演講時直接說「看到就知道了」。Kent Beck 最知名的範例是 Chrysler 薪資系統，他把產生薪資單比喻成「組裝線」：空白支票從一個工站移到下一個，逐步加上 ID、總薪資、聯邦稅、社保、醫保……讓工程師和客戶都秒懂。但隱喻會走偏：有團隊把資料切片叫「slices」、延伸出「toaster」「loaves」「crumbs」，工程師之間順暢，經理客戶聽得一頭霧水；更慘的是把輸出緩衝區叫「garbage trucks（垃圾車）」，等於暗示付錢的客戶是「垃圾商人」。直到 Eric Evans 的 Domain-Driven Design 提出 Ubiquitous Language（通用語言），這個實踐才終於有了名字——團隊需要的是一個所有人（工程師、QA、管理者、客戶、使用者）都用同一套詞彙的「問題領域模型」。

2. 軟體是馬拉松，不是衝刺——加班的真相

Uncle Bob 用自己 18 歲的慘痛經歷說這段：當年為「重要專案」每週工作 60 小時、高峰 80 小時、通宵無數次，還引以為傲——結果全組燃燒殆盡、集體辭職。而那些被他們私下嘲笑「不夠投入」、穩定每週 40 小時的同事，最後接手系統並維護得好好的。更狠的是他的觀察：自己最嚴重的技術錯誤，全發生在深夜狂熱工作的時段（凌晨兩點想出的「天才解法」事後付出數倍代價）。然後是那句重話：加班不是敬業，它反映的是你不善規劃、答應了不該答應的截止日、是個容易被操控的勞工而非專業人士。 還有睡眠經驗法則：少睡 1 小時 = 損失 2 小時生產力，少睡 3 小時 = 完全沒有生產力。這段對 996 文化是一記重拳。

3. 集體所有權 vs 知識孤島：The X Files

核心原則一句話：沒有人擁有程式碼，程式碼屬於整個團隊，任何人可以在任何時候改善任何模組。反面教材是書裡的「X Files」案例——一家高階印表機公司，軟體團隊按硬體裝置劃分（feeder、printer、stacker、stapler），結果政治地位取決於你負責哪個裝置：printer 團隊地位最高、stapler 團隊無人在意，於是沒人分享程式碼、互相指責、各自重新發明輪子（明明 feeder/printer/stacker 的控制軟體大同小異，都在控制馬達繼電器）。最深的一刀：按硬體線路劃分軟體，本身就是個錯誤的架構決策——組織結構的問題，最後變成了架構的問題（這其實就是 Conway’s Law 的反例教材）。

4. 持續整合：The Build Never Breaks

CI 的早期定義是每隔「幾個小時」就 check in 並合併主線，規則簡單：所有測試持續通過、沒有 feature branch 長期不整合、用 toggles 處理未啟用功能。最生動的反例是 XP Immersion 課堂上那個學生——超過一小時沒整合，等他要 check in 時，其他五人已累積大量變更，他掙扎合併時別人還在每 15 分鐘 check in 一次，他永遠追不上。這證明了：CI 只在你「真正持續」整合時才有效。2001 年 ThoughtWorks 推出 CruiseControl（第一個 continuous build 工具），Kent Beck 的「幾個小時」被縮短成「幾分鐘」。核心紀律只有一條：Build 壞掉是「Stop the Presses」等級的事件，所有人停下手邊工作搶救。團隊信條必須是：The Build Never Breaks.

注意事項

⚠️ 集體所有權不等於「不能專精」。書裡講得很清楚：系統複雜後專業化是必要的，但即使你是某領域專家，也要同時保持通才能力，把時間分配在專業區和其他區之間。目標是「知識分散」，不是「人人都是樣樣通的萬金油」。別讓聽眾誤以為集體所有權就是反對深度。

⚠️ 「Build 壞掉就全員停工搶救」聽起來很硬，但書裡警告的是反過來的災難：有些團隊在截止日壓力下放任 build 失敗，然後因為厭倦失敗通知 email，乾脆把失敗的測試「移除」，承諾之後再修——結果 build server 開始發綠燈，所有人鬆口氣，然後忘記那堆被擱置的測試，最後一個有問題的系統就這樣上線了。重點不是「不准弄壞 build」，是「絕不能靠刪測試來讓 build 變綠」。

⚠️ Standup Meeting 這段，Uncle Bob 的態度出乎意料地「隨便」——他說這會議是可選的，很多團隊不開也運作良好；不必每天開；就算大團隊也該控制在 10 分鐘內。三個問題（做了什麼/要做什麼/有什麼阻礙）每人 30 秒，不討論、不表態、不抱怨。別把 Standup 講得太神聖——它在書裡的份量其實很輕，這個「去儀式化」的態度本身就是對「敏捷淪為儀式」的隱性批判。

專家補充

💡 通用語言（Ubiquitous Language）是 Eric Evans《Domain-Driven Design》（2003）的核心概念之一，而 DDD 如今是後端架構的顯學。值得拉一條更老的線：書裡提到早在 1970 年代 Tom DeMarco 就把類似概念叫 Data Dictionaries。所以「讓全團隊講同一套詞彙」這個需求，從結構化分析時代就存在，只是 Evans 把它系統化成一門學科。這條接得到《Clean Architecture》的邊界與領域模型。

💡 X Files 案例其實是 Conway’s Law（康威定律） 的活教材：「設計系統的組織，其產出的設計會複製該組織的溝通結構。」印表機公司按硬體部門劃分團隊，結果軟體架構就長成了硬體的形狀——重複、耦合、難維護。這條定律是現代微服務、團隊拓撲（Team Topologies）的理論基石，可以順勢預告。

💡 「軟體是馬拉松不是衝刺」這個比喻，反諷的是 Scrum 居然把開發週期就叫「Sprint（衝刺）」。Uncle Bob 在書裡其實不太喜歡這個詞——一場接一場的「衝刺」，本質上違背了「可持續節奏」。這是個很好的觀察點：連敏捷的官方術語，都可能在無意間鼓勵了它本想避免的行為。

討論問題

🎙️ 開場鉤子：「Uncle Bob 18 歲時每週工作 80 小時、引以為傲，結果整組燒光辭職。而那些被他嘲笑『不夠拼』、準時下班的同事，最後接手了系統。今天我們聊聊——為什麼加班不是敬業，是不專業。」

🎙️ 自問自答：「為什麼那家印表機公司的軟體會爛成那樣？」——因為他們按硬體部門切團隊，於是軟體架構複製了組織的政治結構（Conway’s Law）。組織問題會變成架構問題，這是這集最深的一條。

🎙️ 拋給聽眾：「你的團隊有『不能碰的模組』嗎？那個只有某個人懂、他請假整個專案就停擺的角落——那就是知識孤島。集體所有權要拆的，正是它。」

🎙️ 帶走的一題：「這禮拜記錄一下你的睡眠和產出。Uncle Bob 說少睡 1 小時要賠上 2 小時的白天生產力——驗證看看，那個你以為『多撐一下趕出來』的夜晚，到底是賺還是賠。」

更大範圍關聯

  • Reading Uncle Bob 路線：本集是 Circle of Life 中間環，夾在業務實踐（EP2）與技術實踐（EP4）之間。集體所有權與 CI 直接通往下一集的 TDD/Refactoring——沒有可信賴的測試，集體所有權和 CI 都會變成災難（你不敢動別人的 code、build 一直壞）。
  • 領域建模脈絡：Ubiquitous Language 接 Eric Evans《Domain-Driven Design》、Vaughn Vernon《Implementing DDD》；X Files / Conway’s Law 接 Matthew Skelton《Team Topologies》（團隊拓撲，現代組織設計顯學）。
  • 持續整合脈絡：CI 接 Paul Duvall《Continuous Integration》、Jez Humble《Continuous Delivery》、《Accelerate》（DORA：整合頻率與部署效能的實證研究）。CruiseControl → Jenkins → GitHub Actions 這條工具演化線可順帶一提。
  • 工作倫理與健康：Sustainable Pace 接 Tom DeMarco《Peopleware》（人性化的軟體管理）、以及對 996／過勞文化的當代批判。這是整本書裡最「以人為本」的一章。
  • 在 [軟體工程領域切分藍圖] 的位置：橫跨「敏捷團隊協作」與「領域建模」兩格，是把「流程」與「設計」縫合起來的一章。

錄製建議

  • 建議時長：約 20 分鐘。配比：Metaphor/通用語言約 6 分、Sustainable Pace/加班/睡眠約 6 分（情緒最濃，慢講）、Collective Ownership/X Files 約 5 分、CI 約 3 分、Standup 約 1 分（刻意輕描淡寫）。
  • 討論策略：用「18 歲過勞辭職」的親身故事開場，情感共鳴最強。中段把 X Files 講成一個小故事（政治、地位、垃圾車），帶出 Conway’s Law 的深度。CI 用「永遠追不上的學生」當畫面。Standup 刻意快速收尾，呼應「別讓敏捷淪為儀式」的整季基調。
  • 這集情緒和故事性比 EP2 強、概念密度較低，是個適合「放鬆但有料」的中段集數。記得在開頭用一句話把 Circle of Life 三環複習一下，幫聽眾定位。