SlideShare une entreprise Scribd logo
1  sur  95
Télécharger pour lire hors ligne
跟著RD 一起跳坑 DDD
之
Event Storming 帶給PM的好處
#Sylv!a
1
● 從 QA 轉 RD 而後轉至PM
● 喜歡且善於分析、改善流程
● 是一位PM,也不只是PM
● 持續學習與實踐,並希望藉由自身的實踐影響
更多人,讓更多的人再去影響更多人。
#Sylv!a 楊孟真
相信可以藉由產品
為使用者的人生帶來不一樣的轉變
2
泰爾科技
3
對於這場分享,你希望可以獲得什麼?
.Outline.
● 為什麼你可能也需要 Event Storming
● 以PM的觀點
○ 初步認識什麼是 Event Storming
○ 我們是如何在公司實務上執行
○ 執行上可能會遇到的疑問與狀況
● 對於PM的幫助
4
在某一個加班的夜晚
5
欸PM
我們下次專案要跑Event Storming
6
不然我們對項目裡的流程都很亂
7
8
PM 問號
9
● 有完整的需求文件:
裡面敘述項目的目標、和相關的功能內容。
● UI/UX 有繪製 UI Flow、Wireframe、Prototype:
裡面有各頁面間的交互流程。
● 我們有開需求會議:
PM會將需求文件整個說明過,也有請UI/UX將整個
Prototype說明過,並且與RD一起討論也表示有了解。
是因為缺少什麼文件嗎?
10
PM & UI/UX 表示
11
● 明明文件上有寫的內容...
RD:我沒有看到xxxxxxxxx,這個是要怎麼做?
PM:可是我文件有寫欸
UI/UX:我的Prototype 有畫唷
● 明明開會上有講過的流程...
RD:這個流程怎麼會變這樣?
PM/UIUX:這個上次有問過也有討論過了...
RD:是喔,我忘記了。
層出不窮的狀況
要怎麼解決這樣的狀況?
12
為什麼會覺得需要
Event Storming
13
通常在開發團隊中
不乏會遇到這些類型的 RD
14
15
只有文字的時候
因為沒有畫面所以沒有感覺所以也不覺得有任何問題
不同的類型的RD可能有不同的症頭
#1
16
有畫面的時候只非常在意是要用什麼資料型態去儲存
(這邊要用 string 還是 integer?)
不同的類型的RD可能有不同的症頭
#2
17
下意識直接用程式碼思維與需求方、設計方溝通
(這邊要先更新資料庫、可能會 rollback失敗)
不同的類型的RD可能有不同的症頭
#3
18
項目都已經進行到一半了,但是還是沒有很清楚
這些功能到底為什麼要這樣做,跟業務邏輯的關係是什麼
不同的類型的RD可能有不同的症頭
#4
通常在開發流程中
大致上就是這兩類
19
20
《圖片出處》
21《圖片出處》
22
PM表示
23
RD表示
24
《圖片出處》
“我們賣的是情境,
不是賣Function。
25
26
需求方最在意的是什麼時候做完業務流程
工程師通常最在意的是程式流程
27
想要拉近需求方與工程師的距離
該如何拉近呢?
28
看來我們真的很需要來一場
Event Storming
什麼是
Event Storming?
29
Event Storming是...
30
一種可以用在 DDD 中,快速建模的一個方法。
透過工作坊的模式,讓參與者使用「共通語言」,將商業
業務邏輯,用視覺化的方式呈現。
通常在使用 Event Storming 以後
● 獲取到項目的全貌
● 發現大家的共識有所對齊,像是項目目標、名詞定義
(更深入)對話產生
Event Storming 可以應用的場景
31
BIG
PICTURE
呈現商業流程的全局
PROCESS
MODELLING
細部的流程討論,確保共識
SOFTWARE
DESIGN
依照前面兩階段產出進行軟體設計
● 引導者 (如果可以有的話!!!)
● 參與者:這個項目的所有利益相關者們
○ 領域專家(白話文:可以解答、決策的人)
○ 相關利害關係人(白話文:有疑問的人)(包括但不限於下列)
■ 開發人員
■ 業務人員
■ UI/UX
● 足夠大的牆面 + 很多很多顏色的便利貼 (or…. Miro?)
開始 Event Storming 前要做的準備
32
要多大?
33
34
35
● 準備各種不同顏色的便利貼
各種不同顏色的便利貼?
36
Event
Read
Model
Command
Process
Actor
Rule
External
System
Memo/
Answer
我們如何
在公司項目中執行
37
38
PM UI/UX
Front Front Front
Back Back Back BackBack
需求方需求方
Back
PM UI/UX
需求方需求方
前置1:需求訪談/使用者數據調查
39
40
PM UI/UX
前置2:確認彼此共識
前置3:提前釋出資料
41
Product Vision、Persona
42
PM UI/UX
Front Front Front
Back Back Back BackBack Back
領域專家代表會議引導者
前置4:角色分配
43
會議開始
● 會議引導者進行開場
○ 介紹在場的人員
○ 說明此次會議的目標
● 需求說明
○ 項目的達成目標
○ 整體要做的事情
● 為這次的 Event Storming 設定
範圍
● 一定要用過去式的方式去敘述,
如:訂單已完成、商品已刪除
第1-1步
領域專家貼出開始與結束
44
Event
45
↑
我
是
第
一
張
↑
我
是
最
後
一
張
● 依照時間軸,由左到右
● 有重複沒關係,後面整理
● 一樣的規矩:一定要用過去式的
方式去敘述
● 預計保留 5-10 分鐘
第1-2步
大家貼出所有目前想得到的事件
46
Event
為什麼一定要寫過去式的事件?
47
● 一個不爭的事實
○ 就是一個我們認為會發生的事情、結果
● 避免發散
○ 每個動作可能產生很多結果
48
↑
我
是
第
一
張
↑
我
是
最
後
一
張
正常來說應該要這樣
49
↑
我
是
第
一
張
↑
我
是
最
後
一
張
但也有可能這樣
● 先以 Happy Path 為主
● 更正沒有照規則的便利貼
如:下訂單、刪除商品這種「動
作」敘述
第2步
引導者由左到右確認一次
50
● 對應的事件上去貼上問題
● 一定要斜斜地貼:明顯!
● 通常需要保留 5-10 分鐘
第3步
提出疑慮
51
52
● 由左到右一一解答
● 通常是由領域專家做解答
● 如果當場在場的人都回答不出來
,可以另外做標記,後續統一教
請人做回答
第4步
做出解答
53
Memo/
Answer
54
55
請一個人(非領域專家)
從頭到尾 Review
56
● 每個 Event 照理都會有一個
Command 觸發
● Command:Event
1:1 / 1:N / N:1
第5-1步
觸發動作
57
Command Event
58
● 對於現階段目標不是首要關注的
部分,或是另一個領域的範圍
● 對於 RD 來說是很複雜的過程,
但是領域專家不關注的部分。
● 通常後面會再延伸觸發其他事件
第5-2步
標示認知起來會是複雜的部分
59
Command Event Process
60
下訂單 訂單已建立建立訂單流程
訂單建立失敗
已下訂單
● 公司另一個部門的系統
● 外面第三方服務(金流 等)
第5-3步
標示第三方
61
External
System
62
綠界
● 每個Command 一定會有一個
觸發者
● 可以是人,也可以是系統
● 注意:統一名詞
第5-4步
貼上觸發者
63
Command Event
Actor
64
換一個人(非領域專家)
從頭到尾 Review Again
65
66
Event
Read
Model
Command
Process
Actor
Rule
External
System
Memo/
Answer
第10步
添加下Command 的所需的資料
67
● 這個 Actor 要下 Command 時
所需要的資料、參考依據
Read
Model
Command Event
Actor
68
第11步
添加要遵守的條件、規矩
69
● 例如
○ 身分證號碼不可重複註冊
○ 最少三張圖片,最多12張圖片
Read
Model
Command Event
Actor
Rule
70
第12步
添加如 Wireframe 的畫面輔助
71
● 輔助大家對於事件樣貌的想像
● 可能延伸幫助大家再想到其他未
討論到的業務流程
Read
Model
Command Event
Actor
Rule
從 Big Picture
到 Process Modeling
72
73
Event
Read
Model
Command Process
Actor
Rule
External
System
Memo/
Answer
Event
Event
執行時你可能會遇到這些狀況(1/2)
74
● 沒有使用通用語言
不小心又開始說出的專業名詞,秀一波行話
● 不小心發散到其他領域
大家聚在一起,一定可能會有其他好的聯想
● 體力不支
Event Storming 要求就是要站著開會
執行時你可能會遇到這些狀況(2/2)
75
● UI/UX 來不及出圖
如果真的到Event Storming 才出 Wireframe,後續的Mockup、
Portotype 會非常趕
● UI/UX 出的圖跟 Read Model 有落差
初次執行有可能會忘記互相核對與同步,如果真的有運用
EventStorming 的產出做軟體規劃時,會缺少對應資料的規劃
● 故意提問
○ 就算你是明知道答案的人,也可以故意貼上問題
● 設置階段間的空窗期
○ 讓大家可以有一個「空白時間」做思考
○ 增加N次請人做 Review 的機會
● 預留便利貼空白
○ 實體的 Event Storming 尤其需要
執行時也可以考慮這樣做
76
● UML 圖
● 設計文件
● 開發部署文件
Event Storming
只是可以強化輔助其中一環的工具
它不可以成為它們的替代品
77
對於PM的幫助
78
幫助到RD,就是幫助到PM
79
● 所有人對於產品具備全面的了解
● 可視化產品模型、集思廣益
● 有人又忘記業務流程的時候
○ Event Storming 的圖可以幫你解答
○ 其他 RD 可以幫你解答
● 幫助需求方慢慢瞭解實務上的實作複雜度
○ 從「這個不是很簡單嗎」慢慢前往 「 辛苦了」
80
Why Product Vision Board
When Story Mapping
How Product Backlog
81
Why Product Vision Board
What Event Storming Workshop
When Story Mapping
How Product Backlog
82
執行的方式
怎麼好像跟我之前聽的不一樣
“
83
沒有最佳方法,
你的目的會影響你的流程
Q&A
84
from Slido
85
Q、當領域專家無法參加會議,你是如何確定你對領域的理
解與領域專家的理解是一致的?
在前面需求訪談的時候我們會盡量確保有一致性,另外在簡報中有
提到,只要是我與UI/UX無法回答的,我們絕對不會裝懂,會留下來
請原始需求方來解答,然後藉由邀請他來的時候,也會一起跟他講
一下這些內容。
Q、“引導人”身兼“領域專家”如何確保自己不會陷入討論而
忽略時間與流程掌控
這邊我是先跟我的另一位一起擔任領域專家的說好,我都會先請他
做解答(畢竟我們也已有先有所共識),真的是我才知道的、有需
要我回答的,或是感覺有點錯誤的,我才會做介入,所以反而其實
我主要還是會投入在「引導人」的腳色。
86
Q、我看到你們用了三面牆,我覺得很棒,你們真的是一個
高效的團隊,我想問問,電子化是必要的嗎?電子化後有
什麼困擾?有什麼壞處?
我偏好在前面兩層的時候用實體的,一部分就如簡報中的一種想要
讓需求方「視覺化」的感受他的一個需求是長什麼樣的,另一部分
是會更有「凝聚感」的討論。
後續開始要做第三層(Software Design)的時候,就會更新到 Miro上
面,方便RD可以 duplicate 一份去做。如果一開始就用電子化,除
非真的是因為大家都遠端或是人數不多,不然同一個辦公室又各自
用電腦一起做個人感覺會有點小疏離。
87
Q、有推薦紀錄成電子文件的工具嗎
以Event Storming 的話,如投影片裡提到的,我會推薦Miro。
88
Q、開始與結束的需求範圍如何定義?
假設你的團隊有PM的話,那麼每一個里程碑或是每一個階段應該要
做的項目應該會有一個範圍,不過並不確定你想問的「需求範圍」
是哪個部分的。
那基於這個範圍,如投影片中提到我們的做法,在 Event Storming
的第1-1 會先貼下 領域專家認為這次需求範圍中,最一開始會遇到
的事件跟最後的事件,若後續有人認為其實還有更早的事件,就是
可以貼上後,引導者帶著大家去討論是否真的需要異動這個Event
Storming 的開始與結束。
如果沒有回答到你想要理解的,也歡迎直接聯繫我一起討論交流!
89
Q、什麼原因一定要站著開event storming 呢?
我想這是一個基於人類的惰性而產生的規則。
正常來說大家一定是能坐就坐、能躺就躺😆
EventStorming 的過程就是一個需要大家往前去看 牆壁上的項目、
動手寫跟移動牆壁上的項目,當人開始坐下以後,就會不自主的開
始「不想動」,這樣對於會議上的進行的順暢度會增加阻礙(沒有人
想要寫貼、大家開始把自己當成一個觀眾等)。
如果更嚴格一點,會要求大家不可帶任何電子產品進入這個會議。
90
Q、導入event storming 初期一定不熟悉且不確定是否有
用及正確,因這些都可能有額外的成本,該怎麼說服團隊
和老闆來導入
可能會想先知道,是什麼樣的情境下讓你覺得團隊需要 Event
Storming?你想要解決的問題會是什麼樣的問題?會先需要盤點一
下你的現況,找到需要使用 Event Storming 的原因和想要解決的問
題,這樣你才有所謂的立足點去做「說服」的動作。另外也可以在小
型的 Side Project 上面做引入。
的確 Event Storming 進行的時候是會花時間,但如果在你專案真的
流程挺複雜的情況下,看是希望辛苦在前面還是辛苦在後面。
91
Q、ES 可以寫在工作日誌嗎? ES 2hr
是因為有什麼顧慮所以讓你覺得需要確認「能不能」寫在日誌上?
不太確定會這樣問是因為什麼樣的背景,但如果有需要紀錄我覺得
這樣紀錄應該是沒有問題的。我自己的日誌是都會記錄,而其他人
的部分,我自己也會發會議通知去 booking 他們的時間,然後 RD
在每天立會也都會講到,例如「下午預計要開第 N Part 的 Event
Storming,所以我預計早上處理好 XXXX 事情」。
92
Q、一個專案基本上平均都定位幾次,每次定位平均大約都
多久,感謝
這邊的定位是指什麼?有點不太明白。可以的話歡迎在slide share
下做comment ,或是歡迎直接聯繫我一起交流 :)
93
Q、Event storming 後產出的功能,有遇到無法驗收的情
況嗎?
如果你的無法驗收是說沒做完,我想應該不是因為用了Event
Storming 才產生的問題。但如果你的無法驗收像是前面的問題提到
的「怎麼確定跟真正的需求方認知一致」,不變的法則就是盡量持
續溝通。我們公司剛好需求方就在自己公司,所以相對容易找到他
們做討論與對齊。
94
95
Contact Me 聯絡我
FB: imsylviaymc 楊孟真
Linkedin: pmsylvia
泰爾科技股份有限公司

