傳統(tǒng)軟件工程方法的文檔輛過重
??
于是出現(xiàn)了 ?? 敏捷開發(fā) ?? “輕量級”方法的軟件開發(fā)方法
??
XP是敏捷開發(fā)的一種方式

定義：

XP是一種輕量（敏捷）妖胀、高效篡殷、低風險嫩絮、柔性秽澳、可預測泻骤、科學而且充滿樂趣的軟件開發(fā)方式惧盹。與其他方法論相比，其最大的不同在于：

• 在更短的周期內瞪讼，更早地提供具體钧椰、持續(xù)的反饋信息。
• 在迭代的進行計劃編制符欠，首先在最開始迅速生成一個總體計劃嫡霞，然后在整個項目開發(fā)過程中不斷的發(fā)展它。
• 依賴于自動測試程序來監(jiān)控開發(fā)進度希柿，并及早地捕獲缺陷诊沪。
• 依賴于口頭交流养筒、測試和源程序進行溝通。
• 倡導持續(xù)的演化式設計端姚。
• 依賴于開發(fā)團隊內部的緊密協(xié)作晕粪。
• 盡可能達到程序員短期利益和項目長期利益的平衡。

內容：

XP由價值觀渐裸、原則巫湘、實踐和行為四個部分組成，它們彼此相互依賴昏鹃、關聯(lián)尚氛， 并通過行為貫穿于整個生命期

一、 四大價值觀：溝通洞渤、簡單阅嘶、反饋、勇氣载迄。

1. 溝通促進協(xié)作讯柔；

• 工作簡單化，重復沒必要的工作cut掉护昧；提倡對代碼進行重構磷杏，保持良好結構和可拓展性；
• 開發(fā)內部及時反饋代碼問題與進展捏卓；向客戶與管理層及時反饋可運行版本及時發(fā)現(xiàn)問題极祸；
• XP方法論要求開發(fā)人員穿上強大、自動測試的盔甲怠晴，勇往直前遥金，在重構、編碼規(guī)范的支持下蒜田，有目的地快速開發(fā)
  在這四大價值觀之下稿械，隱藏著一個更深刻的東西，那就是尊重冲粤。
  因為這一切都建立在團隊成員之間的相互關心美莫、相互理解的基礎之上。

二梯捕、 原則

1. 快速反饋
   及時地厢呵、快速地獲取反饋，并將所學到的知識盡快地投入到系統(tǒng)中去傀顾；
   （開發(fā)人員應該通過較短的反饋循環(huán)迅速地了解現(xiàn)在的產(chǎn)品是否滿足了客戶的需求）
2. 簡單性假設
   要求開發(fā)人員將每個問題都看得十分容易解決襟铭，也就是說只為本次迭代考慮，不去想未來可能需要什么，相信具有將來必要時增加系統(tǒng)復雜性的能力寒砖，也就是號召大家出色地完成今天的任務赐劣。
3. 逐步修改
   微調。不要一次做出很大的改變哩都，那樣將會使得可控性變差魁兼。
4. 提倡更改
   盡量為下一次修改做好準備。
5. 優(yōu)質工作
   貫徹的是“小步快走”的開發(fā)原則漠嵌，因此工作質量決不可打折扣咐汞，通常采用測試先行的編碼方式來提供支持。

三献雅、 實踐（13個）
在XP中碉考，集成了13個最佳實踐塌计。有趣的是挺身，它們沒有一個是創(chuàng)新的概念，大多數(shù)概念和編程一樣老锌仅。其主要創(chuàng)新點在于提供一種良好的思路章钾，將這些最佳實踐結合在一起，并且確保盡可能徹底地執(zhí)行它們热芹，使得它們能夠在最大程度上相互支持贱傀。

1. 計劃游戲

