一、什么是用戶故事

用戶故事描述了對用戶、系統(tǒng)或軟件購買者有價值的功能。一個好的用戶故事包括三個要素：

1.角色：誰要使用這個功能。

2.功能：需要完成什么樣的功能。

3.價值：為什么需要這個功能，這個功能帶來什么樣的價值。

用戶故事通常按照如下的格式來表達：

英文：As a , I want to , so that .

中文：作為一個<角色>, 我想要<功能>, 以便于<商業(yè)價值>

舉例：“作為招聘網(wǎng)站注冊用戶，我想要查看最近3天發(fā)布的招聘信息，以便于我看到最新的招聘信息”。

由于用戶故事的描述信息以傳統(tǒng)的手寫方式寫在紙質(zhì)卡片上，所以Ron Jeffries(2001)對這三個方面稱為3C：卡片(Card)、對話(Conversation)和確認(rèn)(Confirmation)。

卡片（Card）：用戶故事一般在小卡片上寫著故事的簡短描述，工作量估算等。

交談（Conversation）：用戶故事背后的細(xì)節(jié)來源于和客戶或者產(chǎn)品負(fù)責(zé)人的交流溝通。

確認(rèn)（Confirmation）：通過驗收測試確認(rèn)用戶故事被正確完成。

二、如何編寫用戶故事

故事應(yīng)該很清晰地體現(xiàn)對用戶或客戶的價值，最好的做法是讓客戶團隊來編寫故事。客戶團隊?wèi)?yīng)包括能確定軟件最終用戶需求的人，可能包括測試者，產(chǎn)品管理者，真實用戶和交互設(shè)計師。因為他們處于描述需求的最佳位置，也因為隨后他們需要和開發(fā)者一同設(shè)計出故事細(xì)節(jié)并確定故事優(yōu)先級。

為了構(gòu)造好的用戶故事，我們關(guān)注六個特征。一個優(yōu)秀的故事應(yīng)該具備以下特點：

?獨立的（Independent）— 我們要盡量避免故事間的相互依賴。在對故事排列優(yōu)先級時，或者使用故事做計劃時，故事間的相互依賴會導(dǎo)致工作量估算變得更加困難。通常我們可以通過兩種方法來減少依賴性：1.將相互依賴的故事合并成一個大的、獨立的故事；2.用一個不同的方式去分割故事。

?可討論的（Negotiable）— 故事卡是功能的簡短描述，細(xì)節(jié)將在客戶團隊和開發(fā)團隊的討論中產(chǎn)生。故事卡的作用是提醒開發(fā)人員和客戶進行關(guān)于需求的對話，它并不是具體的需求本事。一個用戶故事卡帶有了太多的細(xì)節(jié)，實際上限制了和用戶的溝通。

?對用戶或客戶有價值的（Valuable）— 用戶故事應(yīng)該很清晰地體現(xiàn)對用戶或客戶的價值，最好的做法是讓客戶編寫故事。一旦一個客戶意識到這是一個用戶故事并不是一個契約而且可以進行協(xié)商的時候，他們將非常樂意寫下故事。

?可估算的（Estimable）—開發(fā)團隊需要去估計一個用戶故事以便確定優(yōu)先級，工作量，安排計劃。但是讓開發(fā)者難以估計故事的問題來自：1.開發(fā)人員缺少領(lǐng)域知識；2.開發(fā)人員缺少技術(shù)知識；3.故事太大了。

?小的（Small）— 一個好的故事在工作量上要盡量小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代或Sprint中能夠完成。用戶故事越大，在安排計劃，工作量估算等方面的風(fēng)險就會越大。

?可測試的（Testable）— 故事必須是可測試的。成功通過測試可以證明開發(fā)人員正確地實現(xiàn)了故事。如果一個用戶故事不能夠測試，那么你就無法知道它什么時候可以完成。一個不可測試的用戶故事例子：用戶必須覺得軟件很好用。

三、用戶角色建模

在很多項目中，需求分析人員只是從一個角度編寫用戶故事，這樣往往容易忽略一下需求(故事)。所以在編寫用戶故事前識別用戶角色和虛擬人物(Persona)有很多好處。

以下是招聘網(wǎng)站可能出現(xiàn)的用戶角色列表：

角色建模的步驟：

1.通過頭腦風(fēng)暴列出初始的用戶角色集合：每個人要做的只是盡量在卡片上寫出自己想到的角色。

2.整理最初的角色集合：對于有重疊的角色，把它們相應(yīng)的卡片重疊在一起。

3.整合角色：在角色分組完成后，試著整合及濃縮角色。

