Upgrade to Pro — share decks privately, control downloads, hide ads and more …

EventStorming SoftwareDesign as a Cooperative Game

98lerr
August 02, 2020

EventStorming SoftwareDesign as a Cooperative Game

2020.8.2 にモデリング会で EventStorming のうちの ProcessModeling を行った際、参考にした資料です。

98lerr

August 02, 2020
Tweet

More Decks by 98lerr

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  7. 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

    View Slide

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

    View Slide

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

    View Slide

  10. カラーベースの文法 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

    View Slide

  11. カラーベースの文法 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/

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  18. 参考
    ● 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/

    View Slide