l

2014年1月15日 星期三

用故事地圖管理敏捷開發需求(上)

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來作為撰寫需求的格式。

螢幕快照 2014-01-10 下午5.27.51


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

螢幕快照 2014-01-10 下午5.48.00

***

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

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

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

螢幕快照 2014-01-10 下午6.48.13

上圖第一層紫色在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〉。

***

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

1 則留言:

  1. 嗯,樹狀結構比較好看出全貌,但list比較可以看出順序,計算開發成本。

    回覆刪除