• 主要思想：先快速地制定一份概要的計劃，然后隨著項目細節(jié)的不斷清晰伊脓，再逐步完善這份計劃府寒。
• 產(chǎn)生的結果：一套用戶故事及后續(xù)的一兩次迭代的概要計劃。
• 計劃游戲獲得成功的前提條件：客戶負責業(yè)務決策报腔，開發(fā)團隊負責技術決策株搔。（系統(tǒng)的范圍、下一次迭代的發(fā)布時間纯蛾、用戶故事的優(yōu)先級應該由客戶決定纤房；而每個用戶故事所需的開發(fā)時間、不同技術的成本翻诉、如何組建團隊炮姨、每個用戶故事的風險，以及具體的開發(fā)順序由開發(fā)團隊決定碰煌。）
• 流程：
  • 首先客戶和開發(fā)人員坐在同一間屋子里舒岸，每個人都準備一支筆、一些用于記錄用戶故事的紙片芦圾，最好再準備一個白板
  • 客戶編寫故事：由客戶談論系統(tǒng)應該完成什么功能吁津，然后用通俗的自然語言，使用自己的語匯，將其寫在卡片上
  • 開發(fā)人員進行估算：首先客戶按優(yōu)先級將用戶故事分成必須要有碍脏、希望有梭依、如果有更好三類，然后開發(fā)人員對每個用戶故事進行估算典尾，先從高優(yōu)先級開始估算役拴。如果在估算的時候，感到有一些故事太大钾埂，不容易進行估算河闰，或者是估算的結果超過2人/周，那么就應該對其進行分解褥紫，拆成2個或者多個小故事
  • 確定迭代的周期：接下來就是確定本次迭代的時間周期姜性，這可以根據(jù)實際的情況進行確定，不過最佳的迭代周期是2~3周髓考。有了迭代的時間之后部念，再結合參與的開發(fā)人數(shù)，算出可以完成的工作量總數(shù)氨菇。然后根據(jù)估算的結果儡炼，與客戶協(xié)商，挑出時間上夠查蓉、優(yōu)先級合適的用戶故事組合乌询，形成計劃

2. 小型發(fā)布
   每一次發(fā)布的版本應該盡可能的小，秉承“持續(xù)集成豌研，小步快走”的哲學妹田。前提條件：每個版本有足夠的商業(yè)價值，值得發(fā)布鹃共。
   由于小型發(fā)布可以使得集成更頻繁鬼佣，客戶獲得的中間結果也越頻繁，反饋也就越頻繁及汉，客戶就能夠實時地了解項目的進展情況沮趣，從而提出更多的意見，以便在下一次迭代中計劃進去坷随。以實現(xiàn)更高的客戶滿意度房铭。
