一支極限團隊要運作，某些角色必須有人擔任：程式設計師、客戶、測試人員、追蹤者、教練、顧問、大老闆。

角色只是慣例，不是自然律#

一支運動隊伍在「有人為特定位置負責」時運作得最好：足球有守門員、前鋒、清道夫；籃球有控球後衛、中鋒、得分後衛。接下這些位置的球員，就接受了一組特定的責任——為隊友創造得分機會、阻止對手得分、負責管理場上某個區域。有些角色近乎獨立作業，有些則要求球員修正隊友的錯誤或管理他們的互動。

這些角色之所以成為慣例、甚至被寫進比賽規則，正是因為它們管用。某個時候，大概所有其他的責任組合都被試過了；你今天看到的這些之所以存在，是因為它們有效，而其他的沒效。

時不時地，比賽會改變、球員會改變，以至於一個新位置變得可能、或一個舊位置變得過時。偉大的教練總是在尋找「創造新位置、淘汰現有位置」能帶來什麼優勢。

偉大教練的另一項本事，是把系統塑造成適合球員，而不是反過來。如果你有一套「球員速度快就無比好用」的系統，而第一次練習來的隊伍卻是又大又壯，那你最好創造一套能讓這支隊伍才華發光的新系統。很多教練做不到這點——他們太專注於「系統」的美，以至於看不見它根本沒在運作。

以上都是為了對接下來的內容提出一個大警告：下面列的是在先前專案上被發現運作良好的角色。如果你手上的人不符合這些角色，那就改角色——別試圖改變人（好吧，別改太多）。

也別假裝沒有問題。 如果某個角色說「這個人必須願意冒大險」，而你手上是個鐘錶匠，那你就得找出另一種責任分工，在該角色不由冒險者擔任的前提下仍能達成目標。

程式設計師#

程式設計師是 XP 的心臟。 事實上，如果程式設計師總能做出仔細平衡短期與長期優先序的決策，專案上除了程式設計師之外就不需要任何其他技術人員了。（當然，如果客戶不是絕對需要軟體來維持業務運轉，那也就不需要程式設計師——所以別為自己的重要性太過得意。）

表面上，當 XP 程式設計師看起來很像在其他開發紀律裡當程式設計師：你花時間與程式打交道，讓它們更大、更簡單、更快。

你的第一價值是與其他人溝通。 程式跑得動，但如果還有某項關鍵的溝通沒完成，你就還沒完成。

於是你會：

• 寫測試來展示軟體的某個關鍵面向
• 把程式拆成更多更小的片段，或把太小的片段併成更大、更連貫的片段
• 找出一套更準確反映你意圖的命名體系

這聽起來也許像是高尚地追求完美，其實完全不是。你試著為客戶開發最有價值的軟體，但不開發任何沒有價值的東西。

如果你能把問題的規模縮得夠小，你就負擔得起對剩下的工作認真以待；然後，認真就成了習慣。

XP 程式設計師需要的技能#

• 結對程式設計——這是可學習的技能，但常與「典型會走進程式設計這行的人」的傾向相衝突。說得直白些：書呆子通常不擅長講話。 當然有例外，而且與人交談是學得會的——但事實是，你必須與其他程式設計師緊密溝通與協調，才會成功。
• 簡單的習慣——當客戶說「你必須做這個、這個、還有這個」，你得準備好討論哪些項目真的必要、各自需要多少。簡單也延伸到你寫的程式碼上。
• 技術面：你得程式寫得夠好、能重構（這項技能的深度與微妙至少不亞於寫程式本身）、能為程式碼寫單元測試（和重構一樣，要用得好需要品味與判斷）。
• 放下個人所有權——願意放下「系統某部分屬於我」的感覺，換取對整個系統的共同所有權。如果有人改了你寫的程式碼，你必須信任那些改動並從中學習；當然，如果改動方向錯了，你有責任把事情變得更好。

• 害怕看起來笨
• 害怕被認為沒用
• 害怕變得過時
• 害怕自己不夠好

沒有勇氣，XP 就是行不通——你會把所有時間都花在拚命「不要失敗」上。反過來，如果你願意在團隊的協助下承認自己的恐懼，你就能回到正事上：歸屬於一支團隊，開心地寫出很棒的軟體。

客戶#

客戶是極限程式設計那組本質二元性的另一半：程式設計師知道怎麼寫，客戶知道要寫什麼——當然一開始並不知道，但客戶和程式設計師一樣願意學。