4.提煉角色：一旦我們整合好角色，并且對角色之間的關(guān)系有了一個基本的了解，就有可能通過給每個角色定義一些特征來建立角色的模型。

虛擬人物，可以考慮一兩個主要的用戶角色寫下虛擬人物定義，從虛擬人物的角度描述會使故事變得更加生動。

四、如何搜集故事

用戶需求并不容易得到，因為用戶并不知道所有的需求，所有不能單靠用戶給我們解釋需求。Robertson 和 Robertson(1999)引入了拖網(wǎng)(trawling)這個詞來描述收集需求的過程，要像“拖網(wǎng)漁船捕撈魚”那樣來收集需求。

首先，不同大小的網(wǎng)用來捕獲不同大小的需求。第一遍，我們可以用大網(wǎng)眼的漁網(wǎng)撈一遍需求池，以此得到所有的大需求。通過這些大需求，形成對軟件的整體感覺。接下來，用網(wǎng)眼稍微小一些的漁網(wǎng)得到中等大小的需求。

其次，需求會像魚一樣，會成長，也可能會死亡。今天漁網(wǎng)可能會漏掉一個需求，因為這個需求對于系統(tǒng)來說不重要。但是，根據(jù)每輪迭代的反饋，系統(tǒng)會朝著事先不可預(yù)知的方向發(fā)展，有些需求會變得越來越重要。

第三，在某一區(qū)域拖網(wǎng)捕魚不可能捕獲到所有的魚，我們也不可能捕獲所有需求，也可能撈到一些廢棄的貨物或漂浮的殘，這會使需求膨脹。

最后，技能也是發(fā)現(xiàn)需求的一個要素，一個熟練的需求分析人員知道要到哪里去找需求。

故事會隨著項目的進展而演進，所以我們可以通過用戶訪談、觀察用戶、問卷調(diào)查和舉辦故事編寫工作坊來發(fā)現(xiàn)用戶故事。另外通過開放式、與背景無關(guān)的提問更容易獲得有用的答案，例如：“告訴我你想怎么搜索工作？”就勝于“你要通過職位名稱來搜索工作嗎？”

五、與用戶代理合作

對于一個項目來說，客戶團隊里包括一個或多個真實用戶是極其重要的。但是但我們無法接觸到他們時，我們就需要求助于用戶代理(User Proxy)，選擇合適的用戶代理對于項目的成功至關(guān)重要。

?用戶的經(jīng)理：如果用戶的經(jīng)理不是軟件的實際用戶，并從中干預(yù)產(chǎn)品功能的開發(fā)。這種情況下，務(wù)必小心，不要得罪該用戶經(jīng)理，在部分圍繞她的同時，想辦法接觸終端用戶。

?開發(fā)經(jīng)理：讓開發(fā)經(jīng)理擔(dān)任用戶代理，是最壞的選擇之一，除非你們開發(fā)的軟件就是給開發(fā)經(jīng)理用的。

?銷售人員：讓銷售人員充當(dāng)用戶代理是危險的，這會讓大家對正在開發(fā)的產(chǎn)品沒有一個全面的藍(lán)圖。然而，銷售人員是非常好的中轉(zhuǎn)站，應(yīng)該讓他們通過電話或銷售拜訪把你介紹給客戶。

?領(lǐng)域?qū)＜?/b>：領(lǐng)域?qū)＜液苓m合做用戶代理，但要避免最終開發(fā)出來的軟件僅僅針對那些與領(lǐng)域?qū)＜矣蓄愃扑降挠脩簟?/p>

?市場營銷團隊：他們可能更關(guān)注軟件特性的數(shù)量而不是質(zhì)量。他們可以為相關(guān)故事的優(yōu)先級提供高層次的指導(dǎo)意見，但他們往往不具備很好的洞察力，無法給提供故事的具體細(xì)節(jié)。

?以前的用戶：應(yīng)謹(jǐn)慎考慮她的目標(biāo)和動機是否與實際用戶的完全一致。

?客戶：考慮客戶的期望是很重要的，因為開支票買軟件的人是他們，而不是用戶。

?培訓(xùn)師和技術(shù)支持：由培訓(xùn)師和技術(shù)支持人員來充當(dāng)用戶代理看似是合乎邏輯的，不幸的是，他們做用戶代理，你的系統(tǒng)最終將只成為一個易于培訓(xùn)系統(tǒng)或只是使得技術(shù)支持工作變得較為容易，而不是功能最大化服務(wù)于最終用戶。

?業(yè)務(wù)分析師或系統(tǒng)分析師：許多業(yè)務(wù)和系統(tǒng)分析師是很好的用戶代理。他們唯一缺點是遇到問題喜歡空想，偶爾會在項目前期花太多時間做產(chǎn)品計劃。

