1.
跟著RD 一起跳坑 DDD
之
Event Storming 帶給PM的好處
#Sylv!a
1

2.
● 從 QA 轉 RD 而後轉至PM
● 喜歡且善於分析、改善流程
● 是一位PM，也不只是PM
● 持續學習與實踐，並希望藉由自身的實踐影響
更多人，讓更多的人再去影響更多人。
#Sylv!a 楊孟真
相信可以藉由產品
為使用者的人生帶來不一樣的轉變
2
泰爾科技

3.
3
對於這場分享，你希望可以獲得什麼？

4.
．Outline．
● 為什麼你可能也需要 Event Storming
● 以PM的觀點
○ 初步認識什麼是 Event Storming
○ 我們是如何在公司實務上執行
○ 執行上可能會遇到的疑問與狀況
● 對於PM的幫助
4

5.
在某一個加班的夜晚
5

6.
欸PM
我們下次專案要跑Event Storming
6

7.
不然我們對項目裡的流程都很亂
7

8.
8
PM 問號

9.
9
● 有完整的需求文件：
裡面敘述項目的目標、和相關的功能內容。
● UI/UX 有繪製 UI Flow、Wireframe、Prototype：
裡面有各頁面間的交互流程。
● 我們有開需求會議：
PM會將需求文件整個說明過，也有請UI/UX將整個
Prototype說明過，並且與RD一起討論也表示有了解。
是因為缺少什麼文件嗎？

10.
10
PM & UI/UX 表示

11.
11
● 明明文件上有寫的內容...
RD：我沒有看到xxxxxxxxx，這個是要怎麼做？
PM：可是我文件有寫欸
UI/UX：我的Prototype 有畫唷
● 明明開會上有講過的流程...
RD：這個流程怎麼會變這樣？
PM/UIUX：這個上次有問過也有討論過了...
RD：是喔，我忘記了。
層出不窮的狀況

12.
要怎麼解決這樣的狀況？
12

13.
為什麼會覺得需要
Event Storming
13

14.
通常在開發團隊中
不乏會遇到這些類型的 RD
14

15.
15
只有文字的時候
因為沒有畫面所以沒有感覺所以也不覺得有任何問題
不同的類型的RD可能有不同的症頭
#1

16.
16
有畫面的時候只非常在意是要用什麼資料型態去儲存
(這邊要用 string 還是 integer?)
不同的類型的RD可能有不同的症頭
#2

17.
17
下意識直接用程式碼思維與需求方、設計方溝通
(這邊要先更新資料庫、可能會 rollback失敗)
不同的類型的RD可能有不同的症頭
#3

18.
18
項目都已經進行到一半了，但是還是沒有很清楚
這些功能到底為什麼要這樣做，跟業務邏輯的關係是什麼
不同的類型的RD可能有不同的症頭
#4

19.
通常在開發流程中
大致上就是這兩類
19

20.
20
《圖片出處》

21.
21《圖片出處》

22.
22
PM表示

23.
23
RD表示

24.
24
《圖片出處》

25.
“我們賣的是情境，
不是賣Function。
25

26.
26
需求方最在意的是什麼時候做完業務流程
工程師通常最在意的是程式流程

27.
27
想要拉近需求方與工程師的距離
該如何拉近呢？

28.
28
看來我們真的很需要來一場
Event Storming

29.
什麼是
Event Storming？
29

30.
Event Storming是...
30
一種可以用在 DDD 中，快速建模的一個方法。
透過工作坊的模式，讓參與者使用「共通語言」，將商業
業務邏輯，用視覺化的方式呈現。
通常在使用 Event Storming 以後
● 獲取到項目的全貌
● 發現大家的共識有所對齊，像是項目目標、名詞定義
(更深入)對話產生

31.
Event Storming 可以應用的場景
31
BIG
PICTURE
呈現商業流程的全局
PROCESS
MODELLING
細部的流程討論，確保共識
SOFTWARE
DESIGN
依照前面兩階段產出進行軟體設計

