理解了極限編程的真諦之后，接下來(lái)，我們以軟件開(kāi)發(fā)的流程為主線(xiàn)，逐個(gè)討論實(shí)用而具體的最佳實(shí)踐。
這個(gè)階段，主要就是XP的經(jīng)典實(shí)踐“計劃游戲”。在這個(gè)階段，用戶(hù)在程序員的幫助下，編寫(xiě)“故事卡”。
計劃游戲中的兩個(gè)玩家是開(kāi)發(fā)方和業(yè)務(wù)方。開(kāi)發(fā)方由所有負責實(shí)現系統的人共同組成。業(yè)務(wù)方由所有負責決定系統功能的人組成。
一、 編寫(xiě)一個(gè)故事—業(yè)務(wù)方編寫(xiě)故事來(lái)描述系統要做的事。故事寫(xiě)在索引卡上，有一個(gè)名稱(chēng)和一小段說(shuō)明故事的目的的文字。這類(lèi)似于UML的用例。我們也可以使用UML的用例圖來(lái)幫助描述“故事”。
二、 估算時(shí)間—開(kāi) 發(fā)方要估算實(shí)現故事需要多長(cháng)時(shí)間。如果開(kāi)發(fā)方無(wú)法對故事進(jìn)行估算，可以要求業(yè)務(wù)方將其解釋清楚或分解。評估故事最簡(jiǎn)單的方法就是問(wèn)自己：“如果這個(gè)故事由 我來(lái)實(shí)現，在沒(méi)有任何干擾或會(huì )議的情況下，我會(huì )需要多長(cháng)時(shí)間呢？”這叫做“理想工程時(shí)間”。一般，在實(shí)際開(kāi)發(fā)中，每個(gè)人的正常速度是每個(gè)工作日實(shí)際完成1/3-1/2個(gè)理想工程時(shí)間。請注意，XP中，軟件質(zhì)量是最基本的要求。如果你每天完成了超過(guò)1/2個(gè)理想工作日的工作量，那么請注意你的代碼是不是足夠健壯！
Bruce Eckel說(shuō)，他總是把自己的估算時(shí)間*210%作為自己最重的工作計劃。因為，其中100%的時(shí)間用來(lái)完成工作。另外100%的時(shí)間用來(lái)使工作完成得更加優(yōu)美。10%的時(shí)間用來(lái)潤飾代碼，添加注釋?zhuān)怪忧逦?，易于閱讀。
三、 分割時(shí)間—如果開(kāi)發(fā)方不能評估整個(gè)故事，或者如果開(kāi)發(fā)方認識到故事中的某個(gè)部分比其他部分更重要，業(yè)務(wù)方可以讓開(kāi)發(fā)方把故事分割為兩個(gè)或多個(gè)故事。
“當你能夠度量你所說(shuō)的，并且能夠用數字去表達它時(shí)，就表示你了解了它；若你不能度量它，不能用數字去表達它，那么說(shuō)明你的知識是匱乏的、不能令人滿(mǎn)意的?！薄獎P 爾文勛爵（英國物理學(xué)家）語(yǔ)。開(kāi)發(fā)人員對用戶(hù)故事的估算，本身就需要開(kāi)發(fā)人員對怎樣用軟件來(lái)解決用戶(hù)故事有一定的理解。如果，開(kāi)發(fā)人員不能夠有效的評估用 戶(hù)故事，那么他們就可以在這個(gè)階段進(jìn)行一些技術(shù)上的探索。比如，設計和編寫(xiě)一些解決方案，對這些代碼進(jìn)行測試，從而幫助評估技術(shù)風(fēng)險和工作量。
通常，分解“用戶(hù)故事”，得到更深入的用戶(hù)故事的細節，將有助于更加精確的估算時(shí)間。但是，在計劃階段，并不需要估算時(shí)間十分精確，只需要大致準確就可以了。如果在這個(gè)階段，開(kāi)發(fā)人員深入技術(shù)細節，那么就違背了XP“盡可能推遲決策”的精神，而更像傳統軟件開(kāi)發(fā)方法“預先制定詳細計劃、分析、設計”的作風(fēng)了！
開(kāi)發(fā)階段是整個(gè)軟件開(kāi)發(fā)的重頭戲，包括大量的步驟。
其中，首先是“發(fā)布計劃”階段。在計劃階段，用戶(hù)得到了其提出的所有的用戶(hù)故事及其對應的估算時(shí)間。這樣，用戶(hù)就可以根據用戶(hù)故事的輕重緩急，自由的決定一次小版本內需要實(shí)現的用戶(hù)故事。
一、 小版本。XP主張，將一個(gè)簡(jiǎn)單系統迅速投入生產(chǎn)，然后以很短的周期發(fā)布新版本。這樣，1，系統可以盡早的投入生產(chǎn)，為客戶(hù)提供效益。也可以使客戶(hù)在決定中止項目時(shí)，不使項目的投資浪費掉。2，投入生產(chǎn)的系統，比傳統的“快速軟件原型”更能夠揭示系統的工作，可以盡早的發(fā)現很多問(wèn)題，讓業(yè)務(wù)人員和開(kāi)發(fā)人員及早的解決。如果，直到整個(gè)系統已經(jīng)完成了90%，才發(fā)現采用的軟件架構根本無(wú)法實(shí)現系統的性能要求，那么一切都已經(jīng)太晚了。3，更重要的是，一般只有當業(yè)務(wù)人員真正看到運行中的系統時(shí)，業(yè)務(wù)人員才會(huì )知道他們真正要的是什么！盡快投產(chǎn)的系統，使用戶(hù)有更多的時(shí)間更改用戶(hù)故事。
20-80原則是一個(gè)非常普遍的原則，各個(gè)學(xué)科都有這樣的原則。軟件程序員習慣于使用的20-80原則是：80%的效益來(lái)自20%的工作。而XP程序員用自己的方式利用這條原則：將最有價(jià)值的20%的功能率先投入生產(chǎn)，依靠20-80原則來(lái)延期優(yōu)化。將80%錦上添花的功能留在后面的版本中實(shí)現?！靶“姹尽本褪沁@一XP哲學(xué)的體現。
二、迭代計劃。在小版本內，還劃分成若干個(gè)更小的“迭代計劃”。開(kāi)發(fā)人員完成的版本，是一個(gè)個(gè)發(fā)布之后能夠使用的完整但可能并不完善的軟件。而“迭代計劃”的成果，則并不是可以發(fā)布的完整的應用軟件，只是在原有的軟件基礎之上又添加了幾個(gè)完整的用戶(hù)故事。
三、任務(wù)卡。業(yè)務(wù)人員和管理人員制定發(fā)布計劃和迭代計劃后，業(yè)務(wù)人員編寫(xiě)每個(gè)用戶(hù)故事的功能測試。功能測試，就是客戶(hù)問(wèn)自己，如果軟件能夠通過(guò)這些功能測試，就可以認為軟件能夠完成用戶(hù)故事。功能測試也是文字描述。實(shí)際上，按照我的理解，功能測試，很像UML的用例的事件流，或者是UML的序列圖。實(shí)際上就是用戶(hù)故事的分解。這當然有助于開(kāi)發(fā)人員更清晰的知道自己要做的是什么。
隨著(zhù)理解的加深，開(kāi)發(fā)人員對迭代計劃中人物的時(shí)間估算會(huì )更加準確。
開(kāi)發(fā)人員編寫(xiě)任務(wù)卡。開(kāi)發(fā)人員將開(kāi)發(fā)任務(wù)和對應的估算時(shí)間寫(xiě)在一張卡上。任務(wù)卡中的任務(wù)不僅僅包括實(shí)現用戶(hù)故事的任務(wù)，還包括其他所有的工作任務(wù)。任務(wù)估算完畢之后，開(kāi)發(fā)人員根據自己在本次迭代中應承擔的“標準編程時(shí)間”認領(lǐng)任務(wù)卡。這就是詳細的開(kāi)發(fā)計劃了！XP管理者不制定具體的實(shí)施計劃，只是分配任務(wù)給開(kāi)發(fā)人員。具體怎樣分配時(shí)間來(lái)完成用戶(hù)故事和任務(wù)，由程序員自己決定。
管理者跟蹤程序員的任務(wù)完成情況，并在軟件實(shí)際開(kāi)發(fā)與估算發(fā)生偏差時(shí)提供幫助，或者調整任務(wù)分配。當所有的功能測試都通過(guò)時(shí)，我們的一次迭代任務(wù)就完成了。
三、軟件架構
在軟件的第一個(gè)版本的第一次迭代計劃中，要實(shí)現的用戶(hù)故事是有開(kāi)發(fā)人員決定。因為，開(kāi)發(fā)人員首先要在實(shí)現這些最基本的用戶(hù)故事的同時(shí)，構建軟件的架構。為后續的用戶(hù)故事的實(shí)現提供一個(gè)基礎的軟件平臺。
在開(kāi)發(fā)軟件之時(shí)，我們總會(huì )首先構建一個(gè)軟件框架。軟件框架的構造有幾種方式：
1，從已有的軟件中，去除所有的特定與業(yè)務(wù)的部分，得到一個(gè)“參考架構”。比如說(shuō)，微軟、SUN、Oracle、iBATIS開(kāi)源項目、Spring開(kāi)源項目都采用各自不同的技術(shù)實(shí)現過(guò)PetStore寵物店這個(gè)軟件。我們可以去除掉所有與特定業(yè)務(wù)相關(guān)的代碼，就得到了一個(gè)個(gè)使用不同技術(shù)的“參考架構”。以此為基礎，在其中添加上實(shí)現用戶(hù)故事的代碼，就能夠方便的完成軟件。
還可以對其他來(lái)源的軟件，提取出“參考架構”。比如，以前開(kāi)發(fā)過(guò)的軟件等。
2，軟件技術(shù)非常之多，將各種技術(shù)以不同的方式組合起來(lái)，可以有無(wú)數種軟件架構。我們可以在軟件的第一個(gè)版本的第一次迭代時(shí)，選取一套簡(jiǎn)單的、基本的，能夠搭建起整個(gè)體系結構的故事。根據業(yè)務(wù)需要，將集中最適合的軟件技術(shù)整合起來(lái)，構建出一個(gè)軟件架構。
只有需要構建軟件架構的迭代計劃中，才由開(kāi)發(fā)人員指定要完成的用戶(hù)故事，其他情況下，都由客戶(hù)指定要完成的故事。
四、實(shí)際的開(kāi)發(fā)階段
制定了迭代計劃，分配了任務(wù)之后，程序員就可以進(jìn)入全速的開(kāi)發(fā)狀態(tài)了！
UML中最常用到的圖是：用例圖、序列圖（或者狀態(tài)圖，它們可以互相轉化）、類(lèi)圖。其他的UML圖都存在很大的爭議，在我看來(lái)，未必有用。UML中，Ivar Jacobson提出的用例驅動(dòng)開(kāi)發(fā)，最值得稱(chēng)道。
XP可以說(shuō)是“測試驅動(dòng)開(kāi)發(fā)”。測試驅動(dòng)開(kāi)發(fā)，有兩個(gè)方面：
功能測試驅動(dòng)開(kāi)發(fā)（又叫做“驗收測試驅動(dòng)開(kāi)發(fā)”）和單元測試驅動(dòng)開(kāi)發(fā)。其中的“功能測試驅動(dòng)開(kāi)發(fā)”和UML的“用例驅動(dòng)開(kāi)發(fā)”類(lèi)似。
在計劃階段，XP首先由客戶(hù)主導，編寫(xiě)了“故事卡”，這類(lèi)似于“用例”。
軟件開(kāi)發(fā)可以分為3大模塊：文檔層面的業(yè)務(wù)模塊，代碼層面的業(yè)務(wù)模塊，代碼層面的業(yè)務(wù)模塊。
，文檔層面的業(yè)務(wù)模塊
其中，文檔層面的業(yè)務(wù)模塊，是由客戶(hù)負責編寫(xiě)的。包括故事和功能測試。對應于UML來(lái)說(shuō)，就是用例圖和序列圖。故事是整體上的、概略的軟件需求。用于概略的描述整個(gè)系統的需求。在計劃階段，選擇相應的故事之后，在迭代計劃階段，客戶(hù)對選中的故事進(jìn)行深入地挖掘。為故事添加更多的細節，這樣就得到了UML中用例的“事件流”。然后，可以據此編寫(xiě)功能測試（又叫驗收測試）和功能測試所需的測試數據。系統的這部分功能完成后，如果對于輸入的數據，其結果都和預期的一致，那么軟件的故事就實(shí)現了。
，代碼層面的業(yè)務(wù)模塊
客戶(hù)提供了用戶(hù)故事和功能測試之后，開(kāi)發(fā)人員就可以使用序列圖對用戶(hù)故事及其事件流進(jìn)行分析，以序列圖為主線(xiàn)，找到提供服務(wù)的對象及其功能和配合方式。
代碼層面的業(yè)務(wù)模塊，是開(kāi)發(fā)人員開(kāi)發(fā)的代碼。這些代碼是直接對應于故事和功能測試的，是為了滿(mǎn)足功能測試而存在的。其主要分為兩個(gè)部分：業(yè)務(wù)代表模塊和業(yè)務(wù)服務(wù)模塊。業(yè)務(wù)代表模塊，我使用Action表示；業(yè)務(wù)服務(wù)模塊，我使用Service來(lái)表示。至于表現層（就是用戶(hù)界面）這一部分，我沒(méi)有把它們歸在軟件開(kāi)發(fā)的三大模塊中，因為表現層僅僅是一個(gè)用戶(hù)界面，和軟件核心無(wú)關(guān)。表現層是一個(gè)非常薄的軟件模塊，而且還可以任意替換。
表現層模塊有很多種，如B/S架構的Browser(網(wǎng)絡(luò )瀏覽器)作為表現層，或者C/S架構的富客戶(hù)端技術(shù)作為表現層。在Java中，富客戶(hù)端表現層技術(shù)主要有AWT,Swing,SWT這些界面技術(shù)；在Web瘦客戶(hù)端方面，主要有JSP,Spring MVC,WebWork,Struts，Tapstry,JSF等技術(shù)。這里，我主要以目前最流行的Java網(wǎng)絡(luò )瀏覽器表現層技術(shù)Struts為例來(lái)加以說(shuō)明。Struts中Action是MVC模式（MVC模型-視圖-控制器模式）中的控制器。同時(shí)，它也是業(yè)務(wù)代表。所謂業(yè)務(wù)代表，是指在客戶(hù)端和業(yè)務(wù)服務(wù)層之間，增設一個(gè)“代表層”，所有客戶(hù)端到服務(wù)器的調用，都“委托”該層完成。[10J2EE核心模式 第二版218頁(yè)]業(yè)務(wù)代表雖然身處表現層（客戶(hù)端）內，但實(shí)際上執行的是調用業(yè)務(wù)服務(wù)模塊功能的任務(wù)，完成的是業(yè)務(wù)功能。因此，不少人都將業(yè)務(wù)代表劃分在業(yè)務(wù)模塊內。我也認同這種劃分方法。
業(yè)務(wù)代表Action提供的是服務(wù)，為表現層提供業(yè)務(wù)處理的服務(wù)。所以，它和具體的客戶(hù)是無(wú)關(guān)的，它為所有的客戶(hù)都提供同一種服務(wù)。所以，它一般是多線(xiàn)程的單例對象。Struts的Action就是這樣的。當然也有不同的，WebWork的Action是多例的。為每一個(gè)客戶(hù)的請求都新建一個(gè)Action的實(shí)例。
業(yè)務(wù)服務(wù)模塊Service提供的是業(yè)務(wù)服務(wù)。它是完全獨立于表現層，可以為不同的表現層提供服務(wù)的模塊。業(yè)務(wù)代表通過(guò)調用業(yè)務(wù)服務(wù)模塊的服務(wù)方法為客戶(hù)提供服務(wù)。Service也是多線(xiàn)程單例的對象。因為它為不同的客戶(hù)提供的是同一種服務(wù)方法。
業(yè)務(wù)代表類(lèi)Action和業(yè)務(wù)服務(wù)類(lèi)Service互相配合，完成客戶(hù)指定的用戶(hù)故事和功能測試。同時(shí)，它們也是很容易混淆的。
表現層要盡可能的薄。這句話(huà)的意思也就是說(shuō)業(yè)務(wù)代表Action也要盡可能的?。ㄒ驗楸憩F層主要的代碼就是在業(yè)務(wù)代表Action類(lèi)中了）。Action只是接受客戶(hù)請求，然后調用業(yè)務(wù)服務(wù)Service類(lèi)的方法完成業(yè)務(wù)。它不應該包括任何業(yè)務(wù)代碼。而我們常犯的錯誤，就是Action類(lèi)太大，含有太多的業(yè)務(wù)代碼。實(shí)際上，Action中不應該含有任何業(yè)務(wù)代碼。因為，表現層是軟件中最多變的需求?？蛻?hù)常常會(huì )僅僅因為界面不好看而要求更改。如果，Action中代碼盡可能的少，那么更改用戶(hù)界面就是一件很省力的事情。
讓Action變薄的最簡(jiǎn)單方法，就是考慮如果對于這個(gè)業(yè)務(wù)需求，還需要增加一個(gè)表現層，那么在A(yíng)ction中哪一些代碼會(huì )重復出現。如果有重復代碼，就“重構”，把它們提煉成方法，然后移到對應的業(yè)務(wù)服務(wù)Service類(lèi)中。
業(yè)務(wù)代表Action模塊盡可能的?。ㄟ@樣整個(gè)表現層也就薄了），業(yè)務(wù)服務(wù)Service模塊盡可能的厚（這樣，可重用代碼就多了），這是代碼層面的業(yè)務(wù)模塊的第一大原則。
[注意：
本文未完，待續。這是我的一篇研究性的文章。本是草稿。成書(shū)于半年前，后面未寫(xiě)完，尚遺一部分。因為寫(xiě)到這里，覺(jué)得沒(méi)有寫(xiě)下去的必要，所以一直未序。
這里，我草草把它翻出來(lái)，整理一下格式，發(fā)表出來(lái)。未完部分，只有等待以后有時(shí)間再續。
或者，您也可以看我的另一篇文章《開(kāi)發(fā)健壯的企業(yè)級應用的研究》，那里可以看到本文接下來(lái)要講的完整內容。就是因為寫(xiě)到這里，我決定換一個(gè)角度，寫(xiě)那篇文章，才終止了本文的寫(xiě)作。
敬請諒解！
Learning the Planning Game
An Extreme Exercise
http://pclc.pace.edu/~bergin/xp/planninggame.html
http://www.javaeye.com/forums/tag/XP
