XP極限程式設計

靈活方法論有一個共同的特點，那就是都将矛頭指向了“文檔”，它們認為傳統的軟體工程方法文檔量太“重”了，稱為“重量級”方法，而相應的靈活方法則是“輕量級”方法。正是因為“輕量級”感覺沒有什麼力量，不但不能夠有效展現靈活性，反而顯得是不解決問題的方法論似的。是以，就有了一次劃時代的會議，建立了靈活聯盟。

在靈活方法論領域中，比較知名的、有影響力的，是擁有與Microsoft的作業系統相同縮寫語——XP的極限程式設計（eXtreme Programming）。極限程式設計方法論可以說是靈活聯盟中最鮮豔的一面旗幟，也是被研究、嘗試、應用、贊揚、批判最多的一種方法論，也是相對來說最成熟的一種。

這一被譽為“黑客文化”的方法論的雛形最初形成于1996—1999年間，Kent Beck、Ward Cunninggham、Ron Jeffrey在開發C3項目（Chrysler Comprehensive Compensation）的實踐中總結出了XP的基本元素。在此之後，Kent Beck和他的一些好朋友們一起在實踐中完善提高，終于形成了極限程式設計方法論。

解析極限程式設計

那麼什麼是XP呢？XP是一種輕量（靈活）、高效、低風險、柔性、可預測、科學而且充滿樂趣的軟體開發方式。與其他方法論相比，其最大的不同在于：

• 在更短的周期内，更早地提供具體、持續的回報資訊。
• 在疊代的進行計劃編制，首先在最開始迅速生成一個總體計劃，然後在整個項目開發過程中不斷的發展它。
• 依賴于自動測試程式來監控開發進度，并及早地捕獲缺陷。
• 依賴于口頭交流、測試和源程式進行溝通。
• 倡導持續的演化式設計。
• 依賴于開發團隊内部的緊密協作。
• 盡可能達到程式員短期利益和項目長期利益的平衡。

Kent Beck曾經說過“開車”就是一個XP的範例，即使看上去進行得很順利，也不要把視線從公路上移開，因為路況的變化，将使得你必須随時做出一些這樣那樣的調整。而在軟體項目中，客戶就是司機，他們也沒有辦法确切地知道軟體應該做什麼，是以程式員就需要向客戶提供方向盤，并且告知我們現在的位置。

XP包括寫什麼呢？如圖，XP由價值觀、原則、實踐和行為四個部分組成，它們彼此互相依賴、關聯， 并通過行為貫穿于整個生命期。

四大價值觀

XP的核心是其總結的溝通（Communication）、簡單（Simplicity）、回報（Feedback）、勇氣（Courage）四大價值觀，它們是XP的基礎，也是XP的靈魂。

此外還擴充了第五個價值觀：謙遜（Modesty）。 XP用“溝通、簡單、回報、勇氣和謙遜”來減輕開發壓力和包袱；XP精神可以啟發我們如何學習和對待快速變化、多樣的開發技術。成功學習XP的關鍵，是用“溝通、簡單、回報、勇氣和謙遜”的态度來對待XP；輕松愉快地來感受XP的實踐思想；自己認真實踐後，通過對真實回報的分析，來決定XP對自己的價值；有勇氣接受它，或改進它。

1. 溝通

通暢程式員給人留下的印象就是“内向、不善言談”，然後項目中的許多問題就出在這些缺乏溝通的開發人員身上。經常由于某個程式員做出了一個設計決定，但是卻不能及時地通知大家，結果使得大家在協作與配合上出現了很多的麻煩，而在傳統的方法論中，并不在意這種口頭溝通不暢的問題，而是希望借助于完善的流程和面面俱到的文檔、報表、計劃來替代，但是這同時又引入了效率不高的新問題。

XP方法論認為，如果小組成員之間無法做到持續的、無間斷的交流，那麼協作就無從談起，從這個角度能夠發現，通過文檔、報表等人工制品進行交流面臨巨大的局限性。是以，XP組合了諸如結對程式設計這樣的最佳實踐，鼓勵大家進行口頭交流，通過交流解決問題，提高效率。

2. 簡單

