iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 7
3

Event Storming Part 1 - 簡介與事前準備

cover

隨著現代軟體的服務越來越複雜,開發人員要面對的商業邏輯的複雜度也跟著起飛。商業團隊的需求時常在變,而當開發人員只能照著模糊又瑣碎的需求書摸石頭過河時,專案失敗的風險跟著提升、團隊間的隔閡也跟著擴大。

事實上,一項軟體產品所需要的領域知識往往是跨團隊的,沒有任何單一團隊可以掌握它的全貌。但要如何媒合不同背景知識的人做有效溝通非常的困難。幸好在 2013 年,一位義大利人 Alberto Brandolini 發明了 Event Storming 工作坊提供了一個不錯的解決方案。

本主題分為四篇,分為 「事前準備」「展開風暴」、**「進入軟體設計」**以及 「可以做得更好的部分」,即使沒有學過 DDD 也可以上手。同時先聲明,使用事件風暴不代表一定要採用 DDD,只要你有意想促進團隊的溝通與領域知識的理解, Event Storming 永遠都是你的選項之一!

本篇涵蓋內容:

  • Event Storming 概覽
  • Event Storming 應用場景
  • Event Storming 事前準備

註:在本系列中,我會用英文如 Event、Command 來指便利貼,而如果只是單純敘述事情我會用中文如事件來描述。


Event Storming 概覽

Event Storming 是一個透過高度互動的方式,將企業或系統的商業流程視覺化,最終協助建立軟體模型的工作坊。簡單來說就是探索功能、找出盲點、建立共識。

跑完後,與會者們都將會獲得:

  • 對於商業流程的共同理解,包含名詞使用、責任範圍、使用者體驗等。
  • 一份整體流程的概覽圖 (Big Picture),事後也可以數位化製成文件。
  • 可以找出商業流程中的核心價值、風險與機會。
  • 一個導入 DDD 的好起點。

整個過程中會用便利貼來視覺化流程,不會有艱深的技術詞彙或商業報表,只會有團隊學習與多元觀點的對話。實際跑起來會像是這樣:

適合的對象

如果你的工作流程出現以下症狀,請儘早服用 Event Storming:

  • 規格書的知識瑣碎、難以理解、沒有明確架構。
  • 討論時常陷入細節的爭論,或是過多的技術詞彙讓主題失焦。
  • 開發到一半還在理解功能在幹嘛。
  • 等到上線了才發現一堆 Bug。

Event Storming 應用場景

使用的場景點從巨觀到微觀:

  1. Big Picture 綜觀全局 ── 釐清混亂的商業流程,凸顯出合作關係、邊界、責任歸屬與不同利益相關者的觀點。
    • 邀請任何有興趣的人、不用限制討論範圍
    • 找出瓶頸、核心價值甚至是新的解決方案
    • 主要以 Event、System、Question 為主。
    • 適合新創或小團隊(人少、技術債少)
  2. Process Modelling 流程展示 ── 討論特定功能流程,以確保沒有理解錯誤。
    • 有明確範圍,所以路徑越完整越好。
    • 在細節中找出流程的 Bug,並且每個 Bug 都需要被處理。
    • 再加上 Event、Actor、Command、System、Policy、Read Model。
  3. Software Design 軟體設計 ── 利用前面的產出進一步設計軟體
    • 加入 Aggregate、Bounded Context 建立模型邊界。
    • 對於用詞更加精準

你可以照順序從 1 至 3,或是混合使用皆可。

