關於使用者故事

關於使用者故事
使用者故事，User Story，這個詞兒來自於敏捷方法Scrum。到底什麼是使用者故事，因為近期重拾Redo一些專案方面和產品方面的工作，來整理整理相關知識。使用者故事與另外幾個概念，如使用者故事切分、使用者故事地圖、用例、場景，都有啥關聯或關係呢。

1、什麼是使用者故事
1.1 使用者故事
使用者故事，User Story。這是一個從屬於產品設計的概念，它所指的，是從使用者的角度來描述使用者需求，要使用使用者可以理解的業務預研來描述、切忌使用技術術語。

意即：

角色：誰
活動：需要做什麼
價值：為什麼
用一句常見格式來描述，即：

As a role, I want goal/desire so that benefit.

或

作為一個“網站管理員”，我想要“統計每天有多少人訪問了我的網站”，以便於“我的贊助商瞭解我的網站會給他們帶來什麼收益。”

使用者故事要點（Ron Jeffries，3C）：

簡述：用卡片（Card）來簡要描述故事。
細節：與Product Owner（或客戶）交談（Conversation）來明確細節。
確認：驗收評審，確認（Confirmation）被正確完成。
1.2 使用者故事切分
故事有大小、長度，如何編寫一個使用者故事、才算得上好的使用者故事？ 
它應該遵循INVEST原則：

獨立性（Independent）：儘可能讓一個使用者故事獨立於其他使用者故事，解除相互依賴性，便於確定優先順序、評估工作量。可以通過組合、分解的方式來達到“獨立性”的目的。
可協商性（Negotiable）：這個使用者故事的內容可以協商，是一個簡短的描述，而具體細節在溝通階段產出，避免過多的細節限制了與使用者的溝通。
有價值（Valuable）：這個使用者故事，必須對客戶具有價值，因此應該站在使用者的角度去編寫，描述的是一個一個的feature，而非一個一個的task。
可以估算性（Estimable）：這個使用者故事，優先順序、工作量、安排計劃，都是可行的，以減少評估上的不確定性。
**短小（Small）：一個好的使用者故事，可評估的工作量要儘量短小，確保在一個迭代週期內可完成。使用者故事越大、風險越大。
可測試性（Testable）：這個使用者故事可以測試以確認是可以完成的，所以必須在定義了驗收測試通過的標準後才能認為故事劃分完畢。
為了保證使用者故事的顆粒度，上面說到了組合、分解的方法，我們也可以靈活應用，目標就是為了讓產出的軟體能夠（Rachel Davies）：

能夠工作
交付價值
能有效地得到使用者的反饋
對於使用者故事切分，不同的前輩也總結出一些更多的進一步的方法可供借鑑。

Richard Lawrence方法：

根據工作流程的步驟來切分故事
讓業務規則中的每種變化都是其自身的故事
切分“實現第一個[x]”，然後“實現其他的[x]”
複雜故事中，將最簡單的版本切分為單獨的故事
通過故事所操作的資料型別來切分
通過簡單資料輸入方法和複雜方法之間的區別來切分故事
當前故事的效能轉移到一個或多個新故事
按照CRUD（建立/讀取/更新/刪除）來切分
Bob Hartman方法：

根據角色來切分
將高風險和低風險的分離
在每個故事上工作的開發者數量最大化
Rachel Davies對於根據輸入/輸出的資料來切分故事的方式提供了一些細節處理方法：

可以為每個輸入頁面建立故事
可以為輸入頁面每個可用元素建立故事
可以建立簡單的UI（簡單≠漂亮）
可以建立一個命令列介面
1.3 使用者故事地圖
當我們開始進行一個產品或者專案規劃的時候，首先需要梳理出一個backlog，在其中按照優先順序列出所要實現的場景和具體功能。

而使用者故事地圖就有這麼一種功效。 
 
 
使用者故事地圖，代表一個完整的使用者故事。其核心是一條從左到右的時間線（橫軸），以及其下的自上而下的必要程度線（縱軸）。

時間線（橫軸，從左到右）

在時間線的上方防止最大粒度的內容（可理解為Epic 史詩，即比較大的User Story）；
在時間線的下方放置二級粒度的內容（可看做backlog item，即待辦列表項）；
在二級粒度內容的下面放置三級粒度的內容（即切分好的使用者故事，可作為User Story Task）。
以上形式可以靈活按照實際產品情況進行削減，去掉Epic、將backlog item移到時間線上面。

必要程度線（縱軸，自上而下）
使用者故事地圖的縱軸，而對於上述的Task（最小使用者故事），按照必要程度、重要程度自上而下往下排列。

通過這種方式的劃分，可以制定backlog及task使用者故事的優先順序，並安排迭代週期、迭代版本及對應任務。

大家一定多多少聽過MVP，即Most Variable Product 最小化可用產品。這個概念，源於《精益創業》（埃裡克·萊斯），有一定了解的朋友一定知道，MVP的目的是以最小的投入釋出對使用者有價值的產品，幫助我們快速試錯，並通過不停的迭代最終找到產品的正確方向。

2、使用者故事與其他相關概念
2.1 用例
Use Case

User Story關注的是業務場景和使用者故事，更傾向於以使用者角度描述響應業務功能的業務價值。使用者故事會比較簡單，重點是把業務需求和場景（或含業務價值/商業價值）說清楚即可。

而Use Case 用例，它包含了有業務用例和系統用例。其用例建模比較複雜，會涉及到業務流程、業務規則、輸入、輸出、介面和互動等等。

使用者故事與用例裡面的業務用例有點類似。但是，使用者故事的粒度往往比用例的粒度更細化，如用例中的基本流、擴充套件流、業務規則都可能轉化為使用者故事（見上面“1.2使用者故事切分”）。

還有一種比較明顯的思維/角色/物件上的區別。使用者故事從產品角度、業務場景看待，重在使用者使用產品的目的/任務/流程/情節等等；而用例面向需求人員和開發人員，重在邏輯、次序。

2.2 場景
Scenario

Scenario 場景，有兩撥人在用，當然，他們所指的含義也不一樣。

互動設計師（如Alan Cooper） 
在RUP（Rational Unified Process）中已有辨析：“場景”在 RUP 內部指用例例項，即只是一個經過可能的基本流和備選流的特定“路徑”（即Cockburn所說的“一個行為序列”）。
需求分析師（如Alistair Cockburn） 
在以使用者為中心的設計方法和使用者介面設計方法中常常將“場景”描述為使用經歷（Cooper就這麼做），這實際上包含了更多的細節，而不僅侷限於事件流。雖然該附加資訊可能與後來的設計階段無關，但它對於瞭解使用者、任務和環境卻必不可少。
因此，場景可以在業務建模工作流程中廣泛應用，但是在需求工作流中，重點則轉移到用例上。

Alistair Cockburn：“使用者故事”相當於“場景”的標題，而“用例”則是多個“場景”內容的集合。
--------------------- 
作者：山書生 
來源：CSDN 
原文：https://blog.csdn.net/taizans/article/details/51698951?utm_source=copy