Event Storming - wstęp

Artykuł pozwolę sobie rozpocząć od pewnego przemyślenia, które towarzyszy mi w branży IT od pewnego czasu... Nie zapominajmy, po co tu jesteśmy - my twórcy oprogramowania.

Ja wiem - niektórzy dla CV, inni dla chwały :) .... jednak bazowo, jesteśmy tu, aby realizować inwestycje. Z perspektywy zleceniodawcy oprogramowanie jest inwestycją, być może optymalizującą jakiś proces, obniżającą koszty, wprowadzającą produkt, a może pozyskującą klientów.

W każdym z tych przypadków, team pracujący nad danym rozwiązaniem musi dobrze rozumieć domenę biznesową i cel istnienia projektu.

W nazwijmy to "klasycznym" podejściu, projekt IT wygląda następująco :

• Gdzieś na poziomie biznesowym pojawia się decyzja o inwestycji w oprogramowanie,
• Zostaje wydelegowany analityk, którego celem jest zebranie wymagań,
• Analityk rozmawiając z zainteresowanymi, produkuje dokument, który strukturyzuje zebrane wymagania,
• Team projektowy otrzymując dokument, przerabia go na taski,
• Programista podejmuje task i tworzy na jego podstawie rozwiązanie (kod),
• Oczywiście jest to pewnego rodzaju uproszczenie, można do tego procesu dodać wyceny, przepychanki, być może nawet architekta, który chwilę zastanowi się, jak daną funkcjonalność zrealizować, czy bardziej zwinną metodykę zarządzania projektem typu scrum lub scrum'ish :). Te elementy nie będą częścią tej publikacji.

CO TU JEST JEDNAK NIE TAK?

Przypomnijmy sobie, na czym polega zabawa w głuchy telefon. Po kilku iteracjach słuchania i powtarzania, adresat dostaje upragnioną wiadomość - raz się uda, raz nie :)

Czym większa złożoność wiadomości, tym większa szansa na deformację wyniku. W biznesie jest tak samo. Im bardziej skomplikowany proces biznesowy, tym bardziej zdeformowane wyniki dostanie programista. Taski, które otrzyma zostały co najmniej trzy razy zmapowane (raz z głów biznesu do analityka, dwa z głowy analityka do dokumentu, trzy z dokumentu analityka do tasków). Nie zapominajmy, że na swojej wiedzy o biznesie i na taskach, programista będzie opierał powstające rozwiązanie.

MAMY WIĘC DWA PROBLEMY:

1. Brak zrozumienia biznesu i celu istnienia projektu przez programistę,
2. Deformacja wymagań i wybranych rozwiązań, które otrzymuje programista.

Jednym ze skuteczniejszych sposobów, aby zapobiec tym problemom i jednocześnie zachować analityka w zespole jest Event Storming.

CZYM WŁAŚCIWIE JEST EVENT STORMING?

Metodyką do pozyskiwania i strukturyzowania wiedzy domenowej.

OK, ALE JAK TO DZIAŁA?

Koncept jest bardzo prosty - zbierzmy w jednym pomieszczeniu osoby, które :

• Znają domenę biznesową,
• Potrafią analizować potrzeby biznesowe,
• Potrafią technicznie zrealizować rozwiązanie oraz kogoś, kto zadba o odpowiedni kurs rozmów.

W ten oto sposób zebraliśmy:

• Ekspertów domenowych - czyli osoby, które mają wiedzę biznesową dotyczącą zakresu warsztatów,
• Analityków - czyli osoby, które mają zdolności pozyskiwania i walidowania wiedzy,
• Programistów - czyli osoby, które potrafią techniczne zrealizować rozwiązanie problemu oraz znają ograniczenia ekosystemu,
• Moderatora (facilitator) - osobę, która będzie moderować spotkanie, dbając o jego efektywny i spójny przebieg.

Na pierwszy rzut oka, brzmi jak coś, co nie ma prawa się udać. Biznes nie potrafi rozmawiać z programistami. Najzwyczajniej w świecie, nie rozumie ich języka. Adresacja tego problemu, jest podstawą, na której powstała technika Event Storming'u. Mówimy tu o zrozumiałej dla wszystkich uczestników, możliwie najprostszej gramatyce. Jest to fundament do budowania poczucia swobody, co ma owocować wkładem wszystkich uczestników w warsztaty.

GRAMATYKA

