用戶故事是一種捕捉早期需求的強大技術。用戶故事捕捉了需求的 WHO、WHAT 和 WHY，這讓每個人都能更容易地儘早達成共識。然而，像其他需求一樣編寫用戶故事需要了解一個好的用戶故事的特徵是什麼。
那麼，我們如何才能寫出有效的用戶故事呢？在開始之前，讓我們先了解用戶故事的基礎知識。
用戶故事是一種從外部用戶角度表示軟件系統的功能或用戶需求的流行格式。該格式包含三個關鍵元素，如下所示：
作為 <用戶角色>
我想要 <做某事>
以便我可以 <實現某個目標>
用戶角色代表一種用戶類型（而不是單個用戶）。需求是從這個用戶角色的角度提出的—— **<做某事>。**用戶故事的第三部分是行動的目的。
用戶故事不僅代表系統功能/要求，還解釋了為什麼要這樣做？
讓我們舉一個簡單的例子來更好地理解用戶故事的基礎知識。一位客戶希望獲得一個用於預訂機票的旅行門戶。此門戶的要求之一是為商務旅客搜索機票。此案例的用戶故事可以如下所示：
作為 <用戶>，
我想 <根據我的日程安排搜索機票>
這樣我就可以 <這樣我就可以參加商務會議>
用戶故事的好處是每個利益相關者（客戶和開發人員）都對需求有一個完整的了解。
讓我們舉一個簡單的例子來更好地理解用戶故事的基礎知識。一位客戶希望獲得一個用於預訂機票的旅行門戶。此門戶的要求之一是為商務旅客搜索機票。此案例的用戶故事可以如下所示：
作為 <用戶>，
我想 <根據我的日程安排搜索機票>
這樣我就可以 <這樣我就可以參加商務會議>
用戶故事的好處是每個利益相關者（客戶和開發人員）都對需求有一個完整的了解。
好的用戶故事有哪些特點？編寫好的用戶故事對於項目的成功至關重要。INVEST 代表了一個好的用戶故事的特徵，如下所述：
除了 INVEST 原則，在編寫用戶故事時還應該考慮一些重要的點：
產品通常由數百個需求描述，這些需求組織在產品待辦事項列表中。主題或史詩無法在一個 sprint 中完成，因此它們被分解為更多的用戶故事，然後是一組相關的任務。史詩然後以發行版的形式交付。但即使是來自不同史詩的小用戶故事也可以有一些共同點。這樣一組用戶故事稱為主題。
您是否曾經對敏捷開發中的主題（或功能）或史詩等術語的使用感到困惑？新人可能不知道有什麼區別，甚至會導致錯誤。
Scrum 沒有“故事”、“史詩”等。Scrum 有產品待辦列表項 (PBI)，它們通常按優先級排序、拆分和細化為史詩、用戶故事、技術任務、峰值和錯誤。待辦事項整理過程中的時間方式。
主題提供了一種方便的方式來表明一組相關的史詩具有一些共同點，例如位於同一功能區域。通過為主題分配財務價值，管理人員可以確保交付最高價值，並且項目/計劃與其目標和組織的戰略方向保持一致。
Epic 可用作大型需求的佔位符。它可能不適合衝刺，應該分解成故事。史詩通常在最初的產品路線圖中定義，並隨著了解的更多而分解為產品待辦列表中的故事，通常以用戶故事格式編寫。史詩中分解的故事具有共同的目標和特定的結果或高級用戶需求或某人使用服務的旅程或過程的一部分。
用戶故事是敏捷中用戶功能的最小單位，可以在一個敏捷衝刺中交付。它們通常使用故事點進行估計，並使用 INVEST 標准進行定義。用戶故事應該向客戶提供一個垂直的功能切片，這些功能在迭代結束時是有價值的和完整的。用戶故事必須為用戶提供特定的價值，並且必須可以用簡單的語言描述，概述所需的結果。
任務是故事的分解部分，涉及故事將如何完成。如果需要，可以估計任務時間。任務通常由從事工作的人員（開發人員、QA 等）定義，而故事和史詩通常由客戶或產品所有者代表客戶創建。因此，任務不再需要業務用戶可以理解，因此可以是高度技術性的。將故事分解為任務的過程也有助於開發團隊更好地了解需要完成的工作。
通過 Jeff Patton 和其他人的努力，用戶故事地圖正在成為一種流行的用戶故事管理技術。用戶故事工具允許您通過將用戶需求細分為用戶活動、用戶任務、史詩和用戶故事，為產品待辦事項建立多個級別和維度。通常，敏捷開發團隊在協作會議中使用故事地圖來確定最終用戶想要實現的預期結果。
Visual Paradigm 的故事地圖支持 3 或 4 級層次結構 的需求收集，適用於復雜、中等或簡單的項目。故事地圖從從不同來源（即用例、BPMN、WBS 甚至思維導圖）接收到的用戶特徵的集合開始進入故事地圖的待辦事項，這些用戶特徵將被實現為用戶活動並成為相關的行走骨架（用戶任務）。這些任務可以進一步分解為史詩，然後是軟件開發的用戶故事。
中型項目的三層故事地圖
3 級故事地圖涉及三個部分：活動 > 任務 > 故事（默認）
4級故事地圖將史詩添加到3級地圖中：活動>任務>史詩>故事（可配置為）
warren2lynch
iThome鐵人賽
看影片追技術