Contenu connexe

Tendances

商流物流金流.pdf
商流物流金流.pdf商流物流金流.pdf
商流物流金流.pdfZenji Kanzaki
 
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)Takuto Wada
 
No011-01-Suc3rum-20100225
No011-01-Suc3rum-20100225No011-01-Suc3rum-20100225
No011-01-Suc3rum-20100225Sukusuku Scrum
 
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer
オブジェクト指向プログラミング入門 -- Java object-oriented programming primerオブジェクト指向プログラミング入門 -- Java object-oriented programming primer
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer増田 亨
 
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーWhere狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーyoku0825
 
リーンなコードを書こう:実践的なオブジェクト指向設計
リーンなコードを書こう:実践的なオブジェクト指向設計リーンなコードを書こう:実践的なオブジェクト指向設計
リーンなコードを書こう:実践的なオブジェクト指向設計増田 亨
 
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方増田 亨
 
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方増田 亨
 
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~Kenji Hiranabe
 
リッチなドメインモデル 名前探し
リッチなドメインモデル 名前探しリッチなドメインモデル 名前探し
リッチなドメインモデル 名前探し増田 亨
 
RDRAにおける合意形成の仕組み
RDRAにおける合意形成の仕組みRDRAにおける合意形成の仕組み
RDRAにおける合意形成の仕組みZenji Kanzaki
 
