2024/7/27 更新部分內容，把Size of User Story 移到下篇心得，請移步到這裡。
自從決定做 side project 之後，我試著在 Jira 上設定「吃吃記帳」的專案，過程中注意到裡面的 “story” 這個功能。然後，我突然有點困惑，因為發現自己對 user story 的概念有點模糊 — — 我知道它是什麼，怎麼做，但不確定自己做得是否正確。學習這部分已經是好多年前的事情了，所以我決定先停下來，重新複習關於 user story 的概念和使用方法。
搜尋了幾堂線上課後，我選了 Udemy 的這堂課程: User Stories: A Practitioner’s Guide，因為它內容很詳盡，涵蓋了從基礎到進階的所有相關內容，包括最開始的撰寫、到refinement、fit to product等，總長約 2.5 小時。
不過實際上課後，我發現這堂課比我預期的難懂。一部分是因為講者經驗豐富？會從很基礎的理論解說，一下子跳到實施案例的細節；另一部分是因為口音，大概太久沒有聽英式英文了(Warwick的老師對不起!)，很多內容都不在簡報上，光用聽的有點吃力。而且它的字幕是系統自動生成，不是那麼準確。總體而言，雖然內容很精實、很豐富，可是不一定適合所有人。不過已經上了一半，我還是會努力上完的。
為了避免對這個主題有興趣的人和我經歷一樣的痛苦，整理了筆記。內容不全然和課程相同，加上我自己的理解和比喻，重新排序和刪減。如果對內容有任何看法，歡迎留言討論！
因為長度的關係，這是上篇。
過去和現在 - 開發的需求描述
在早期，產品需求描述通常是從公司或系統的角度出發，而不是使用者的角度。通常由Business Analyst（業務分析師）負責蒐集和整理需求，將內容寫成詳細的系統需求規格，然後交給開發團隊。這是瀑布式開發中常見的方法。
傳統方法的缺點是，事情很難在開發前就規劃得盡善盡美，有些需求可能會被漏掉，或是在開發過程中發現需求可以合併或刪除。而且這種描述方式容易忽略使用者的真實觀點，設計出不符合需求的產品。
而現在，隨著敏捷開發的普及，普遍改採用User Story的寫法。它是以終端使用者End User為中心，由Product Owner（產品負責人）在Business Analyst的輔助下，用故事來表述需求。
它有各式各樣的模板，但基本上採用下列格式：
- As a： 身為一個…(使用者的身分描述)
- I want： 我想要…(描述行動或期望)
- So that： 這樣才可以…(達成某個目的)
相比於傳統的方式，User Story更加平易近人、易懂，而且聚焦於實際的使用情境。舉例如下：
- 傳統的需求描述： 當銀行轉帳交易完後，系統要產生轉帳成功通知。
- User Story的描述： (As a) 身為一個薪轉戶的使用者，(I want) 我想要轉帳完成後，可以立刻收到通知，(So that) 這樣我可以即時通知房東，避免產生任何誤會。
User Story 使用者故事的詳細用法
1. As a 的用法 — Who
這裡要聚焦在最終使用者，盡量真實、精確地描述這個角色。如果不確定怎麼寫，可以試著總結使用者的行為和目的。例如，一個替警察工作、需要在資料庫搜尋被偷車輛的人，可以總結為「汽車犯罪調查員」。或是一個每天查看 call center 來電數量的人，也可以總結為「進線量分析師」。
另一個方法是參考 User Personas 來設定使用者。Personas 是基於市場研究和數據的虛構角色，例如「38-40歲想要練出二頭肌的男性單身上班族」，來代表目標用戶群體中的某個特定類型。
不過，在某些情況下，可能會沒有明確的使用者。這個時候可以將系統人格化來思考，例如「作為公司的人資系統，它需要能更好的儲存員工考績資料，這樣才不會每次搜尋都要好幾分鐘」。
如果實在寫不出來，那麼代表Product Owner對使用者並不清楚，應該先進行 user research，再回到這一步驟。
2. I want 的用法 — What
描述使用者的某個行為或動作。要注意的是，盡量避免開放式的敘述。例如「我想要管理我的帳戶」是開放、模糊的說法，是怎麼樣的管理？管理帳戶的哪個部分？
換個說法，「我想要更新自己帳戶的密碼」就是很明確、易懂的表達。越是明確的敘述，越可以幫助團隊找到最佳的解決策略。
3. So that 的用法 — Why
解釋這個行為的目的和益處。這部分的內容很重要，可以避免團隊做出不恰當的設計。例如「我想要更新自己的密碼」，是因為「想保護個人的隱私」，那麼解決方法應該達成安全性的目的，例如綁定生物辨識功能；但假如「我想要更新自己的密碼」是為了「可以和家人共用帳戶」，那綁定個人生物辨識的設計就太不適合了。
如果有時候不知道怎麼寫 So that的內容，可以用 “5 why” 這個方法，詢問使用者五次「為什麼你需要這個」，來了解對方真正的目的和想法。
User Story 沒有絕對最好或最正確的版本，不同的人可能會寫出不同的觀點，只要能夠清楚地描述需求並為團隊所理解即可。
管理 User Stories 的方法：3C 模型
Card（卡片）
簡單來說，就是把每個 User Story 都寫在一張卡片上。它可以是實體卡片，也可以是線上的卡片（例如 Miro 等白板工具）。這樣方便大家移動卡片來進行排序，也方便新增、更新或刪除故事。
Conversation（對話）
寫好卡片後，團隊要進行對話和討論。理想的情況下，整個團隊包含end user代表，一起進行面對面的談話，一張一張的檢查故事卡片，確保每個人都理解故事的內容、細節，和討論可能的解決方法。
這種討論是多次的，在開發前和開發中舉辦，因為隨著時間進展，大家對於故事的看法可能會改變，是當的調整故事可以降低開發的風險，確保產品一直是符合需求的。
討論內容的舉例：
- 這個故事的具體需求是什麼？
- 這個功能為什麼對使用者重要？
- 我們可以如何實現這個故事？
- 實現這個故事需要哪些資源和時間？
- 它可能有哪些風險和挑戰？
Confirmation（確認）
如何確認User Story是否確實完成，達成使用者的目的，非常重要。所以經過討論、釐清後的 user story卡片，應該要包含 Acceptance Criteria。以我的side project 吃吃記帳為例：
User story:
身為一個減肥的人，我想要輸入自己的午餐後，知道自己吃了多少熱量，這樣我才知道自己有沒有達成飲食控制的目標。
Acceptance Criteria:
- 使用者可以輸入食物內容。
- 系統可以計算並顯示食物的總熱量。
- 系統可以告知是否達成飲食控制的目標。
INVEST — 判斷是不是一個好的 User Story
雖然 User story 沒有絕對的答案，但我們還是有方法可以檢查自己寫得好不好、是否思考周全。講者提到了六個準則：
Independent（獨立）
確保每個故事都是獨立的，一個故事不會涵蓋其他功能或系統。例如說，「我希望可以快速登入銀行app查看餘額」這個故事應拆分為「登入app」和「查看餘額」兩個獨立的故事。
Negotiable（可商議）
故事內容應保持彈性，可以討論，避免在故事中提到預設的解決方法。例如，「我希望可以用指紋辨識快速登入銀行app」這個描述就預設了「指紋辨識」這個方法，會影響團隊的判斷。
Valuable（有價值）
故事應該有明確的商業成果（business outcome）和價值。它應該對用戶或業務帶來實際的利益，具備明確的目的。
Estimable（可估量）
故事的大小是可以評估的。這是一個大故事還是小故事？大概需要多少時間和工作量來達成？這些問題都應該可以回答，使故事可排序和計劃。
Small（小）
故事夠小了嗎？是否已經拆分到可以讓團隊立刻開發的功能描述？一個好的User Story應該足夠小，能在一個迭代內完成。
Testable（可測試）
故事有能夠測試、檢驗的標準嗎？團隊對「完成」的定義有共識嗎？每個User Story都應該有清晰的Acceptance Criteria，來確保它可以被測試和驗證。
小結
要開始寫User Story並不困難。我想最好的是先找出一疊便利貼，謹記「我是 — 我想要 — 因為」這個規則，把對產品的想像、理解都寫下來，貼在牆壁或白板上。先做到這一步，就會慢慢有頭緒了！一開始不要在意對不對、寫得好不好，之後會有重新梳理的環節。先把思緒清空最重要。
