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

在敏捷方法論領域中，比較知名的、有影響力的，是擁有與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