3. 隱喻
   相對而言，隱喻這一個最佳實踐是最令人費解的温眉。根據(jù)詞典缸匪，隱喻的定義是：一種語言的表達手段，它用來暗示字面意義不相似的事物之間的相似之處类溢。（當然凌蔬，如果能夠找到合適的隱喻是十分快樂的露懒，但并不是每種情況都可以找到恰當?shù)碾[喻，也沒有必要強求）

• 隱喻的作用：
  • 尋求共識：也就是鼓勵開發(fā)人員在尋求問題共識時砂心，可以借用一些溝通雙方都比較熟悉的事物來做類比懈词，從而幫助大家更好地理解解決方案的關鍵結構，也就是更好地理解系統(tǒng)是什么辩诞、能做什么坎弯。
  • 發(fā)明共享詞匯：通過隱喻，有助于提出一個用來表示對象译暂、對象間的關系通用名稱抠忘。例如，策略模式（用來表示可以實現(xiàn)多種不同策略的設計模式）外永、工廠模式（用來表示可以按需“生產(chǎn)”出所需類得設計模式）等崎脉。
  • 創(chuàng)新的武器：有的時候，可以借助其他東西來找到解決問題的新途徑伯顶。例如：“我們可以將工作流看做一個生產(chǎn)線”囚灼。
    描述體系結構：體系結構是比較抽象的，引入隱喻能夠大大減輕理解的復雜度砾淌。例如管道體系結構就是指兩個構件之間通過一條傳遞消息的“管道”進行通信啦撮。

4. 簡單設計
   強調簡單設計的價值觀谭网，引出了簡單性假設原則汪厨，落到實處就是“簡單設計”實踐。這個實踐看上去似乎很容易理解愉择，但卻又經(jīng)常被誤解劫乱，許多批評者就指責XP忽略設計是不正確的。其實锥涕，XP的簡單設計實踐并不是要忽略設計衷戈，而且認為設計不應該在編碼之前一次性完成，因為那樣只能建立在“情況不會發(fā)生變化”或者“我們可以預見所有的變化”之類的謊言的基礎上的层坠。

Kent Beck概念中簡單設計是這樣的：
>能夠通過所有的測試程序殖妇。
沒有包括任何重復的代碼。
清楚地表現(xiàn)了程序員賦予的所有意圖破花。
包括盡可能少的類和方法

他認為要想保持設計簡單的系統(tǒng)谦趣，需要具備簡單思考的能力，擁有理解代碼和修改的勇氣座每，以及為了消除代碼的“壞味道”而定期重構的習慣前鹅。

流程：
（1）首先寫測試代碼：具體將在后面詳細描述。
（2）保持每個類只負責一件事：SRP（單一職責原則）是面向對象設計的基礎原則之一峭梳。
（3）使用Demeter（迪米特）法則：迪米特法則舰绘，也稱為LoD法則、最少知識原則。也就是指一個對象應當對其他對象盡可能少地了解捂寿。用隱喻的方法來解釋的話就是“只與你直接的朋友通信”口四、“不要和陌生人說話”。
（4）使用CRC卡片進行探索秦陋。

5. 測試先行／測試驅動開發(fā)
   打個比方：
   工匠一：先拉上一根水平線窃祝，砌每一塊磚時，都與這跟水平線進行比較踱侣，使得每一塊磚都保持水平粪小。
   工匠二：先將一排磚都砌完，然后再拉上一根水平線抡句，看看哪些磚有問題探膊，對有問題的磚進行適當?shù)恼{整。
   顯然待榔，工匠二的做法浪費時間逞壁。然而平時在編寫程序的時候又是怎么做的呢？我們就是按工匠二的方法在工作呀锐锣！甚至有時候比工匠二還笨腌闯，是整面墻都砌完了，直接進行“集成測試”雕憔，經(jīng)常讓整面的墻倒塌姿骏。

不僅我們沒有采用工匠一的工作方法，甚至有的時候程序員會以“開發(fā)工作太緊張”為理由斤彼，而忽略測試工作分瘦。但這樣卻導致了一個惡性循環(huán)，越是沒有空編寫測試程序琉苇，代碼的效率與質量越差嘲玫，花在找Bug、解決Bug的時間也越來越多并扇，實際產(chǎn)能大打降低去团。由于產(chǎn)能降低了，因此時間更緊張穷蛹，壓力更大土陪。你想想，為什么不拉上一根水平線呢俩莽？難道旺坠，我們不能夠將后面浪費的時間花在單元測試上，使得我們的程序一開始就更健壯扮超，更加易于修改嗎取刃？不過蹋肮，編寫測試程序當然要比拉一條水平線難道多，所以我們需要引入“自動化測試工具”璧疗，免費的xUnit測試框架就是你最佳的選擇坯辩。
為了鼓勵程序員原意甚至喜歡在編寫程序之前編寫測試代碼，XP方法論還提供了許多有說服力的理由崩侠。
如果你已經(jīng)保持了簡單的設計漆魔，那么編寫測試代碼根本不難。
如果你在結對編程却音，那么如果你想出一個好的測試代碼改抡，那么你的伙伴一定行。
當所有的測試都通過的時候系瓢，你再也不會擔心所寫的代碼今后會“暗箭傷人”阿纤，那種感覺是相當棒的。
當你的客戶看到所有的測試都通過的時候夷陋，會對程序充滿前所未有的信心欠拾。
當你需要進行重構時，測試代碼會給你帶來更大的勇氣骗绕，因為你要測試是否重構成功只需要一個按鈕藐窄。

測試先行是XP方法論中一個十分重要的最佳實踐，并且其中所蘊含的知識與方法也十分豐富酬土。

6. 重構
   重構時一種對代碼進行改進而不影響功能實現(xiàn)的技術荆忍，XP需要開發(fā)人員在聞到代碼的壞味道時，有重構代碼的勇氣诺凡。
   重構的目的是降低變化引發(fā)的風險东揣，使得代碼優(yōu)化更加容易践惑。通常重構發(fā)生在兩種情況之下腹泌。
   實現(xiàn)某個特性之前：嘗試改變現(xiàn)有的代碼結構，以使得實現(xiàn)新的特性更加容易尔觉。
   實現(xiàn)某個特性之后：檢查剛剛寫完的代碼后凉袱，認真檢查一下，看是否能夠進行簡化侦铜。

在《重構》一書中专甩，作者Martin Fowler提示我們：在考慮重構時，應該要養(yǎng)成編寫并經(jīng)常運行測試代碼的習慣钉稍；要先編寫代碼涤躲，再進行重構；把每一次增加功能都當做一次重構的好時機贡未；將每一個糾正錯誤當做一次重構的重要時機种樱。同時蒙袍，該書中也列出大量需要重構的情況和重構方法。
最后類似地嫩挤，給還沒有足夠勇氣進行重構的程序員打幾劑強心針：
XP提倡集體代碼所有制害幅，因此你可以大膽地在任何需要修改的地方做改動。
由于在XP項目組中有完整的編碼標準岂昭，因此在重構前無須重新定義格式以现。
在重構中遇到困難，和你結對編程的伙伴能夠為你提供有效的幫助约啊。
簡單的設計邑遏，會給重構帶來很大的幫助。
測試先行讓你擁有了一個有效的檢驗器恰矩，隨時運行一下就知道你重構的工作是否帶來了影響无宿。
由于XP在持續(xù)集成，因此你重構所帶來的破壞很快就能夠暴露枢里，并且得以解決孽鸡。

重構技術是對簡單性設計的一個良好的補充，也是XP中重視“優(yōu)質工作”的體現(xiàn)栏豺，這也是優(yōu)秀的程序員必備的一項技能彬碱。

7. 結對編程
   “什么！兩個人坐在一起寫程序奥洼？那豈不是對人力的巨大浪費嗎巷疼？而且我在工作時可不喜歡有一個人坐在邊上當檢察官×榻保”是的嚼沿，正如這里列舉出來的問題一樣，結對編程技術還是被很多人質疑的瓷患。
   但是長期研究得出：結對編程的效率反而比單獨編程更高骡尽。一開始雖然會犧牲一些速度，但慢慢的擅编，開發(fā)速度會逐漸加快攀细。
   究其原因，主要是結對編程大打降低了溝通的成本爱态，提供了工作的質量谭贪，具體表現(xiàn)在：

• 所有的設計決策確保不是由一個人做出的。

• 系統(tǒng)的任何一個部分都肯定至少有2個人以上熟悉锦担。
• 幾乎不可能有2個人都忽略的測試項或者其他任務俭识。
• 結對組合的動態(tài)性，是一個企業(yè)知識管理的好途徑洞渔。
• 代碼總是能夠保證被評審過套媚。
• 而且XP方法論集成的其他最佳實踐也能夠使得結對編程更加容易進行：
  • 編碼標準可以消除一些無謂的分歧理盆。
  • 隱喻可以幫助結對伙伴更好地溝通。
  • 簡單設計可以使得結對伙伴更了解他們所從事的工作凑阶。

結對編程技術被譽為XP保持工作質量猿规、強調人文主義的一個典型的實踐，應用得當還能夠使得開發(fā)團隊之前的協(xié)作更加流暢宙橱、知識交流與共享更加頻繁姨俩，團隊的穩(wěn)定性也會更加穩(wěn)固。

8. 集體代碼所有制
   團隊中的每個成員都擁有對代碼進行改進的權利师郑，每個人都擁有全部代碼环葵，也都需要對全部代碼負責。同時宝冕，XP強調代碼是誰破壞的（也就是修改后發(fā)生問題）张遭，就應該由誰來修復。
   由于在XP中地梨，有一些與之匹配的最佳實踐菊卷，因此你并無須擔心采用集體代碼所有制會讓你的代碼變得越來越亂。
   由于在XP項目中宝剖，集成工作是一件經(jīng)常性得工作洁闰，因此當有人修改代碼而帶來了集成的問題，會在很快的時間內被發(fā)現(xiàn)万细。
   由于每一個類都會有一個測試代碼扑眉，因此不論誰修改了代碼，都需要運行這個測試代碼赖钞，這樣偶然性的破壞發(fā)生的概率將很小腰素。
   由于每一個代碼的修改就是通過了結對的兩個程序員共同思考，因此通常做出的修改都是對系統(tǒng)有益的雪营。
   由于大家都堅持了相同的編碼標準弓千，因此代碼的可讀性、可修改性都會比較好卓缰，而且還能夠避免由于命名法计呈、縮進等小問題引發(fā)經(jīng)常性得代碼修改。

集成代碼所有制是XP與其他敏捷方法的一個較大不同征唬，也是從另一個側面體現(xiàn)了XP中蘊含的很深厚的編碼情節(jié)。

9. 持續(xù)集成
   在前面談到小型發(fā)布茁彭、重構总寒、結對編程、集體代碼所有制等最佳實踐的時候理肺，我們多次看到“持續(xù)集成”的身影摄闸，可以說持續(xù)集成是對這些最佳實踐的基本支撐條件善镰。
   可能大家會對持續(xù)集成與小型發(fā)布代表的意思混淆不清，其實小型發(fā)布是指在開發(fā)周期經(jīng)常發(fā)布中間版本年枕，而持續(xù)集成的含義則是要求XP團隊每天盡可能多次地做代碼集成炫欺，每次都在確保系統(tǒng)運行的單元測試通過之后進行。
   這樣熏兄，就可以及早地暴露品洛、消除由于重構、集體代碼所有制所引入的錯誤摩桶，從而減少解決問題的痛苦桥状。
   要在開發(fā)過程中做到持續(xù)集成并不容易，首先需要養(yǎng)成這個習慣硝清。而且集成工作往往是十分枯燥辅斟、煩瑣的，因此適當?shù)匾朊咳占晒ぞ呤鞘直匾穆谩P建議大家首先使用配置管理服務器將代碼管理起來士飒，然后使用Ant或Nant等XP工具，編寫集成腳本蔗崎，調用xUint等測試框架变汪，這樣就可以實現(xiàn)每當程序員將代碼Check in到配置服務器上時，Ant就會自動完成編譯和集成蚁趁，并調用測試代碼完成相應的測試工作裙盾。
