即使個別實踐都能由「藍領程式設計師」執行，把所有零件湊在一起、並讓它們持續在一起，卻很難。而讓 XP 變難的，主要是情緒——尤其是恐懼。

簡單，但不容易#

有人聽作者談 XP 之後說：「但你把它講得好簡單。」——嗯，那是因為它確實簡單。要為一個 XP 專案做出貢獻，不需要電腦科學博士學位（事實上，博士有時候是最卡的）。

再說一次：XP 很簡單，但不容易？沒錯。

組成 XP 的實踐，任何「說服過別人付錢請他寫程式」的人都學得會——那不是難的部分。難的部分是把所有零件湊在一起，然後讓它們保持平衡。

這些零件傾向互相支撐，但有許多問題、顧慮、恐懼、事件與錯誤，都可能把流程推離平衡。你之所以願意「犧牲」一位資深技術人員去當教練，正是因為「讓流程保持平衡」這個問題如此困難。

作者不想嚇你——超過必要程度的話。大多數軟體開發團隊都執行得了 XP（例外見〈何時不該用 XP〉）。

以下是他發現 XP 難在哪裡的清單——無論是他自己寫程式時，還是在指導團隊採用時。別去向未來借麻煩；但當轉向 XP 的過程很不順時（而且一定會有那種日子，作者保證），你該知道你不孤單——你之所以難受，是因為你在做的事本來就難。

難處一：做簡單的事很難#

聽起來很瘋狂，但有時候做複雜的事反而比做簡單的事容易——尤其當你過去靠著做複雜的事而成功時。

學會用最簡單的措辭看世界，是一項技能，也是一項挑戰。 而挑戰在於：你可能得改變你的價值體系。

你不能再因為某人（例如你自己）把一個複雜的東西弄能動了而感到佩服；你得學會對複雜感到不滿足，直到你再也想像不出更簡單的東西能運作為止，才肯罷休。

難處二：承認自己不懂很難#

這讓採用 XP 成為一項個人挑戰——因為 XP 這門紀律的前提是：你只能以「你學習的速度」開發。而如果你在學，那就意味著你之前不懂。

• 去找客戶、請他們解釋那些對他們而言最基本的概念，是會令人害怕的
• 轉頭向你的結對夥伴承認「有些電腦科學的基本東西，老實說我念書時從來沒真的搞懂」——或是「我忘了」——同樣令人害怕

難處三：協作很難#

多數公司的獎勵制度——個人評鑑與加薪（常被塑造成零和遊戲）——同樣鼓勵個人主義式的思考。

你很可能得學習新的人際技能，才能像在 XP 中那樣與團隊如此緊密地互動。

難處四：拆掉情緒的牆很難#

如果有人正在挫折或生氣卻不說出來，過不了多久團隊就會開始表現不佳。

我們學會把情緒生活與商業生活分開；但如果溝通不保持流動、恐懼不被承認、憤怒不被釋放、喜悅不被分享，團隊就無法有效運作。

如果這聽起來讓 XP 像是某種 Big Sur 式、摸來摸去、啜著白蘭地泡熱水池的體驗——作者說他不是那樣想的。

他試過假裝自己沒有情緒、並要求與同事保持距離的方式開發軟體。行不通。 他談自己的感受，也在別人談他們的感受時傾聽，於是流程順暢得多。

難處五：XP 聽起來太違逆常識#

XP 的實踐與我們過去聽過、說過、甚至靠它成功過的東西都是斜的。

作者說他初次見到一位新管理者時，常常擔心自己聽起來太激進、太瘋狂或太不切實際。但他不知道有更好的軟體開發方式，所以最後也就釋懷了。

不過，要準備好：當你解釋 XP 時，人們會有強烈反應。

難處六：小問題可能造成巨大影響#

作者認為 XP 的制衡機制相當穩健，流程能容忍大量變異。然而，小事往往能造成巨大的差別。

作者說這個故事不是要主張「你得一字不差照我說的做，否則你就慘了」。你仍然必須為自己的流程負責。

但 XP 之所以難，正是這一點——當你為自己的開發流程接下責任時，你同時接下了「察覺問題並修好它」的責任。

難處七：許多企業文化不接受「掌舵」#

最後一項困難——而且很容易讓一個 XP 專案沉船的——是：在許多公司文化裡，「掌舵」根本不被接受。

「一點一點修正方向來驅動專案」，違背了許多組織中盛行的「把車頭對準方向」的隱喻。

在這些組織裡，問題的早期預警被視為軟弱或抱怨的表徵。

當你的公司要求你做出違背「你為自己選擇的流程」的行為時，你會需要勇氣。