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

時間 2019-11-12

標籤步步敏捷開發如何用戶故事简体版

原文原文鏈接

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

1、什麼是用戶故事

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

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

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）：經過驗收測試確認用戶故事被正確完成。

2、如何編寫用戶故事

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

爲了構造好的用戶故事，咱們關注六個特徵。一個優秀的故事應該具有如下特色：

 獨立的（Independent）：咱們要儘可能避免故事間的相互依賴。在對故事排列優先級時，或者使用故事作計劃時，故事間的相互依賴會致使工做量估算變得更加困難。一般咱們能夠經過兩種方法來減小依賴性：1.將相互依賴的故事合併成一個大的、獨立的故事；2.用一個不一樣的方式去分割故事。

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

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

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

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

 可測試的（Testable）：故事必須是可測試的。成功經過測試能夠證實開發人員正確地實現了故事。若是一個用戶故事不可以測試，那麼你就沒法知道它何時能夠完成。一個不可測試的用戶故事例子：用戶必須以爲軟件很好用。

3、怎麼拆分故事

當故事很是大時，咱們將很難對它進行估計。若是故事預計在N次迭代後才進行，那麼大的故事很正常。但若是估計預計在接下來的迭代中進行，那麼咱們就可能會對大的故事進行拆分。很大的故事基本上都能進行拆分，只要肯定每一個小故事均可以交付業務價值就行。注意在這裏不要把故事拆分到任務，故事是能夠交付的東西，是產品負責人所關心的，而任務是不可交付的東西，產品負責人對它並不關心，任務是在sprint計劃會議上拆分的。測試

分割用戶故事：網站

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

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

3. 按照操做邊界分割，把大型用戶故事分割成獨立的創建、讀取、更新和刪除操做（例如預算二次導入，或者新增時須要嚮導、規則而比較複雜時也能夠單獨成一個故事來描述）。設計

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

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

在拆分故事時，咱們有時也須要考慮組合故事的場景，如把bug列入產品backlog時，能夠把多個相似的bug組合成一個故事。

4、怎麼評定優先級

最簡單的方法就是問問客戶最但願在下一個迭代中最想看到的是哪一些功能。從考慮的因素來看，咱們能夠從如下4個因素來考慮：

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

2. 開發成本帶來的影響。例如可能2個月後因爲使用新技術只須要2周，而如今作須要2個月，這時能夠考慮把優先級放低一些。

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

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

5. 開發這些功能所減小的風險。在開發過程當中，會出現進度風險、成本風險、技術風險等，對於風險越高價值越大的咱們須要首先處理，對風險高價值低的要儘可能避免，能夠經過如下圖查看肯定功能優先級時綜合考慮風險和價值的關係。

5、怎麼進行初始評估

對每一個故事進行初始估計後就能夠知道項目的規模。通常採用故事點來進行這類初始評估，能夠經過撲克牌來進行，撲克牌點數通常有0、1/二、一、二、三、五、八、1三、20、40、100、？、咖啡。首先由產品負責人對product backlog進行講解，而後由Scrum master負責協調進行初始評估工做。敏捷估算中不是要估計絕對的時間，而是儘可能確保故事之間的相對估計是準確的。因爲估計是相對的，因此須要首先找打一個基準，咱們能夠先找一個不是最小的，也不是最大的來做爲一個基準，能夠先找出一個你們認爲適合分配爲2點的故事。在找2點的故事時，極可能會出現你們意見不一致的狀況，這時就須要你們都分別說明本身的看法後再從新找。有了2點基準後，就能夠對每一個故事進行評估了，然後面的故事均可以基於之前的故事來進行相對估計了。在估計過程當中，有可能會出現你們對故事理解不一致，這時就須要返回去修改故事，確保你們理解一致。