XP方法論提倡在工作中秉承“夠用就好”的思路，也就是盡量地簡單化，隻要今天夠用就行，不考慮明天會發現的新問題。這一點看上去十分容易，但是要真正做到保持簡單的工作其實很難的。因為在傳統的開發方法中，都要求大家對未來做一些預先規劃，以便對今後可能發生的變化預留一些擴充的空間。

正如對傳統開發方法的認識一樣，許多開發人員也會質疑XP，保持系統的擴充性很重要，如果都保持簡單，那麼如何使得系統能夠有良好的擴充性呢？其實不然，保持簡單的理由有兩個：

• 開發小組在開發時所做的規劃，并無法保證其符合客戶需要的，是以做的大部分工作都将落空，使得開發過程中重複的、沒有必要的工作增加，導緻整體效率降低。
• 另外，在XP中提倡時刻對代碼進行重構，一直保持其良好的結構與可擴充性。也就是說，可擴充性和為明天設計并不是同一個概念，XP是反對為明天考慮而工作，并不是說代碼要失去擴充性

而且簡單和溝通之間還有一種相對微妙的互相支援關系。當一個團隊之間，溝通的越多，那麼就越容易明白哪些工作需要做，哪些工作不需要做。另一方面，系統越簡單，需要溝通的内容也就越少，溝通也将更加全面。

3. 回報

是什麼原因使得我們的客戶、管理層這麼不了解開發團隊？為什麼客戶、管理層總是喜歡給我們一個死亡之旅？究其症結，就是開發的過程中缺乏必要的回報。在許許多多項目中，當開發團隊經曆過了需求分析階段之後，在相當長的一段時間内，是沒有任何回報資訊的。整個開發過程對于客戶和管理層而言就像一個黑盒子，進度完全是可見的。

而且在項目的過程中，這樣的現象不僅出現在開發團隊與客戶、管理層之間，還包括在開發團隊内部。這一切問題都需要我們更加注重回報。，回報對于任何軟體項目的成功都是至關重要的，而在XP方法論中則更進一步，通過持續、明确的回報來暴露軟體狀态的問題。具體而言就是：

• 在開發團隊内部，通過提前編寫單元測試代碼，時時回報代碼的問題與進展。
• 在開發過程中，還應該加強內建工作，做到持續內建，使得每一次增量都是一個可執行的工作版本，也就是逐漸是軟體長大，整個過程中，應該通過向客戶和管理層示範這些可運作的版本，以便及早地回報，及早地發現問題。

同時，我們也會發現回報與溝通也有着良好的配合，及時和良好的回報有助于溝通。而簡單的系統更有利于測試盒回報。

4. 勇氣

在應用XP方法論時，我們每時每刻都在應對變化：由于溝通良好，是以會有更多需求變更的機會；由于時刻保持系統的簡單，是以新的變化會帶來一些重新開發的需要；由于回報及時，是以會有更多中間打斷你的思路的新需求。

總之這一切，使得你立刻處于變化之中，是以這時就需要你有勇氣來面對快速開發，面對可能的重新開發。也許你會覺得，為什麼要讓我們的開發變得如此零亂，但是其實這些變化若你不讓它早暴露，那麼它就會遲一些出現，并不會是以消亡，是以，XP方法論讓它們早出現、早解決，是實作“小步快走”開發節奏的好辦法。

也就是XP方法論要求開發人員穿上強大、自動測試的盔甲，勇往直前，在重構、編碼規範的支援下，有目的地快速開發。

勇氣可以來源于溝通，因為它使得高風險、高回報的試驗成為可能；勇氣可以來源于簡單，因為面對簡單的系統，更容易鼓起勇氣；勇氣可以來源于回報，因為你可以及時獲得每一步前進的狀态（自動測試），會使得你更勇于重構代碼。

5. 四大價值觀之外

在這四大價值觀之下，隐藏着一個更深刻的東西，那就是尊重。因為這一切都建立在團隊成員之間的互相關心、互相了解的基礎之上。

5個原則

1. 快速回報

及時地、快速地擷取回報，并将所學到的知識盡快地投入到系統中去。也就是指開發人員應該通過較短的回報循環迅速地了解現在的産品是否滿足了客戶的需求。這也是對回報這一價值觀的進一步補充。

