隨便說說
先說什么樣的情況不適合xp
1. 大型和超大型的軟件項目
受限于溝通成本和人力資源限制， 大一點的軟件項目很難有效實施xp，即便是把團隊拆分成多個xp小組，隨著規模的擴大，也會面臨溝通機制失效而徹底失控的局面。
而xp強調以人為本，強調充分發揮個體程序員的能力，強調有效溝通，對程序員本身的綜合素質（注意不是單純的技術能力）是有相當要求的，對于大型項目，正如DEATH TO MARCH中的指出的， 人力資源永遠都是一個問題， 規模越大的項目可以獲得的合格程序員就越少， 越容易失控。

20個人在xp團隊是個很尷尬的數字，對于一個團隊來說，太大，拆分成2個團隊，又有點多余，而對于新建的xp團隊來說，應該從小規模做起，6-8人組比較妥當。


2. 做不到和用戶穿一條褲子的項目

xp和很多人的想法完全相反，他真正的核心在于站在用戶的立場上去考慮軟件開發， 所以如果項目團隊做不到這種立場的轉換，則必然失敗，而反過來，如果用戶還是抱著那種收鑰匙的態度做項目，不愿意或者沒有能力在項目中全程參與，那么也基本意味著失敗了， 用戶缺乏合作條件時固然可以使用有經驗的分析員或項目經理代表用戶，但是可以預計大部分情況下，大部分項目會缺乏這樣富有經驗能有效抓穩用戶需求的人。而更大的問題是，現在業界的一貫作風，包括18mo，hp這樣的公司，對用戶也是堅持一種坑蒙拐騙，軟硬兼施的態度，效果可想而知，所以xp一般在企業內部會更容易實施。

這條實際是xp能否正確實施的關鍵，如果做不到這點，就不要玩xp。相當多的xp團隊，實際上也沒有做到這點， 很多人錯誤的把xp理解為程序員的狂歡，因此而極力鼓吹xp，這也是xp獲得壞名聲的一個原因。

3.  boss，qc，團隊成員未能結成共識， 團隊內部結構不合理也缺乏對敏捷開發的認可。

對于boss和qc部門來說， xp項目的初期往往呈現出一種極度的混亂，要把這種混亂過渡到正常的，有序的混亂，需要相當的時間，xp項目在初期因此很容易被cancel了。如果不能和boss，qc部門做有效的溝通，那么需要花很多的精力在這些無謂的工作上。比如說，xp團隊是把qc做為開發人員的責任，要求qc全程融入開發過程，而一些大公司的qc部門，更習慣和開發團隊分開工作，只承擔過程檢查和質量驗收的工作，這是有問題的。

一個理想的團隊結構是接近金字塔的結構，有層次，而層次和各層之間能緊密耦合（具有良好的溝通協商機制）， 但是很多中小公司往往不具備這樣的結構。很多有經驗的程序員，尤其在國內，往往缺乏有效溝通和交流的能力，他們更習慣于單兵作戰，不擅長協作和團隊學習，這些程序員在實施xp的過程中往往會成為巨大的阻力，直接導致xp項目實施的失敗。我個人的經驗，花費巨大的精力試圖去轉換這部分程序員，基本是不可能完成的任務。

國內程序員的文化里面， 以技壓人是一個核心， 如果一個團隊缺乏塔尖的技術leader，是很難組織起有效的溝通文化的，這和很多外包團隊不同，他們的leader并不需要有太強的技術能力。而這個leader如果只是一個單純的技術上的geek，不是一個不喜歡團隊學習的人，或者還沒學會如何把手下當牛使， 實施xp也有相當大的風險。

一個xp團隊的建設，在早期leader需要花費大量的精力和大家達成共識，讓大家認可和接受xp的工作模式，盡可能在項目的早期讓成員體會到其中的好處，但是在國內缺乏有效的顧問團隊的情況下， coach這個角色很難找到合適的，也只能完全靠摸索。所以項目的早期往往能決定成敗。xp強調的是發揮人的主動性，如果無法讓團隊成員真正理解，支持這一點，同意自發的改變他們傳統的工作模式，全靠boss或者leader的強制推行的話（這實際就是xp極力反對的），是注定失敗的。

如果無法改變團隊成員結構，無法和團隊成員達成共識，則應該尊重團隊人員的實際能力和意愿，采取更合適的開發方法。

國內的xper在推行xp的過程中，都很容易忽略一點，國內程序員文化和西方程序員文化是截然不同的 ，鬼子越是精英的人，越喜歡合作，國內剛好相反。所以在國內最容易組建的xp團隊，往往是由1，2個骨干和大量菜鳥構成的，白紙最好畫。一些彼此關系融洽，長期合作的老鳥，也很適合組成xp團隊。