32.
● 引導者 (如果可以有的話!!!)
● 參與者：這個項目的所有利益相關者們
○ 領域專家（白話文：可以解答、決策的人）
○ 相關利害關係人（白話文：有疑問的人）(包括但不限於下列)
■ 開發人員
■ 業務人員
■ UI/UX
● 足夠大的牆面 + 很多很多顏色的便利貼 (or…. Miro?)
開始 Event Storming 前要做的準備
32

33.
要多大？
33

34.
34

35.
35

36.
● 準備各種不同顏色的便利貼
各種不同顏色的便利貼？
36
Event
Read
Model
Command
Process
Actor
Rule
External
System
Memo/
Answer

37.
我們如何
在公司項目中執行
37

38.
38
PM UI/UX
Front Front Front
Back Back Back BackBack
需求方需求方
Back

39.
PM UI/UX
需求方需求方
前置1：需求訪談/使用者數據調查
39

40.
40
PM UI/UX
前置2：確認彼此共識

41.
前置3：提前釋出資料
41
Product Vision、Persona

42.
42
PM UI/UX
Front Front Front
Back Back Back BackBack Back
領域專家代表會議引導者
前置4：角色分配

43.
43
會議開始
● 會議引導者進行開場
○ 介紹在場的人員
○ 說明此次會議的目標
● 需求說明
○ 項目的達成目標
○ 整體要做的事情

44.
● 為這次的 Event Storming 設定
範圍
● 一定要用過去式的方式去敘述，
如：訂單已完成、商品已刪除
第1-1步
領域專家貼出開始與結束
44
Event

45.
45
↑
我
是
第
一
張
↑
我
是
最
後
一
張

46.
● 依照時間軸，由左到右
● 有重複沒關係，後面整理
● 一樣的規矩：一定要用過去式的
方式去敘述
● 預計保留 5-10 分鐘
第1-2步
大家貼出所有目前想得到的事件
46
Event

47.
為什麼一定要寫過去式的事件？
47
● 一個不爭的事實
○ 就是一個我們認為會發生的事情、結果
● 避免發散
○ 每個動作可能產生很多結果

48.
48
↑
我
是
第
一
張
↑
我
是
最
後
一
張
正常來說應該要這樣

49.
49
↑
我
是
第
一
張
↑
我
是
最
後
一
張
但也有可能這樣

50.
● 先以 Happy Path 為主
● 更正沒有照規則的便利貼
如：下訂單、刪除商品這種「動
作」敘述
第2步
引導者由左到右確認一次
50

51.
● 對應的事件上去貼上問題
● 一定要斜斜地貼：明顯！
● 通常需要保留 5-10 分鐘
第3步
提出疑慮
51

52.
52

53.
● 由左到右一一解答
● 通常是由領域專家做解答
● 如果當場在場的人都回答不出來
，可以另外做標記，後續統一教
請人做回答
第4步
做出解答
53
Memo/
Answer

54.
54

55.
55

56.
請一個人(非領域專家)
從頭到尾 Review
56

57.
● 每個 Event 照理都會有一個
Command 觸發
● Command:Event
1:1 / 1:N / N:1
第5-1步
觸發動作
57
Command Event

58.
58

59.
● 對於現階段目標不是首要關注的
部分，或是另一個領域的範圍
● 對於 RD 來說是很複雜的過程，
但是領域專家不關注的部分。
● 通常後面會再延伸觸發其他事件
第5-2步
標示認知起來會是複雜的部分
59
Command Event Process

60.
60
下訂單 訂單已建立建立訂單流程
訂單建立失敗
已下訂單

61.
● 公司另一個部門的系統
● 外面第三方服務（金流 等）
第5-3步
標示第三方
61
External
System

62.
62
綠界

63.
● 每個Command 一定會有一個
觸發者
● 可以是人，也可以是系統
● 注意：統一名詞
第5-4步
貼上觸發者
63
Command Event
Actor

64.
64

65.
換一個人(非領域專家)
從頭到尾 Review Again
65