與用戶代理合作時，做些什么？

1.能接觸到用戶但訪問受限時：最好可以申請由部分用戶組成一個用戶顧問團隊。

2.實在不能接觸到用戶時：必須求助于用戶代理；如果有競爭產(chǎn)品，也可以用其做一些故事的來源。

3.避免陷入思維的誤區(qū)：知道用戶的想法，所以不需要或可以忽略用戶代理。

六、用戶故事驗收測試

編寫驗收測試有很多好處，其一就是很多客戶和開發(fā)人員討論的細(xì)節(jié)可以通過驗收測試記錄下來。測試的要點記錄了客戶提出的一些假設(shè)，也提供了確認(rèn)故事是否被完整實現(xiàn)的基本標(biāo)準(zhǔn)。

在寫代碼之前寫測試

考慮每個故事，然后問類似下面的一些問題：

1.關(guān)于這個故事，程序員還需要知道什么？

2.對怎么實現(xiàn)這個故事，我的想法是什么？

3.有沒有一些特殊情況會使這個故事有不一樣的行為？

4.這個故事在什么情況會出錯？

客戶定義測試

客戶可以和程序員與測試人員合作創(chuàng)建測試，但客戶至少應(yīng)該給我們詳細(xì)指出一些測試，用以驗證故事的實現(xiàn)是正確的。

測試是過程的一部分

測試時開發(fā)過程中的一部分，這點對使用用戶故事非常重要。一般情況下，產(chǎn)品經(jīng)理和測試人員共同負(fù)責(zé)列出詳細(xì)的測試。產(chǎn)品經(jīng)理帶來驅(qū)動項目的公司目標(biāo)的知識；測試人員則帶來懷疑的心態(tài)。

多少測試才算多？

只要這些測試還在繼續(xù)為故事增加價值和使它更加清晰，客戶就應(yīng)該繼續(xù)寫測試。同時，一個優(yōu)秀的開發(fā)團隊會為很多詳細(xì)的用例編寫單元測試。

集成測試框架

客戶負(fù)責(zé)引領(lǐng)系統(tǒng)的開發(fā)。同時，在每輪迭代時都執(zhí)行以往迭代的所有測試時非常重要的，開發(fā)團隊?wèi)?yīng)該自動化部分或全部驗收測試。FIT和FitNesse是寫驗收測試的優(yōu)秀工具。

測試類型

測試類型有很多，故事測試主要是功能性的測試，用來確定應(yīng)用程序是如期運行的。

七、優(yōu)秀的用戶故事準(zhǔn)則

優(yōu)秀用戶故事的一些準(zhǔn)則：

1.試著讓故事的大小能夠在使用后讓用戶感到可以去喝杯咖啡休息一下；

2.不要讓故事過早涉及用戶界面；

3.實際編寫故事時，要包括用戶角色；

4.用主動語態(tài)編寫故事；

5.為單個用戶編寫故事；

6.讓客戶編寫故事，而不是開發(fā)人員；

7.用戶故事要簡短，它們只是提醒開發(fā)人員和客戶進行對話；

8.不要給故事卡添加編號。

八、用戶故事的估算

以故事點估算

用戶故事通常用故事點來估算，故事點表明一個故事相對于其他故事的大小和復(fù)雜度。通常以理想工作日作為故事點的單位：相較于用連續(xù)時間估算，它更簡單；相較于用完全模糊單位，它可使我們的估算擁有更好的依據(jù)。

以團隊估算

故事估算應(yīng)該由整個團隊集體完成，團隊大部分成員都參加估算是非常重要的?？蛻粢部梢詤⒓?，但是他不能提出他個人的估算或者在聽到自己不贊成的估算時發(fā)表意見。

Wideband Delphi估算方法

與采用迭代方式進行開發(fā)軟件的極限編程類似。最終目的是要為故事得到一個統(tǒng)一的估算值，這個迭代過程很少超過3輪。

三角測量

三角測試是幫助團隊驗證他們沒有逐漸改變一個故事點含義的有效方法。

九、團隊的速率

速率是每一輪迭代開發(fā)中能完成的工作量。一旦知道團隊速率，就可以用它將理想日轉(zhuǎn)換變成日歷日。總故事點 / 團隊的速率 = 需要的迭代次數(shù)。

初始速率

可以通過三種方法獲得初始速率：

1.使用歷史值

2.執(zhí)行一輪初始迭代，使用那輪迭代的速率

3.猜測

測試速率

團隊在在一輪迭代完成的故事點數(shù)的總和就是團隊速率，不能將部分完成的故事也計算在速率中。用集中全部力量完成一個故事的方法會提高團隊的意識：大家一起先完成一些故事比所有故事都只能完成一部分更有價值。