10. 每周工作40小時／可持續(xù)的速度
    XP方法論認為，加班最終會扼殺團隊的積極性他嫡，最終導致項目失敗番官。充分體現(xiàn)了XP方法關注人的因素比關注過程的因素更多一些。
    Kent Beck認為開發(fā)人員即使能夠工作更長的時間钢属，他們也不該這樣做徘熔，因為這樣做會使他們更容易厭倦編程工作，從而產(chǎn)生一些影響他們效能的其他問題淆党。因此酷师，每周工作40小時是一種順勢行為，是一種規(guī)律染乌。其實對于開發(fā)人員和管理者來說山孔，違反這種規(guī)律是不值得的。
    開發(fā)人員：如果不懂得休息荷憋，那么就無法將自己的節(jié)奏調整到最佳狀態(tài)台颠，那么就會帶來很大的負面影響。而且在精神不集中的狀態(tài)下勒庄，開發(fā)質量也得不到保證串前。
    管理者：也許這可以稱得上“第二種人月神話”瘫里，那就是你不得不通過延長每天的工作時間來獲得更多的人月。這是因為荡碾，每個開發(fā)人員的工作精力是有限的谨读，不可能無限增長，在精力不足的時候坛吁，不僅寫出來的代碼質量沒有保障劳殖，而且還可能為項目帶來退步的效果。因此采用加班的方式并不是一個理性的方式阶冈，是得不償失的闷尿。