66.
66
Event
Read
Model
Command
Process
Actor
Rule
External
System
Memo/
Answer

67.
第10步
添加下Command 的所需的資料
67
● 這個 Actor 要下 Command 時
所需要的資料、參考依據
Read
Model
Command Event
Actor

68.
68

69.
第11步
添加要遵守的條件、規矩
69
● 例如
○ 身分證號碼不可重複註冊
○ 最少三張圖片，最多12張圖片
Read
Model
Command Event
Actor
Rule

70.
70

71.
第12步
添加如 Wireframe 的畫面輔助
71
● 輔助大家對於事件樣貌的想像
● 可能延伸幫助大家再想到其他未
討論到的業務流程
Read
Model
Command Event
Actor
Rule

72.
從 Big Picture
到 Process Modeling
72

73.
73
Event
Read
Model
Command Process
Actor
Rule
External
System
Memo/
Answer
Event
Event

74.
執行時你可能會遇到這些狀況(1/2)
74
● 沒有使用通用語言
不小心又開始說出的專業名詞，秀一波行話
● 不小心發散到其他領域
大家聚在一起，一定可能會有其他好的聯想
● 體力不支
Event Storming 要求就是要站著開會

75.
執行時你可能會遇到這些狀況(2/2)
75
● UI/UX 來不及出圖
如果真的到Event Storming 才出 Wireframe，後續的Mockup、
Portotype 會非常趕
● UI/UX 出的圖跟 Read Model 有落差
初次執行有可能會忘記互相核對與同步，如果真的有運用
EventStorming 的產出做軟體規劃時，會缺少對應資料的規劃

76.
● 故意提問
○ 就算你是明知道答案的人，也可以故意貼上問題
● 設置階段間的空窗期
○ 讓大家可以有一個「空白時間」做思考
○ 增加N次請人做 Review 的機會
● 預留便利貼空白
○ 實體的 Event Storming 尤其需要
執行時也可以考慮這樣做
76

77.
● UML 圖
● 設計文件
● 開發部署文件
Event Storming
只是可以強化輔助其中一環的工具
它不可以成為它們的替代品
77

78.
對於PM的幫助
78

79.
幫助到RD，就是幫助到PM
79
● 所有人對於產品具備全面的了解
● 可視化產品模型、集思廣益
● 有人又忘記業務流程的時候
○ Event Storming 的圖可以幫你解答
○ 其他 RD 可以幫你解答
● 幫助需求方慢慢瞭解實務上的實作複雜度
○ 從「這個不是很簡單嗎」慢慢前往 「 辛苦了」

80.
80
Why Product Vision Board
When Story Mapping
How Product Backlog

81.
81
Why Product Vision Board
What Event Storming Workshop
When Story Mapping
How Product Backlog

82.
82
執行的方式
怎麼好像跟我之前聽的不一樣

83.
“
83
沒有最佳方法，
你的目的會影響你的流程

84.
Q&A
84
from Slido

85.
85
Q、當領域專家無法參加會議，你是如何確定你對領域的理
解與領域專家的理解是一致的?
在前面需求訪談的時候我們會盡量確保有一致性，另外在簡報中有
提到，只要是我與UI/UX無法回答的，我們絕對不會裝懂，會留下來
請原始需求方來解答，然後藉由邀請他來的時候，也會一起跟他講
一下這些內容。

86.
Q、“引導人”身兼“領域專家”如何確保自己不會陷入討論而
忽略時間與流程掌控
這邊我是先跟我的另一位一起擔任領域專家的說好，我都會先請他
做解答（畢竟我們也已有先有所共識），真的是我才知道的、有需
要我回答的，或是感覺有點錯誤的，我才會做介入，所以反而其實
我主要還是會投入在「引導人」的腳色。
86

