Tom Chang
← 回文章列表

2024年12月17日

在 Scrum 中加入 Event Storming：Big Picture 建立 Product Backlog，Process Modeling 拆出 User Story

ScrumEvent StormingDDD敏捷開發需求分析

Scrum 流程整理 那篇整理了 Scrum 的角色、事件和產出物，Event Storming 怎麼跑 那篇整理了工作坊的做法。兩者各自都清楚，但放在一起時有個落差：

  • Scrum 沒有說需求從哪裡來：Product Backlog 要「排好優先順序、上面的項目要清楚」，但 PO 怎麼知道該有哪些項目？一個個獨立寫出來的 User Story，很容易看不出彼此的關係，Refinement 變成 PO 逐張念卡片
  • Event Storming 沒有說之後怎麼辦：牆貼滿了、熱點也找到了，然後呢？如果要先把所有流程都拆到 Software Design 才開始開發，那就變回瀑布了

這篇整理把兩者接起來的方式。核心原則只有一句：Big Picture 看全貌只做一次，細節只為接下來一兩個 Sprint 建模。

每種 Event Storming 放在哪裡

Event Storming 在 Scrum 中的位置：產品啟動或設定新的 Product Goal 時，跑一次半天到一天的 Big Picture，產出 Epic、熱點與 Product Goal，進入 Product Backlog；之後每個 Sprint 重複：Backlog Refinement 時針對下一個 Epic 跑 1 到 2 小時的 Process Modeling，拆出 User Story 與驗收條件，放回 Product Backlog；Sprint Planning 時只針對複雜的 Story 跑 30 到 60 分鐘的 Software Design，找出聚合並拆出 Task；開發期間把牆面當參考，新發現的問題貼成熱點；Sprint Review 時在牆面上標出這次完成的事件，和利害關係人對齊全貌；Review 結束後進入下一個 Sprint

時機Event Storming 層次參與者產出
產品啟動、設定新的 Product GoalBig Picture（半天～一天）PO、各部門的領域專家、DevelopersEpic、熱點、Product Goal 的方向
Backlog RefinementProcess Modeling（1～2 小時）PO、相關的領域專家、DevelopersUser Story、驗收條件、還沒釐清的熱點
Sprint Planning 的「How」Software Design（30～60 分鐘，視需要）Developers，PO 在場回答問題聚合、命令、事件的設計，以及 Task
Sprint 進行中不另外跑，牆面當參考Developers新的熱點
Sprint Review回到牆面更新Scrum Team、利害關係人已完成的範圍、對全貌的新理解

Big Picture → Product Backlog

Big Picture 不需要每個 Sprint 跑，通常在這些時候才跑：

  • 新產品或新專案開始
  • 要設定新的 Product Goal，例如「讓斡旋流程全面線上化」
  • 團隊接手一個不熟悉的領域

跑完之後，牆上的東西可以直接對應到 Product Backlog：

  • 關鍵事件切出來的每一段，變成一個 Epic：例如「委託與刊登」、「帶看」、「斡旋」、「簽約交屋」。這些段落也是 子域與限界上下文 的候選邊界，Epic 和團隊的分工可以一起考慮
  • 投票選出的熱點，決定先做哪個 Epic：大家最痛的地方通常就是最有價值的地方。例如投票最多的是「斡旋要經紀人逐一打電話通知，常常漏掉」，那斡旋就是第一個 Epic
  • 問題型的熱點，變成待釐清的項目：「斡旋已接受算不算成交？」不是開發工作，而是要 PO 去和業務、財務確認的事。可以放進 Product Backlog 並指定負責人，或者在需要時排一個探索性的 Spike
  • Product Goal：整面牆和投票結果，讓 PO 更容易寫出一個具體的 Product Goal，而不是「優化交易流程」這種口號

這時候 Product Backlog 上只有幾個 Epic，不需要把每個 Epic 都拆成 Story。拆得太早，到真的要做時需求可能已經變了。

Process Modeling → User Story

每個 Sprint 的 Backlog Refinement 中，挑出排在最前面、下一兩個 Sprint 就要做的 Epic，跑一場 Process Modeling。Scrum Guide 2017 版曾建議 Refinement 不要超過 Developers 產能的 10%，兩週的 Sprint 大約一天左右，花 1～2 小時跑 Process Modeling 是合理的。

沿著命令和事件切 Story

Process Modeling 的牆貼完後，一條「命令 → 事件」或「政策 → 事件」的路徑，就是一個 Story 的候選：

把斡旋流程的 Process Modeling 切成 User Story：上方是牆面，依序是命令「提出斡旋」與事件「斡旋已提出」組成 Story A 提出斡旋；政策「每當斡旋已提出就通知屋主」與事件「屋主已收到通知」組成 Story B 通知屋主；角色屋主發出命令「接受斡旋」產生事件「斡旋已接受」組成 Story C 屋主接受斡旋；另一條路徑政策「每當期限到就失效」與事件「斡旋已過期」組成 Story D 斡旋到期失效；政策「每當斡旋已接受就通知其他斡旋人」旁邊貼著熱點「多組斡旋時誰優先」，所以 Story E 還沒就緒，暫時不放進 Sprint。下方展開 Story C，把相關的事件寫成 Given When Then 的驗收條件：斡旋已提出且未過期時接受，結果是斡旋已接受；斡旋已過期時接受，結果是拒絕並提示斡旋已過期；斡旋已撤回時接受，結果是拒絕並提示斡旋已撤回

