Slide 1

Slide 1 text

Event Storming software design as a cooperative game Modeling-Kai 2020.08.02

Slide 2

Slide 2 text

現状と今日進めること ● 前回やったこと ○ Big Picture で全体を視覚化した。 ○ どんな Command から どんな Event が発生していくかを書き出した。 ● 今回やること ○ Cooperative Game で間のプロセスのモデリングを行う。

Slide 3

Slide 3 text

Vision から詳細化、そして戻る https://www.slideshare.net/ziobrando/software-design-as-a-cooperative-game-with-eventstorming/83 今日は ここ

Slide 4

Slide 4 text

今日の進め方 ● Big Picture の Events をもとに、Cooperative Game を進める。 ● プロセスの開始から、順に付箋を並べていく。 ○ Command → Event の 間を埋めていく。 ○ カラーベースの文法にしたがって、順番に並べる。 ● Rush to the Goal. ○ まずは 1つのHappy Path を通す。複数Pathを並行して進めない。 ○ 疑問点、分岐は一旦 HotSpot の付箋を置いて進める。

Slide 5

Slide 5 text

Cooperative Game を使いたくなる状況 ● Process Modeling の実施方法 ● Big Picture を書いてみて ○ そこで見つかる複雑な問題に、明確な答えはない。 ○ 背景の違うメンバー全員で合意を取るのは難しい。 ● 共通のゴールを持ちたい。

Slide 6

Slide 6 text

Cooperative Game: Model Sessionのやり方 進め方は 3通り (組み合わせOK) ● 頭から : ユーザからのコマンド、または外部ソースのイベントから ○ わかりやすい、自然なストーリー ○ 分岐が一番起きやすい。 Rash to the Goal が大事かも。 ● 後ろから : Event + People + Value から戻る ○ 無駄がない ○ 経験がいる、結果が明確である必要がある。 ● ごちゃごちゃに : イベント周りのブレストから。 ○ 現状の矛盾を出しやすい、議論がなければスケルトンを作りやすい。 ○ 議論が暴走しやすい。散らかる。

Slide 7

Slide 7 text

Rush to the Goal 1. まずは最短ルートのゴールへの道筋を声に出していう。 2. 異論をキャプチャして、ホットスポットとして挙げる。 a. 代替パスをホットスポットとして全て挙げる。 b. とにかく一つゴールに向かう。 c. 終わったら、ホットスポットを一つ 選んで再度行う。 https://www.slideshare.net/ziobrando/software-design-as- a-cooperative-game-with-eventstorming/53 https://www.slideshare.net/ziobrando/software-design-as- a-cooperative-game-with-eventstorming/56

Slide 8

Slide 8 text

Game Rules: Cooperative Game ルールは4つ。(Software Design まで入ると、5つ目が増える) 1. 全てのプロセスパスが完了する 2. カラーベースの文法に則っている 3. 全てのステークホルダーが合理的に満足している 4. 全てのホットスポットに対処できている。 5. アグリゲートが一貫している。

Slide 9

Slide 9 text

プロセスパスが完了するとは? ● ビジネスプロセスは、一連ステップだけでは終わらない ○ 最終的にメインストリームに戻るものもある。 ○ 異なる終了条件で終了するものもある。 ● プロセスのあるべき姿 ○ 開始: 与えられたトリガー(Command あるいは 外部Event) ○ 終了: Eventと Model の組み合わせ ■ Event: System Happy (これ以上やることない) ■ Model: User Happy (終わったと認識できてる) ● People + Value で表現 ○ 「可能な限り幸せ」な状態で終わる。 ■ 例: キャンセルは全員にとっての完全な幸せでないが、可能な限りの幸せ。

Slide 10

Slide 10 text

カラーベースの文法 1:やること ● 大きくは以下を実施していく。 ○ 青色(Command)とオレンジ(Event)の間に、ピンク(System) を置く ○ オレンジ(Event) と 青色 (Command) の間に、薄紫色(Policy) を置く https://www.slideshare.net/ziobrando/software-design-as-a-cooper ative-game-with-eventstorming/40 https://www.slideshare.net/ziobrando/software-design-as-a-cooper ative-game-with-eventstorming/67

Slide 11

Slide 11 text

