一步步學敏捷開發：3、如何寫用戶故事

本文是今年1月份參加Agile1001公開課后，並參考《用戶故事與敏捷方法》這本書整理，閱讀全文

一、什么是用戶故事

用戶故事是描述對用戶有價值的功能，好的用戶故事應該包括角色、功能和商業價值三個要素。

用戶故事通常的格式為：作為一個<角色>, 我想要<功能>, 以便於<商業價值>。一個好的用戶故事包括三個要素：

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

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

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

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

英文：As a <Role>, I want to <Activity>, so that <Business Value>.

中文：作為一個<角色>, 我想要<功能>, 以便於<商業價值>

舉例：“作為招聘網站注冊用戶，我想要查看最近3天發布的招聘信息，以便於我看到最新的招聘信息”。

 

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

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

交談（Conversation）：用戶故事背后的細節來源於和客戶或者產品負責人的交流溝通。

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

 

 

二、如何編寫用戶故事

故事應該很清晰地體現對用戶或客戶的價值，最好的做法是讓客戶團隊來編寫故事。客戶團隊應包括能確定軟件最終用戶需求的人，可能包括測試者，產品管理者，真實用戶和交互設計師。因為他們處於描述需求的最佳位置，也因為隨后他們需要和開發者一同設計出故事細節並確定故事優先級。

為了構造好的用戶故事，我們關注六個特征。一個優秀的故事應該具備以下特點：

 

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

  可討論的（Negotiable）：故事卡是功能的簡短描述，細節將在客戶團隊和開發團隊的討論中產生。故事卡的作用是提醒開發人員和客戶進行關於需求的對話，它並不是具體的需求本事。一個用戶故事卡帶有了太多的細節，實際上限制了和用戶的溝通。

  對用戶或客戶有價值的（Valuable）：用戶故事應該很清晰地體現對用戶或客戶的價值，最好的做法是讓客戶編寫故事。一旦一個客戶意識到這是一個用戶故事並不是一個契約而且可以進行協商的時候，他們將非常樂意寫下故事。

   可估算的（Estimable）：開發團隊需要去估計一個用戶故事以便確定優先級，工作量，安排計划。但是讓開發者難以估計故事的問題來自：1.開發人員缺少領域知識；2.開發人員缺少技術知識；3.故事太大了。

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

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

三、怎么拆分故事

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

分割用戶故事：

1. 按照用戶故事所支持數據的邊界來分割大型用戶故事（例如導入GBQ文件、Excel等）。

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

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

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

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

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

四、怎么評定優先級

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

1. 獲取這些功能帶來的經濟價值，價值越高的優先級越高。

2. 開發成本帶來的影響。例如可能2個月后由於使用新技術只需要2周，而現在做需要2個月，這時可以考慮把優先級放低一些。

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

4. 故事之間會存在依賴關系，這時候被依賴的優先級會更高，需要先完成。

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

五、怎么進行初始評估

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

 

五、優秀的用戶故事准則

優秀用戶故事的一些准則：

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

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

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

4.用主動語態編寫故事；

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

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

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

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

本章小結

1、用戶故事是描述對用戶有價值的功能，用戶故事應該包括角色、功能和商業價值三個要素。

2、優秀的故事應該具備六個特征：獨立的、可討論的、 對用戶有價值的、可估算的、小的、可測試的

3、當故事非常大時，我們將很難對它進行估計，有必要進行故事拆分

4、故事優先級評定，最簡單的方法就是問問客戶最希望在下一個迭代中最想看到哪些功能。

5、故事評估一般采用故事點來進行這類初始評估，可以通過撲克牌來進行。