XP 的確切邊界尚未明朗。但有幾個絕對的致命障礙會讓 XP 無法運作：大團隊、不信任的客戶，以及不支援優雅變更的技術。

為什麼「不該用」和「該用」一樣重要#

XP 中有些實踐無論你怎麼看待整幅圖像都是好主意——你就該做，沒別的。測試就是好例子。規劃遊戲大概也管用，即使你在估算與前期設計上花更多時間。然而如 20–80 法則所示，「全部」與「不是全部」之間，很可能有巨大的差別。

老實說，完整的 XP 並不是一個能到處講的故事，也不是一個應該到處講的故事。

有些時間、地點、人與客戶，會像戳破一顆便宜氣球那樣讓 XP 專案爆掉。在「註定失敗」的地方不使用 XP，和在「能帶來真正優勢」的地方使用它，同等重要。

作者說他不會告訴你「別用 XP 造飛彈鼻錐」——他從沒寫過飛彈鼻錐軟體，不知道那是什麼樣子，所以既無法說 XP 會成功，也無法說它不會。如果你寫飛彈鼻錐軟體，你可以自己判斷。

不過他失敗過的次數夠多，足以知道 XP 確實行不通的幾種方式。以下是他知道「用 XP 效果不好」的環境清單。

障礙一：企業文化#

任何試圖靠「把車頭對準正確方向」來跑專案的企業，遇上一支堅持要「掌舵」的團隊，都會很難受。

「大規格書」變體#

「把車頭對準方向」的一個變體是大規格書。如果客戶或管理者堅持在動手寫程式這件「小事」之前，要先有完整的規格、分析或設計，那團隊文化與客戶／管理者文化之間必然摩擦。

專案用 XP 仍可能成功，但不會輕鬆——因為你是在要求對方拿一份「給了他控制感的文件」，去換一場「要求他持續投入」的對話（規劃遊戲）。對一個本來就分身乏術的人來說，那可能很可怕。

加班文化#

另一種不利於 XP 的文化，是要求你投入長時間工時以證明「對公司的忠誠」。

你不能在疲憊狀態下執行 XP。 如果一支團隊以最高速工作所產出的量，對你的公司來說還不夠，那 XP 就不是你的解答。

一個 XP 專案上連續第二週的加班，是流程出了問題的確鑿徵兆，你最好把出問題的地方修好。

障礙二：某些人#

有時候正是聰明人，最難把「猜對遊戲」換成緊密溝通與持續演化。

障礙三：規模#

規模顯然有影響。

• 一百個程式設計師的 XP 專案，你大概跑不動
• 五十個，也不行
• 二十個，大概也不行
• 十個絕對可行
• 三、四個程式設計師時，你可以安全地捨棄一些聚焦於「程式設計師協調」的實踐，例如迭代規劃遊戲

如果你有一個大專案，可以先用一支小團隊試 XP 一個月，看看你可能開發得多快。

障礙四：技術#

本質上呈指數成本曲線的技術#

例如：你正在開發第 N 套使用同一個關聯式資料庫的主機系統，而你並非絕對確定資料庫綱要「現在與永遠」都正好是你需要的樣子——那你就不該用 XP。

XP 仰賴讓程式碼保持乾淨與簡單。如果你為了避免修改 200 支既有應用而把程式碼弄複雜，很快你就會失去當初引你走向 XP 的那份彈性。

回饋週期過長的環境#

• 如果你的系統要花 24 小時才編譯連結完，你很難一天整合、建置、測試好幾次
• 如果軟體上線前必須經過兩個月的品保週期，你會很難學到足夠的東西來取得成功

無法實際測試的環境#

作者見過根本不可能實際測試軟體的環境：

• 你在一台滿載運轉的百萬美元機器上跑正式系統，而周遭就是沒有另一個一百萬美元
• 或者可能出問題的組合多到你根本無法在一天內跑完任何有意義的測試套件

這種情況下，你完全有理由用「思考」換掉「測試」——但那時候你就不再是在做 XP 了。

作者說他在那種環境寫程式時，從來不覺得自己能自由地演化軟體設計，他必須預先把彈性建進去。你仍然能用這種方式做出很棒的軟體，但你不該用 XP 去做。

障礙五：實體環境#

還記得那個「資深人員各佔角落辦公室」的故事嗎？如果你的實體環境不對，XP 就無法運作。

作者所知最好的環境是：一個大房間，周邊圍著小隔間，中央的桌上擺著強力機器。

如果你絕對搬不動桌子、或噪音水準妨礙對話、或你們無法近到能發生偶遇式的溝通，那你就無法把 XP 執行到接近它的完整潛力。

確定行不通的情況：

• 程式設計師分在兩個樓層——免談
• 程式設計師在同一樓層但相距甚遠——免談
• 地理上分隔——如果真的是兩支團隊在做互動有限的相關專案，大概可行。作者的做法是：先把他們當成一支團隊起步，出完第一次發布，再沿著應用的自然斷裂線把團隊拆開，讓每一部分各自成長。

最後，房間裡有嬰兒在尖叫時，你絕對沒有辦法做 XP。相信作者這一點。