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