カラーベースの文法 2:色見本 https://www.slideshare.net/ziobrando/software-design-as-a-cooperative-game-wit h-eventstorming/40 青: Command オレンジ: Event ピンク: System 薄紫色: Policy 緑色: Read Model 黄色: People 蛍光ピンク: Hot Spot (紫) (45°傾ける) ----------------- 赤/緑の小さい付箋: Values 薄黄色: Aggregate https://baasie.com/2020/07/16/eventstormin g-core-concepts-glossary-and-legend/

Slide 12

Slide 12 text

カラーベースの文法 3:付箋の補足(Event) [Event] 常に以下4つの状況の結果 トリガー ユーザインタラクション ユーザ起点。Command, System が手前にくる。 複数イベントがトリガーされることもある。 外部システム センサーとか。一定間隔サンプルとかなら、時間トリガー。 時間 分周期のタイマーとか、1日の終わりにとかタイムアウトとか。 特殊ケースがあるなら、ポリシーでカバーする。 カスケード あるイベントが起きると、このイベントもというようなもの。 間にポリシーなどが挟めるかもしれない。

Slide 13

Slide 13 text

カラーベースの文法 4:付箋の補足(Command, People) [Command] ● システムで起こっているアクション。ユーザの意思決定。 ● 呼び方はチームで。Action でも Intention でも。 ● コマンドは完了を意味しない。 [People] ● まずは何かをする人を表す。利用者も、内部ユーザも。 ● 異なるタイプの人、異なるステップで分けるのが有効なこともある。 ○ 通勤目的の切符購入、休暇目的の切符購入。 ○ モデルに欠陥が出てきたとき、差別化する対応はよくある。

Slide 14

Slide 14 text

カラーベースの文法 5:付箋の補足(System, ReadModel) [System] ● 一般化して書くのはよくない。明示的にする。 ○ Social Media < Twitter, Facebook (代表的なものを書く) ● 対話型システムの場合、横に長くなって行きがち。 ○ Systemの後ろにEventを並べることがおすすめ。対話結果を重視する。 [ReadModel] ● 与えられた決定を行うために必要な情報。 Event 1 System Event 2 Event 3

Slide 15

Slide 15 text

カラーベースの文法 6:付箋の補足(Policy) [Policy] ● イベントに対するリアクション。 ○ 暗黙的に行われるもの ○ 明示的に行われるもの ○ 自動対応 ● イベントとコマンドの間にはなくてはならないもの。 ○ 明白すぎて気付きにくいこともあるが、2つの間には常にビジネス上の意思決定がある。 ● 名前に時間をかけすぎないつけなくてもいい。 ○ 何をするか、まずは実施することを声に出す。それでも名前が決まらないこともある。 ● 嘘が多く混ざる場所。 ○ ポリシー通りの実態があるとは限らない。 ○ 議論の余地のあるトピックが多くある。 ● 「いつも」「すぐ」と合わせて読む。 ○ コーナーケースが見えてくる。

Slide 16

Slide 16 text

カラーベースの文法 7:付箋の補足(Value, Hotspots) [Value] ● それぞれのStep で作られる、または削除される。 ○ わかりやすいのはお金 ○ なんらかの機会、不一致状況。時間、ストレス、満足。 ● 原書だと2020.8.2時点では記述なし。 [HotSpots] ● 矛盾、おかしいところ、質問を書く。 ● Rush to the Goal を使って一つずつ解決していく。(次のステップ) People :( People :)

Slide 17

Slide 17 text

Model Session 中盤の対処 ● 目に見えないものは口にしない。 ● Rush to the Goal.

Slide 18

Slide 18 text

参考 ● Introducing EventStorming ○ https://leanpub.com/introducing_eventstorming ● Software design as a cooperative game with EventStorming ○ スライド: https://www.slideshare.net/ziobrando/software-design-as-a-cooperative-game-with-eventstorming ○ 動画: https://www.youtube.com/watch?v=awyMC9PZNfc (AgileByExample 2019) ● 新しいモデリング手法: EventStorming (イベントストーミング) をはじめるための準備 ○ https://yoskhdia.hatenablog.com/entry/2018/11/09/200556 ● EventStorming; Core concepts, glossary and legend ○ https://baasie.com/2020/07/16/eventstorming-core-concepts-glossary-and-legend/