學習 Event Storming 事件風暴的感想

學習 Event Storming 的一點感想

前言

近幾年，工作坊非常流行，也順便分享我的感想。

先說明，Event Storming 的初始概念非常棒，小編也從不排斥各種軟體開發的方法論與流程，但在接觸了 Event Storming 後，對於軟體開發的初心者來說，當中可能有兩個小陷阱。

Event Storming

最近一直在看 Event Storming ，也曾聽聞有人說用事件風暴來取代 UML Methodology，但 UML 充其量只是個 Methodology，你又不是導入 RUP，所以我特別強調這個 XDD，那麼..言歸正傳、的確，事實上我是同意一項軟體產品所需要的領域知識往往是跨團隊的，沒有任何單一團隊可以掌握它的全貌，但要如何媒合不同背景知識的人做有效溝通非常的困難，所以即便是求討論會議除了需要各利害關係人參與之外、客戶能加入討論更能釐清許多需求認知的問題、避免走過多冤枉路，UML 各個圖形的繪製也必須是團隊一同繪製、而不是單一個 Member 來繪製，因為對於商業流程的理解、包含名詞的使用、團隊有共識需使用客戶端的專有名詞與語言。

看完 Event Storming 我倒認為重點不在於 Event Storming，透過 Event Storming 確實很容易找出商業流程的核心價值、風險、與機會，但注意了，我覺得這裡有一個小陷阱就是，重點是在於〔團隊 與 多方角色 所進行討論的『這一個過程』中，便利貼只是風暴過程中的工具而已〕。

我們進行需求討論的的『多方討論』即是邀請任何有興趣的人、也不用限制討論範圍，但這裡還有第二個陷阱，在討論特定功能流程 Process Modeling 時，當你有了 Command、Event、Actor、System、Policy 或 Read Model... 等，準備進行 Software Design 軟體設計時，這裡我非常推崇 Aggregate 與 Bounded Context 等概念，因為這算是 OOA(Object Oriented Analysis) / OOD(Object Oriented Design) 的缺陷部分（OOAD 不是沒有缺陷、近期學習 DDD 時我發現可以補足 OOAD 不足之處），但我要講的第二個小陷阱是，當你在進行 Software Design 時，仍然是回歸到基礎 OOD，就像我先前說的，如果您撰寫的程式語言是物件導向 OO 的程式語言，那你就還是在進行 OO 的軟體設計，OO 的軟體設計就脫離不了 SOLID 物件導向五大設計原則、DI (Dependency Injection)、IoC (Inversion Of Control) 控制反轉、以及實際軟體開發需理解的 GoF 整理的 Design Patterns 等，這些都是實作上必備的基礎，甚至這些類別的分析 + 如何產生也可以使用 UML，所以我另外一個要說明的就是，Event Storming 與 UML 沒有什麼誰取代的問題，細部底層軟體架構設計 UML 仍然是非常好描述架構的圖形表示法 Notations 與 Syntax，對了，再者，在事件風暴下所有細節、需求方向都清楚的情況下，雖然你不會需求不確定性而產生的技術債，但若程式語言或框架不熟悉，仍然有可能產生架構類型的技術債。

結論：

事件風暴最大好處，可增加團隊向心力 + 共識，大家一起把事情做好，專案透明化、敏捷、共同解決問題，除了提升效率外、也大大降低專案的失敗率。

我們仍別忘了軟體專案開發最終產出還是程式碼、能夠賺錢的也還是程式碼、最後會有技術債把你壓垮的可能也還是程式碼。前期的 SA 一個人的需求發想不如團隊與所有關係人的多方討論與釐清需求方向與流程，同時加上『基礎扎實』 + 豐富實務開發經驗、在經驗中（學習 / 成長），可能才是軟體專案開發容易成功的不二法門。

而這些小陷阱就像是小編以前文章中提及的像是敏捷的推行中，國外許多進行敏捷的大神都早已經沒有自身『技術』的問題，許多甚至是 hacker 等級的，對於 (程式碼編寫 / 重構) 都像是『吃飯』一樣的容易，他們只是不擅長『合作』而已。

許多工具都只是補助（使用什麼工具或方法都不是問題），還是要對軟體開發具備熱情，才能持續的學習、成長，也才走得長久啊。