2. 簡單性假設

類似地，簡單性假設原則是對簡單這一價值觀的進一步補充。這一原則要求開發人員将每個問題都看得十分容易解決，也就是說隻為本次疊代考慮，不去想未來可能需要什麼，相信具有将來必要時增加系統複雜性的能力，也就是号召大家出色地完成今天的任務。

3. 逐漸修改

就像開車打方向盤一樣，不要一次做出很大的改變，那樣将會使得可控性變差，更适合的方法是進行微調。而在軟體開發中，這樣的道理同樣适用，任何問題都應該通過一系列能夠帶來差異的微小改動來解決。

4. 提倡更改

在軟體開發過程中，最好的辦法是在解決最重要問題時，保留最多選項的那個。也就是說，盡量為下一次修改做好準備。

5. 優質工作

在實踐中，經常看到許多開發人員喜歡将一些細小的問題留待後面解決。例如，界面的按鈕有一些不平整，由于不影響使用就先不管；某一兩個成員函數暫時沒用就不先寫等。這就是一種工作拖泥帶水的現象，這樣的壞習慣一旦養成，必然使得代碼品質大打折扣。

而在XP方法論中，貫徹的是“小步快走”的開發原則，是以工作品質決不可打折扣，通常采用測試先行的編碼方式來提供支援。

13個最佳實踐

在XP中，內建了13個最佳實踐，有趣的是，它們沒有一個是創新的概念，大多數概念和程式設計一樣老。其主要創新點在于提供一種良好的思路，将這些最佳實踐結合在一起，并且確定盡可能徹底地執行它們，使得它們能夠在最大程度上互相支援，緊接下來，我們就對每一種最佳實踐進行一番了解。

1. 計劃遊戲

計劃遊戲的主要思想就是先快速地制定一份概要的計劃，然後随着項目細節的不斷清晰，再逐漸完善這份計劃。計劃遊戲産生的結果是一套使用者故事及後續的一兩次疊代的概要計劃。

“客戶負責業務決策，開發團隊負責技術決策”是計劃遊戲獲得成功的前提條件。也就是說，系統的範圍、下一次疊代的釋出時間、使用者故事的優先級應該由客戶決定；而每個使用者故事所需的開發時間、不同技術的成本、如何組建團隊、每個使用者故事的風險，以及具體的開發順序應該有開發團隊決定。

好了，明白這些就可以進行計劃遊戲了。首先客戶和開發人員坐在同一間屋子裡，每個人都準備一支筆、一些用于記錄使用者故事的紙片，最好再準備一個白闆，就可以開始了。

• 客戶編寫故事：由客戶談論系統應該完成什麼功能，然後用通俗的自然語言，使用自己的語彙，将其寫在卡片上，這也就是使用者故事。
• 開發人員進行估算：首先客戶按優先級将使用者故事分成必須要有、希望有、如果有更好三類，然後開發人員對每個使用者故事進行估算，先從高優先級開始估算。如果在估算的時候，感到有一些故事太大，不容易進行估算，或者是估算的結果超過2人/周，那麼就應該對其進行分解，拆成2個或者多個小故事。
• 确定疊代的周期：接下來就是确定本次疊代的時間周期，這可以根據實際的情況進行确定，不過最佳的疊代周期是2~3周。有了疊代的時間之後，再結合參與的開發人數，算出可以完成的工作量總數。然後根據估算的結果，與客戶協商，挑出時間上夠、優先級合适的使用者故事組合，形成計劃。

2. 小型釋出

XP方法論秉承的是“持續內建，小步快走”的哲學，也就是說每一次釋出的版本應該盡可能的小，當然前提條件是每個版本有足夠的商業價值，值得釋出。

由于小型釋出可以使得內建更頻繁，客戶獲得的中間結果也越頻繁，回報也就越頻繁，客戶就能夠實時地了解項目的進展情況，進而提出更多的意見，以便在下一次疊代中計劃進去。以實作更高的客戶滿意度。

3. 隐喻

相對而言，隐喻這一個最佳實踐是最令人費解的。什麼是隐喻呢？根據詞典中的解釋是：“一種語言的表達手段，它用來暗示字面意義不相似的事物之間的相似之處”。那麼這在軟體開發中又有什麼用呢？總結而言，常常用于四個方面。