毎日が越境だ!
毎日が越境だ!毎日が越境だ!
毎日が越境だ!増田 亨
 
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanフロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanItsuki Kuroda
 
アジャイルレトロスペクティブズ
アジャイルレトロスペクティブズアジャイルレトロスペクティブズ
アジャイルレトロスペクティブズYagi Natsuki
 
アジャイル開発とメトリクス
アジャイル開発とメトリクスアジャイル開発とメトリクス
アジャイル開発とメトリクスRakuten Group, Inc.
 
ペアプログラミング ホントのところ
ペアプログラミング ホントのところペアプログラミング ホントのところ
ペアプログラミング ホントのところTakuto Wada
 
HBaseとRedisを使った100億超/日メッセージを処理するLINEのストレージ
HBaseとRedisを使った100億超/日メッセージを処理するLINEのストレージHBaseとRedisを使った100億超/日メッセージを処理するLINEのストレージ
HBaseとRedisを使った100億超/日メッセージを処理するLINEのストレージLINE Corporation
 
ドメインオブジェクトの設計ガイドライン
ドメインオブジェクトの設計ガイドラインドメインオブジェクトの設計ガイドライン
ドメインオブジェクトの設計ガイドライン増田 亨
 

Tendances (20)

商流物流金流.pdf
商流物流金流.pdf商流物流金流.pdf
商流物流金流.pdf
 
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
 