當 XP 客戶並不容易。 你得學一些技能，例如寫出好故事；還得有一種能讓你成功的態度。

而最重要的是：你必須習慣於「能影響一個專案、卻無法控制它」。

你控制不了的力量，會和你所做的決策一樣多地塑造出最終被建造的東西——業務條件的變化、技術、團隊的組成與能力，全都對「什麼軟體被交付」有巨大影響。

你必須做決定#

他們習慣了 IT 只交付承諾的一半、而交付的那半又有一半是錯的；他們學會了絕不對 IT 讓步半吋，反正終究會失望。XP 不會在這種客戶身上運作。

如果你是 XP 客戶，團隊需要你有信心地說出：

• 「這個比那個重要。」
• 「這個故事做到這裡就夠了。」
• 「這幾個故事加起來剛剛好。」

而當時局艱難時——時局總是會艱難——團隊需要你能夠改變主意：「嗯，我想這個我們其實不必非得在這一季拿到。」

誰適合當客戶#

最好的客戶是真的會使用開發中系統的人，但同時對「要解決的問題」有某種視野。

• 如果你是這種客戶，你必須留意：自己此刻這樣想，究竟是因為問題的某種本質，還是只因為事情向來都這麼做。
• 如果你離「實際使用系統」還有一兩步距離，你就得格外努力，確保自己準確代表了真實使用者的需求。

你要學的三件事#

• 學會寫故事——起初這看似不可能的任務，但團隊會在你寫的頭幾個故事上給你大量回饋這份禮物，你會迅速學到每個故事該涵蓋多大範圍、該包含與排除哪些資訊。
• 學會寫功能測試——如果你的應用有數學基礎，工作會比較輕鬆：花幾分鐘或幾小時用試算表就能造出測試案例的資料；或者團隊會為你打造工具，讓輸入新測試案例變得容易。流程式的程式（例如工作流）同樣需要功能測試。你得與團隊緊密合作，學會測什麼有幫助、哪類測試是冗餘的。有些團隊甚至會指派技術人力協助你挑選、撰寫與執行測試。你的目標是寫出能讓你說「如果這些都通過，我就有信心系統跑得動」的測試。
• 展現勇氣——從你今天所在之處，到你想去的地方，是有一條路的。這支團隊能幫你找到它——只要你也幫他們找到它。

測試人員#

由於大量測試責任落在程式設計師肩上，XP 團隊中測試人員的角色其實是聚焦於客戶的：

• 你負責協助客戶挑選並撰寫功能測試
• 如果功能測試不屬於整合套件的一部分，你負責定期執行功能測試，並把結果張貼在顯眼的地方

但總得有人定期跑完所有測試（如果你無法把單元測試與功能測試一起跑）、廣播測試結果，並確保測試工具運作良好。

追蹤者#

身為追蹤者，你是團隊的良心（想想小蟋蟀吉明尼，但衣著品味好一點）。

做出好估算，靠的是練習與回饋：你必須做大量估算，然後留意現實與你的猜測有多吻合。你的工作就是把回饋的迴路合上。

• 下次團隊在做估算時，你要能說出：「我們上次三分之二的估算至少高估了 50%。」
• 針對個人，你要能說出：「你的任務估算不是高得離譜，就是低得離譜。」

接下來產出的估算，責任仍在那些必須實作的人身上——但你已經給了他們回饋，讓新估算能比上次更好。

你也負責盯著大局：

• 迭代進行到一半時，你該能告訴團隊：照目前航向走得完嗎？還是需要改變些什麼？
• 承諾時程進行了幾次迭代後，你該能告訴團隊：不做大改動的話，趕得上下次發布嗎？

你還是團隊的史官：記錄功能測試分數、記錄回報的缺陷、每個缺陷由誰接下責任、以及為每個缺陷加上了哪些測試案例。

你確實想稍微干擾流程一下——讓人們意識到自己在一項任務上實際花了多少時間（若你不問，他們可能根本不會意識到）。但你不能煩到讓人們開始躲你、不回答你。

教練#

身為教練，你為整個流程負責。你注意到有人偏離團隊的流程，並把這件事帶到團隊面前。

XP 團隊裡每個人都有責任在某種程度上理解自己如何應用 XP；而你有責任理解得更深——哪些替代實踐可能有助於當前這組問題、其他團隊怎麼用 XP、XP 背後的想法是什麼、以及它們與當前處境有何關聯。

