這篇是User Story系列的最後一篇，用我自己的side project 吃吃記帳來練習User Stories: A Practitioner’s Guide這堂Udemy課程中的內容。課程筆記可以參考這兩篇：
課程筆記: User Stories: A Practitioner’s Guide(上)
課程筆記: User Stories: A Practitioner’s Guide(下)
我的理解是，撰寫使用者故事沒有絕對的步驟，可以根據產品和團隊的需要做調整，因此這篇的步驟，只是我個人的方法唷！
第一步：設定Persona
我在第一篇筆記中，提到了User Story的基本格式：「As a… I want…so that…」，也就是角色 + 需求 + 目的。為了更好地理解 「As a」 的這個角色，我決定先設定 Persona。
一般來說，Persona 是基於市場調查或使用者訪談來建立的。由於這是個人的 side project，沒有進行真實的市場調查，因此我決定捏造一個想像的使用者。參考身邊的幾個朋友和同事，捏出了米米這個角色。
順帶一提，Persona 的內容可以非常詳細，但我們可以根據產品需求，決定是否需要包含某些資訊或欄位。例如說，是否要記錄使用者的婚姻情況、種族、信仰、居住地區等等。在幾番考慮之後，我記錄了以下資訊：
我的產品Persona
- 姓名：米米
- 年齡：38 歲
- 職業：線上銷售業務
- 居住地點：台灣
- 收入水平：中等收入生活習慣：工作時間長，壓力大，常常外食，經常熬夜。早餐很少吃，午餐大多是叫外送，晚上偶爾有聚餐。有時候會慢跑，大概一週一次。
- 興趣愛好：看電影，追劇。
- 科技水平：高，熟悉各類科技產品和應用。
- 主要目標：吃得更健康均衡，改善整體的健康。
- 需求：一個可以方便記錄飲食、提供飲食建議、並且能夠溫柔陪伴的服務。
- 動機：最近一次的健康檢查結果不理想，體脂肪過高，有輕度脂肪肝。
對現在的體態不滿意，小腹越來越凸。經常感到疲倦，尤其是吃完大餐後，容易昏昏欲睡，精力不濟。 - 痛點：
- 工作忙碌，無法花太多時間紀錄飲食；
- 外食居多，難以計算食物的熱量和份量；
- 對飲食控制缺乏信心，使用過多個app和服務，都無法持續；
- 因工作壓力，經常有暴飲暴食的衝動，偏愛重口味食物。 - 期望：
- 希望工具簡單好用，界面不浮誇，不希望紀錄飲食時引起他人注意。
- 希望產品能夠天天使用，成為生活習慣的一部分。
- 希望價格適中，不要太過昂貴。
其實我覺得職業、興趣愛好不一定和產品有關係，但保留這兩個欄位，可以讓米米這個角色更真實。還有我決定不指定性別，以便米米能代表任何人。
寫Persona的疑惑
在填寫Persona內容時，我有點困惑，因為許多欄位的內容似乎重複，不確定應該寫什麼好。在反覆跟AI討論後，這是它給出的建議：
- 主要目標 是「使用者最終想達到的結果」。
- 需求 是「需要哪些具體功能來幫助使用者達到目標」。
- 動機 是「驅使使用者採取行動的原因或背景」。
- 期望 是「使用者對使用過程中的具體要求或標準」。
特別是需求和期望的辨別，需求是使用者希望解決問題所需要的功能或服務。例如說，米米需要一個可以方便記錄飲食的工具，因為這是他實現「吃得更健康」目標的必需品。
期望是使用者對使用體驗的期望。這可能包括產品的易用性、價格、隱私性等細節。例如，米米希望工具的使用過程簡單，最好不引人注意，且費用合適，這樣他才能長期使用。
透過這樣釐清，我更清楚Persona該怎麼寫了。那麼接下來就根據米米這個人物，來進行使用者故事的撰寫。
第二步：撰寫最初的使用者故事
有了米米這個角色，再搭配最開始的我的 Side Project：吃吃記帳的靈感與計畫一文的內容，我寫了九個使用者故事。
根據第一篇筆記提到的3C理論，每個故事最好都寫成卡片，所以我選了Miro這個工具來當白板，因為我很喜歡它便利貼的格式，可以輕鬆地挪動修改，也可以與團隊協作。它本身也有User story map的模板可以套用，不過為了保持簡單，我用的是空白的版本。
最初寫的九個使用者故事看起來有些粗糙，不過，就像課程建議的，不要想太多，先寫再說！如果有需要，隨時都可以回來新增和刪減故事，像是隔了幾天後我決定新增「鑑別超加工食物」的故事。
第三步：拆分使用者故事
接下來，我要在故事中選一個最重要、最能代表產品的，開始拆分。我選擇從這個故事開始：「身為使用者，我需要可以輕鬆地記錄自己每一天吃的內容，沒有太複雜的操作，這樣可以降低我使用的阻力」。因為這個故事包含我最在意的產品特色：簡單的操作、紀錄飲食。
如同筆記所說，先找出最大且呈現核心價值的故事，做為Epic，再拆出主要的功能Features，然後拆到可以直接開發的底層故事。最後的結果如下：
很推薦在拆故事的過程中和 AI 討論，這能有效幫助濃縮、提煉想法和文字。一開始我有五個 Features，但最後縮減為三個，讓整體更清晰。
拆使用者故事的疑惑
在練習拆分的過程中，我也有一些疑問，下面是我找到的答案：
- 在描述Feature和User stories這個層級的時候，我們不用再描述一次As a… I want…so that…」這種格式嗎?
當進入 User Stories 的拆分階段後，確實不再需要每個故事都使用『身為…我想要…所以』的格式。這種格式主要用在 Epic 和高階的 Features 上，幫助從使用者角度清晰描述需求。而在具體的 User Stories 階段，則可以直接描述具體的任務和功能。
2. 在拆完第一個故事後，我發現已經有很多工作可以開始，那我是否需要等到所有故事都拆完，才能開始行動嗎？
不需要全部故事拆完才能開始行動。一旦將部分 User Stories 拆解完成，就可以將這些故事放入 backlog 中，並開始開發和測試。這樣可以逐步推進專案，不必等待所有細節都確認後才開始。這樣可以隨時根據優先順序和需求，調整開發流程。
最後，如第二篇筆記所說，我在某些故事上標註了『第一階段』，這是為了決定哪些故事可以歸入最小可行性產品(MVP)範圍。比如，我認為『文字記錄』是最核心的功能，雖然它不是最方便，但它是最可靠的，因為照相和語音輸入可能會有誤差。因此，我將它歸類為第一階段要完成的故事。
第四步：將故事放到Jira上
我最開始想要複習使用者概念，就是因為在把專案放到Jira上時，有點困惑自己做的對不對。這次釐清概念後，我決定重開一個Project，並將內容填入，結果如下：
我將第一個故事放入 Epic，命名為『輕鬆記錄飲食』，並依序輸入其餘故事。對於 Feature 的呈現，因為Jira本身沒有這個層級設定，我決定用 Label 來標示。另一種可能的做法是將 Issue 設定為 Feature，然後用 child issue 來表示子故事。
手動輸入每個故事確實有些麻煩，不過AI提到在某些情境下，可以使用其他工具來批量處理，或者直接匯入白板內容到 Jira 中。或是有的時候在故事討論階段，團隊成員可以邊討論邊寫，就比較不會感覺枯燥重複了。
心得：用使用者故事重製Backlog的安心感
這只是我的初步心得 — — 我感覺自己安心了很多！
下圖是我最初的 Jira 內容，當時寫了很多東西，但心裡還是有點茫然，不確定自己是否涵蓋了所有想要的功能？以及該從哪裡開始做？
有了使用者故事的輔助，我對功能需求和範圍更加有信心，並且清楚當需求變化時，我該如何處理 — — 回去修正故事，再調整 backlog 的內容。同時，我也更清楚開發的優先順序。
最棒的是，我感覺自己對專案更了解，更知道怎麼和其他人解釋。後續，如果有新的看法，會再更新!
接下來，我打算寫另外一篇文章，使用 Customer Journey Map 來比較現行的飲食 app 與我的產品之間的差異。如果在過程中有發現新的使用者故事，也會持續更新Miro白板的內容。
謝謝你看到這裡，敬請期待下一篇文章！