おやつ神社
おやつ神社おやつ神社
おやつ神社
 
No011-01-Suc3rum-20100225
No011-01-Suc3rum-20100225No011-01-Suc3rum-20100225
No011-01-Suc3rum-20100225
 
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer
オブジェクト指向プログラミング入門 -- Java object-oriented programming primerオブジェクト指向プログラミング入門 -- Java object-oriented programming primer
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer
 
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーWhere狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキー
 
リーンなコードを書こう:実践的なオブジェクト指向設計
リーンなコードを書こう:実践的なオブジェクト指向設計リーンなコードを書こう:実践的なオブジェクト指向設計
リーンなコードを書こう:実践的なオブジェクト指向設計
 
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
 
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
 
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
 
リッチなドメインモデル 名前探し
リッチなドメインモデル 名前探しリッチなドメインモデル 名前探し
リッチなドメインモデル 名前探し
 
RDRAにおける合意形成の仕組み
RDRAにおける合意形成の仕組みRDRAにおける合意形成の仕組み
RDRAにおける合意形成の仕組み
 
毎日が越境だ!
毎日が越境だ!毎日が越境だ!
毎日が越境だ!
 
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanフロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkan
 
アジャイルレトロスペクティブズ
アジャイルレトロスペクティブズアジャイルレトロスペクティブズ
アジャイルレトロスペクティブズ
 