間接工作是最難的部分#

作者說，當教練最困難的一點是：你在間接工作時效果最好。

如果你看到設計上的一個錯誤，你首先得決定：它重要到值得你介入嗎？

所以你得先決定：你看到的問題，是否嚴重到值得你承擔「介入」的風險。

如果你決定自己確實比團隊懂，那你必須以盡可能不突兀的方式表達你的觀點。

例如，建議一個「只有修好設計才能乾淨地實作」的測試案例，遠遠好過你自己跑去把設計修掉。

但「不直說你看到的東西，而是用一種讓團隊也看見的方式說出來」，本身就是一項技藝。

有時候你必須直接#

不過有時候你必須直接，直接到近乎無禮的程度。

自信而積極的程式設計師之所以有價值，正是因為他們自信而積極；但這也讓他們容易陷入某種盲點，而唯一的解藥就是把話說白。

當你已經讓局面惡化到「輕放在軛上的手」再也不管用時，你必須準備好雙手抓住軛去掌舵——但只抓到足以把團隊拉回正軌為止，然後你就得再放掉一隻手。

教練不必是技術大神#

作者說他總是處在教導 XP 技能（簡單設計、重構、測試）的位置上，但他不認為那必然是教練的職務內容。

如果你的團隊技術上自給自足、只是流程需要幫助，你不必是技術天才也能當教練——你仍然得說服那些技術腦聽你的，但一旦技能已經到位，教練的工作主要是提醒團隊：他們自己說過在各種情境下想要怎麼行動。

依循分散控制與被接受的責任這兩條原則，「流程」應該是每個人的責任——只是在轉向 XP 的早期，這對任何程式設計師來說要求都太高了。

顧問#

XP 專案不會孳生大量專才。 因為每個人都和每個人結對、配對又浮動得很頻繁、而且任何人想接下任務都可以，所以幾乎不可能發展出「只有一兩個人懂系統」的黑洞。

強調設計簡單降低了「需要尖帽子巫師」的頻率，但這種需求仍會偶爾發生。

當它發生時，團隊需要一位顧問。而作為顧問，你很可能不習慣極限的工作方式，也很可能帶著某種懷疑看待團隊在做的事。

但團隊會做到兩件事：

• 對他們需要解決的問題極其清楚
• 能提供測試，精確標示問題何時被解決（事實上他們會堅持要有測試）

如果團隊在某個領域需要深厚技術知識一次，他們很可能會再需要一次。他們的目標是讓你教會他們解決自己的問題。

所以會有一兩位團隊成員在你解問題時坐在旁邊。他們大概會問你一堆問題，會挑戰你的設計與假設，看能不能找到更簡單而仍然可行的做法。

別覺得被冒犯。 他們每天都對自己這樣做一點點，而且大概每個月會扔掉一天的工作成果。

大老闆#

如果你是大老闆，團隊最需要你的是勇氣、信心，以及偶爾堅持要他們做到自己說過會做的事。

一開始與這支團隊共事，你大概會覺得困難：

• 他們會要求你頻繁地查核他們
• 他們會向你解釋情況變化的後果——例如你沒給他們要的那位新測試人員，他們會精確說明這對時程的影響；如果你不喜歡這個答案，他們會邀請你縮減專案範圍

從一支 XP 團隊口中說出來，這構成的是誠實的溝通。他們不是在抱怨，真的不是。

他們希望你盡早知道事情正在偏離計畫，好讓你有盡可能多的時間反應。

團隊需要你有勇氣，因為他們做的事有時看起來會很瘋狂——尤其如果你有軟體開發背景。有些想法你會認得也會認同，例如對測試的強烈重視；有些起初就是說不通，例如「結對程式設計是更有效率的寫程式方式」、「持續精煉設計是更低風險的設計方式」。

如果行不通，你可以介入；如果行得通，你就走運了——你將擁有一支高生產力運作、讓客戶開心、並竭盡所能永遠不讓你意外的團隊。

這不表示團隊不會偶爾搞砸——他們會。

你會看著他們在做的事，覺得說不通，於是要他們解釋，而解釋也說不通。

那正是團隊仰賴你的時刻——要他們停下來、看一看自己正在做什麼。 你坐上今天的位置是有原因的；團隊想在需要時把那份本事用上，而且老實說，在不需要時把它擋在外面。