用故事地圖管理敏捷開發需求（上）

Jan. 10 17:18~19:04

有一陣子沒談Scrum，今天介紹一下另外一種組織Product Backlog的方式：故事地圖（Story Map）。不知道Product Backlog是什麼的鄉民可參考〈Scrum 是什麼（4）：Product Backlog〉與〈我在第二次Certified ScrumMaster課程學到的事（7）〉。簡而言之，Product Backlog是一個內容經過排序的一維列表（list），裡面的東西稱為Product Backlog Item（PBI）。PBI就是需求，許多敏捷團隊會使用user story來作為撰寫需求的格式。

在〈需求的大小〉這一篇，Teddy介紹了四種PBI的大小。

***

前情介紹完畢，由於Scrum標準的Product Backlog是一個清單，當需求的數量稍微多一點的時候，管理起來會有一些問題。使用者在操作軟體的時候，其實是有一定的操作路徑，例如線上購物系統，使用者總是要先「看到商品」，然後「選購商品」，再來「結帳」，最後才可以查詢「送貨管理」或是「退貨」。這些需求很大，類似Epic等級，還可以再細分下去。例如：

• 瀏覽商品
  • 靜態分類顯示
    • 依商品
    • 依商品分類，然後依據廠商
    • 依商品分類熱銷排行顯示前10名
    • 依金額顯示商品
    • 依規格顯示商品
  • 動態顯示
    • 依查詢條件
    • 依促銷
    • 主動推薦
• 選購商品
  • 直接選購
    • 單品結帳
  • 批次選購
    • 加入購物車
    • 多品結帳
  • 願望管理
    • 加入下次購買清單
    • 加入追蹤清單
• 結帳管理
  • 個資管理
    • 購買人
    • 收件人
    • 多重地址管理
  • 付款管理
    • 信用卡
    • 超商代收
    • 貨到付款
    • ATM轉
  • 快速結帳
    • 一個按鈕結帳
• 送貨管理
  • 進度查詢
    • 網頁查詢本次送貨紀錄
    • 網頁查詢歷次送貨紀錄
    • 手機App查詢本次送貨紀錄
  • 進度通知
    • 簡訊通知
    • email通知
• 退貨
  • 退貨申請
    • …
  • 退貨記錄管理
    • …

也就是說，需求從上而下細分，至少也可以分成三層，變成一個如下的Story Map：

上圖第一層紫色在Story Map的術語裡面稱為User Activity（使用者活動），第二層藍色稱為User Task（使用者工作），第三層黃色稱為User Story（使用者故事），有點類似〈需求的大小〉這一篇裡面的Epic、Feature、Story。

補充說明一下，鄉民們有沒有看出來，Story Map有點Activity-Centered Design（以活動為中心的設計）的味道呢？（請參考〈五種設計決策類型〉）

***

其實以上觀念很簡單，鄉民們可以先把Story Map想成傳統應用程式的表單（menu），看起來不就像是一個Story Map。當然Story Map還有一些其他的特點，留待下一集在介紹。有興趣的鄉民可以先讀一下這一篇很棒的文章〈The new user story backlog is a map〉。

***

友藏內心獨白：二維的方式好像有比一維要清楚耶。