• 尋求共識：也就是鼓勵開發人員在尋求問題共識時，可以借用一些溝通雙方都比較熟悉的事物來做類比，進而幫助大家更好地了解解決方案的關鍵結構，也就是更好地了解系統是什麼、能做什麼。
• 發明共享詞彙：通過隐喻，有助于提出一個用來表示對象、對象間的關系通用名稱。例如，政策模式（用來表示可以實作多種不同政策的設計模式）、工廠模式（用來表示可以按需“生産”出所需類得設計模式）等。
• 創新的武器：有的時候，可以借助其他東西來找到解決問題的新途徑。例如：“我們可以将工作流看做一個生産線”。
• 描述體系結構：體系結構是比較抽象的，引入隐喻能夠大大減輕了解的複雜度。例如管道體系結構就是指兩個構件之間通過一條傳遞消息的“管道”進行通信。

當然，如果能夠找到合适的隐喻是十分快樂的，但并不是每種情況都可以找到恰當的隐喻，你也沒有必要強求

4. 簡單設計

強調簡單設計的價值觀，引出了簡單性假設原則，落到實處就是“簡單設計”實踐。這個實踐看上去似乎很容易了解，但卻又經常被誤解，許多批評者就指責XP忽略設計是不正确的。其實，XP的簡單設計實踐并不是要忽略設計，而且認為設計不應該在編碼之前一次性完成，因為那樣隻能建立在“情況不會發生變化”或者“我們可以預見所有的變化”之類的謊言的基礎上的。

Kent Beck概念中簡單設計是這樣的：

• 能夠通過所有的測試程式。
• 沒有包括任何重複的代碼。
• 清楚地表現了程式員賦予的所有意圖。
• 包括盡可能少的類和方法
• 他認為要想保持設計簡單的系統，需要具備簡單思考的能力，擁有了解代碼和修改的勇氣，以及為了消除代碼的“壞味道”而定期重構的習慣。
• 那麼如何開始進行簡單的設計呢？XP實踐者們也總結也一些具體的、可操作的思考方法。
• 首先寫測試代碼：具體将在後面較長的描述。
• 保持每個類隻負責一件事：SRP（單一職責原則）是面向對象設計的基礎原則之一。
• 使用Demeter（迪米特）法則：迪米特法則，也稱為LoD法則、最少知識原則。也就是指一個對象應當對其他對象盡可能少地了解。用隐喻的方法來解釋的話就是“隻與你直接的朋友通信”、“不要和陌生人說話”。
• 使用CRC卡片進行探索。

5. 測試先行／測試驅動開發

當我第一次看到“測試先行”這個概念的時候，我的第一感覺就是不解，陷入了“程式都還沒有寫出來，測試什麼呀？”的迷思。我開始天馬行空地尋求相關的隐喻，終于找到了能夠啟發我的工匠，首先，我們來看看兩個不同的工匠是如何工作的吧。

• 工匠一：先拉上一根水準線，砌每一塊磚時，都與這跟水準線進行比較，使得每一塊磚都保持水準。
• 工匠二：先将一排磚都砌完，然後再拉上一根水準線，看看哪些磚有問題，對有問題的磚進行适當的調整。

你會選擇哪種工作方法呢？你一定會罵工匠二笨吧！這樣多浪費時間呀！然而你自己想想，你平時在編寫程式的時候又是怎麼做的呢？我們就是按工匠二的方法在工作呀！甚至有時候比工匠二還笨，是整面牆都砌完了，直接進行“內建測試”，經常讓整面的牆倒塌。看到這裡，你還會覺得自己的方法高明嗎？這個連工匠都明白的道理，自己卻畫地為牢呀。

不僅我們沒有采用工匠一的工作方法，甚至有的時候程式員會以“開發工作太緊張”為理由，而忽略測試工作。但這樣卻導緻了一個惡性循環，越是沒有空編寫測試程式，代碼的效率與品質越差，花在找Bug、解決Bug的時間也越來越多，實際産能大打降低。由于産能降低了，是以時間更緊張，壓力更大。你想想，為什麼不拉上一根水準線呢？難道，我們不能夠将後面浪費的時間花在單元測試上，使得我們的程式一開始就更健壯，更加易于修改嗎？不過，編寫測試程式當然要比拉一條水準線難道多，是以我們需要引入“自動化測試工具”，免費的xUnit測試架構就是你最佳的選擇。

