透過System Context Diagram講故事

May 06 08:40~10:00

▲畫面節錄自Google搜尋「System Context Diagram」結果

 

前幾天提了〈在領域模型上講故事〉，今天介紹另外一種講故事的方法：System Context Diagram（系統關係圖）。

前一陣子跟Erica討論這學期北科「軟體生命週期管理」課程的專案需求。這學期將全班學生編成三組，在Scrum框架下共同開發一個專案。為了讓專案具體且貼近業界實際狀況，今年的Product Owner改由助教Erica擔任，專案內容就是開發一個支援泰迪軟體開課活動的系統。Erica是Product Owner也是真正的使用者，和學生討論需求會具體很多。

▼Erica首先建好「現況」的user story map（用戶故事地圖）：

 

接著應該在這個user story map上以「用戶期待的成果」來講故事，藉此發展新的需求並且安排軟體釋出計畫（release plan）。但是，這個專案比較特別，主要的force（限制）有：

• 開發時間只有4個為期3周的sprint（共12周）
• 開發人員是學生（不是全職的專業工程師）
• 希望學期結束的產出物真正可以派上用場

因此，如果單純以「用戶期待的成果」這個觀點來規劃專案，最後切出來的最小可行性產品（minimum viable product，MVP）不見得可以在4個sprint完成。此外，目前泰迪軟體採用Google表單讓學員填寫報名表，這部分暫時沒有要替換。因此衍伸出「舊系統」（Google表單）與新系統之間的整合問題。理論上「技術問題」主要應交給團隊去傷腦筋，不太需要Product Owner來煩惱。但因為這是學校課程的專案，授課講師（就是Teddy）需要事前規劃讓這個專案可以在一學期內順利進行，所以在撰寫user story與準備產品釋出計畫的同時，不得不先考慮這部份的技術問題。

***

瞪著user story map看了老半天，不容易從上面思考整合的問題。這實屬正常現象，因為從使用者的角度，根本不管你「課程報名採用Google表單，課程其它行政活動支援採用另一個系統」這件事。這是比較偏設計與實作面的問題。

▼怎麼辦？回到OOAD（物件導向分析與設計）老方法，畫個system context diagram來協助思考新系統與其他系統之間的關係：

 

▼畫好system context diagram之後開始在上面「講故事」，最後找出9個最重要的user story作為初始product backlog的內容，然後用便利貼標示它們的優先順序（照片中黃色便利貼）。

***

接下來事情就簡單很多了。回到user story map，此時思考幾種情境：

• 立即享受：開課單位（泰迪軟體）想要在最短的時間內獲得這個系統的幫助。
• 最大痛苦解除：目前哪些活動最花時間、最容易出錯？
• 最完美狀況：在最理想的情況下，這個系統需具備哪些功能？例如有自己的報名功能、可以串接金流、開立電子發票、學員關係管理等。如果達到這個狀態，這個系統本身也可以拿去賣錢了XD。

考量到只有12周的開發時間，最後選擇「最大痛苦解除」作為第一個釋出計畫的目標。有了目標之後，在回頭重新檢視需求的優先順序，就容易許多。

***

這整個準備過程中還有遇到很多細節，例如因為技術問題（與Google表單整合）而「綁架」了user story的優先順序安排。Product Owner最痛苦的點就是每次課程結束之後要花很多時間製作與寄發學員結業證書，因此自動製做與寄發結業證書的user story價值最高，優先權也最高。但是，問題來了，學員的所有資料都在Google表單裡面，這些資料沒有匯入到新系統裡面，怎麼自動寄發結業證書？那到底匯入資料的user story要先做，還是寄發結業證書的user story要先做？此外，三個開發團隊如何處理具有相依性的user story？這些都是需要思考與解決的問題。

***

友藏內心獨白：魔鬼藏在細節中。