[尋求一致性]產生活動與步驟

軟體開發者總是花費大量的時間在學習，學習那些他們未知的東西，這與其他工作截然不同，因為我們的每一次總是我們的第一次(儘管在外人看來都是在敲鍵盤)
— Alberto Brandolini

本節快速導覽

拆解工作故事--產生活動與步驟
當我們都站在領域知識的門口前--事件風暴
事件風暴的優點與挑戰
總結

Align後的下一步是具體化 — 產生活動與步驟

拆解工作故事 — 產生活動與步驟

藉由工作故事找出用戶的需求、動機、情境、目標等資訊後，還需要進一步將工作故事展開成更具體的活動與相對應的步驟

工作故事 — 活動 — 步驟層級示意圖

活動指的是為達成目的所付出的勞務，步驟是分解自活動的更小的工項單位
一旦所有步驟完成，意味著其上的活動完成；一旦所有活動完成，意味著其上的需求與目的被完成

書中示例表格部分內容統整

從活動解構出步驟需要對API有深入的了解，而這需要借助外部領域專家(subject matter expert, SME)的專業知識，但也可以在用戶中尋找合適的人擔任，在設計時必須注意:

• 在把活動解構成步驟時，務必確保對活動的動機、情境、問題有足夠理解，讓每個步驟都是明確不存在任何假設的
• 每個活動的複雜度有所差異，所以一個活動拆成多個步驟或無法拆解成更細的步驟都是正常的，重點是每個步驟可以被一個人獨力搞定
  瞬間想到SOLID裡面的單一職責原則 ヾ(•ω•`)o

當我們都站在領域知識的門口前 — 事件風暴

當然不一定在每次設計時，都能夠對專業領域知識十分熟悉，而事件風暴(EventStorming)就是一種幫助我們實現MECE，取得理解與共識而不會鬼打牆╰(￣ω￣ｏ)的方法

EventStorming可以將一個未知領域的各個層面，商業流程、需求、事件等以具象化的方式呈現，使成員們增進某個特定領域的知識與凝聚共識

事件風暴五大步驟

• 區分領域事件
  區分工作中的領域事件(business domain event)，每個人用便利貼寫上領域事件貼在看板上
  主持人可以幫助大家梳理每張便利貼的因果關係，直到所有便利貼的因果關係都清楚明確

brainstorming產出可能出現的business domain event

• 建立事件敘述
  將便利貼依照事件發生的順序重新調整，去掉重複的便利貼，並將便利貼依照時間順序貼在看板上
  為了避免過度發散，當出現事件分支時，可以將分支擺在事件主線下方做為參考主線的定義感覺可以參考MVP思維o((>ω< ))o
若出現難以取得定論的便利貼事件，可以將其視為熱點(hotspot)留待後續處理

• 回顧事件敘述與劃分事件範圍
  派人從頭到尾敘述一遍便利貼的事件，如果在敘述途中發現還是有不清楚的地方需要及時補正
  在此步驟也要統一詞彙的意思，並修正舊有詞彙，才有辦法用統一的詞彙與語境在後續ADDR流程中做一致的描述

• 補充領域知識
  這一步可以用其他顏色的便利貼來補完其他資訊
• 回顧最終的事件描述
  最後再回顧一次全部的便利貼，逐一確認每張便利貼沒有任何遺漏的地方，重要事件與觸發條件都有被正確標示

完成事件風暴後，妥善收納看板，以供未來有疑問時可以拿出來回顧

事件風暴的優點與挑戰

事件風暴能為我們帶來以下好處:

• 將問題建立成模型，利用模型工具建立成員對需求與範圍的共同理解
• 建立成員對工作流程、商業規則、主客觀環境限制的共同理解
• 建立一致性詞彙，增加溝通效率
• 在實際設計與開發進行前，先對更原始的需求與動機做一次梳理
• 找出事件的邊界、界定事件的範圍，後面的API設計可依照此處找出的邊界與範圍進行分類，分類後更易交由不同的小組平行實作，降低依賴、提高效率

組織一場事件風暴時也需要注意以下挑戰，避免失敗風險:

• 在API或微服務開始設計或實作前舉辦，才有可能將客戶導向思維導入後續設計中，並驗證假設與澄清疑問
• 所有角色都要參與，最好每位參與者都要對事件風暴的議題有一定熟悉度，並且最好有該主題現行的標準文件，用於事後相互驗證
• 事件風暴的議題規模不要太大，有限的規模才有可能在有限的人力與時間內克服有限的問題
• 若連問題需求都不明確不要急著通靈(X，先使用工作故事梳理用戶需求與動機，再舉辦事件風暴
• 要得到非技術團隊的支持與參與，不然技術團隊自己在角落玩事件風暴，獲得的共識也只是技術團隊的共識，無法做到組織的一致性就會互相傷害(X
• 如果已經被DDL追著跑或已經release的軟體，建議不要跑事件風暴
  在scrum中軟體的交付遠大於文件

總結

產品服務的開發離不開對特定商業領域知識的理解，藉由事件風暴讓大家共同參與，並在過程中凝聚共識與對齊目標