為了鼓勵程式員原意甚至喜歡在編寫程式之前編寫測試代碼，XP方法論還提供了許多有說服力的理由。

• 如果你已經保持了簡單的設計，那麼編寫測試代碼根本不難。
• 如果你在結對程式設計，那麼如果你想出一個好的測試代碼，那麼你的夥伴一定行。
• 當所有的測試都通過的時候，你再也不會擔心所寫的代碼今後會“暗箭傷人”，那種感覺是相當棒的。
• 當你的客戶看到所有的測試都通過的時候，會對程式充滿前所未有的信心。
• 當你需要進行重構時，測試代碼會給你帶來更大的勇氣，因為你要測試是否重構成功隻需要一個按鈕。

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

6. 重構

重構時一種對代碼進行改進而不影響功能實作的技術，XP需要開發人員在聞到代碼的壞味道時，有重構代碼的勇氣。重構的目的是降低變化引發的風險，使得代碼優化更加容易。通常重構發生在兩種情況之下。

• 實作某個特性之前：嘗試改變現有的代碼結構，以使得實作新的特性更加容易。
• 實作某個特性之後：檢查剛剛寫完的代碼後，認真檢查一下，看是否能夠進行簡化。

在《重構》一書中，作者Martin Fowler提示我們：在考慮重構時，應該要養成編寫并經常運作測試代碼的習慣；要先編寫代碼，再進行重構；把每一次增加功能都當做一次重構的好時機；将每一個糾正錯誤當做一次重構的重要時機。同時，該書中也列出大量需要重構的情況和重構方法。

最後類似地，給還沒有足夠勇氣進行重構的程式員打幾劑強心針：

• XP提倡集體代碼所有制，是以你可以大膽地在任何需要修改的地方做改動。
• 由于在XP項目組中有完整的編碼标準，是以在重構前無須重新定義格式。
• 在重構中遇到困難，和你結對程式設計的夥伴能夠為你提供有效的幫助。
• 簡單的設計，會給重構帶來很大的幫助。
• 測試先行讓你擁有了一個有效的檢驗器，随時運作一下就知道你重構的工作是否帶來了影響。
• 由于XP在持續內建，是以你重構所帶來的破壞很快就能夠暴露，并且得以解決。

重構技術是對簡單性設計的一個良好的補充，也是XP中重視“優質工作”的展現，這也是優秀的程式員必備的一項技能。

7. 結對程式設計

“什麼！兩個人坐在一起寫程式？那豈不是對人力的巨大浪費嗎？而且我在工作時可不喜歡有一個人坐在邊上當檢察官。”是的，正如這裡列舉出來的問題一樣，結對程式設計技術還是被很多人質疑的。

不過，自從20世紀60年代，就有類似的實踐在進行，長期以來的研究結果卻給出了另外一番景象，那就是結對程式設計的效率反而比單獨程式設計更高。一開始雖然會犧牲一些速度，但慢慢的，開發速度會逐漸加快，究其原因，主要是結對程式設計大打降低了溝通的成本，提供了工作的品質，具體表現在：

• 所有的設計決策確定不是由一個人做出的。
• 系統的任何一個部分都肯定至少有2個人以上熟悉。
• 幾乎不可能有2個人都忽略的測試項或者其他任務
• 結對組合的動态性，是一個企業知識管理的好途徑。
• 代碼總是能夠保證被評審過。
• 而且XP方法論內建的其他最佳實踐也能夠使得結對程式設計更加容易進行：
• 編碼标準可以消除一些無謂的分歧。
• 隐喻可以幫助結對夥伴更好地溝通。
• 簡單設計可以使得結對夥伴更了解他們所從事的工作。

結對程式設計技術被譽為XP保持工作品質、強調人文主義的一個典型的實踐，應用得當還能夠使得開發團隊之前的協作更加流暢、知識交流與共享更加頻繁，團隊的穩定性也會更加穩固。

