本章介紹 Ron Jeffries「Circle of Life」中間層的 Team Practices，這些實踐規範了團隊成員之間的關係，以及他們與產品之間的互動方式。主要涵蓋：Metaphor、Sustainable Pace、Collective Ownership 與 Continuous Integration，最後簡要談論 Standup Meetings。

Metaphor（隱喻）#

在 Agile Manifesto 簽署前後，Metaphor 一直是一個令人尷尬的實踐——因為倡導者們自己也說不清楚它到底是什麼。他們知道它很重要，也能舉出成功案例，但就是無法有效地表達其定義，甚至在演講中直接說「看到就知道了」。

核心概念#

  • Metaphor 的目的：讓團隊擁有一套 有約束、有紀律的共通詞彙，以便有效溝通
  • Kent Beck 稱之為 Metaphor，是因為他把專案比喻成團隊已有共識的事物

經典範例：Chrysler 薪資系統#

Beck 最知名的範例是 Chrysler 薪資專案。他把薪資單的產生比喻成 組裝線（Assembly Line）：

  • 空白支票從一個工站移到下一個工站，逐步加上各種「零件」
  • 先到 ID 工站加上員工識別資訊，再到薪資工站加上總薪資，然後經過聯邦稅、社會保險、醫療保險等工站
  • 這個隱喻讓程式設計師和客戶都能輕鬆理解系統運作
flowchart LR
    A[空白支票] --> B[ID 工站]
    B --> C[薪資工站]
    C --> D[聯邦稅]
    D --> E[社會保險]
    E --> F[醫療保險]
    F --> G[完成薪資單]

隱喻的陷阱#

隱喻可能會走偏。一個對程式設計師有效的隱喻，可能讓客戶和管理者完全摸不著頭腦，甚至造成冒犯。

書中舉了兩個反面案例：

  1. 麵包隱喻：一個 T1 網路品質監測專案把資料切片叫做「slices」，然後延伸出「toaster」、「loaves」、「crumbs」等詞彙。程式設計師之間溝通順暢，但經理和客戶聽了只會搖頭離開。
  2. 垃圾車隱喻：一個分時系統把輸出緩衝區叫做「garbage trucks」，等於隱含著客戶是「垃圾商人」的意思。雖然技術溝通有效，但對付錢的人極不尊重。

Domain-Driven Design 的解方#

Eric Evans 在 Domain-Driven Design 一書中提出了 Ubiquitous Language（通用語言） 的概念，完美解決了 Metaphor 的定義問題。

Metaphor 真正該叫的名字是 Ubiquitous Language。團隊需要的是一個所有人都同意的 問題領域模型——程式設計師、QA、管理者、客戶、使用者，每一個人都使用相同的詞彙。

  • 早在 1970 年代，Tom DeMarco 就把類似概念稱為 Data Dictionaries：用簡單的方式表示應用程式操作的資料和流程
  • Evans 將這個簡單想法擴展為一整套領域建模的學科
  • Ubiquitous Language 貫穿專案的所有層面：商業案例、需求、設計、架構、驗收測試，是串聯整個專案生命週期的一致性線索

Sustainable Pace（可持續節奏）#

加班的教訓#

Uncle Bob 用自身經歷說明為什麼不能長期加班：

  • 18 歲時：和同事們為了「重要專案」每週工作超過 60 小時，高峰達 80 小時以上，還通宵了許多次。他們以此為傲，覺得自己是真正的程式設計師。
  • 結果：全部燃燒殆盡（burned out），集體辭職走人。而那些被他們私下嘲笑為「不夠投入」的同事，穩定地每週工作 40 小時，最終接手了系統並維護得很好。

軟體專案是一場 馬拉松（Marathon），不是短跑，也不是一連串的衝刺。你必須控制節奏，才能撐到終點。如果一開始就全力衝刺，你會在終點線前耗盡能量，被迫停下休息，平均速度反而更慢。

Overtime（加班）#

  • 隨著經驗增長，Uncle Bob 發現自己 最嚴重的技術錯誤 都發生在深夜狂熱工作的時段
  • 經典反面案例：凌晨兩點時，他和夥伴 Jim Newkirk 想出了一個「把資料寄給自己」的解法。這個決定在當下看似天才，事後卻付出了數倍的代價，而且已經深入系統到無法逆轉

加班不是展現敬業精神的方式。它反映的是：你不善於規劃、你答應了不該答應的截止日期、你做了不該做的承諾、你是一個容易被操控的勞工而非專業人士。

關於加班的平衡觀點#

  • 並非所有加班都是壞的，確實存在不得不加班的特殊情況——但這應該 極其罕見
  • 必須清楚認知：加班的代價通常 大於 你在時程上節省的時間

Sleep（睡眠）#

程式設計師生活中最珍貴的要素是 充足的睡眠。Uncle Bob 的經驗法則：

  • 少睡 1 小時 = 白天損失 2 小時 的生產力
  • 少睡 2 小時 = 再額外損失 4 小時 的生產力
  • 少睡 3 小時 = 完全沒有生產力可言

Collective Ownership（集體所有權）#

核心原則#

  • 在 Agile 專案中，沒有人擁有程式碼——程式碼屬於整個團隊
  • 任何團隊成員都可以在任何時候 checkout 並改善專案中的任何模組

