---
# System prepended metadata

title: User Story Mapping Notes

---

# User Story Mapping Notes

## 介紹

### 什麼是使用者故事

使用者故事描述了對使用者、系統或軟體購買者有價值的功能。用以使用者在使用產品時，組織起會遇到的大小故事之間的脈絡關係。由三個面相組成

1. 卡片：一份書面的故事描述，用來做計劃
2. 對話：有關故事的對話，用於具體化故事細節
3. 確認：測試，用於表達和和編檔故事細節且可用於確定故事何時完成
![](https://i.imgur.com/pI52VMZ.png)


### 細節在哪裏

> 身為使用者，我可以出料

其中的細節，如
- 誰可以出料?
- 出料的需要顯示的資訊有哪些?
- 出料的檢查條件有哪些?

很明顯故事太大太模糊，裡面蘊含的細節太多。

多個小故事遠勝於一個大故事，大故事稱為 Epic，可再切割為小故事。

攤開整理大小故事的對應關係，以便釐清整個故事的脈絡。

> 身為作業員，我可以搜尋場內的 Joblist 清單，以便進行出料作業
> 身為作業員，我可以開始進行一筆 Joblist 出料作業。
> 身為作業員，我可以瀏覽一筆 Joblist 的 Output data 清單。
> 身為作業員，我可以掃料完成一筆 Output data 出料。
> 身為作業員，我可以放下做一半的出料作業。

故事不需要被切太細，足夠覆蓋每個細節的寫法就好，太細的細節請把重點放在討論。

故事不具有契約性質，是開發者與客戶討論用的。達成的協議可藉由測試的形式來記錄。

### 必須多長時間「完成」

蒐集有多少時間、資源、人力的資訊，並共識都認可的「完成」定義。更多的細節可先寫在卡片背面或另外補充描述。

> Joblist 查詢條件，試試 Line, Joblist type
> Joblist 查詢結果，限尚未被領取的 Joblist
> Joblist 顯示資訊 line, mcno, face, mo, jobListType, outPutUser

測試描述的目的是傳遞故事的附加資訊，以便開發人員了解客戶的期望，並能知道什麼時候算是完成客戶需要的功能。
- 在寫程式前先寫測試
- 測試是過程的一部份
- 多少測試才足夠

更多內容請見 [驗收測試案例](https://hackmd.io/gmxt5pA7QfO42yRFEnDsTA)

### 客戶團隊

客戶團隊職責包含確保系統滿足使用者的需求、排列故事優先級。包含使用者、產品經理、銷售員、客服員、測試員、互動設計師。

### 使用故事的過程是怎麼樣的

從傳統的瀑布流開發流程，使用者和客戶只在開始和最後驗收產品才出現，從蒐集需求後到驗收之間幾乎都不參與。現今已知這種方法非常難行通。

以故事驅動的專案而言，客戶與使用者全程參與。在每次疊代開始前，可以修正故事開發計畫，並在疊代結束後，依照開發速率調整故事增量的多寡。

由客戶團隊主責撰寫故事的好處
1. 用商業術語來寫，以利安排工作優先級
2. 以產品的構想者角度，最適合描述產品的行為

### 規劃發布與疊代

在多個循環疊代中，力求專案疊代時程表與預期功能數量之間到達平衡。

客戶排優先順序，最大化客戶組織利益最大化：
1. 大部分使用者和客戶對特定功能的渴望程度
2. 小部分重要的使用者和客戶對特定功能的渴望程度
3. 故事之間的關聯程度
4. 開發技術風險的考量、成本點數估算

在故事的優先級上，開發團隊可能與客戶團隊意見不同。可能基於技術的風險程度的考量，或者是某個故事與其他故事互補，而建議改變故事的優先級。

客戶團隊應該傾聽開發團隊的觀點，隨後調整排序時，應該堅持客戶組織利益最大化的原則。

排列故事時也須考慮實現的成本。

註. 詳細的疊代與故事點數估算，請查閱 Scrum

### 動手做做看

3-5 人一組討論 10 分鐘，把便利貼貼在牆壁上。

結束後，組間輪流分享。

> 題目
> 小新是個 5 歲的小朋友，你身為他的父母，要如何督促小新，完成每天上下學應該做的事情。
> 1. 小新從早上起床，到踏入幼兒園的過程故事。
> 2. 小新從下午幼兒園放學，到上床睡覺的過程故事。

### 為什麼要改變 - 使用者故事的優勢

- 強調口頭溝通
- 容易理解
- 大小適合做計劃
- 鼓勵延遲細節
- 支持隨機應變的開發
- 鼓勵參與性設計
- 傳遞隱性知識

### 使用者故事不足之處

大型團隊與專案難以追蹤成千上萬的使用者故事，往往需要額外的文件實現可追蹤性。隱性知識傳遞難以單靠這種交流來有效的擴展與維護。

## 撰寫使用者故事

> 完整格式: As a [type of user], I want [some goal or objective] so that [benefit/value]
- 獨立的
- 可討論的
- 對使用者或客戶有價值的
- 可估計的
- 小的
- 分割故事
- 合併故事
- 可測試的
- 開發團隊職責
- 客戶團隊職責
- 問題舉例練習：判斷故事好壞並說明理由

## 使用者角色建模

- 整理最初版的角色清單
- 整合與提煉角色

## 蒐集故事的方法

- 使用者訪談
- 問卷調查
- 觀察
- 工作坊

## 優秀的使用者故事準則

- 從目標故事開始
- 切蛋糕
- 撰寫封閉的故事
- 卡片約束
- 根據實際時間來確定故事規模
- 不要過早進入使用者介面
- 有些需求不是故事
- 故事裡包括使用者角色
- 只為一個使用者撰寫
- 以主動語句撰寫
- 由客戶團隊撰寫
- 向故事卡片編號說不
- 不要忘記使用故事的意圖
- 問題舉例練習

## 使用者故事壞味道

- 故事太小
- 故事相互依賴
- 鍍金
- 細節太多
- 過早考慮使用者介面
- 想得太遠
- 故事切割太頻繁
- 客戶團隊很難為故事安排優先級
- 客戶團隊不願意寫使用者故事，也不願安排故事優先級
- 問題舉例練習

![使用者故事](https://i.imgur.com/0B2qSre.png)

## 工具

- 便利貼，適合面對面
- 線上協作白板，適合遠距離
    - [Miro](https://miro.com/), [Leangoo](https://www.leangoo.com/)

___

## 延伸閱讀

[【文思不藏私】使用者故事對照 Part 1](https://medium.com/%E6%96%87%E6%80%9D%E4%B8%8D%E8%97%8F%E7%A7%81/%E6%96%87%E6%80%9D%E4%B8%8D%E8%97%8F%E7%A7%81-%E4%BD%BF%E7%94%A8%E8%80%85%E6%95%85%E4%BA%8B%E5%B0%8D%E7%85%A7-part-1-89f8b9abc543)

[【文思不藏私】使用者故事對照 Part 2](https://medium.com/%E6%96%87%E6%80%9D%E4%B8%8D%E8%97%8F%E7%A7%81/%E6%96%87%E6%80%9D%E4%B8%8D%E8%97%8F%E7%A7%81-%E4%BD%BF%E7%94%A8%E8%80%85%E6%95%85%E4%BA%8B%E5%B0%8D%E7%85%A7-part-2-918f767e65ac)