Do dokumentowania procesów biznesowych, podczas warsztatów, używa się notacji "karteczkowej". Karteczki posiadają inne znaczenie, rozróżniane są po kolorach. W skład gramatyki wchodzą następujące klasy karteczek:

• Zdarzenia (pomarańczowe) - opis zdarzenia bazujący na czasownikach, czasu przeszłego dokonanego,
• Polecenia (niebieska) - oznaczająca możliwe do wykonania polecenie - niczym przyciski na pilocie,
• Systemy zewnętrzne (różowa) - oznaczająca system zewnętrzny, który nie jest przedmiotem warsztatów, jednak posiada wpływ na badany proces (np. częścią procesu jest wywołanie funkcji w systemie zewnętrznym),
• Politykę/proces (fioletowa) - oznaczająca zbiór reguł reagujących na zdarzenie i mający swoje konsekwencje w innym zdarzeniu lub komendzie, albo po prostu proces, czyli automatyzację,
• Aktorzy (żółta wąska) - oznaczająca podmiot, który może wykonać dane polecenie,
• Hot spoty (czerwony romb) - oznaczająca punkt sporny/wątpliwość, cokolwiek będące przedmiotem dyskusji,
• Read model (zielona) - odzwierciedla miejsce w systemie, gdzie dostarczamy danych odczytowych np. do umożliwienia podjęcia decyzji użytkownikowi,
• Agregat (żółta szeroka) - jest to element najtrudniejszy do odpowiedniego wskazania, polecany do wyznaczania na samym końcu. Agregat jest granicą pewnego kontekstu domenowego (więcej w artykule o DDD).

Lista elementów gramatyki, nie jest zamknięta, a powinna być dostosowana do pożądanego efektu warsztatów. Przykładowo: jeśli mocniej interesuje nas metryka i logowanie, możemy dodać karteczki oznaczające punkt wygenerowania jakiegoś logu/metryki.

PRZEBIEG WARSZTATÓW

Do przeprowadzenia spotkania, potrzeba:

1. Możliwie nieskończonej powierzchni (np. ściany) na której, będą naklejane karteczki,
2. Karteczek w kolorach zgodnych z gramatyką,
3. Markerów do pisania po karteczkach.

Na powierzchni roboczej oznaczyć należy poziomą oś czasu (od lewej do prawej).

Pierwszym krokiem będzie, "wyrzucenie" z głów wszystkich uczestników, zdarzeń domenowych na pomarańczowych karteczkach. Takimi zdarzeniami mogą być "Dodano do koszyka", "Zamówienie zostało opłacone". Ważne, aby trzymać się możliwie zwięzłej formy, bazując na czasownikach w formie przeszłej dokonanej.

Karteczki naklejamy zachowując prawidłowość osi czasu (to nie musi stać się od razu). Kluczem do powodzenia warsztatów jest aktywność uczestników, dlatego nawet nietrafione karteczki powinny zostać na początku na tablicy. Z czasem będziemy się ich pozbywać, za zgodą i ze zrozumieniem wszystkich uczestników.

Wszystkie pytania i wątpliwości, które pojawiają się podczas dyskusji, należy zapisywać na karteczka czerwonych, przyklejanych w romb, będą to hot spoty. Ważne, aby utrzymywać odpowiednie flow rozmowy, dlatego moderator, widząc dyskusję rozbijającą się na dwie grupy, powinien jednej z grup zaproponować stworzenie karteczki hot spota, do której dyskusja wróci w następnej kolejności. Istotne jest, aby wszyscy uczestnicy, brali udział w jednej dyskusji.

Jeśli wyczerpiemy temat zdarzeń domenowych, możemy śmiało przejść do niebieskich karteczek oznaczających komendy. Są to punkty wejściowe do naszych (jeszcze nie określonych) bytów. Można utożsamić sobie je z przyciskami na pilocie, jak np. "włącz dekoder", czy też trzymając się przykładu ecommerce "złóż zamówienie".

Jeśli nasza domena biznesowa ma wielu aktorów, możemy wprowadzić tu wąskie żółte karteczki, które oznaczają aktorów procesu. Naklejmy odpowiedniego aktora przy komendzie, aby pokazać, kto aktywuje daną ścieżkę np "włącz dekoder" i aktor "Pan domu".

Często, aby podjąć decyzję w procesie, aktor potrzebuje danych. Jeśli chcemy ukazać tę potrzebę w naszym modelu, należy zastosować karteczkę zieloną. Oznacza ona read model, czyli miejsce, które dostarczy danych do procesu decyzyjnego.

