敏捷開發之XP

時間 2019-11-12

標籤敏捷開發欄目 Windows 简体版

原文原文鏈接

敏捷方法論有一個共同的特色，那就是都將矛頭指向了「文檔」，它們認爲傳統的軟件工程方法文檔量太「重」了，稱爲「重量級」方法，而相應的敏捷方法則是「輕量級」方法。正是由於「輕量級」感受沒有什麼力量，不但不可以有效體現靈活性，反而顯得是不解決問題的方法論似的。所以，就有了一次劃時代的會議，建立了敏捷聯盟。html

在敏捷方法論領域中，比較知名的、有影響力的，是擁有與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方法論的編碼標準的目的不是建立一個事無鉅細的規則表，而是隻要可以提供一個確保代碼清晰，便於交流的指導方針。

若是你的團隊已經擁有編碼標準，就能夠直接使用它，並在過程當中進行完善。若是尚未，那麼你們能夠先進行編碼，而後在過程當中逐步總結出編碼規則，邊作邊造成。固然除了這種文字規範之外，還能夠採用一些如自動格式化代碼工具之類的方法進行代碼規範。，事實上，你只須要很好地貫徹執行其餘的實踐而且進行溝通，編碼標準會很容易地浮現出來。