8. 集體代碼所有制

由于XP方法論鼓勵團隊進行結對程式設計，而且認為結對程式設計的組合應該動态地搭配，根據任務的不同、專業技能的不同進行最優組合。由于每個人都肯定會遇到不同的代碼，是以代碼的所有制就不再适合于私有，因為那樣會給修改工作帶來巨大的不便。

也就是說，團隊中的每個成員都擁有對代碼進行改進的權利，每個人都擁有全部代碼，也都需要對全部代碼負責。同時，XP強調代碼是誰破壞的（也就是修改後發生問題），就應該由誰來修複。

由于在XP中，有一些與之比對的最佳實踐，是以你并無須擔心采用集體代碼所有制會讓你的代碼變得越來越亂：

• 由于在XP項目中，內建工作是一件經常性得工作，是以當有人修改代碼而帶來了內建的問題，會在很快的時間内被發現。
• 由于每一個類都會有一個測試代碼，是以不論誰修改了代碼，都需要運作這個測試代碼，這樣偶然性的破壞發生的機率将很小。
• 由于每一個代碼的修改就是通過了結對的兩個程式員共同思考，是以通常做出的修改都是對系統有益的。
• 由于大家都堅持了相同的編碼标準，是以代碼的可讀性、可修改性都會比較好，而且還能夠避免由于命名法、縮進等小問題引發經常性得代碼修改。

內建代碼所有制是XP與其他靈活方法的一個較大不同，也是從另一個側面展現了XP中蘊含的很深厚的編碼情節。

9. 持續內建

在前面談到小型釋出、重構、結對程式設計、集體代碼所有制等最佳實踐的時候，我們多次看到“持續內建”的身影，可以說持續內建是對這些最佳實踐的基本支撐條件。

可能大家會對持續內建與小型釋出代表的意思混淆不清，其實小型釋出是指在開發周期經常釋出中間版本，而持續內建的含義則是要求XP團隊每天盡可能多次地做代碼內建，每次都在確定系統運作的單元測試通過之後進行。

這樣，就可以及早地暴露、消除由于重構、集體代碼所有制所引入的錯誤，進而減少解決問題的痛苦

要在開發過程中做到持續內建并不容易，首先需要養成這個習慣。而且內建工作往往是十分枯燥、煩瑣的，是以适當地引入每日內建工具是十分必要的。XP建議大家首先使用配置管理伺服器将代碼管理起來，然後使用Ant或Nant等XP工具，編寫內建腳本，調用xUint等測試架構，這樣就可以實作每當程式員将代碼Check in到配置伺服器上時，Ant就會自動完成編譯和內建，并調用測試代碼完成相應的測試工作。

10. 每周工作40小時／可持續的速度

這是最讓開發人員開心的、管理者反對的一個最佳實踐了，加班、再加班早已成為開發人員的家常便飯，也是管理者最常使用的一種政策，而XP方法論認為，加班最終會扼殺團隊的積極性，最終導緻項目失敗，這也充分展現了XP方法關注人的因素比關注過程的因素更多一些。

Kent Beck認為開發人員即使能夠工作更長的時間，他們也不該這樣做，因為這樣做會使他們更容易厭倦程式設計工作，進而産生一些影響他們效能的其他問題。是以，每周工作40小時是一種順勢行為，是一種規律。其實對于開發人員和管理者來說，違反這種規律是不值得的。

• 開發人員：如果不懂得休息，那麼就無法将自己的節奏調整到最佳狀态，那麼就會帶來很大的負面影響。而且在精神不集中的狀态下，開發品質也得不到保證。
• 管理者：也許這可以稱得上“第二種人月神話”，那就是你不得不通過延長每天的工作時間來獲得更多的人月。這是因為，每個開發人員的工作精力是有限的，不可能無限增長，在精力不足的時候，不僅寫出來的代碼品質沒有保障，而且還可能為項目帶來退步的效果。是以采用加班的方式并不是一個理性的方式，是得不償失的。

不過有一點是需要解釋的，“每周工作40小時”中的40不是一個絕對數，它所代表的意思是團隊應該保證按照“正常的時間”進行工作。那麼如何做到這一點呢？

