XP爲什麼不適合國內的現狀？下面是我個人的一些看法。
針對極限編程的準則：
- 用戶故事
先說說XP的描述：不需要在一開始完全瞭解需求，因爲以後很可能會變化。不需要一開始就瞭解詳細的需求，只需要到可以估算的程度就可以了，可以一邊實現一邊詳細瞭解，因爲有現場客戶在。不需要詳細的需求文檔，代之以用戶故事，因爲溝通勝過文檔，而且用戶故事簡單又容易編寫。
我的想法：用戶故事體現了將需求分解爲條目的思想，在這點上來說，是可取的。但是其他的說法就有問題了。
首先是不需要一開始就完全瞭解需求的說法。對於互聯網項目來講，這種說法可能是正確的，因爲需求變化非常快速。但是對於一般的業務應用系統來講呢？需求會變化，但是關鍵的業務流程是相對比較穩定的。當你明明可以掌握全局的時候如果還要偏激的從局部開始着眼的話，豈不是有些鑽牛角尖了？就好比要蓋一座房子，在初期我可以不清楚將來的衛生間如何裝修，但是總是需要在一開始的時候就瞭解需要打多深的地基吧？全面瞭解需求肯定有助於在項目開始時候建立正確的系統架構方案。
其次是關於需求文檔的問題。不可否認，在一定的項目規模內，有現場客戶在，再加上充分的溝通，能夠達到比文檔更好的效果。但是，限定條件是不是太多了一點啊？大一點的項目，如果需要40個成員都需要和現場客戶進行溝通怎麼辦？另外，我們知道，很多項目都會一期一期的做下去，鐵打的營盤流水的兵，幾期項目做下來，項目組成員甚至現場客戶早就不是原來的人了，這些人靠什麼來對項目進行了解呢？是不是項目組的老員工每個人都能夠知道項目的所有細節呢？有很多情況，如果想要比較透徹的理解需求和業務，則需要對該業務的發展背景以及生成原因有所瞭解，程序員和測試人員當然有權瞭解這些。而這些當然都需要有文檔來進行傳承，僅靠用戶故事顯然不能勝任。有很多情況，我們需要從更高的層面來觀察客戶的業務，需要看到一張客戶業務的全局性視圖，而從用戶故事那裏我們能夠得到什麼呢，全部都是局部的片段。有很多時候，一些非常複雜的業務流程是技術人員和客戶進行艱苦的討論得出的成果，這些討論的過程和結果如果不能夠記錄下來的話，早晚有一天，你會發現艱苦的討論經常會重複的出現。
第三，我們需要在項目初期就明確項目的business goal，明確項目邊界，我們還需要明確項目的非功能需求，這些都是用戶故事所無法承擔的工作。
最後，用戶故事代替需求需要有一個非常嚴格的配合條件：必須要有現場客戶，並且進行結對編程。 - 緊急設計過程
XP的原則：對於每個故事做少於15分鐘的預先設計，主要設計工具是白板和CRC卡片，使用最簡單的方式來實現眼前的問題。對於系統中出現的問題，使用重構來解決。
我的看法：XP承認這樣會帶來一些問題，所以必須嚴格執行配合條件：持續的重構。
同樣，對於互聯網項目來講，有一定的道理，但也是局部的。而對於業務應用系統來講呢？對於相對比較穩定的需求，我們仍然需要走到哪裏設計到哪裏並且修改的哪裏嗎？設計階段多花些時間能夠避免的問題依靠編碼之後的重構來進行解決嗎？重構的工作量會比預先設計的工作量小嗎？（按照教科書的說法應該是被放大10倍了吧？）這不是人爲的造成的浪費嗎？你的客戶除非就是你某個uncle，能夠允許你如此糟蹋他的資金。
中國古人扁鵲曾經介紹：真正的醫術高手其實是他的師兄，但是他的師兄爲什麼沒有他的名氣大呢？因爲扁鵲的師兄總是在別人的健康又出現問題的前兆的時候，就已經出手化解了。（這纔是高手中的高手啊！）亡羊補牢雖不算晚，但是防患於未然豈不是更好？
事無鉅細的預先設計是不現實的，但是完全省略也不是個辦法。
設計文檔需要嗎？顯然非常需要。還是那句話，很多項目是需要進行延續的。對於一個新的項目組成員來講，源代碼就算再規範，其可讀性也比不上設計文檔。做人真的不能只想着自己方便……
說的更遠一些，你的項目組中的經驗豐富的有設計能力的成員將無法充分發揮他的聰明才智。他將經常看到別的一些經驗不夠多的程序員對子寫的低水平代碼，然後對他們進行重構。這種感覺就像經常需要給別人擦屁股。 - 現場客戶
XP的原則：客戶長期與開發人員在同一間辦公室辦公，隨時解決開發人員關於需求的問題。現場客戶負責編寫用戶故事，負責決定用戶故事的優先級以及實現順序。現場客戶負責編寫驗收測試用例。
說說實話吧，你見過這樣的客戶嗎？
哪個客戶的公司能夠安排一個全職的客戶代表來參與到項目中呢？如果真的安排了一個客戶代表的話，他真的能夠全面瞭解需求並對之進行把握嗎？
哪個客戶公司的客戶代表有能力完成這些任務呢？如果有的話，我看其他的XP原則就算都不堅持，項目結果也不會差到哪裏去，因爲你的客戶代表本身就應該是一個很有經驗的項目經理了。
我們對客戶的要求過高了一點點吧？
而且，如果你所負責的項目的業務在客戶公司是跨部門的，那該怎麼辦？每個部門派一個客戶代表來嗎？
我看最有希望實施現場客戶原則的項目應該是那種爲公司內部開發的業務系統。即便如此，也很玄。 - 小型發佈
XP的原則：每隔一到兩個月對客戶進行一次系統發佈，儘量早的讓客戶看到可執行的系統。
我的看法：非常好。但是發佈規模小到什麼程度不能一概而論，只能說是儘量小。要做到小型發佈，則必須先實現持續集成，否則很難承擔多次的發佈成本。 - 規劃
XP強調了對每個迭代進行規劃。
我的看法：XP的說法並沒有錯，只是還缺了一些東西。我們需要對整個項目進行規劃，雖然越遠期的計劃可能越粗略，但是還是很有必要的。
軟件開發的合同不僅僅只是要求“我限定你這些時間，你看你能完成什麼？”，還會要求“我需要完成這些功能，你看看你需要多長時間？”所以，做到哪裏算哪裏的想法似乎只能存在於政府或高校的研發部門吧。 - 隱喻
在XP中，隱喻用來使項目成員對於系統的實現方式達成共識，但是似乎XP的教科書中對隱喻也沒有進行很透徹的講解。
在我看來：隱喻是設計和溝通的輔助手段，適當的應用效果理想。但是也僅僅就是一種輔助手段而已。 - 簡單設計
XP的原則：力求使用最簡單的方式實現當前的需求。簡單的就是最好的。
我的看法：這個說法本身就非常模糊，無法度量。簡單與複雜都是相對的，僅僅存在於人們的頭腦中，我覺得簡單的問題可能你就覺得非常複雜。現實當中無法一概而論。
另外，所有的時候最簡單的就是最好的嗎？典型的如8皇后問題，8重循環是最簡單的解決方案……
其實我們所追求的應該是不做不必要的複雜設計。
同樣，如果需要保持簡單設計原則有效，則必須配合重構原則。 - 結對編程
XP的原則：結對編程的優勢在於：代碼會被100%review，有效地降低代碼缺陷率，提供了很好的機會進行知識傳遞，使每個成員都有機會了解系統的全貌，提高生產效率。更換結對的週期從半天到3天不等。
我的看法：結對編程優點與缺點都很明顯。
每個項目組的成員都是有自己的特長和喜好的。最成功的管理是充分發揮每個人的優勢，而不是將每個人編程一模一樣的編程機器。有的人一邊討論一邊工作時思維會更加活躍，而有的人則是喜歡獨自安靜的思考。同樣，遇到不解的問題時，有的人喜歡立刻向別人請教，有的人喜歡現場是自己解決。我們必須面對這些差異性，而不是試圖將它們消除。從這個方面來講，XP顯得不那麼以人爲本。
開發人員作爲技術人員羣體，其中有相當一部分人個性很強但主動溝通能力不足。在國內，這樣的情況則更爲誇張一些。而往往這些技術強人在項目組成員當中有很有影響力。在這樣的情況下，如果我們不得不強迫進行結對編程的話，我想，管理層後面將面臨非常棘手的問題。
結論：結對編程是好東西，但需要根據具體情況適度運用。要想進行結對編程，必須具備項目組統一的編碼標準。 - 代碼集體擁有
XP原則：項目組的所有開發人員有權更改所有的代碼。每個人都對所有的代碼負有責任。
我的看法：容易落入的陷阱是：沒有人對代碼負有責任。
代碼集體擁有的前提是結對編程。否則的話，這就是一句空話。
編程有時候和體育競技有些類似的地方：高手的某個出招（實現技巧）在庸手看來是非常愚蠢的。在這樣的情況下，庸手會根據代碼集體所有權理直氣壯的對高手的精品代碼進行重構……
結論：代碼集體擁有可以實施，但是不能簡單處理，需要進行更多的溝通和一些技巧。 - 持續集成
XP原則：開發人員堅持隨時進行提交，系統每天一次集成。
我的想法：這是很好的原則。但願我們能夠做到。 - 編碼標準
XP原則：實行項目組統一的編碼標準，嚴格執行。
我的看法：這是最基本的。而且越嚴格越好。我們時刻需要提醒自己：軟件項目的產出是產品而不是藝術品。開發人員的想象力不需要浪費在這樣的地方。每個人寫的代碼不僅僅是給自己看的。 - 測試先行
XP原則：對於每一個用戶故事，在開始代碼之前，現場客戶就需要編寫驗收用例，而開發人員需要先編寫單元測試。這樣能夠保證每一個用戶故事是可測的而且是自動化測試。
我的看法：這是個非常令人憧憬的奮鬥目標。但是，理想很美好，現實很殘酷。
作爲一個典型的國內軟件公司來講，你所處的項目小組是什麼樣的人員素質呢？如果項目組有10個人的話，那麼其中3 個有經驗的開發人員，具有一定的設計能力。3個經驗稍差的熟練工，另外大約還會有2個應屆的畢業生。2個專職的測試人員，大約1-2年的工作經驗。這應該算是平均水平了吧，很多團隊連這個水平也達不到。這樣一個團隊存在什麼問題呢？
開發人員不會做測試，更加不會寫測試用例。個別開發人員甚至不太清楚單元測試是程序員的責任之一。測試人員不會寫代碼，多數都是高校it專業能力不足的畢業生，接收單位經考察認爲無法勝任開發工作，所以就去做測試吧。並不誇張，現狀就是如此。
在這樣一個團隊中強制執行測試先行，簡直就是自虐。
要實現這樣的目標需要循序漸進：第一步要求編碼人員自己完成單元測試並養成習慣，要求測試人員能夠撰寫全面的系統測試案例；第二步要求編碼人員能夠編寫單元測試代碼，要求測試人員能夠運用自動化測試工具進行迴歸測試；第三步要求編碼人員將單元測試編碼工作提前到編程之前進行，要求測試人員提前根據需求編寫自動化測試腳本。 - 重構
XP的原則：隨時對代碼進行重構，要進行殘忍的重構。
我的看法：有時候重構是必需的，但是重構不能代替預先設計。
進行重構時也需要小心，基於兩個因素：
第一，你的項目組成員有沒有能力進行正確的重構？中國的開發人員有百分之多少充分理解了設計模式呢？而耐心學習過重構的人會更少一些吧？我看你還是現在項目組內部做一些技術培訓再說吧。
第二，你的老闆或客戶能否允許你這樣做？重構是一件需要消耗成本、不產生利潤又需要冒很大風險的活動，至少表面看上去是這樣的。去說服你的老闆支持你的做法對每個人來講都是挑戰。
實施重構原則的前提是：必須實施代碼集體擁有原則。 - 每週工作40小時
XP原則：加班只會造成質量低下，要堅持每週工作40小時。
我的看法：這個不難，我所管理的項目沒有實施XP，也都輕鬆實現了這個原則。
上面就是我對極限編程的一些看法，極限編程並非一無是處，而是不適合中國國情。而且極限編程的各個實施原則之間是緊密耦合互相補充的，所以很難進行裁剪。
在我看來，極限編程的最大問題就在於“極限”二字。“水滿則溢，月盈而虧”是國人都明白的道理，所以對於極限編程而言，我們都需要問一句：“把所有的事情都做到極端就好嗎？”
最後，推薦ICONIX過程，一個相對比較中庸的敏捷過程，實施起來也不困難，指導明確，效果明顯。
http://liurongming.blog.163.com/blog/static/1053014422009064120264/?fromPostsense