上面說的是什么樣的情況不適合做xp，實際上，我用了2，3年的時間才逐漸明白這些東西。至于如何做好xp，那是一個很長很長的話題，而正如我前后所提，大部分項目并不適合做xp， 圖壁哦鬧得圖壁，你需要先考慮清楚這個問題。

順便解釋一下xp的某些誤區

1. xp很適合做engineering的項目，很多xp項目都是這個類型的， 實際上，我最早接觸的xp概念來自hp， 國內最早開始推廣xp的人也來自hp的電子商務團隊。不過因為前面2的原因， xp最適合做大企業內部的項目，或者產品研發性質的項目。

2. xp和scrum沒有等同關系， xp和scrum，iconix，crystal，fdd都是Agile運動的主力， 如果說他們之間有關系的話，那個關系就是agile的核心，軟件開發以人為本。
scrum和icons相對xp沒有那么激進，更適合那種傳統上已經建立了過程管理機制的團隊。fdd是個很好玩的東西， 創建者更是一個傳奇，有興趣的同學可以找找看看。 弄清楚xp和agile的區別，你會明白，你其實還有很多選擇。

【G：xp算是agile中最激進的一種了，有個老板曾經說過，辛辛苦苦幾十年一下回到解放前】

3. 大部分號稱是xp的項目實際都不是xp，原因請對照上面3條和下面的6。基于國內程序員文化和國外的巨大差異，還有業界的生存空間的慘烈狀況等等，單純的xp很難玩。在我看過的幾個公司，所謂的xp都變成老板玩程序員的游戲或者變成程序員玩老板的游戲。xp在國內已經變成一個符號，一種時尚。 有個笑話，我以前一個同事管理的項目，某人要辭職回家去研究xp，說要花半年時間在家里獨自刻苦鉆研，徹底掌握xp精髓再出來工作，弄得我哭笑不得。


4. 國內大公司做CMMI，CMM是主流， 表面上 CMM和xp是完全對立的東西，最容易引起直接沖突的是文檔問題，但是實際沒有根本意義上的沖突，可惜能真正理解到這一層的人不多，所以對于實施CMM、CMMI或者強調過程化的公司，XP注定是很容易失敗的。玩rup平穩的多，雖然罕見有人能玩好，但是至少能多解決一些人的就業問題

5. 傳統的軟件工程和學院派，最主要是服務商強調的是通過制度和工具來回避人力資源的問題，不管好汗孬種全部螺絲釘花，大家都流水線。而xp強調的是極度發揮個人的能力來提高軟件開發效率間接解決人力資源的問題， 這2者代表了解決方式的兩個極端，所以xper和傳統教授學者整天打架。 有趣的是，我認識的一個很有見地的一個美國名牌商學院的教授，也極力支持前者，并再三鼓吹工具終究能代替一般程序員，呵呵，我覺得有趣的原因是他在技術問題上發表過一些相當有水準和這個觀點根本是對立的文章，看來還是屁股決定了腦袋的立場。
[G:其實人家是商學院的，當然要支持了，這叫市場策劃]

6. xp的那些最佳實踐都不是xp首創的， 這些實踐只是業界對軟件開發過程中的一些有效經驗的總結，所以同樣可以使用在其他類型的開發過程中，并取得很好的效果。 xp中最難接受的2個實踐TDD和PP也是如此，用在別的過程里一樣困難，但是用好了一樣舒服。而xp的獨特在于強調這些實踐的綜合利用，利用彼此之間是互補和互相推動關系來達到最佳效果，所以一直有不實踐所有最佳實踐就不是xp的說法。 比如TDD和PP, 某些人對TDD方式產生的代碼質量有質疑，而xp中實際是通過PP來彌補單純TDD的代碼覆蓋率問題的。 所以我個人覺得，選擇什么樣的開發方法， 都應該看一下xp和rup的相關東西，能開闊你的思路，當然里面的大量問題，都只能通過實踐才能吃透。

作為一個項目管理者應該明白一點， 沒有任何方法和過程是萬能的，有效的項目管理應該關注的是如何用好手中的牌，盡可能的玩好這一局， xp只是其中的一種可能性選擇而已。

xp的精髓在一些傳統的著作里面都可以找到，推薦看一下人月神話， Death to MARCH ， xp中文系列書籍里面有一本玩者致勝（play to winning？），對我幫助很大，可以看看， 另外國內有個人寫了一本關于xp實踐的書，里面的經驗教訓總結的非常好，基本都是當年我曾經碰到過的，也絞盡腦汁要解決的，很值得讀，好像叫極限編程的實踐與鏡像之類的吧。不好意思，離開軟件開發這個行業好幾年了， 記不準確了。 另外如果下定決心要這么玩的話，現在已經有條件可以請顧問了，建議請TW中國的人來顧問一下，這可以省掉很多彎路，否則，可能光為怎么做是xp都pk半年。