アジャイル開発とメトリクス
アジャイル開発とメトリクスアジャイル開発とメトリクス
アジャイル開発とメトリクス
 
ペアプログラミング ホントのところ
ペアプログラミング ホントのところペアプログラミング ホントのところ
ペアプログラミング ホントのところ
 
HBaseとRedisを使った100億超/日メッセージを処理するLINEのストレージ
HBaseとRedisを使った100億超/日メッセージを処理するLINEのストレージHBaseとRedisを使った100億超/日メッセージを処理するLINEのストレージ
HBaseとRedisを使った100億超/日メッセージを処理するLINEのストレージ
 
Tackling Complexity
Tackling ComplexityTackling Complexity
Tackling Complexity
 
ドメインオブジェクトの設計ガイドライン
ドメインオブジェクトの設計ガイドラインドメインオブジェクトの設計ガイドライン
ドメインオブジェクトの設計ガイドライン
 

Similaire à DDD TW Conference 2020 與RD一起跳坑DDD (20201127)

SRE Study Notes - Opening, CH1
SRE Study Notes - Opening, CH1SRE Study Notes - Opening, CH1
SRE Study Notes - Opening, CH1Rick Hwang
 
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑Chang Shih-Chieh
 
Why Scrum (敏捷式專案管理)
Why Scrum (敏捷式專案管理)Why Scrum (敏捷式專案管理)
Why Scrum (敏捷式專案管理)Yu Wei Shang
 