87.
Q、我看到你們用了三面牆，我覺得很棒，你們真的是一個
高效的團隊，我想問問，電子化是必要的嗎？電子化後有
什麼困擾？有什麼壞處？
我偏好在前面兩層的時候用實體的，一部分就如簡報中的一種想要
讓需求方「視覺化」的感受他的一個需求是長什麼樣的，另一部分
是會更有「凝聚感」的討論。
後續開始要做第三層(Software Design)的時候，就會更新到 Miro上
面，方便RD可以 duplicate 一份去做。如果一開始就用電子化，除
非真的是因為大家都遠端或是人數不多，不然同一個辦公室又各自
用電腦一起做個人感覺會有點小疏離。
87

88.
Q、有推薦紀錄成電子文件的工具嗎
以Event Storming 的話，如投影片裡提到的，我會推薦Miro。
88

89.
Q、開始與結束的需求範圍如何定義？
假設你的團隊有PM的話，那麼每一個里程碑或是每一個階段應該要
做的項目應該會有一個範圍，不過並不確定你想問的「需求範圍」
是哪個部分的。
那基於這個範圍，如投影片中提到我們的做法，在 Event Storming
的第1-1 會先貼下 領域專家認為這次需求範圍中，最一開始會遇到
的事件跟最後的事件，若後續有人認為其實還有更早的事件，就是
可以貼上後，引導者帶著大家去討論是否真的需要異動這個Event
Storming 的開始與結束。
如果沒有回答到你想要理解的，也歡迎直接聯繫我一起討論交流！
89

90.
Q、什麼原因一定要站著開event storming 呢？
我想這是一個基於人類的惰性而產生的規則。
正常來說大家一定是能坐就坐、能躺就躺😆
EventStorming 的過程就是一個需要大家往前去看 牆壁上的項目、
動手寫跟移動牆壁上的項目，當人開始坐下以後，就會不自主的開
始「不想動」，這樣對於會議上的進行的順暢度會增加阻礙(沒有人
想要寫貼、大家開始把自己當成一個觀眾等)。
如果更嚴格一點，會要求大家不可帶任何電子產品進入這個會議。
90

91.
Q、導入event storming 初期一定不熟悉且不確定是否有
用及正確，因這些都可能有額外的成本，該怎麼說服團隊
和老闆來導入
可能會想先知道，是什麼樣的情境下讓你覺得團隊需要 Event
Storming？你想要解決的問題會是什麼樣的問題？會先需要盤點一
下你的現況，找到需要使用 Event Storming 的原因和想要解決的問
題，這樣你才有所謂的立足點去做「說服」的動作。另外也可以在小
型的 Side Project 上面做引入。
的確 Event Storming 進行的時候是會花時間，但如果在你專案真的
流程挺複雜的情況下，看是希望辛苦在前面還是辛苦在後面。
91

92.
Q、ES 可以寫在工作日誌嗎？ ES 2hr
是因為有什麼顧慮所以讓你覺得需要確認「能不能」寫在日誌上？
不太確定會這樣問是因為什麼樣的背景，但如果有需要紀錄我覺得
這樣紀錄應該是沒有問題的。我自己的日誌是都會記錄，而其他人
的部分，我自己也會發會議通知去 booking 他們的時間，然後 RD
在每天立會也都會講到，例如「下午預計要開第 N Part 的 Event
Storming，所以我預計早上處理好 XXXX 事情」。
92

93.
Q、一個專案基本上平均都定位幾次，每次定位平均大約都
多久，感謝
這邊的定位是指什麼？有點不太明白。可以的話歡迎在slide share
下做comment ，或是歡迎直接聯繫我一起交流 :)
93

94.
Q、Event storming 後產出的功能，有遇到無法驗收的情
況嗎？
如果你的無法驗收是說沒做完，我想應該不是因為用了Event
Storming 才產生的問題。但如果你的無法驗收像是前面的問題提到
的「怎麼確定跟真正的需求方認知一致」，不變的法則就是盡量持
續溝通。我們公司剛好需求方就在自己公司，所以相對容易找到他
們做討論與對齊。
94

95.
95
Contact Me 聯絡我
FB： imsylviaymc 楊孟真
Linkedin： pmsylvia
泰爾科技股份有限公司