專精與通才的平衡#

  • Collective Ownership 不代表不能專精：當系統變得複雜，專業化成為必要
  • 但即使你專精，也必須 同時保持通才能力：把工作時間分配在專業領域和其他區域之間
  • 當團隊實踐 Collective Ownership 時，知識會分散到整個團隊，每個成員都能更好地理解模組邊界和系統全貌，大幅提升溝通和決策能力

反面教材：獨佔式程式碼所有權#

Uncle Bob 在職涯中見過一些公司實踐 Collective Ownership 的反面——每個程式設計師擁有自己的模組，其他人不准碰。這類團隊的特徵：

  • 不斷互相指責和溝通不良
  • 某個模組的作者不在時，該模組的所有進展 完全停擺
  • 沒有人敢碰別人擁有的東西

The X Files 案例#

書中以一家高階印表機公司 X 為例，深入說明獨佔所有權的災難：

  • 軟體團隊按照硬體裝置來劃分（feeder、printer、stacker、stapler 等）
  • 政治地位 取決於你負責的裝置：printer 團隊地位最高，stapler 團隊無人在意
  • 因為政治因素，沒有人分享程式碼——printer 團隊把程式碼鎖得死死的

獨佔所有權造成的問題：

  • 溝通困難：無法檢視你正在使用的程式碼
  • 互相指責：finger pointing 和 backstabbing 成為常態
  • 荒謬的重複：feeder、printer、stacker、stapler 的控制軟體其實大同小異（都要控制馬達、繼電器、螺線管和離合器），但每個團隊都得各自重新發明輪子
  • 更根本的問題是，按硬體線路劃分軟體本身就是一個 錯誤的架構決策

Continuous Integration（持續整合）#

早期定義#

在 Agile 早期，Continuous Integration 的意思是開發者每隔 「幾個小時」 就 check in 原始碼並合併到主線。規則很簡單：

  • 所有 unit tests 和 acceptance tests 持續通過
  • 沒有 feature branch 停留在未整合的狀態
  • 不應在部署時啟用的功能，使用 toggles 來處理

持續整合的教訓#

Continuous Integration 只在你真正「持續」整合時才有效。 書中描述了一個 XP Immersion 課堂上的真實案例：一位學生超過一小時沒有整合程式碼，當他試圖 check in 時，其他五位同事已經累積了大量變更。他掙扎著合併時，其他人繼續每 15 分鐘 check in 一次，導致他陷入永遠追不上的困境。

Continuous Build 工具的誕生#

  • 2001 年，ThoughtWorks 推出了 CruiseControl——第一個 continuous build 工具
  • CruiseControl 監視原始碼控制系統，每次有變更 check in 時就自動觸發 build
  • Build 過程中會執行大部分自動化測試，然後將結果 email 給所有團隊成員
  • Kent Beck 原本的「幾個小時」被縮短為 「幾分鐘」——Continuous Integration 演化成了 Continuous Checkin
  • 後續出現了 Jenkins、Bamboo、TeamCity 等工具

Continuous Build 的紀律#

Build 不應該壞掉。 這是最核心的紀律。

  • 每位程式設計師在 check in 之前，都應該先在本機執行所有 acceptance tests 和 unit tests
  • Mike Two（ThoughtWorks）的團隊在牆上掛了一個大日曆：build 失敗的日子貼紅點，成功的日子貼綠點。這個簡單的視覺化在一兩個月內就把滿是紅點的日曆變成了幾乎全綠

Build 壞掉是一個「Stop the Presses」等級的事件。 所有程式設計師應該停下手邊的工作，全力搶救 build。團隊的信條必須是：The Build Never Breaks.

作弊的代價#

有些團隊在截止日壓力下，允許 continuous build 維持在失敗狀態。這是自殺式的舉動：

  1. 大家厭倦了不斷收到失敗通知 email
  2. 於是把失敗的測試移除，承諾「之後」再修
  3. Build server 開始發送成功通知，所有人鬆了一口氣
  4. 大家忘記了那堆被擱置的失敗測試
  5. 結果：一個有問題的系統被部署上線

Standup Meetings（站立會議）#

基本原則#

關於 Daily Scrum 或 Standup Meeting，有太多不必要的混亂。以下是要點：

  • 這個會議是 可選的——很多團隊不開也運作得很好
  • 不一定要每天開，選擇適合團隊的頻率即可
  • 即使是大型團隊，也應該控制在 約 10 分鐘 以內
  • 遵循一個簡單的公式

三個問題#

團隊成員站成一圈，每個人回答三個問題（每人約 30 秒）：

  1. 上次會議以來我做了什麼？
  2. 到下次會議前我要做什麼？
  3. 有什麼阻礙我的事情？

就這樣。不討論、不表態、不深入解釋、不抱怨。 每個人 30 秒左右回答三個問題，會議結束，回去工作。

Pigs and Chickens？#

關於「只有開發者能發言」的規則：Uncle Bob 的立場是他不在乎誰發言，只要所有人都遵循相同的三問題格式，並且會議控制在 10 分鐘左右。

Shout-out（致謝）#

一個有用的變體是加入第四個可選問題：

  • 你想感謝誰？

這只是快速地肯定某位幫助過你、或做了值得認可之事的人。

Conclusion#

Agile 是一組幫助小型團隊建構小型軟體專案的原則、實踐與紀律。本章描述的實踐幫助團隊真正成為一個 團隊——它們定義了溝通用的語言，以及團隊成員之間、團隊與專案之間的行為期望。

Backward Business Practices Technical Practices Forward