為了精準估算,你必須付出什麼代價?
為了精準估算,你必須付出什麼代價?為了精準估算,你必須付出什麼代價?
為了精準估算,你必須付出什麼代價?William Yeh
 
Agile scrum in startup
Agile scrum in startup  Agile scrum in startup
Agile scrum in startup Len Chang
 
Pm bar首刊d v1.0
Pm bar首刊d v1.0Pm bar首刊d v1.0
Pm bar首刊d v1.0磊 石
 
Scrum essential
Scrum essentialScrum essential
Scrum essential國昭 張
 
Getting Real
Getting RealGetting Real
Getting Realrogerwang
 
Scrum gathering 2012 shanghai 产品管理及用户体验 分会场:敏捷的hard模式 产品经理视角(窦涵之)
Scrum gathering 2012 shanghai 产品管理及用户体验 分会场:敏捷的hard模式 产品经理视角(窦涵之)Scrum gathering 2012 shanghai 产品管理及用户体验 分会场:敏捷的hard模式 产品经理视角(窦涵之)
Scrum gathering 2012 shanghai 产品管理及用户体验 分会场:敏捷的hard模式 产品经理视角(窦涵之)LetAgileFly
 
Ops as Code using Serverless
Ops as Code using Serverless Ops as Code using Serverless
Ops as Code using Serverless Rick Hwang
 
2012/05/23 AU Talk - 讓事情發生
2012/05/23 AU Talk - 讓事情發生2012/05/23 AU Talk - 讓事情發生
2012/05/23 AU Talk - 讓事情發生appuniverz
 
Introduction to Agile & Scrum
Introduction to Agile & ScrumIntroduction to Agile & Scrum
Introduction to Agile & ScrumPicker Weng
 
開源教 教我 Odoo 管理 ERP 和 CRM
開源教 教我 Odoo 管理 ERP 和 CRM開源教 教我 Odoo 管理 ERP 和 CRM
開源教 教我 Odoo 管理 ERP 和 CRMTsungWei Hu
 
成為一位有效率的產品經理-王姵瑾
成為一位有效率的產品經理-王姵瑾成為一位有效率的產品經理-王姵瑾
成為一位有效率的產品經理-王姵瑾CAREhER CAREhER
 
Mopcon 2021 Scrum 是新的死亡行軍嗎?
Mopcon 2021   Scrum 是新的死亡行軍嗎?Mopcon 2021   Scrum 是新的死亡行軍嗎?
Mopcon 2021 Scrum 是新的死亡行軍嗎?Jen-Chieh Ko
 
O.R.I.D 初探 - 新竹敏捷分享.pdf
O.R.I.D 初探 - 新竹敏捷分享.pdfO.R.I.D 初探 - 新竹敏捷分享.pdf
O.R.I.D 初探 - 新竹敏捷分享.pdfJen-Chieh Ko
 
银弹!银弹! 徐毅@Italk salon 2011
银弹!银弹! 徐毅@Italk salon 2011银弹!银弹! 徐毅@Italk salon 2011
银弹!银弹! 徐毅@Italk salon 2011Yi Xu
 
