我們將用商業基本功來管理整個專案——分階段交付、快速而具體的回饋、清楚闡述系統的業務需求，以及讓專才處理專門任務。

管理的兩難#

一方面，你會希望由管理者做所有決定：沒有溝通開銷（因為只有一個人）、有一個人向高階管理層負責、有一個人擁有願景，其他人都不必知道，因為所有決定都來自同一個人。

但我們知道這個策略行不通——沒有任何單一個人知道的東西，多到足以把所有決定都做好。而且偏向中央集權控制的管理策略也難以執行，因為它們要求被管理者付出大量開銷。

另一方面，相反的策略也行不通。你不能讓每個人各自跑去做想做的事而完全沒有監督——人們無可避免會跑到旁枝去。得有人擁有專案的較大視野，並在專案偏離航道時能夠施加影響。

回到原則#

我們可以再次退回到原則，幫我們在兩個極端之間導航：

• 被接受的責任——暗示管理者的工作是凸顯什麼需要被完成，而不是指派工作。
• 品質工作——暗示管理者與程式設計師的關係必須建立在信任之上，因為程式設計師本來就想把工作做好。這不表示管理者什麼都不做，但「我試著讓這些傢伙做出像樣的工作」與「我能幫這些傢伙做得更好」之間，有巨大的差別。
• 增量式變更——暗示管理者一路上持續提供引導，而不是在一開始丟出一本厚重的政策手冊。
• 因地制宜——暗示管理者需要帶頭把 XP 調整成適合在地條件，察覺 XP 文化與公司文化在哪裡衝突，並找到化解不合的辦法。
• 輕裝上路——暗示管理者不強加大量開銷（冗長的全員會議、落落長的狀態報告）。管理者對程式設計師的任何要求，都不該花太多時間才能滿足。
• 誠實的度量——暗示管理者蒐集的任何指標，都應落在符合現實的精確度層級上。如果你的錶只有分針，就別試圖交代每一秒。

從這番評估浮現出的策略，更像去中心化的決策，而非中央集權的控制。

管理者的工作是：主持規劃遊戲、蒐集指標、確保指標被「工作正被度量的那些人」看見，並偶爾介入那些無法以分散方式解決的情況。

指標#

XP 最基本的管理工具就是指標（metric）。

例如「估計開發時間與日曆時間的比值」，是主持規劃遊戲的基本度量，它讓團隊得以設定專案速度（Project Velocity）。

但指標要小心解讀。上述比值上升（同樣的估計開發量花掉較少日曆時間）可能代表團隊流程運作良好；也可能代表團隊除了滿足需求之外做得不夠（例如重構與結對），而長期將為此付出代價。

大而顯眼的圖表#

指標的媒介是大而顯眼的圖表（Big Visible Chart）。與其寄電子郵件給每個人——他們終究會學會忽略——管理者應該定期（不少於每週一次）更新一張醒目的圖表。

指標的紀律#

• 別有太多指標，並且準備好讓已達成目的的指標退役。三、四個度量通常就是一支團隊一次能承受的極限。
• 指標會隨時間走味。特別是任何逼近 100% 的指標，很可能已經沒用了。
• 單元測試分數必須是 100%，這條建議不適用——但單元測試分數比較像是一個「假設」，而不是一個指標。
• 你不能指望「97% 的功能測試分數」意味著還剩 3% 的工作量。如果一個指標接近 100%，就用另一個從個位數舒服地起步的指標取代它。

這不是在建議你能「按數字」管理一個 XP 專案。數字只是一種溫和而非強制地溝通「需要改變」的方式。

XP 管理者對「需要改變」最敏銳的氣壓計，是察覺自己的感受，包括生理與情緒上的。如果你早上上車時胃在打結，那你的專案就有哪裡不對勁——而促成改變是你的工作。

教練#

多數人心目中的「管理」，在 XP 中被拆成兩個角色：教練（coach）與追蹤者（tracker）（兩者可以、也可以不由同一人擔任）。

教練主要關心流程的技術執行（與演化）。 理想的教練是好的溝通者、不易慌張、技術嫻熟（雖然這不是絕對要求）、而且自信。

通常你會希望由「在其他團隊裡會擔任首席程式設計師或系統架構師」的人來當教練。但 XP 中的教練角色非常不同。

「首席程式設計師」與「系統架構師」這些字眼，召喚出的是孤立天才替專案做重要決策的畫面。教練恰恰相反——衡量一位教練的標準，是他做的技術決策有多少。他的工作是讓其他每個人都做出好決策。

教練不承擔太多開發任務，其職責如下：

• 作為開發夥伴待命，尤其是為剛開始承擔責任的新程式設計師，或為困難的技術任務
• 看見長期的重構目標，並鼓勵小尺度的重構去逐步逼近這些目標
• 協助程式設計師的個別技術技能，例如測試、格式化與重構
• 向高階管理者解釋流程

玩具與食物#

但也許教練最重要的工作，是採購玩具與食物。

XP 專案似乎特別會吸引玩具，其中多數是那種到處的水平思考顧問都會推薦的普通益智玩具。但每隔一陣子，教練就會有機會靠買對一個玩具而深刻影響開發——而對這種可能性保持敏感，是教練最大的職責之一。

食物也是 XP 專案的標誌。 和一個人掰餅同食有某種強大的力量——如果你們同時在咀嚼，你們會有完全不同的對話。所以 XP 專案總是有食物擺著。

追蹤#

追蹤（tracking）是 XP 管理的另一個主要成分。

你想做多少估算都可以，但如果你不去度量「實際發生了什麼」對照「你預測會發生什麼」，你永遠不會學到東西。

追蹤者的工作是蒐集當下正在追蹤的各種指標，並確保團隊知道實際量到了什麼（並被提醒當初預測或期望的是什麼）。

主持規劃遊戲是追蹤的一部分。追蹤者必須把遊戲規則背得滾瓜爛熟，並準備好即使在情緒化的場合也執行規則（規劃永遠是情緒化的）。

追蹤者應該實驗看看：自己能少量到什麼程度、卻仍然有效。一週蒐集兩次真實開發資料就非常足夠了；量更多大概不會給你更好的結果。

介入#

管理一支 XP 團隊，並不全是買甜甜圈和丟飛盤。有時候問題就是無法靠「一位慈愛而警醒的管理者所鼓勵出的團隊集體才智」解決。這種時候，XP 管理者必須能自在地介入、做出決定（即使是不受歡迎的決定），並把後果看到底。

但首先，管理者必須仔細追查：是否有什麼事，是他早該察覺或早該做，就能完全避免這個問題的？

介入的時刻不是穿上白盔、躍上戰馬的時刻。 而是走向團隊說：「我不知道我怎麼會讓事情變成這樣，但現在我必須做 XXX。」——謙卑是介入之日的守則。

嚴重到需要介入的事項包括三類：

• 人事變動——如果一位團隊成員就是不合適，管理者必須請他離開。這類決定越早做越好：一旦你想不出任何情境下這個人會是助力而非阻力，你就該行動。等待只會讓問題更糟。
• 流程需要改變——這是稍微愉快一點的職責。一般而言，管理者的工作不是規定要改什麼、怎麼改，而是指出改變的需要。團隊應該提出一個或多個要跑的實驗，然後由管理者回報這些實驗所造成的、被度量到的變化。
• 終止專案——這是管理者最後的介入職責。團隊很可能永遠不會自己放棄。 但總有一天，繼續在現行系統上投入工程資源，會變得不如某個替代方案（例如啟動一個替換專案）有吸引力。管理者有責任察覺這個門檻何時被跨過，並告知高階管理層需要做出改變。