在領域模型上講故事

May 05 15:52~17:10

▲畫面節錄自滾石愛情故事 In Love臉書貼文。

 

User story（用戶故事）是許多敏捷開發團隊用來溝通需求與建立共識（shared understanding）的方法。在Scrum框架中，sprint planning meeting與product backlog refinement workshop（PBR）是Product Owner（PO）與團隊討論user story內容的主要場合。常見的討論模式有：

1. PO念完story card上面所撰寫的user story內容，然後口頭解釋再請團隊發問。
2. 同1，但PO同時還準備草圖（假畫面）、操作流程等輔助資料。
   
   ▲參考畫面與操作流程
   
3. 同1或加上2，PO與團隊討論結束後，為了確認團隊真的有聽懂，PO請團隊寫下每一個user story的驗收條件（acceptance criteria），雙方透過檢視user story的驗收條件作為是否已經建立共識的依據。
4. 採用user story mapping的團隊，可以直接在user story map（用戶故事地圖）上透過講故事的方式來解釋需求。

▲User Story Map

***

今天在北科上課的時候，有一位學生甲針對目前這個sprint正在開發的user story—「為了知道報名是否成功，身為學員，當我送出報名資料後希望立即收到報名結果通知」問了一個問題…

學生甲：不同的課程（例如Design Pattern與Scrum）寄發的報名成功email通知內容都不同，例如課名、課程網址不同。這個user story我們只要建立一種課程的通知就好，還是要完成好幾種課程的通知？

Teddy：這兩者有什麼不同？

▼當下學生甲也不太清楚要如何解釋這兩者的差異，於是Teddy請全班學生一起幫這個user story建「領域模型」（domain model，又稱為概念模型，conceptual model）。

 

最後找到幾個重要的概念：

• Student
• Class
• RichText eMail Template
• eMail

以下開始講故事：「【學生】選【課程】成功之後，【課程】依據設定好的【電子郵件範本】寄出【電子郵件】」。

現在回到學生甲的問題，不同課程寄發電子郵件通知的時候，郵件的內文會不一樣，例如課名、課程網址等資料會改變。原本學生甲認為這種改變會影響user story的scope（範圍），造成工作量增加，所以詢問Teddy這個user story只要針對一個課程寄發報名成功的電子郵件就好，還是要支援多個課程？

上圖這個簡單的domain model其實已經回答了這個問題：支援一個課程就等於支援多個，因為只要把變動的資料（課名、課程網址）記錄在Class類別即可，即便只有一個電子郵件的範本，也可以支援多個課程的報名成功通知。

***

這個domain model其實已經包含了一點點設計的概念，不過不算嚴重且有助於團隊釐清需求，所以尚可接受。一個簡單的domain model，有時比千言萬語還要來的有助於建立共識（shared understanding）。

***

友藏內心獨白：不要光唱歌，要講故事XD。