敏捷開發分享
敏捷開發分享敏捷開發分享
敏捷開發分享東城 楊
 
Scrum敏捷实施实例讲解
Scrum敏捷实施实例讲解Scrum敏捷实施实例讲解
Scrum敏捷实施实例讲解Brenda Bao
 

Similaire à DDD TW Conference 2020 與RD一起跳坑DDD (20201127) (20)

SRE Study Notes - Opening, CH1
SRE Study Notes - Opening, CH1SRE Study Notes - Opening, CH1
SRE Study Notes - Opening, CH1
 
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑
 
Why Scrum (敏捷式專案管理)
Why Scrum (敏捷式專案管理)Why Scrum (敏捷式專案管理)
Why Scrum (敏捷式專案管理)
 
為了精準估算,你必須付出什麼代價?
為了精準估算,你必須付出什麼代價?為了精準估算,你必須付出什麼代價?
為了精準估算,你必須付出什麼代價?
 
Agile scrum in startup
Agile scrum in startup  Agile scrum in startup
Agile scrum in startup
 
Pm bar首刊d v1.0
Pm bar首刊d v1.0Pm bar首刊d v1.0
Pm bar首刊d v1.0
 
Scrum essential
Scrum essentialScrum essential
Scrum essential
 
Getting Real
Getting RealGetting Real
Getting Real
 
Scrum gathering 2012 shanghai 产品管理及用户体验 分会场:敏捷的hard模式 产品经理视角(窦涵之)
Scrum gathering 2012 shanghai 产品管理及用户体验 分会场:敏捷的hard模式 产品经理视角(窦涵之)Scrum gathering 2012 shanghai 产品管理及用户体验 分会场:敏捷的hard模式 产品经理视角(窦涵之)
Scrum gathering 2012 shanghai 产品管理及用户体验 分会场:敏捷的hard模式 产品经理视角(窦涵之)
 
Ops as Code using Serverless
Ops as Code using Serverless Ops as Code using Serverless
Ops as Code using Serverless
 
Scrum培训
Scrum培训Scrum培训
Scrum培训
 
2012/05/23 AU Talk - 讓事情發生
2012/05/23 AU Talk - 讓事情發生2012/05/23 AU Talk - 讓事情發生
2012/05/23 AU Talk - 讓事情發生
 
Introduction to Agile & Scrum
Introduction to Agile & ScrumIntroduction to Agile & Scrum
Introduction to Agile & Scrum
 
開源教 教我 Odoo 管理 ERP 和 CRM
開源教 教我 Odoo 管理 ERP 和 CRM開源教 教我 Odoo 管理 ERP 和 CRM
開源教 教我 Odoo 管理 ERP 和 CRM
 
成為一位有效率的產品經理-王姵瑾
成為一位有效率的產品經理-王姵瑾成為一位有效率的產品經理-王姵瑾
成為一位有效率的產品經理-王姵瑾
 
Mopcon 2021 Scrum 是新的死亡行軍嗎?
Mopcon 2021   Scrum 是新的死亡行軍嗎?Mopcon 2021   Scrum 是新的死亡行軍嗎?
Mopcon 2021 Scrum 是新的死亡行軍嗎?
 
O.R.I.D 初探 - 新竹敏捷分享.pdf
O.R.I.D 初探 - 新竹敏捷分享.pdfO.R.I.D 初探 - 新竹敏捷分享.pdf
O.R.I.D 初探 - 新竹敏捷分享.pdf
 
银弹!银弹! 徐毅@Italk salon 2011
银弹!银弹! 徐毅@Italk salon 2011银弹!银弹! 徐毅@Italk salon 2011
银弹!银弹! 徐毅@Italk salon 2011
 
敏捷開發分享
敏捷開發分享敏捷開發分享
敏捷開發分享
 
Scrum敏捷实施实例讲解
Scrum敏捷实施实例讲解Scrum敏捷实施实例讲解
Scrum敏捷实施实例讲解
 

DDD TW Conference 2020 與RD一起跳坑DDD (20201127)