計劃速率和實際速率

計算速率是用迭代開始前分配的故事點數(shù)，實際速率是迭代中實際完成的故事點書。計劃速率與實際速率可能會出現(xiàn)偏差。

三、怎么拆分故事

當(dāng)故事非常大時，我們將很難對它進行估計。如果故事預(yù)計在N次迭代后才進行，那么大的故事很正常。但如果估計預(yù)計在接下來的迭代中進行，那么我們就可能會對大的故事進行拆分。很大的故事基本上都能進行拆分，只要確定每個小故事都可以交付業(yè)務(wù)價值就行。注意在這里不要把故事拆分到任務(wù)，故事是可以交付的東西，是產(chǎn)品負(fù)責(zé)人所關(guān)心的，而任務(wù)是不可交付的東西，產(chǎn)品負(fù)責(zé)人對它并不關(guān)心，任務(wù)是在sprint計劃會議上拆分的。

分割用戶故事：

1. 按照用戶故事所支持?jǐn)?shù)據(jù)的邊界來分割大型用戶故事（例如導(dǎo)入GBQ文件、Excel等）。

2. 從主用戶故事中除去對例外或錯誤條件的處理（相當(dāng)于用戶的基本路徑和擴展路徑），從而把一個大型用戶故事變小許多。

3. 按照操作邊界分割，把大型用戶故事分割成獨立的建立、讀取、更新和刪除操作（例如預(yù)算二次導(dǎo)入，或者新增時需要向?qū)А⒁?guī)則而比較復(fù)雜時也可以單獨成一個故事來描述）。

4. 考慮去除橫切考慮（例如安全處理、日志記錄、錯誤處理等），為用戶故事建立兩個版本：一個具備對橫切考慮的支持，另一個不具備這種支持。

5. 考慮功能性需求和非功能性需求隔離到不同的用戶故事，從而分割大型用戶故事（性能）。

在拆分故事時，我們有時也需要考慮組合故事的場景，如把bug列入產(chǎn)品backlog時，可以把多個類似的bug組合成一個故事。

四、怎么評定優(yōu)先級

最簡單的方法就是問問客戶最希望在下一個迭代中最想看到的是哪一些功能。從考慮的因素來看，我們可以從以下4個因素來考慮：

1. 獲取這些功能帶來的經(jīng)濟價值，價值越高的優(yōu)先級越高。

2. 開發(fā)成本帶來的影響。例如可能2個月后由于使用新技術(shù)只需要2周，而現(xiàn)在做需要2個月，這時可以考慮把優(yōu)先級放低一些。

3. 獲取新知識的重要性。在開發(fā)中會不斷的產(chǎn)生一些項目和產(chǎn)品的新知識，及早了解和開發(fā)這些新知識可以減少不確定性，所以這類功能優(yōu)先級會高些。

4. 故事之間會存在依賴關(guān)系，這時候被依賴的優(yōu)先級會更高，需要先完成。

5. 開發(fā)這些功能所減少的風(fēng)險。在開發(fā)過程中，會出現(xiàn)進度風(fēng)險、成本風(fēng)險、技術(shù)風(fēng)險等，對于風(fēng)險越高價值越大的我們需要首先處理，對風(fēng)險高價值低的要盡量避免，可以通過以下圖查看確定功能優(yōu)先級時綜合考慮風(fēng)險和價值的關(guān)系。

五、怎么進行初始評估

對每個故事進行初始估計后就可以知道項目的規(guī)模。一般采用故事點來進行這類初始評估，可以通過撲克牌來進行，撲克牌點數(shù)一般有0、1/2、1、2、3、5、8、13、20、40、100、？、咖啡。首先由產(chǎn)品負(fù)責(zé)人對product backlog進行講解，然后由Scrum master負(fù)責(zé)協(xié)調(diào)進行初始評估工作。敏捷估算中不是要估計絕對的時間，而是盡量確保故事之間的相對估計是準(zhǔn)確的。由于估計是相對的，所以需要首先找打 一個基準(zhǔn)，我們可以先找一個不是最小的，也不是最大的來作為一個基準(zhǔn)，可以先找出一個大家認(rèn)為適合分配為2點的故事。在找2點的故事時，很可能會出現(xiàn)大家 意見不一致的情況，這時就需要大家都分別說明自己的見解后再重新找。有了2點基準(zhǔn)后，就可以對每個故事進行評估了，而后面的故事都可以基于以前的故事來進 行相對估計了。在估計過程中，有可能會出現(xiàn)大家對故事理解不一致，這時就需要返回去修改故事，確保大家理解一致。