不過有一點是需要解釋的，“每周工作40小時”中的40不是一個絕對數(shù)女坑，它所代表的意思是團隊應該保證按照“正常的時間”進行工作谬晕。那么如何做到這一點呢卢未？
首先臂港，定義符合你團隊情況的“正常工作時間”椒涯。
其次，逐步將工作時間調整到“正常工作時間”碉就。
再次盟广，除非你的時間計劃一團糟，否則不應該在時間妥協(xié)瓮钥。
最后筋量，鼓起勇氣，制定一個合情合理的時間表碉熄。
正如米盧說過的“享受足球”一樣桨武，同樣地，每一個開發(fā)人員應該做到“享受編程”锈津，那么“每周工作40小時”就是你的起點呀酸。
團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作琼梆，他們保存精力性誉，他們把項目看作是馬拉松長跑，而不是全速短跑茎杂。

11. 現(xiàn)場客戶
    為了保證開發(fā)出來的結果與客戶的預想接近错览，XP方法論認為最重要的需要將客戶請到開發(fā)現(xiàn)場。就像計劃游戲中提到過的蛉顽，在XP項目中蝗砾，應該時刻保證客戶負責業(yè)務決策，開發(fā)團隊負責技術決策携冤。因此悼粮，在項目中有客戶在現(xiàn)場明確用戶故事，并做出相應的業(yè)務決策曾棕，對于XP項目而言有著十分重要的意義扣猫。
    也許有人會問，客戶提交了用戶故事之后不就完成工作了嗎翘地？其實很多嘗試過用戶故事的團隊都會發(fā)現(xiàn)其太過簡單申尤，包含的信息量極少，XP方法論不會不了解衙耕，因此昧穿，不會把用戶故事當做開發(fā)人員交付代碼的唯一指示。用戶故事只是一個起點橙喘，后面的細節(jié)還需要開發(fā)人員與客戶之間建立起來的良好溝通來補充时鸵。
    作為一名有經(jīng)驗的開發(fā)人員，絕對不會對現(xiàn)場客戶的價值產(chǎn)生任何懷疑厅瞎，但是都會覺得想要實現(xiàn)現(xiàn)場客戶十分困難饰潜。要實現(xiàn)這一點，需要對客戶進行溝通和簸，讓其明白彭雾，想對于開發(fā)團隊，項目成功對于客戶而言更為重要锁保。而現(xiàn)場客戶則是保障項目成功的一個重要措施薯酝，想想在你裝修房子的時候，你是不是常常在充當現(xiàn)場客戶的角色呢爽柒？其實這隱喻就是讓客戶理解現(xiàn)場客戶重要性最好的突破口吴菠。
    其實現(xiàn)場客戶在具體實施時，也不是一定需要客戶一直和開發(fā)團隊在一起霉赡，而是在開發(fā)團隊應該和客戶能夠隨時溝通橄务，可以是面談，可以是在線聊天穴亏，可以是電話蜂挪，當然面談是必不可少的。其中的關鍵是當開發(fā)人員需要客戶做出業(yè)務決策是嗓化，需要進一步了解業(yè)務細節(jié)時能夠隨時找到相應的客戶棠涮。
    不過，也有一些項目是可以不要現(xiàn)場客戶參與的：
    當開發(fā)組織中已經(jīng)有相關的領域專家時刺覆。
    當做一些探索性工作严肪，而且客戶也不知道他想要什么時（例如新產(chǎn)品、新解決方案的研究與開發(fā)）。

