如何寫出 User Story

什麼是 User Story?

User Story 是一段簡單的功能敘述，以 客戶或使用者的觀點 撰寫下有價值的功能(functionality/feature)。與其說它是規格文件(documentation)，不如說它代表(represent)客戶的一個需求而已，因為實做細節將延後至開發時才會確定。

幾個 User Stories 的範例如下：

• 使用者可以在網站上張貼履歷
• 使用者可以搜尋有哪些工作
• 公司可以張貼新工作
• 使用者可以限制誰可以看到他的履歷

為什麼要寫 User Story？

User stories 是一種非常好用且容易上手的需求文件，它是一種極簡主義，只要求寫下最有價值不要忘記的東西，而且夠讓我們足以估計時程以及與客戶溝通。
嚴謹、漂亮、詳細的文件有兩大危險，一是製作厲害的文件本身變成了一個目標，而不是製作軟體。二是語言本身是模糊的，”詳細”的文件會造成”確定性的幻覺”，以為規格都確定了無需要溝通，最後做出根本不符合預期的軟體。敏捷開發鼓勵我們將時間多花在開發者、客戶、使用者之間頻繁的溝通，而不是製作文件。

User Stories? Use Case? Scenario?

首先，User Story 不是 Use Case，也不是Scenario。
兩者的在專案中的角色是很接近的，都是用於表達 Requirement 的方式，不應在專案中同時使用。兩者的關注點也不同，就我的理解，User Story 著眼於使用者角度，Use Case 則是從系統面出發。
Use Case 的歷史比較古老，User Story則是2000年左右才被提出並討論。不論是對於技術或非技術出身的人員來說，User Story 相對比較親切，也常被用在敏捷開發流程中。

Use Case 範例

如何寫出User Stories?

首先，了解你的User、定義你的角色（利用Pesonas）

你的產品要面對的，很有可能不只一種角色，舉例來說，就一個校務系統來說，至少就有以下的角色：

• 學生
• 家長
• 老師
• 學校行政人員

每個角色都有不同的使用動機及知識背景，我們要做的第一件事就是讓這些角色躍然紙上，寫出各自的 "Personas" 。可參考以下圖片：

你可能會覺得要煞有其事的為一個虛擬的使用者設定名字和外觀是一件很扯的事情，但是Personas方法有它的優點在：它可以對設計進行有效聚焦，讓我們把精力集中在最有價值的行為模式上，也可以促進團隊中的溝通和交流。很重要的是，它可以讓我們把人物角色當作真正的人來看待（但是請記住，它們不是真正的人），從而更好地站在用戶的角度去思考和體會，讓它們以具體人物的方式來表達使用者的目標和需求。

從角色出發，粗略但簡明的寫出 User Stories .... in Epic!

User Story 有著通用的撰寫格式，通常是寫在便利貼或是紙卡(user story card)上：  

身為一個 {{特定角色}}，我希望能有 {{特定功能}} 以便能讓我 {{得到某種價值}}
As a (role of user), I want (some feature) so that (some business value).

舉例來說：

身為一個 {{學生}}，我希望 {{只有我能查到自己的成績}}，這樣才能 {{知道我的分數又不用讓同學知道}} 

而此階段只要確保 User Story 簡明、直觀即可，也就是 "Epic"。
Epic 也是 User Story，只是他的粒度比較大(Epics are big, coarse-grained user stories)。也就是還有被分割、拆解的空間。

拆解Epic，成為可執行的 Ready User Stories

Epic 還無法被視為一個清楚可執行的 Task，需要再被拆解、細分為 Ready User Story。
但是到底要拆到怎樣的地步才算是 "Ready" 呢？我們可以用以下三個原則去評估他：

1. 明確
2. 可執行
3. 可測試

基於以上原則所拆分出來的User Story不應太大，且應能顯而易見的被判定「是否被完成」，不會有灰色地帶！ ( there has to be an effective way to determine if the story is done)

加入驗收標準 (acceptance Criteria)

當 Ready Story 被訂定出來後，開發人員還是可能會面臨到一個問題：「我怎麼知道這個功能怎樣叫做『完成』？」
這時候就要翻到 Ready Story 卡片的背後，寫下更明確的 "驗收標準"。有了這些準則，程式設計師就可以知道客戶會做哪些驗收測試、期望跟假設。例如：會有哪些資料會被輸入、使用者輸入之後期望看到什麼、任何其他潛在的商業邏輯? 有什麼可能的邊際條件出錯需要處理?

用有效率的工具或平台管理這些Story

不論是用紙本或是線上平台管理，PO要盡量讓這些 Story 能夠被所有團隊成員看到

後記：

其實 Ihower 的文章已經把 User Story 講得很好了，只是看完以後還是沒有 Step-by-Step的感覺，於是又找了這篇文章，從裡面的內容再延伸資訊的收集方向。這兩篇文章一篇是從技術的角度出發，一篇是從UX的角度出發，有時間不妨都看看，相信會有很大幫助。
另外，在Ihower的文章中有一段我特別想節錄出來，對於像我這種技術出身的開發者來說特別重要：

1. 一條 User Story 可以包含多個實作 Tasks 任務。User story 不會有任何技術細節(可以給 manager 看的)，但我們會在 Task 裡描述技術細節(會給 programmer 看的)
2. 每次 Iteration 開始時，才由 Architect 根據 Stories 拆成 Tasks 分配給 programmer, tester 甚至是 art。
3. 一條 User story 如果對應到一條 Ticket，對於 programmer 來說，粒度有時候太大了，而且一條 User story 很可能包含多個實作者，例如實作 Model、實作 Controller、美術設計、套版和整合測試。

Reference:

1. 10 Tips for Writing Good User Stories
2. User Stories (1) 什麼是 User Story?
3. From Personas to User Stories
4. 關於人物角色(Personas)和使用者研究
5. User Stories: An Agile Introduction
6. User Stories - by Mountain Goat Software
7. ATDD - Acceptance Testing