https://ithelp.ithome.com.tw/upload/images/20190924/20111997zEwTb8tQuA.png
(source: https://www.slideshare.net/ziobrando/50000-orange-stickies-later)

此外, Event Storming 也可以讓新進員工快速上手領域知識。想知道更仔細的,可以看這部 GOTO 2018 • 50.000 Orange Stickies Later • Alberto Brandolini

事前準備

一場好的 Event Storming,人事時地物缺一不可。

場地設置

  • 找到一面限制最少的表面來進行活動。
    不管是牆面、窗邊甚至用多面移動白板組成都可以。你無法預測最後的產出有多少,所以盡你所能,不要因為空間而限制活動的品質。
  • 在表面上貼上大型畫紙捲方便收納產出以及進行另一場 Event Storming。
  • 最大化活動空間。將現場的雜物移開,不過可以留下一張小桌子放道具。
  • 一定要將椅子移走。經驗中,只要有人坐下,就會開始沈默,最後自我放逐。
  • (建議)一面白板或海報寫上名詞定義清單。這場會議中的對話都要遵照清單上的用詞。
  • 提供幾張有圖示標明 (Legend) 的海報紙。可以參考以下圖示:

便利貼種類與互動模式:
legend
(source: https://leanpub.com/introducing_eventstorming)

每種便利貼的詳細用法:

(source: https://medium.com/@springdo/a-facilitators-recipe-for-event-storming-941dcb38db0d)

當你準備好場地,大概就會長這樣子。

setup
(source: https://leanpub.com/introducing_eventstorming)

邀請對的人

這是最重要的元素。一場 Event Storming 會需要以下角色:

  • 主持人 Facilitator:
    建議一定要有一名參與者負責主持會議進行、推動議程討論。要嚴格注意時間與流程。最好不要跟 Domain Expert 重複。
  • 領域專家(們) Domain expert(s):
    專案的主要推動者,或是擁有足夠領域知識的人,建議最好有一定的決定權,在陷入泥沼時才可以做出決定。如果是新創領域,可以事先做好使用者訪談或是找使用者來參加。可以不只一名。
  • 其他利益相關者 Other Stackholder:
    可能是參與專案的工程師、設計師,也可能任何能提供專業意見的人士如業務、商業分析師甚至是主管。

通常一場 Event Storming 有 6-8 人就可以進行一場精彩的混戰交流,至於超過 10 人以個人經驗來說,除非主持人經驗豐富,否則場面就會開始混亂起來。

火力展示你的道具

你需要「非常多」的便利貼。千萬不要因為省錢就少買某個顏色,因為每個顏色都有各自的意義,無法互相替代。你會需要以下顏色的便利貼:

  • 橘色(正方形 76*76):Event 事件
  • 藍色(正方形):Command 命令
  • 紫色(長方形): Policy/Process 商業政策/流程
  • 黃色(小張長方形):Actor 角色
  • 黃色(長方形):Aggregate 聚合
  • 粉紅色(長方形):System 外部系統
  • 紅色(正方形):Hotspot 熱點
  • 紅色(小張長方形):Problem 疑問
  • 綠色(小張長方形):Opportunity 機會
  • 綠色(正方形):Read Model 資料讀取模型
  • 白色(大張正方形):Uset Interface 使用者介面

以上顏色皆可以自行調整,不過 Event 還是熟悉的橘色最對味。接著還有其他道具:

  • 簽字筆。每個人至少一支。
  • 一隻粗一點的奇異筆。
  • (推薦)計時器。可以幫助時間控管。
  • (選用)投影設備。方便讓領域專家解說需求。

可以參考這張購物清單

滿滿的能量

Event Storming 超級耗費心力,可以喝杯咖啡後再上路。或是在周圍放些小點心供與會者取用。

線上替代方案

如果你想要愛地球減少浪費,或是時間跟人都擠不出來,可以考慮使用線上版工具 Miro

https://ithelp.ithome.com.tw/upload/images/20190923/20111997aljnGJqOEr.png
(Miro 使用示意圖)

Summary

Event Storming 是一個知識交流、打破穀倉效應 (silo effect) 的絕佳場所。同時對於團隊來說是一個非常好的「階段式學習」過程。過程中不但可以提早發現盲點,也能讓未來開發專注在核心功能上。最重要的事,他可以讓原本各自為政的團隊有機會聚在一起達成共識。從商業層面來看, Event Storming 讓我們綜覽全局來辨識出問題的癥結點,並專注在核心競爭力上;從開發層面來看,Event Storming 提供了一個有效的建構軟體方向,讓開發更有自信且減少貧血模型的使用。甚至可以將成果導入 DDD Strategic Design (DDD 剛出來時,就是因為溝通難度太高讓很多人放棄 Strategic Design 結果讓導入成效事倍功半)。

除此之外,使用 Event Storming 除了提升開會的效率,更重要的是帶來個人的成長。一名開發者的價值並不僅僅在於會用多少技術,也與工作領域的熟悉程度有高度相關。當你對於某項產業的理解越深刻,加上技術能力,你就越難被取代。甚至,你可以從技術人員升為顧問,一同參與重要的商業決策。

Resources

以下都是非常好的學習資源,每篇都值得一讀:


上一篇
戰略設計:重點回顧以及比喻
下一篇
Event Storming Part 2 - 風暴展開
系列文
Think in Domain-Driven Design30

尚未有邦友留言

立即登入留言