去嘗試吧驳糯，現(xiàn)場客戶不僅可以爭取得到篇梭，而且還能使得團隊煥然一新，與客戶建立起良好的合作與信任酝枢。

12. 編碼標準
    編碼標準是一個“雅俗共享”的最佳實踐恬偷，不管是代表重型方法論的RUP，PSP帘睦，還是代表敏捷方法論的XP袍患，都認為開發(fā)團隊應該擁有一個編碼標準。XP方法論認為擁有編碼標準可以避免團隊在一些與開發(fā)進度無關的細節(jié)問題上發(fā)生爭論竣付，而且會給重構诡延、結對編程帶來很大麻煩。試想如果有人將你上次寫的代碼的變量命名法做了修改古胆，下次你需要再改這部分代碼時肆良，會是一種什么感覺呢？
    不過赤兴，XP方法論的編碼標準的目的不是創(chuàng)建一個事無巨細的規(guī)則表妖滔，而是只要能夠提供一個確保代碼清晰，便于交流的指導方針桶良。
    如果你的團隊已經(jīng)擁有編碼標準座舍，就可以直接使用它，并在過程中進行完善陨帆。如果還沒有曲秉，那么大家可以先進行編碼，然后在過程中逐步總結出編碼規(guī)則疲牵，邊做邊形成承二。當然除了這種文字規(guī)范以外，還可以采用一些如自動格式化代碼工具之類的方法進行代碼規(guī)范纲爸。亥鸠，事實上，你只需要很好地貫徹執(zhí)行其他的實踐并且進行溝通识啦，編碼標準會很容易地浮現(xiàn)出來负蚊。