Wraz z przybywającymi niebieskimi karteczkami, zaczną pojawiać się głosy "jeśli zdarzy się te wydarzenie to.." to czas, aby wprowadzić karteczki fioletowe czyli procesy. Mogą one być aktywowane na podstawie zdarzenia, produkując w wyniku inne zdarzenie lub wywoływać komendę. Jeśli potrzebujemy zaznaczyć w procesie zbiór reguł, które w jakiś sposób są ważne, to w tym celu również użyjmy karteczki fioltetowej - tym razem jako polityki. 

Nie obawiajcie się chaosu, na początku "nie trzyma się to kupy". Do obowiązków moderatora dyskusji należy prowadzenie spotkania iteracyjnie. Wraz z uszczelnianiem modelu, powinniśmy być w stanie usunąć część hot spotów. Dlatego, raz na jakiś czas, należy "zamrozić" dyskusję, aby wrócić do rozwiązywania hot spotów. Jeśli model odpowiada już na wątpliwość postawioną w hot spotcie - usuńmy karteczkę. Jeśli nie, moderator powinien prowadzić dyskusję w kierunku rozwinięcia hot spota. Czym mniej hot spotów tym bliżej udanego modelu jesteśmy.

Ostatnim elementem jaki pojawi się na tablicy będą szerokie żółte karteczki - agregaty. Jest to najtrudniejszy element, wzbudzający jednocześnie najwięcej pytań. Oznaczać ma jakiś kontekst, w uproszczeniu mówiąc, zamyka zbiór zachowań i zdarzeń w grupę - nadając jej nazwę (np. agregatem może być wcześniej wspomniany pilot, zbierający funkcje). Wydziałanie agregatów (jako część DDD) oraz przydatną technikę "gibberish game" pokryjemy w oddzielnych artykułach.

Modelowanie Event Storming w zależności od tematu i ilości uczestników może trwać od kilku do nawet kilkudziesięciu godzin. Należy pamiętać, że efektywność spotkania jest odwrotnie proporcjonalna do liczby uczestników, dlatego nie przesadzajmy z ilością gości. Ograniczmy się do minimum jednej, maksymalnie trzech, osób o danej roli. Optymalna grupa dyskusyjna oscyluje w granicach 5-8 uczestników.

Nie bójmy się modyfikować. Jeśli podczas warsztatów chcemy położyć na coś szczególny nacisk, nic stoi na przeszkodzie, aby dodać swój element gramatyki, przykładowo mierniki.

Efektem końcowym warsztatów będzie zbiór uporządkowanych względem czasu elementów gramatyki, które opisują proces biznesowy. Jest to doskonały punkt wyjściowy do rozpoczęcia modelowania DDD, ba większość roboty jest już zrobiona! Jest to również, świetna dokumentacja, czy to dla nowych pracowników, czy dla obecnych pracujących gdzieś wokół procesu.

CZY MA TO SENS?

Jak najbardziej tak.

Z doświadczenia mogę powiedzieć, że zdecydowana większość błędów w oprogramowaniu, jest w jakimś stopniu pochodną niezrozumienia procesów biznesowych, czy celów powstawania oprogramowania.

Warsztaty Event Stormingowe niosą za sobą ważne elementy, a mianowicie:

• możliwość uczestniczenia i wpływ na kierunek modelowania rozwiązania. Już na samym początku projektu, developerzy doskonale znając cel, przesłanki biznesu mają możliwość wyłapania ewentualnych niespójności. Takie doświadcznie może potęgować motywację, świadomość projektową oraz wzmożyć proaktywność programistów. 
• ustabilizowanie wiedzy i wyrównanie rozumienia problemu miedzy anylitykami, programistami a biznesem. Co więcej wypracowany zostanie nie tylko wspólny mianownik interpretacji problemu ale także, co istotniejsze, wspólny ujednolicony język, którym opisują domenę. 

Często podczas warsztatów biznes uświadamia się również o złożoności rozwiązania. "Przecież to tylko dodanie przycisku!" - nie jest już takie proste, kiedy trzeba dokładnie prześledzić ścieżkę kolejnych kroków procesu :)

_____________________________________________

Łukasz Janczewski - Jeden z założycieli i współtwórców bloga technologicznego Architects Guru. Specjalista w obszarze Architektury IT z ponad 10-letnim komercyjnym doświadczeniem w projektach IT od małych stron do wielomilionowych portali. Miłośnik architektury i podejścia software craftsmanship.