Event Storming to bardzo modny ostatnio termin. Co się pod nim kryje? Do czego może być przydatny? W ostatnim czasie słyszałem wiele na ten temat, czytałem, oglądałem różne prezentacje. Jednak podczas SegFault University Gdańsk nadarzyła się okazja, żeby uczestniczyć w warsztatach z Event Stormingu i zobaczyć jak to wygląda w praktyce. W tym poście opiszę do czego jest przydatny Event Storming. Nie zabraknie oczywiście również odniesienia do możliwego wykorzystania w projektach embedded.

Na czym polega Event Storming?

Event Storming to technika służąca do modelowania systemów. Możemy za jej pomocą odkrywać nieznany system, który dopiero mamy stworzyć. Ale również określić co robi działający system. To drugie zastosowanie jest o tyle ciekawe, że często podczas trwania projektu zrozumienie systemu przez poszczególne osoby się rozjeżdża. Sam model, a przede wszystkim proces jego powstawania są zaproszeniem do dyskusji o systemie. Dzięki temu możemy poznać różne punkty widzenia i upewnić się, że wszyscy rozumieją system tak samo. Jest to również lekki i tani sposób na planowanie, prototypowanie i weryfikowanie koncepcji systemów bez użycia kodu ani formalnej notacji takiej jak np. UML.

Wszystko czego potrzebujemy do przeprowadzenia sesji Event Stormingu to duży, kilkumetrowy kawałek ściany i ogromne ilości kolorowych karteczek. Pojedyncza sesja może trwać kilka godzin, albo nawet cały dzień. Wszyscy uczestnicy stoją (najlepiej jeśli w sali w ogóle nie ma krzeseł). Chodzi o to, że kiedy stoimy, a także kiedy fizycznie naklejamy i przekładamy karteczki angażujemy różne obszary swojego mózgu. Dlatego mamy lepsze pomysły niż podczas klasycznego meetingu podczas którego wpatrujemy się w slajdy referowane przez pojedynczą osobę, czy przebijając się przez dziesiątki stron dokumentów w Wordzie.

Nie będę dokładnie tłumaczył jak wygląda sesja Event Stormingu. Temat jest ostatnio na tyle popularny, że został już wielokrotnie opisany w internecie. Dobre materiały na ten temat to np. książka pomysłodawcy techniki – Alberto Brandoliniego (cała książka jest płatna i niedokończona, ale darmowy rozdział opisuje wszystko, co trzeba), czy prezentacje Mariusza Gila – propagatora Event Stormingu w Polsce. Jest też repo GitHubowe Awesome Event Storming.

Rodzaje Event Stormingu

Event Storming jest przydatny przy tworzeniu koncepcji całego nowego systemu albo do uchwycenia działania istniejącego. Nazywamy to Big Picture Event Stormingiem. Mając opisany system możemy szukać w nim usprawnień, miejsc generujących zyski/straty, wskazywać hot spoty, czyli miejsca stwarzające problemy, czy wydzielać funkcjonalności do oddzielnych modułów.

Po przeprowadzeniu sesji Big Picture możemy wybrać jakiś mniejszy fragment systemu i dogłębnie go przeanalizować. W tym celu użyjemy Event Stormingu Taktycznego. Dzięki temu możemy rozłożyć moduł na czynniki pierwsze, żeby wiedzieć jak go potem zaimplementować. Na poziomie implementacji Event Storming dobrze uzupełnia się z Domain Driven Design, który daje pewien zestaw klocków, z których tworzymy potem projekt systemu.

Event Storming a embedded

Standardowo Event Storming jest wykorzystywany w systemach biznesowych, w końcu to większość powstającego aktualnie oprogramowania komercyjnego. Systemy embedded trochę się od nich różnią. Nie ma takiej orientacji na klienta, działanie systemu jest opisane w dużo bardziej techniczny sposób, a interakcje z użytkownikami bardzo często są zastąpione przez interakcje ze sprzętem.