13. 配合是關鍵
    有句經(jīng)典名言“1+1>2”最適合表達XP的觀點，Kent Beck認為XP方法論的最大價值在于在項目中融會貫通地運用12個最佳實踐颓哮，而非單獨地使用家妆。你當然可以使用其中的一些實踐，但這并不意味著你就運用了XP方法論冕茅。XP方法論真正能夠發(fā)揮其效能伤极，就必須完整地運用12個實踐蛹找。

適用范圍

XP適合規(guī)模小、進度緊哨坪、需求變化大庸疾、質量要求嚴的項目。它希望以最高的效率和質量來解決用戶目前的問題齿税，以最大的靈活性和最小的 代價來滿足用戶未來的需求彼硫，XP在平衡短期和長期利益之間做了巧妙的選擇炊豪。

敏捷開發(fā)中XP與SCRUM的區(qū)別

• 區(qū)別之一： 迭代長度的不同
  XP的一個Sprint的迭代長度大致為1~2周（短）凌箕；
  Scrum的迭代長度一般為 2~ 4周（較長）。
• 區(qū)別之二: 在迭代中, 是否允許修改需求
  XP在一個迭代中词渤，如果一個需求還沒有實現(xiàn)牵舱， 則可以考慮用另外的需求將其替換，替換的原則是需求實現(xiàn)的時間量是相等的（允許）缺虐；
  Scrum是不允許這樣做的芜壁，一旦迭代開工會完畢, 任何需求都不允許添加進來，并有Scrum Master嚴格把關高氮，不允許開發(fā)團隊受到干擾（不允許）慧妄。
• 區(qū)別之三: 在迭代中，User Story是否嚴格按照優(yōu)先級別來實現(xiàn)
  • XP是務必要遵守優(yōu)先級別的剪芍。
  • Scrum在這點做得很靈活塞淹， 可以不按照優(yōu)先級別來做，Scrum這樣處理的理由是：如果優(yōu)先問題的解決者罪裹，由于其它事情耽擱饱普，不能認領任務，那么整個進度就耽誤了状共。 另外一個原因是套耕，如果按優(yōu)先級排序的User Story #6和#10，雖然#6優(yōu)先級高峡继，但是如果#6的實現(xiàn)要依賴于#10冯袍，則不得不優(yōu)先做#10.
• 區(qū)別之四:軟件的實施過程中，是否采用嚴格的工程方法碾牌，保證進度或者質量
  • Scrum沒有對軟件的整個實施過程開出工程實踐的處方康愤。要求開發(fā)者自覺保證；
  • XP對整個流程方法定義非常嚴格小染，規(guī)定需要采用TDD, 自動測試翘瓮， 結對編程，簡單設計裤翩，重構等約束團隊的行為资盅。因此调榄，原作者認為，這點上呵扛，XP的做法值得認同的每庆，但是卻把敏捷帶入了一個讓人困惑的矛盾, 因為xp的理念，結合敏捷模式今穿，表達給團隊的信息是“你是一個完全自我管理的組織缤灵， 但你必須要實現(xiàn)TDD, 結對編程, ...等等”

不難發(fā)現(xiàn)，這四個區(qū)別顯見的是： Scrum非常突出Self-Orgnization,** XP注重強有力的工程實踐約束**
建議： 在管理模式上啟用Scrum蓝晒；而在實踐中創(chuàng)造一個適合項目組的XP

參考資料
【1】http://blog.csdn.net/fw0124/article/details/48713959
【2】強大的百度腮出，等等等等