Story牆上的路徑說明
A. 提出斡旋提出斡旋 → 斡旋已提出買方能提出斡旋
B. 通知屋主政策：每當斡旋已提出，就通知屋主 → 屋主已收到通知自動通知取代經紀人打電話
C. 屋主接受斡旋接受斡旋 → 斡旋已接受屋主可以接受斡旋
D. 斡旋到期失效政策：每當期限到，就失效 → 斡旋已過期不需要人工處理過期
E. 通知其他斡旋人政策：每當斡旋已接受，就通知其他斡旋人有熱點「多組斡旋時誰優先」，還沒就緒

這樣切出來的 Story 有幾個好處：

  • 天生就是垂直切片：每個 Story 從命令到事件，一定包含畫面、API、規則、資料，完成後就是一個能用的功能，而不是「斡旋的資料表」、「斡旋的 API」這種依技術層切的 Story
  • 大小比較一致：每條路徑的範圍差不多，估算時比較不會出現一個 3 點、一個 40 點
  • 順序很清楚：牆上看得出 C 一定要在 A 之後，B 和 D 可以並行
  • 有熱點的就是還沒就緒：E 牽涉到一個還沒定案的業務規則，不應該放進 Sprint。這和 Scrum 那篇提到的 Definition of Ready 是同一件事

如果一條路徑太大，例如「提出斡旋」要處理斡旋金的線上付款，可以再沿著事件拆開：「提出斡旋（斡旋金現場收取）」先做，「斡旋金線上付款」之後再做，兩個都是能獨立使用的功能。

事件就是驗收條件

Story 的驗收條件，可以直接從牆上的事件寫成 Given–When–Then：

  • Given 前面已經發生的事件（狀態）
  • When 這個 Story 的命令
  • Then 應該產生的事件，或是被拒絕的原因

以 Story C「屋主接受斡旋」為例：

GivenWhenThen
斡旋已提出，且還沒過期屋主接受斡旋斡旋已接受
斡旋已過期屋主接受斡旋拒絕，提示「斡旋已過期」
斡旋已撤回屋主接受斡旋拒絕，提示「斡旋已撤回」

這些驗收條件用的都是牆上的業務用語，PO 看得懂，開發人員也可以直接寫成測試。如果用 DDD 概論 裡的聚合設計，這三列幾乎就是 Offer.Accept() 的三個單元測試。

Sprint Planning：需要時才跑 Software Design

Sprint Planning 的「How」階段，大部分的 Story 直接拆 Task 就好。只有在這些情況，才值得花 30～60 分鐘跑一次 Software Design：

  • 這個 Sprint 要建立新的聚合，例如第一次做斡旋，要決定 Offer 和 Listing 的邊界
  • Story 牽涉到多個聚合之間的一致性，例如「斡旋已接受」之後，物件狀態要不要立刻更新
  • 團隊對設計有明顯的分歧

跑完之後，Task 也很自然地出來了：

  1. Offer 聚合加上 Accept() 方法與驗收條件對應的單元測試
  2. 「接受斡旋」的命令處理
  3. 「斡旋已接受」事件的發布
  4. 屋主端的斡旋列表畫面（讀取模型）

讓牆面活著

Event Storming 的牆如果貼完就收起來，幾個 Sprint 之後就沒人記得全貌了。幾個讓它持續發揮作用的做法：

  • 轉成線上白板：實體牆拍照後整理到 Miro，整個團隊都看得到
  • 標出進度：每個 Sprint 完成的事件，在白板上標記為已完成。Sprint Review 時打開這張圖，利害關係人一眼就能看出這次的 Increment 在整個流程的哪一段
  • 新的發現就更新：開發過程中發現新的規則或例外，直接加一張便利貼或熱點，下次 Refinement 時一起討論
  • 不要追求完整：牆面是溝通工具，不是規格書。過時的部分寧可刪掉，也不要讓它誤導人

角色分工

  • PO：對結果負責，決定哪些熱點要優先處理、哪些 Story 先做。Big Picture 和 Process Modeling 都一定要參加
  • Scrum Master：適合擔任主持人，確保時間盒、確保每個人都有參與。如果團隊裡有人更熟悉 Event Storming，也可以由他主持
  • Developers：一起參與，不是等 PO 把 Story 寫好再看。他們會問出很多業務沒想過的邊界情況
  • 領域專家：Big Picture 要找齊各部門；Process Modeling 只需要該流程的人。他們不一定是 Scrum Team 的成員，由 PO 邀請

常見的陷阱

陷阱結果改善
開發前把所有流程都跑到 Software Design花了一個月設計，需求已經變了，變回瀑布只為接下來一兩個 Sprint 建模
只有 Developers 自己跑牆上都是開發人員的猜測，沒有真正的業務知識PO 和領域專家一定要在場
依技術層切 Story每個 Story 都無法單獨使用，Sprint Review 沒東西可展示沿著命令→事件的路徑切
熱點沒有人追同樣的問題在下一場又被貼一次每個熱點指定負責人，放進 Product Backlog
每個 Sprint 都跑 Big Picture時間成本太高，參與者開始疲乏Big Picture 只在 Product Goal 改變時跑
牆面只用一次幾個 Sprint 後沒人記得全貌轉成線上白板，在 Review 時更新

一句話總結

把 Event Storming 加進 Scrum 的方式，是依照「由寬到窄、剛好夠用」放在不同的時機：產品啟動時用 Big Picture 找出 Epic、熱點與 Product Goal，每個 Sprint 的 Refinement 只為下一個 Epic 跑 Process Modeling，沿著命令與事件切出垂直的 User Story、用事件寫出驗收條件，Sprint Planning 只在必要時跑 Software Design，並讓牆面在每次 Review 時持續更新。