Jednak Event Storming może być lekiem na różne problemy występujące również w embedded. Przecież tutaj również projektowanie jest robione przez pojedynczą osobę albo małą grupę, a wybrane przez nich koncepcje nie są zbyt szczegółowo walidowane, poddawane krytyce ani otwarte na propozycje modyfikacji.

Przepływ wiedzy o systemie często szwankuje. Na porządku dziennym jest sytuacja, gdzie developerzy nie mają wiedzy o działaniu całego systemu. Są raczej zamknięci w swoich modułach, które znają bardzo szczegółowo. Z drugiej strony inni ich modułami aż tak mocno się nie interesują, przez co nie mogą udzielać odpowiedniego wsparcia w podejmowaniu decyzji projektowych. Ktoś może powiedzieć, że nie każdy musi mieć wiedzę o całym systemie. Przecież do realizacji codziennych zadań wystarczy wiedza o jakimś jego wycinku. Jednak problem narasta kiedy mamy na przykład zrobić review cudzego kodu, albo nie daj Boże zastąpić kogoś, kto odchodzi z projektu.

Kolejnym problemem jest mniejsze zaangażowanie ludzi, którzy nie widzą celu działania całego systemu. Trudniej im wtedy zbudować poczucie, że robią coś ważnego. Poza tym pomniejsze decyzje projektowe na poziomie modułów mogą być niezgodne z koncepcją wyższego poziomu. Jeżeli developerzy wiedzą dobrze na czym ta koncepcja polega, dużo łatwiej im dokonywać lepszych wyborów.

Ograniczenia i wady

A czy są jakieś wady, czy ograniczenia Event Stormingu? Otóż nie da się go przeprowadzić zdalnie. Cały zespół musi być fizycznie w jednym miejscu, inaczej nie ma to sensu. Niby są jakieś programy do zdalnych sesji, ale to może być jedynie namiastka sesji na żywo. Robiąc je zdalnie tracimy większość interakcji między uczestnikami, nie ma takiego zaangażowania, ani dyskusji o systemie.

Należy również pamiętać, że Event Storming nie rozwiąże nam wszystkich problemów. Co więcej stworzenie takiej przestrzeni do wymiany spostrzeżeń o projekcie może odsłonić różne brudy. Dlatego ważne zadanie ma tutaj osoba prowadząca (tzw. Facylitator), żeby sesja nie wymknęła się spod kontroli. Może również pójść w drugą stronę i ludzie nie zaangażują się w sesję. Tutaj również rolą Facylitatora jest podsycenie zaangażowania.

Podsumowanie

Event Storming jest elementem projektowania systemu, który jest odpowiedzialny za część kreatywną. Daje proste narzędzia, które każdy jest w stanie od razu zrozumieć i zacząć używać. W klasycznym podejściu natomiast część kreatywna często jest wykonywana równocześnie z częścią formalną np. UML gdzie musimy dbać o stosowanie odpowiednich diagramów i obiektów, a także walczyć z narzędziami do ich rysowania. Dzięki oddzieleniu fazy kreatywnej i zapewnieniu minimalnego i elastycznego zestawu narzędzi jesteśmy w stanie skupić się na wymyślaniu lepszych rozwiązań i nie zaprzątać sobie głowy formalizmami. Później oczywiście dobrze jest efekt takiej sesji uwiecznić w formie dokumentacji. Jednak po uczestnictwie w takiej sesji proces spisywania ustaleń jest dużo prostszy.

Event Storming to przyszłość. Pozwala szybko projektować systemy i walidować, a w razie potrzeby odrzucać, koncepcje. Pozwala programistom efektywnie rozmawiać z osobami nietechnicznymi. Jest dużo ciekawszy i bardziej angażujący niż klasyczne meetingi ze slajdami w Power Poincie. Już teraz coraz więcej zespołów o nim wie i zaczyna go stosować. To pewnie tylko kwestia czasu aż stanie się standardem jak np. Scrum. Jak tylko będę miał okazję, będę chciał wypromować Event Storming w projektach, w których biorę udział.