首先，定義符合你團隊情況的“正常工作時間”。

其次，逐漸将工作時間調整到“正常工作時間”。

再次，除非你的時間計劃一團糟，否則不應該在時間妥協。

最後，鼓起勇氣，制定一個合情合理的時間表。

正如米盧說過的“享受足球”一樣，同樣地，每一個開發人員應該做到“享受程式設計”，那麼“每周工作40小時”就是你的起點。

團隊隻有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們儲存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。

11. 現場客戶

為了保證開發出來的結果與客戶的預想接近，XP方法論認為最重要的需要将客戶請到開發現場。就像計劃遊戲中提到過的，在XP項目中，應該時刻保證客戶負責業務決策，開發團隊負責技術決策。是以，在項目中有客戶在現場明确使用者故事，并做出相應的業務決策，對于XP項目而言有着十分重要的意義。

也許有人會問，客戶送出了使用者故事之後不就完成工作了嗎？其實很多嘗試過使用者故事的團隊都會發現其太過簡單，包含的資訊量極少，XP方法論不會不了解，是以，不會把使用者故事當做開發人員傳遞代碼的唯一訓示。使用者故事隻是一個起點，後面的細節還需要開發人員與客戶之間建立起來的良好溝通來補充。

作為一名有經驗的開發人員，絕對不會對現場客戶的價值産生任何懷疑，但是都會覺得想要實作現場客戶十分困難。要實作這一點，需要對客戶進行溝通，讓其明白，想對于開發團隊，項目成功對于客戶而言更為重要。而現場客戶則是保障項目成功的一個重要措施，想想在你裝修房子的時候，你是不是常常在充當現場客戶的角色呢？其實這隐喻就是讓客戶了解現場客戶重要性最好的突破口。

其實作場客戶在具體實施時，也不是一定需要客戶一直和開發團隊在一起，而是在開發團隊應該和客戶能夠随時溝通，可以是面談，可以是線上聊天，可以是電話，當然面談是必不可少的。其中的關鍵是當開發人員需要客戶做出業務決策是，需要進一步了解業務細節時能夠随時找到相應的客戶。

不過，也有一些項目是可以不要現場客戶參與的：

• 當開發組織中已經有相關的領域專家時。
• 當做一些探索性工作，而且客戶也不知道他想要什麼時（例如新産品、新解決方案的研究與開發）。

去嘗試吧，現場客戶不僅可以争取得到，而且還能使得團隊煥然一新，與客戶建立起良好的合作與信任。

12. 編碼标準

編碼标準是一個“雅俗共享”的最佳實踐，不管是代表重型方法論的RUP，PSP，還是代表靈活方法論的XP，都認為開發團隊應該擁有一個編碼标準。XP方法論認為擁有編碼标準可以避免團隊在一些與開發進度無關的細節問題上發生争論，而且會給重構、結對程式設計帶來很大麻煩。試想如果有人将你上次寫的代碼的變量命名法做了修改，下次你需要再改這部分代碼時，會是一種什麼感覺呢？

不過，XP方法論的編碼标準的目的不是建立一個事無巨細的規則表，而是隻要能夠提供一個確定代碼清晰，便于交流的指導方針。

如果你的團隊已經擁有編碼标準，就可以直接使用它，并在過程中進行完善。如果還沒有，那麼大家可以先進行編碼，然後在過程中逐漸總結出編碼規則，邊做邊形成。當然除了這種文字規範以外，還可以采用一些如自動格式化代碼工具之類的方法進行代碼規範。，事實上，你隻需要很好地貫徹執行其他的實踐并且進行溝通，編碼标準會很容易地浮現出來。

13. 配合是關鍵

有句經典名言“1+1>2”最适合表達XP的觀點，Kent Beck認為XP方法論的最大價值在于在項目中融會貫通地運用12個最佳實踐，而非單獨地使用。你當然可以使用其中的一些實踐，但這并不意味着你就運用了XP方法論。XP方法論真正能夠發揮其效能，就必須完整地運用12個實踐。

轉載文章，原文連結 http://www.cnblogs.com/luoht/archive/2011/05/20/2051714.html