什麼是 User Story#
User Story 是從使用者的角度，用幾句簡短的話描述使用者需要的功能。Story 不是詳細的需求規格書，而是一個對話的承諾——提醒開發人員和客戶之間還有細節需要討論。
一個 Story 包含三個面向，Ron Jeffries 稱之為 3C：
- Card（卡片）：將 Story 寫在實體卡片或便條紙上，作為提醒
- Conversation（對話）：透過口頭討論來補充 Story 的細節
- Confirmation（確認）：透過驗收測試來確認 Story 是否正確完成
Story 的力量不在於寫下來的文字，而在於它所引發的對話。卡片上的文字只是對話的起點。
Story 的寫法#
Story 通常遵循以下格式：
As a [使用者角色], I want [功能] so that [商業價值].
例如：
- 「A user can search for jobs by location.」
- 「A company can post a new job opening.」
- 「A user can limit who can see her resume.」
不一定要嚴格遵守此格式，重點是簡短且以使用者為中心。
User Story 的流程概覽#
在典型的敏捷專案中，User Story 的使用流程如下：
- 撰寫 Story：客戶與開發人員合作寫出初始的 Story
- 估算：開發人員估算每個 Story 的大小（通常用 Story Point）
- 規劃發布：客戶根據估算和優先順序，選擇 Story 組成發布計畫
- 規劃迭代：團隊選擇本次迭代要完成的 Story，並拆解為具體任務
- 開發與測試：開發人員實作 Story，並以驗收測試確認完成
Story 的規模應適合在一個迭代內完成。太大的 Story（Epic）需要拆分，太小的 Story 可以合併。
與傳統需求方法的差異#
User Story 與傳統的 IEEE 830 軟體需求規格（SRS）有根本性的不同：
| 面向 | 傳統 SRS | User Story |
|---|---|---|
| 溝通方式 | 書面文件 | 口頭對話 |
| 詳細程度 | 預先定義所有細節 | 漸進式補充細節 |
| 撰寫者 | 分析師 | 客戶與開發人員共同撰寫 |
| 生命週期 | 長期維護的文件 | 完成即可丟棄 |
試圖在專案初期就完整定義所有需求是不切實際的。使用者會隨著對軟體的認識加深而改變想法，而這種改變是正常且健康的。