每個(gè)人都喜歡聽故事，這也許是從小就養(yǎng)成的習(xí)慣。如果能夠把需求分析工作變成聽故事的過程，那該有多好。需求分析人員寫出一個(gè)個(gè)優(yōu)美的故事，開發(fā)人員邊看故事，邊實(shí)現(xiàn)故事。也許這就是XP的設(shè)計(jì)思路所在。用戶故事，XP把需求變成了一個(gè)個(gè)故事，摒棄了枯燥無味的需求穩(wěn)定。文檔的作用是傳遞信息，如果失去這個(gè)意義，再優(yōu)秀的文檔也沒有任何用處。但是，完整細(xì)致、厚達(dá)數(shù)十頁的需求文檔是否真的能夠達(dá)到溝通的目標(biāo)呢？對(duì)于大多數(shù)而言，恐怕看到文檔的厚度就已經(jīng)心生懼意了吧。好吧，我們通過很多的輔助手段，可以強(qiáng)制要求開發(fā)人員都投入大量的精力來研究、學(xué)習(xí)復(fù)雜的需求文檔。但是這厚厚的需求文檔真的能夠完整的記錄所有的需求嗎？更糟糕的是，需求是會(huì)發(fā)生變化的，到時(shí)候如何維護(hù)這份需求文檔呢？回想精益原則，我們可以判定，這種處理需求的方式一定會(huì)產(chǎn)生大量的浪費(fèi)。將需求做的盡善盡美需要成本，項(xiàng)目組的人員熟悉需求需要成本，維護(hù)文檔需求成本，解決不一致的問題也需要成本。那么，我們可以針對(duì)這幾點(diǎn)做一個(gè)分析：
針對(duì)以上的幾點(diǎn)，XP提出了自己的實(shí)現(xiàn)思路－用戶故事。用戶故事簡(jiǎn)單，每個(gè)人都會(huì)寫，每個(gè)人也都能理解，改變起來也很容易。但用戶故事只是對(duì)系統(tǒng)功能的一個(gè)簡(jiǎn)單的描述，他并不能提供所有的需求內(nèi)容，因此，在XP中，用戶故事的實(shí)踐需要現(xiàn)場(chǎng)客戶的支持。用戶故事之所以簡(jiǎn)單，是因?yàn)樗皇情_發(fā)人員和客戶之間的一種契約，更詳細(xì)的信息需要通過現(xiàn)場(chǎng)客戶來獲得支持。
從XP的觀點(diǎn)來看，用戶故事有這么幾點(diǎn)作用：
| 在收到國(guó)外匯款時(shí)，業(yè)務(wù)人員需要記錄匯款的相關(guān)信息，如果匯款指定的收款人帳戶為本行帳戶，進(jìn)行入帳處理，如果收款人帳戶屬于同城同業(yè)（本地的其他銀行），則通過同城同業(yè)轉(zhuǎn)匯給收款人（后續(xù)如何處理？），如果收款人帳戶屬于異地同業(yè)（異地的其他銀行），則通過銀行的帳戶行將匯款轉(zhuǎn)匯至異地，并支付帳戶行轉(zhuǎn)匯的費(fèi)用（后續(xù)如何處理？）。 |
以上是一個(gè)銀行的國(guó)際結(jié)算業(yè)務(wù)中款業(yè)務(wù)的例子。簡(jiǎn)短的敘述和非正式的形式體現(xiàn)了XP強(qiáng)調(diào)的簡(jiǎn)單原則。故事幫助開發(fā)人員和用戶理順流程的關(guān)系。在上述例子中，我們看到開發(fā)雙方對(duì)流程仍然存在一定的疑慮（即括號(hào)中有問號(hào)的部分），但是這并不影響到用戶故事的創(chuàng)作，因?yàn)檫@個(gè)版本的用戶故事還會(huì)變化多次。但從這個(gè)簡(jiǎn)單的例子上來看，我們發(fā)現(xiàn)故事的形式仍然存在著一些不足：
故事的形式更容易被人接受，但是也有不規(guī)則的缺點(diǎn)。任意描述需求雖然節(jié)約了培訓(xùn)的成本，但是卻造成了不一致性。不同的人對(duì)故事有著不同的理解，對(duì)需求也就有了不同的理解。需求故事雖然看起來很簡(jiǎn)單，但是要講好一個(gè)需求故事絕對(duì)不是一件容易的事情。需求規(guī)約過于形式化和正式化，導(dǎo)致了需求規(guī)約難以使用，但是完全不要形式也不是一個(gè)好的做法。在形式和可用性之間保持平衡，是講好需求故事的關(guān)鍵。
需求故事雖然容易閱讀，但是卻很難寫得好。如何控制需求的描寫精度，如何分解需求，如何組織，如何確定邊界。但是XP并不關(guān)心這個(gè)問題，只要能夠起到溝通的效果，怎么做都行。這種態(tài)度是否正確我們暫不去評(píng)價(jià)。但在實(shí)踐中，由于缺乏系統(tǒng)的指導(dǎo)，一個(gè)新手往往需要花費(fèi)很長(zhǎng)的時(shí)間才能夠?qū)W會(huì)故事的寫法。
對(duì)于XP來說，需求的開發(fā)只有先后次序之分。而先后次序的制定由客戶來負(fù)責(zé)。但是在實(shí)踐中，識(shí)別出先后次序并不僅僅是客戶的責(zé)任，開發(fā)人員同樣需要提供需求優(yōu)先級(jí)和風(fēng)險(xiǎn)的建議。這里有幾點(diǎn)需求優(yōu)先級(jí)的建議：
用例技術(shù)保持了需求的簡(jiǎn)單原則，用例和形式和用戶故事非常的相似，但是用例具有自己的格式，雖然這個(gè)格式也是可以任意定義的。用例的重點(diǎn)是表示系統(tǒng)的行為。我們看看上面的例子如何用用例來表示：
| 主要角色：業(yè)務(wù)人員 層次：業(yè)務(wù)流程級(jí)別 前置條件：收到匯款 基本流程： 1 業(yè)務(wù)人員選擇匯入?yún)R款業(yè)務(wù)。 2 業(yè)務(wù)人員輸入必要的匯款相關(guān)信息。 3 業(yè)務(wù)人員將匯款轉(zhuǎn)入收款人帳戶。 3.1 如果收款人為本銀行帳戶，直接入帳。 3.2 如果收款人為同城同業(yè)（本地的其他銀行），則通過同城同業(yè)轉(zhuǎn)匯給收款人（后續(xù)如何處理？） 3.3 如果收款人帳戶屬于異地同業(yè)（異地的其他銀行），則通過銀行的帳戶行將匯款轉(zhuǎn)匯至異地，并支付帳戶行轉(zhuǎn)匯的費(fèi)用（后續(xù)如何處理？）。 備選流程 暫缺 |
可以看到，用例表示的內(nèi)容和用戶故事并沒有太大的差別，但用例比較強(qiáng)調(diào)格式。雖然不同的團(tuán)隊(duì)有不同的格式，但是在同一個(gè)團(tuán)隊(duì)中，盡可能使用相同和相似的格式（不同的用例可能需要不同的用例格式）基本流程中的每一個(gè)步驟都代表了業(yè)務(wù)人員和系統(tǒng)一次交互，流程非常的簡(jiǎn)單，但是已經(jīng)覆蓋了一個(gè)成功的流程。我們看到，流程的每一步都高度抽象的原因是該用例的層次是業(yè)務(wù)流程級(jí)別的。（業(yè)務(wù)流程級(jí)別也僅僅是一種約定，并不是標(biāo)準(zhǔn)）。利用層次的概念對(duì)用例進(jìn)行精度的劃分。在上面的例子中，低精度的用例主要的目標(biāo)是把握系統(tǒng)的全貌。在RUP中，這種用例也被稱為業(yè)務(wù)用例（Business Use Case）。在原先的用戶故事中，對(duì)分支情況描述比較含糊，但采用了用例的這種描述形式，分支情況就一目了然了，和前面一樣，分支情況的表述也有很多種的形式。
用例技術(shù)從提出到現(xiàn)在，已經(jīng)有了大量的經(jīng)驗(yàn)積累。在XP項(xiàng)目中采用用例技術(shù)并不是什么新鮮事。但在XP中應(yīng)用用例也必須遵循XP的原則，以及精益編程的思路。所幸的是，這些思路是非常自然的，使用用例技術(shù)是完全可以實(shí)現(xiàn)的。本文并不打算詳細(xì)的描述用例技術(shù)，如果要深入了解用例技術(shù)，有幾本書是非常值得一看的（見附錄）。
先把握系統(tǒng)的全貌：在做需求的時(shí)候，常常出現(xiàn)的一種情況是需求分析人員花費(fèi)了很多的心思來精華、完善某個(gè)用例。對(duì)XP來說，這種做法并不推薦，而根據(jù)精益原則，這種行為存在浪費(fèi)的可能性。我們對(duì)軟件、對(duì)項(xiàng)目的認(rèn)識(shí)是不斷深入的。因此，我們?cè)陧?xiàng)目一開始就深入到需求、故事、或用例的細(xì)節(jié)，分析人員的能力可能很強(qiáng)，能夠正確的捕捉到用戶的實(shí)際需要。但是一個(gè)星期之后我們對(duì)需求的認(rèn)識(shí)就有可能發(fā)生變化，也許是原先對(duì)用例范圍的界定出現(xiàn)了問題，也許從另一個(gè)角度分析用例效果會(huì)更好，也許原先處理用例的思路不正確。不管如何，需求變化的可能性是非常大。用例越詳細(xì)，發(fā)生變化的可能性就越大。這時(shí)候，原先花在精化用例上的時(shí)間就被浪費(fèi)了。
因此，不要在一開始就精化需求，一開始的工作重點(diǎn)應(yīng)該是放在盡可能全面的收集用例，了解整體的業(yè)務(wù)流程，分析主體業(yè)務(wù)流程等工作上。在獲得了系統(tǒng)的全貌之后，你會(huì)發(fā)現(xiàn)你原先對(duì)系統(tǒng)的認(rèn)識(shí)是不充分的，用例需要根據(jù)新的思路進(jìn)行重新排列，用例的優(yōu)先級(jí)需要調(diào)整， 在UML圖中，往往有一張系統(tǒng)的用例概覽圖，這張圖所表示的就是系統(tǒng)行為的一個(gè)概述。
尋找優(yōu)先級(jí)高的用例進(jìn)行精化：我們?cè)谏衔奶岬搅诵枨髢?yōu)先級(jí)的判斷，用例的優(yōu)先級(jí)判斷和需求的優(yōu)先級(jí)判斷相似。在討論迭代的時(shí)候我們說過，前幾次迭代的主要目的是要識(shí)別出項(xiàng)目風(fēng)險(xiǎn)。因此，尋找有代表性、優(yōu)先級(jí)高的用例進(jìn)行精化，能夠幫助開發(fā)人員更快的理解領(lǐng)域知識(shí)，構(gòu)建起初步的領(lǐng)域模型。
繼續(xù)上面國(guó)際結(jié)算的例子，在完成總的用例圖之后，我們發(fā)現(xiàn)，銀行的業(yè)務(wù)非常的復(fù)雜，如果缺少領(lǐng)域?qū)＜?，要在短時(shí)間內(nèi)領(lǐng)會(huì)領(lǐng)域邏輯是非常困難的，同時(shí)，我們發(fā)現(xiàn)，匯款的業(yè)務(wù)在日常業(yè)務(wù)中所占的百分比是非常高的，而匯款業(yè)務(wù)涉及到了大多數(shù)的領(lǐng)域知識(shí)，而業(yè)務(wù)流程卻相對(duì)簡(jiǎn)單。因此，我們決定，先把匯款的用例作為一個(gè)突破口，在完成了這個(gè)用例之后，我們的開發(fā)人員就會(huì)對(duì)業(yè)務(wù)領(lǐng)域有著比較深入的認(rèn)識(shí)，也就能夠進(jìn)行更復(fù)雜的工作了：
| 主要角色：業(yè)務(wù)人員 層次：業(yè)務(wù)流程級(jí)別 前置條件：收到匯款 基本流程： 1 業(yè)務(wù)人員選擇匯入?yún)R款業(yè)務(wù)。 2 業(yè)務(wù)人員輸入必要的匯款相關(guān)信息。 3 業(yè)務(wù)人員將匯款轉(zhuǎn)入收款人帳戶。 3.1 如果收款人為本銀行帳戶，直接入帳。 3.2 如果收款人為同城同業(yè)（本地的其他銀行），則通過同城同業(yè)轉(zhuǎn)匯給收款人（后續(xù)如何處理？） 3.3 如果收款人帳戶屬于異地同業(yè)（異地的其他銀行），則通過銀行的帳戶行將匯款轉(zhuǎn)匯至異地，并支付帳戶行轉(zhuǎn)匯的費(fèi)用（后續(xù)如何處理？）。 備選流程 2．A在任何時(shí)候，業(yè)務(wù)人員都可以應(yīng)客戶的要求對(duì)向匯款銀行進(jìn)行查詢。 2．A1在收到匯款銀行的查詢答復(fù)之后，記錄答復(fù)信息。 2．B在任何時(shí)候，業(yè)務(wù)人員收到匯款銀行要求退回匯款的授權(quán)。 2．B1如果匯款未被提走，根據(jù)要求將匯款退回匯款銀行。 2．B2如果匯款已被提走，通知匯款銀行無法處理，用例結(jié)束。 |
注意到，在這個(gè)例子中我們對(duì)用例優(yōu)先級(jí)的判定條件和上文的稍有不同，我們選擇有代表性，但又相對(duì)簡(jiǎn)單的用例作為高優(yōu)先級(jí)的用例。這樣做是因?yàn)閷?duì)業(yè)務(wù)領(lǐng)域比較陌生，一開始實(shí)現(xiàn)復(fù)雜的需求有很大的難度。所以，雖然我們提供了一些制定用例優(yōu)先級(jí)的思路，但是實(shí)踐的時(shí)候仍需要根據(jù)實(shí)際情況權(quán)衡。
迭代精化：用例的編寫過程是一個(gè)對(duì)業(yè)務(wù)領(lǐng)域不斷熟悉的過程。隨著調(diào)研的深入，不斷有新的問題顯露出來，需要補(bǔ)充或修改原先的用例。這里有兩種情況，一種是在同一個(gè)增量?jī)?nèi)，在對(duì)用例B精化的時(shí)候，發(fā)現(xiàn)用例A中忽略了一種情況，這時(shí)候我們就需要補(bǔ)充用例A。例如，我們?cè)诰渌美臅r(shí)候，發(fā)現(xiàn)匯款用例中忽略了報(bào)表的需求，這樣我們的工作又必須回到匯款用例上。這樣的情況是非常普遍的，這就要求我們不要過分的修飾用例，不要把精力花在用例格式上，這樣只會(huì)造成浪費(fèi)。
第二種情況是在不同的增量中，這時(shí)候用例往往會(huì)加入新的需求、新的情境。我們?nèi)绾稳タ刂撇煌隽科陂g的迭代呢？一般來說，有兩種方法，一種是對(duì)原有的用例進(jìn)行增補(bǔ)，增補(bǔ)的部分用不同的顏色或標(biāo)記。另一種方法是為用例建立版本，不同版本的用例對(duì)應(yīng)于不同的增量周期。這樣，對(duì)應(yīng)對(duì)N個(gè)增量周期就有了n個(gè)不同版本的用例（n≤N）。不管是哪一種情況，都要求我們采用迭代的思路來處理用例。
形式不是最重要的：在團(tuán)隊(duì)中強(qiáng)制要求統(tǒng)一的用例書寫格式是有意義的，但有的時(shí)候，這個(gè)意義并沒有想象中的那么大?？梢约s定條件的編寫形式、也可以約定層次的劃分。但是過分的強(qiáng)制形式就沒有什么意義了。
林星，辰訊軟件工作室項(xiàng)目管理組資深項(xiàng)目經(jīng)理，有多年項(xiàng)目實(shí)施經(jīng)驗(yàn)。辰訊軟件工作室致力于先進(jìn)軟件思想、軟件技術(shù)的應(yīng)用，主要的研究方向在于軟件過程思想、Linux集群技術(shù)、OO技術(shù)和軟件工廠模式。您可以通過電子郵件 iamlinx@21cn.com和他聯(lián)系。
聯(lián)系客服
