從OOAD看User Story Mapping

Jan. 25 10:18~12:25

 

一位到大陸工作多年的學弟回台灣過農曆年，昨天下午學弟找Teddy聊天，談談敏捷開發與使用者故事對照（User Story Mapping）。學弟之前念書的時候修過物件導向分析與設計（OOAD），Teddy就從OOAD的角度切入，解釋使用者故事對照在軟體生命週期中所扮演的角色。

▼顧名思義，OOAD包含了兩大內容：A（Analysis，分析）與D（Design，設計）。傳統OOAD在分析的部分採用Use Case來幫需求「塑模」，基於這個Use Case Model接著建立起Domain Model，用來代表問題領域裡面重要的概念以及概念之間的關係。

需求分析完成之後，便可以依此來進行開發規劃。例如，在剛開始的若干個迭代（iteration）內將最重要與風險最高的前20% use cases開發完成，並且同時完成軟體架構雛形。

▼下圖是節錄自維基百科的一張use case diagram，每一個橢圓形代表一個use case，也就是一個系統功能。圖中的「火柴人」稱為Actor，代表一種使用者角色。這張use case diagram看起來是一個餐廳管理系統，使用者包含Waiter（服務員）、Client（客人）、Cashier（櫃台）、Chef（廚師）。Actor與use case中間的直線代表這個Actor可以使用這個use case。

 

▼接下來看一張使用者故事對照或稱為用戶故事地圖。簡單但不精確地來說，最上面紫色的框框可以想成是一個use case，只不過這些use case現在依據時間軸加以展開，這張地圖首先代表「主要使用者」使用這個系統的歷程。依據時間軸展開這些功能的好處是可以用講故事的方式來敘述與溝通使用者使用系統的方式。

 

▼ 如果只是把類似use case這種大粒度的功能模組依據時間展開變成一張圖，那麼這張圖和use case diagram其實差異並不大。從說故事的角度來看，這樣子只能算是有「故事大綱」而已，接下來還要從這個故事大綱展開劇情細節，這才是使用者故事對照精彩的地方。

***

有了使用者故事對照（用戶故事地圖）某種程度算是可以取代或是說輔助傳統OOAD裡面的use case diagram，接下來後面要串什麼就看專案的需要。 例如：

• 採用傳統瀑布式開發：使用者故事對照（用戶故事地圖）可以當成比use case diagram詳細的需求表達方式（如果願意也可以同時建立use case diagram與user story map），在傳統以文件為交接媒介的瀑布式開發流程中，可以幫用戶故事地圖中每一個user story撰寫完整的驗收測試，甚至是包含操作介面雛形作為詳盡需求文件的一部分。
• 採用Scrum：採用敏捷方的的團隊可以依據這張用戶故事地圖安排產品釋出計畫（release plan），也就是每一個迭代預計要開發那些user story。這張圖可以取代線性的product backlog，讓需求比較像一棵樹，有樹幹也有樹葉。
• BDD/TDD：在實作上，用戶故事地圖裡面的每一個user story可以做為BDD/TDD開發的需求源頭，接著透過撰寫「可執行規格（executable specification）」來具體化這些user story，並自動確保它們的實作是否完成。
• 軟體架構：軟體架構主要用來滿足系統的功能與非功能需求，在用戶故事地圖裡主要看到的是功能需求，所以這張地圖可以在專案早期協助我們評估軟體架構是否可以滿足系統的功能性需求。至於非功能性需求，例如安全性、效能、可維護性、可靠性等，就必須要借用其他文件或工具來協助。

***

用戶故事地圖提供一個情境（context）指引團隊方向，避免團隊專心於眼下的開發工作而忘了產品整體目標。它不是什麼神奇工具可以解決所有產品需求的問題，但它的確是一個發展、梳理與溝通需求的好方法。最後打個廣告， 泰迪軟體的「使用者故事對照工作坊 (User Story Mapping Workshop)」 已經確定開課，上課日期為2月12日，對於產品需求管理有需要的朋友請不要錯過。

***

友藏內心獨白：在大陸住久了，聽口音還以為學弟是中國人。