在文章遠離極限程式設計(Don’t do XP) 裡, Tobias Mayer 建議人們不要去搞極限程式設計(XP)。 我和Tobias相知已久，我想他這個問題上錯了。 我不知道他在跟誰爭論，但他們的有些爭論就是“嚼舌根”。我想如果他曾經試過一次XP，那他的言論會更有說服力。 XP並不是一個萬能的解決方案，但它確實是一種方案，而且我們知道如何使用它。
作為一個臨時的XP支持者，我並不抱怨 “在軟體工業中Scrum沒有提供很好的開發原則”，我只抱怨這個產業。 如果我們能在這個產業裡有效率的工作，那我們也就不會有這場關於方法論的戰爭了，因為我們的目地就是出產品。 如今當人們把Scrum概念應用到這個產業時，Scrum也不幸被人們使用的混亂不堪。 另一方面，責備XP阻礙了實施方法的進步顯然有些牽強。
XP是一種很小的運動，只吸引了一部分人的目光。 XP（第一版）所實現的成果是讓大家知道解決一直困擾很多開發團隊的無法負擔開發工期壓力的問題是有辦法解決的，而且是在不須求助高人協助的情況下。 它提供了我一套好的實踐方法讓我們在開發中使用。 當然了， XP 並不能解決世界上的所有問題 ，它並不是對每個人都適用，至少一個原因是你必須對它有相當的認識和研究，這是一般的團隊所不具備的。 Kent beck所論述的第一版XP極具有針對性：它的設計目標是讓我們控制混亂，拓寬我們軟體開發的思路，重新制定研討框架。
我 想Tobias似乎已經忘了這十年來發生的事情。 其實我們所處的完全是一個理論性的運動，因為XP把推遲程式碼實現作為論述的中心—— 只需看看與此相關的人，他們是相同的一群人。 他似乎也忘了眾多的XP實施建議直接和我們的直觀感覺有衝突，特別是和當前的產業發展方向有衝突。
Tobias說這些優秀的開發實施意見傳播的如此緩慢，而我要說的是，沒有XP，我們估計仍在原地等待。 測試驅動開發一直沒有被廣泛的接受，甚至連最初的C3小組也沒有完全的接受它——直到有一天Kent寫出了這本書。 持續反省理論有一小群學院派的人追隨，但是這種理論的實踐如果沒有TDD很好的支援會存在一定的風險情。 我懷疑大多數的團隊仍舊不願輕易重整程式碼，除非要新增新的功能。 結隊程式設計方式也在滯銷，同樣，這種方式在TDD的環境中發揮的會更好。 我知道有相當多的Scrum團隊都沒有找到一套系統的方法理論。 如果說他們需要改進Scrum的實施方法，這是把問題歸咎於他們如何使用Scrum和他們的自我組織問題。
最的的一點挑剔。 XP的論著有二版，第二版釋出不是很久遠，而且裡面提到的方法論更加“柔和”。 與這些實踐理論相關的一件事情：C3 專案組是在 (Smalltalk/Gemstone) 這樣的環境中工作的，落後於大多數我們今天使用的環境。 XP社團裡的很多工作都是在增加XP的靈活性，讓它能在新的開發環境中使用。 真正讓人恐怖的事是這個產業緩慢的發展速度。