使用者故事的層次和使用者故事地圖
經過上一篇的學習，你對使用者故事有了一個大概的了解了嗎？使用者故事這個東西，是需要多多練習的，并且最好是有經驗的 Scrum Master 能夠帶着你一起學習并建立合适的使用者故事應用到實際的項目開發中。
對于使用者故事來說，我們還有一個層次的概念以及使用者故事地圖的概念，這兩個是我們今天需要了解的内容。不用太擔心，今天的内容還是比較簡單易懂的。
故事層次
一個完整的大項目往往是複雜的，而且大量的工作是難以準确預估的。是以，我們的靈活團隊需要将這些故事拆分成為更小的故事，直到可以準确地估算和建構這些工作内容。雖說在靈活中，使用者故事是非常出名的一種需求記錄與規劃工具，但其實他在靈活的整體需求中是處于中間位置的。
一般我們會将使用者的大概念設定為特性，然後通過對特性的分析來建立使用者故事，之後在沖刺計劃會議上，我們确定了這次沖刺的使用者故事之後，就會由具體的開發人員将使用者故事再次分解為任務。是以，使用者故事一般就是在中間層級。除了普通的使用者故事之外，上篇文章中我們還提到過一個概念，那就是史詩。那麼史詩故事應該在什麼地方呢？
很抱歉，對于靈活來說，還沒有一個規範是特别聲明史詩的，甚至史詩的定義其實都是非常模糊的。我們認為史詩可以是一組故事的超集，也可以完全用來替換特性。當然，它也可以在特性之下或者位于特性之上。這個選擇完全是根據團隊以及項目的情況來定的，并沒有統一的規範，甚至像上面的那張圖一樣沒有史詩也是可以的。
使用者故事地圖
既然是地圖，那很明顯的就是一張非常大的使用者故事闆，把所有的待開發的使用者故事羅列在上面。我們可以根據使用者的重要性、優先級以及子產品的切分等進行橫縱向的排列。最終的目的就是能夠完整地讓一個使用者通過故事地圖來完成一次産品體驗。就像我們根據地圖找尋目的地一樣，使用者故事地圖也是類似的概念。
使用者的産品體驗有時候僅靠想象是很難驗證的，通過使用者故事地圖，就可以直覺地展現這些資訊，并且可以想象單獨的使用者故事是一堆散亂的枝葉，我們通過故事間的邏輯關系将這些樹葉連接配接起來形成一顆完整的故事樹。就像我們之前講的 修剪産品樹 一樣，不過地圖會比樹更全面，因為它還有一層邏輯導向的能力，就像上圖中的箭頭指向一樣。
一個子產品下的内容我們也很容易地轉換成一次釋出計劃。這也是使用者故事地圖的一大亮點。子產品内容的使用者故事我們可以在一次或多次替代之後完成，形成一個可釋出版本。然後釋出之後再将地圖前進到下一個故事子產品中。
使用者故事地圖的好處包括：
- 更容易看清 Backlog 的全貌
- 為待辦事項清單和優先級排序提供更好的工具，幫助做出決策
- 便于使用靜默頭腦風暴和其它協作方式來産生使用者故事
- 幫助開發人員更好地進行疊代增量式開發，同時確定早期的釋出可以驗證整體的架構和解決方案
- 為傳統的項目計劃提供了一個更好的替代工具
- 有助于激發讨論和管理項目範圍
- 允許從多個次元進行項目規劃，并確定不同的想法都可以得到考慮和探讨
- 幫助回憶具體細節
- 預防資訊蒸發
對于使用者故事地圖來說，内容比較多，使用大白闆都不一定裝得下，是以更推薦使用電腦繪圖。比如說下面這個我做過的練習。
圖檔比較大，如果大家看不清楚的話可以到 Github 上檢視原圖。這個使用者故事地圖是包含釋出計劃路線圖的，是我在學習一個線上項目管理課程時的作業，并且獲得了優的成績。可能離真實的業務開發還有一定的差距，不過也是具有一些參考價值的。
梳理待開發項
最後再簡單地介紹下我們待開發項的梳理過程，其實也就是我們在 沖刺計劃會議 時要進行的工作。主要就是對納入到這一次沖刺的使用者故事進行細化，拆分任務，優先級排序以及測試要點的分析等。具體要進行以下事項：
- PO 和團隊一起讨論使用者故事的背景、業務目标、使用者角色、場景、業務流程、規則等，保證團隊了解充分。
- PO 和團隊一起讨論界面和互動流程，輸出線框圖或者原型圖。
- PO 和團隊讨論使用者故事的測試要點、技術實作方案、可能存在的技術風險，必須輸出測試要點，這個測試要點其實也就是我們常說的驗收标準。PO 可以與一位資深測試人員讨論和整理出要點，也可以與整個團隊交流使用者故事中的測試要點，最後也可以由團隊來讨論初步的實作方案、技術風險。不過要注意，應該先準備好測試要點，避免從0開始讨論，另外現在讨論的還隻是初步的估算和技術風險的評估，詳細的内容需要在沖刺開發時再讨論。
- 團隊估算出使用者故事的規模（故事點數），對于過大的使用者故事要拆分成小的。初始的估算由 PO 和 SM 進行，再由 SM 與開發人員進行估算，并組織測試人員估算測試規模，最後集中整合。這個時候的估算不需要團隊全體人員參與，應該是 SM 為主并由少數核心人員一起進行。
- PO 對使用者故事排列優先級。優先級隻需要 PO 決定即可，其他人的意見應該在前期就提出，在這裡 PO 是做最後的彙總決定。
總結
對于使用者故事來說，其實對于我們這些剛接觸的同學，怎麼寫好故事更為關鍵。不過如果是在已經有良好實踐的團隊中，使用者故事地圖的作用明顯非常強大。它可以起到一個全覽總局的效果，也能夠讓我們很清楚地看到産品的整個業務流程是如何走下去。此外，在 沖刺計劃會議 中，我們到底要怎麼處理使用者故事也給出了具體的建議，可沒有放大家鴿子吧，畢竟這些東西寫在 Scrum 裡就太長了。
參考文檔：
《某教育訓練機構教材》