什么是用戶故事?例子，優點和缺點

用戶故事的定義

用戶故事是從最終用戶的角度對軟件需求的格式良好、簡短且簡單的描述，以非正式和自然的語言編寫。它是敏捷軟件開發過程中用於捕獲用戶需求的主要工件。

用戶故事由產品經理或團隊成員代表最終用戶編寫，解釋正在開發的系統的預期功能。編寫用戶故事是為了按照預定義的模板捕捉需求中最重要的元素。

用戶在編寫用戶故事時應牢記以下敏捷原則。

1. 可工作的軟件是進度的主要衡量標准。

2. 最優先考慮的是通過早期和持續交付有價值的軟件來滿足客戶。

3. 簡單。

高質量的用戶故事不僅可以幫助項目團隊清晰准確地了解客戶需求，還可以讓項目估算和開發過程更加高效。

用戶故事有什么用？

用戶故事被用作在敏捷開發框架（例如 Scrum 和極限編程 (XP)）中捕獲高級需求的主要方式。

在敏捷 Scrum 框架中，產品待辦列表中的項目被寫為用戶故事，因為它有助於項目團隊和產品負責人從客戶的角度關注需求。

在極限編程 (XP) 中，用戶故事被用作產品驗收的標准。XP 開發人員利用用戶故事編寫驗收測試，這些測試甚至在產品代碼創建之前就已完成。這種方法可以節省時間並確保項目代碼符合客戶的驗收標准。用戶故事還用於創建 XP 框架中發布計划會議的估計。

用戶故事的歷史

用戶故事的最初想法是由 Alistair Cockburn 博士在 90 年代后期提出的。從那時起，用戶故事的使用方式已經由多個從業者開發，即：

• 2001 年，Ron Jeffrey 提出了用戶故事的 “三個 C” 公式。每個 C 分別代表: 卡片 (Card)、談話 (Conversation) 和確認 (Confirmation)。

• 2004 年，Mike Cohn 出版了《User Stories Applied For Agile Software Development》一書，概括了用戶故事原則。

• 2014 年，Jeff Patton 和 Peter Economy 出版了《用戶故事映射：發現整個故事，構建正確的產品》一書，介紹了一套新的技術來識別、構建用戶故事並提供更多可見性。

用戶故事示例

這些是一些使用不同模板編寫的用戶故事示例，敏捷開發團隊采用這些模板來捕獲他們的需求。

模板：作為<角色>我可以<能力>，這樣<獲得利益>

1. 作為經理，我希望能夠查看正在進行的工作的狀態，以便我可以計划何時將其交付給高級領導。
2. 作為用戶, 要支將新朋友添加到我的個人資料中，我應該能夠向其他用戶發送好友請求。
3. 作為關注者，我希望能夠在博客上發表評論，以便我收到作者的反饋。

4、基於五W模型的用戶故事模板

模板：作為<who> <when> <where>，我<want> 因為<why>

示例：作為軟件測試人員，當我以每個開發人員的名義記錄缺陷時，我希望他們每個人都收到通知，因為這樣開發人員就會知道我記錄的缺陷。

使用用戶故事的優勢

一個結構良好的用戶故事可以通過以下方式使軟件開發過程受益：

• 它有助於闡明精確的用戶需求：用戶故事只有在一個句子中包含關鍵元素（例如用戶的角色、能力、願望和目標）時才能成功。將這些元素清楚地表達出來，使它們對整個產品團隊更加精確，確保開發始終專注於最終用戶的需求。

• 更好的協作：用戶故事有助於讓所有關鍵利益相關者不僅關注正在開發的內容，還關注開發原因。  

• 能夠降低項目風險：從本質上講，用戶故事是產品團隊以用戶為中心的工具。這有助於確保盡早發現疏忽和范圍蔓延。

使用用戶故事的缺點

這些是敏捷開發團隊在使用用戶故事來捕獲需求時所面臨的一些問題。

• 較少關注非功能需求 (non-functional requirments)：用戶故事主要關注捕獲功能需求（即最終用戶如何直接與系統交互）。非功能性需求，例如性能、容錯性、可用性、耐用性、可修改性等，可能無法通過典型的用戶故事模板清楚地或根本無法捕獲。

• 難以為更大和更復雜的項目擴展：用戶故事的格式是專注於單一功能的簡單格式。隨着項目變得越來越復雜，這些有時很難擴大規模。

• 產生模糊或不完整的需求：由於用戶故事是用非正式的、更自然的語言編寫的，工程師可能無法處理這些需求。然而，這可以通過如何編寫出色的用戶故事的適當培訓來克服。