想改變既有文化的專案，遠比能從零打造新文化的專案來得常見。 在運行中的專案上採用 XP，要一點一點來，從測試或規劃開始。
改造比新建更難#
在新團隊採用 XP 已是挑戰，在既有團隊加既有程式碼庫上採用更難：
- 你有所有既有的挑戰——學技能、當教練、把流程變成自己的
- 你還有維持正式系統持續運行的即時壓力
- 那些軟體不太可能是照你的新標準寫的，很可能比它需要的更複雜，也不太可能測試到你想要的程度
- 新團隊你可以只挑願意嘗試 XP 的人；既有團隊很可能有些懷疑論者
- 更別提所有桌子都已經擺好了，你連結對程式設計都辦不到
在既有專案上改造 XP，會比在同等規模的新團隊上採用花更多時間。 這是壞消息。
好消息是：有些「綠地」XP 開發必須面對的風險，你不必面對。
- 你永遠不會處在「以為自己有個好軟體構想、卻其實不知道」的危險位置
- 你永遠不會處在「做了大量決策、卻缺乏來自真實客戶那種立即而殘酷的回饋」的危險位置
作者說他遇過很多團隊講：「喔對，我們已經在做 XP 了。除了測試那部分。還有我們有一份 200 頁的需求文件。但其他每一項都完全就是我們的做法。」
正因如此，本章是逐項實踐編排的：你如果已經在做 XP 主張的同一項實踐，就跳過那一節；如果有某項新實踐你想撿起來，就去看專屬那一節。
要在既有團隊、既有正式系統上採用 XP，你必須修改五個領域的採用策略。
測試#
一旦你開始寫測試，畫面就變了：你對新程式碼有信心，你不介意做改動——事實上，那還挺好玩的。
在舊程式碼與新程式碼之間切換，簡直是日夜之別。你會發現自己在迴避舊程式碼——你必須抵抗這個傾向。
在這種處境下取得掌控的唯一辦法，是把所有程式碼都往前帶。否則醜東西會在黑暗中滋長，而你將背負規模未知的風險。
此時很誘人的一件事，是回頭把所有既有程式碼的測試都補寫出來。
- 當你需要為未測試的程式碼加功能時，先為它現有的功能寫測試
- 當你需要修 bug 時，先寫測試
- 當你需要重構時，先寫測試
你會發現開發起初感覺很慢：你花在寫測試的時間遠多於正常的 XP，而且感覺新功能的進展比以前慢。
然而，那些你老是造訪的部分——那些吸引注意力與新功能的部分——很快就會被徹底測試到。不久之後，系統中最常被使用的部分，感覺起來就像是用 XP 寫出來的。
設計#
轉向 XP 設計，很像轉向 XP 測試：你會注意到新程式碼的感覺與舊程式碼截然不同，於是你會想一次修好所有東西——別這樣。
一次一點點來。 加新功能時，準備好先重構。在 XP 開發中你本來就總是準備好在實作前先重構，只是轉型期你得更常這麼做。
把這些目標訂下來、寫在卡片上、顯眼地展示出來。 當你能宣告大重構完成時（可能得一小口一小口啃上數個月甚至一年），辦一場大派對，儀式性地把卡片燒掉，好好吃喝一頓。
這個策略的效果，很像需求驅動的測試策略：那些你在開發活動中經常造訪的系統部位，很快就會感覺像你現在正在寫的程式碼一樣；額外重構的開銷也會很快淡去。
規劃#
- 你必須把既有的需求資訊轉換成故事卡
- 你必須教育客戶遊戲規則
- 客戶必須決定下一次發布包含什麼
切換到 XP 規劃最大的挑戰（也是最大的機會），是教會你的客戶：他們能從團隊那裡得到的，比他們以為的多得多。
他們大概從沒經歷過一支歡迎需求變更的開發團隊。要習慣「客戶能從團隊多拿到多少」，需要一段時間。
管理#
最困難的轉變之一，是習慣 XP 式的管理——XP 管理是一場關於間接與影響力的遊戲。
如果你是管理者，你八成會抓到自己在做「該由程式設計師或客戶做」的決定。別慌——只要提醒自己與在場的每個人「我正在學」，然後去請對的人做這個決定，並把結果告訴你。
突然被賦予新責任的程式設計師，不太可能立刻表現優異。 身為管理者，你在轉型期必須小心地提醒每個人他們自己選擇的規則——因為壓力之下，每個人都會退回先前的行為模式，無論那些模式管不管用。
這種感覺有點像轉換設計或測試：起初會很彆扭，你會知道自己沒有全速前進。但隨著你留意日復一日發生的各種情境，你（以及程式設計師與客戶）會學會如何順暢處理它們，很快就會對新流程感到自在。
不過時不時會冒出一個你以前沒「極限地」處理過的情境。這時候，退一步，向團隊重申規則、價值與原則，然後再決定怎麼做。
管理一場疾馳中的 XP 轉型，最困難的面向之一是判定某位團隊成員不合適。在這種情況下，沒有他你們永遠比較好；而且一旦你確定情況不會再好轉，就該立刻做出改變。
開發#
重讀關於結對程式設計的材料（〈開發策略〉），把桌子擺成兩個人能並肩而坐、且不必移動椅子就能把鍵盤推來推去。
關於結對，轉型期有兩面：
- 一方面，轉型到 XP 時，你對結對程式設計應該比平常更嚴格。結對起初可能不舒服——逼自己去做，即使你不想。
- 另一方面，偶爾也要休息一下：自己躲開去寫個兩小時程式。當然結果要扔掉——但別為了能說「我這週結對了 30 小時」而摧毀你寫程式的樂趣。
至於測試與設計問題，一小口一小口地啃。並且，把你碰到的所有程式碼，都提升到你們議定的編碼標準——你會很驚訝，光是這麼簡單的活動就能學到多少東西。
如果專案已經陷入麻煩#
有些讀者手上有既有團隊，但軟體還沒上線，而且專案可能麻煩纏身——XP 看起來像是可能的救贖。
如果你從一開始就用 XP，也許（也許不）能避免現在的處境。但如果說在河中央換馬已經很難，那從一匹正在溺水的馬上換下來難十倍。情緒會很高漲，士氣會很低落。
如果選擇是「轉用 XP，否則走人」，那你首先要認清：你能一貫地採用新實踐的機會並不高。壓力之下，你會退回舊習慣——而你已經有一大堆壓力了，成功轉換的機會會被大幅削減。
慶祝你能學到多少關於測試的事、關於間接管理的事，或你能把設計做得多漂亮、能刪掉多少程式碼。也許會有足夠的秩序從混沌中浮現，讓你不介意隔天再來上班。
不過，如果你決定把一個陷入麻煩的專案轉向 XP，就把它做成一個戲劇性的姿態。半吊子的措施只會讓每個人停留在跟以前差不多的狀態。
仔細評估目前的程式碼庫：沒有它，你們會不會比較好？如果是，就沖掉它——全部。 辦一場大營火把舊磁帶燒了，休息一週，重新開始。