EventStorming - Process Level

W poprzednim artykule przybliżyłem jak może wyglądać odkrywanie szerokiego obrazu domeny, z którą się mierzymy, dzięki Big Picture EventStorming. Kolejnym krokiem jest zejście poziom niżej i skupienie się na dokładniejszym odwzorowaniu konkretnego wycinka naszej domeny. EventStorming proponuje konkretną technikę, którą możemy wykorzystać do zamodelowania danego procesu. Może to być zupełnie nowy proces, który dopiero chcemy wdrożyć, np. w startupie. Najczęściej jest to jednak istniejący proces, który chcemy poznać w celu jego poprawy i/lub automatyzacji, np. poprzez dostarczenie odpowiedniego oprogramowania.

Gramatyka

EventStorming Process Level może być kolejnym, naturalnym krokiem po Big Picture. Z drugiej strony, nic nie stoi na przeszkodzie, aby realizować go zupełnie od zera na danym wycinku domeny.

Metoda którą proponuje sam autor, Alberto Brandolini, polega na ścisłym podążaniu za wyznaczonym układem elementów. Mamy więc określone zasady „gramatyki karteczkowej”, które musimy przestrzegać, a wyglądają one tak:

Użytkownik (żółty) podejmuje decyzje na podstawie faktów, które zna oraz informacji, które ma dostępne w Read Modelu (zielony).

• Podobnie jak w przypadku Big Picture, tutaj w dalszym ciągu nie posługujemy się ścisłą definicją użytkownika. Możemy go rozumieć jako aktora, rolę, personę albo Panią Krysię z 6 piętra.
• Read Model reprezentuje zbiór informacji, które chcemy przedstawić użytkownikowi, aby ułatwić mu podjęcie decyzji. To może być strona naszej aplikacji, reklama, email, itp.

Na podstawie tych informacji użytkownik podejmuje decyzje - wydaje Komendę (niebieski), która jest przetwarzana przez nasz System (jasno różowy)

• Warto zwrócić uwagę, iż komenda przechodząca przez system nie zawsze musi w rezultacie generować zdarzenie. Komenda może zostać odrzucona przez system lub po prostu się nie udać.
• System może reprezentować naszą aplikację, którą właśnie projektujemy bądź byt zewnętrzny.

System w rezultacie wytwarza Zdarzenie Domenowe (pomarańczowy).

• Jest to zdarzenie, które powinniśmy już mieć odkryte w ramach sesji Big Picture. Zdarzenia tam odkryte stanowią, tak naprawdę, podstawę dla zamodelowania danego procesu. Nie bójmy się natomiast modyfikować, dodawać lub usuwać tych zdarzeń- pamiętajmy, iż warsztat Big Picture nie był precyzyjny.
• Jedna komenda może wyzwolić więcej niż jedno zdarzenie. W takich przypadkach możemy dołożyć dodatkowe karteczki opisujące Reguły (jasno żółty) w jakich okolicznościach dane zdarzenia mają miejsce.

Zdarzenie domenowe może zostać przetworzone na kolejny Read Model. Natomiast równolegle może również wyzwolić Politykę (fioletowy)

• Polityka reprezentuje reakcję naszego procesu, która dzieje się na skutek danego zdarzenia. Polityki są swoistym spoiwem między dwoma zdarzeniami w procesie. zwykle formułujemy je od słów: "Zawsze gdy zdarzy się…", "Kiedy tylko pojawi się…", itp.
• Polityki możemy podzielić na automatyczne i manualne, czyli obsługiwane przez ludzi. Warto tu zwrócić uwagę na polityki nieformalne, nigdzie nieudokumentowane. To mogą być zwyczaje, czy też dobre praktyki w stylu: „a bo tak zawsze robimy i to się sprawdza…".

Hot Spoty - pojawiły się już na etapie Big Picture.

• Dalej spełniają swoją rolę oznaczania problemów, niespójności czy sporów.
• Mogą służyć do odkładnia w czasie miejsc, do których chcemy wrócić po ukończeniu głównego przepływu.

Przeprowadzenie warsztatu

Jest parę rzeczy, na które szczególnie warto zwrócić uwagę aby nasze warsztaty przebiegły sprawnie:

Zacznij od przykładu

Jeśli uczestnicy w większości nie są zaznajomieni z techniką, warto zacząć warsztat od przykładu oderwanego od domeny. Po wyjaśnieniu reguł, możemy poprosić uczestników o zamodelowanie dobrze znanej bajki lub dowolnej innej historyjki, przestrzegając zasad naszej gramtyki.

Ogranicz liczbę uczestników

W przeciwieństwie do warsztatu Big Picture, tutaj musimy precyzyjnie wyselekcjonować ekspertów domenowych, których zaprosimy. Mając niedużą liczbę osób jesteśmy w stanie łatwiej dostrzec czy coś jest dla nich niejasne. Ponadto, wszyscy uczestnicy powinni zgodzić się co do ostatecznego kształtu procesu.

Przestrzegaj zasad

Trzymanie się ściśle układu z legendy - naszej gramatyki. Jakkolwiek trywialnie to brzmi, karteczki muszą być ułożone w tej, a nie innej kolejności i należy się tego trzymać bardziej niż Kim Dzong Un przywództwa w Korei Północnej. jeżeli w danym momencie nie wiemy co opisać jako np. Politykę, lub nie wiemy co ma być na danym Read Modelu, to dodajmy pustą karteczkę w tym miejscu i idźmy dalej.

Co może być źródłem zdarzeń?

Rozpatrzmy kilka scenariuszy związanych z możliwymi źródłami zdarzeń. Jako przykład niech posłuży proces rezerwacji pokoju w hotelu.

Interakcja użytkownika

Jednym z najbardziej oczywistych źródeł dla zdarzeń mogą być akcje zainicjowane przez użytkownika:

Klient hotelu, zdecydowany zarezerwować pokój (to jak doszło do tego, iż klient jest zdecydowany można oczywiście zamodelować osobno), trafia na formularz z kalendarzem. W pierwszym kroku wybiera daty pobytu. Następnie przechodzi do wyboru konkretnego pokoju.

Warto w tym miejscu zwrócić uwagę na ostrożne podchodzenie do zdarzeń interfejsu użytkownika (UI) - nie każde zdarzenie UI będzie istotnym zdarzeniem domenowym wartym odwzorowania. W naszym przykładzie wybór dat pobytu warunkuje listę dostępnych pokoi. Jest więc sensownie pokazać, z punktu widzenia procesu rezerwacji, iż jedno następuje po drugim.

Widzimy również, iż po wybraniu konkretnego pokoju, jest wyzwalana polityka blokująca go w naszym systemie na 15 min.

System zewnętrzny

System zewnętrzny również może występować jako źródło zdarzania. Rozważmy scenariusz, w którym klient hotelu, po uzupełnieniu dodatkowych informacji, jest przekierowany do bramki płatności w celu uiszczenia zaliczki. Nie interesuje nas co dzieje się w środku - czy klient płaci tradycyjnym przelewem, blikiem czy bitcoinem. Interesuje nas natomiast czy płatność zostanie potwierdzona przez bramkę płatności.

Po otrzymaniu zdarzenia z potwierdzeniem płatności, wyświetlamy użytkownikowi końcowy widok z podsumowaniem. Zdarzenie to wyzwala również politykę "Finalizacja rezerwacji", która mówi, iż pokój w tym momencie powinien zostać oznaczony jako zarezerwowany w naszym systemie. W przypadku odrzucenia płatności również mamy odpowiedni widok wraz z polityką, którą omówimy poniżej.

Czas

Czas sam w sobie również może wyzwalać zdarzenia. Mogą to być zdarzenia występujące po określonym czasie lub powtarzające się np. codziennie, co miesiąc, itp.

W naszym procesie system powinien zareagować w momencie, gdy z jakiegoś powodu nie otrzymamy żadnej informacji z bramki płatności.

W reakcji na zdarzenie wyzwalamy politykę "Anulowanie rezerwacji", która odblokowuje pokój w systemie oraz wysyła odpowiednie powiadomienie.

Inne Zdarzenie

Zdarzenia mogą występować kaskadowo gdzie jedno jest źródłem drugiego. Zgodnie z naszą legendą (i rzeczywistością!) pomiędzy nimi zawsze występuje polityka.

Po zarezerwowaniu pokoju zawsze wysyłamy email z potwierdzeniem do użytkownika.

Wskazówki taktyczne

Uwidaczniaj wszystko

Wszystko o czym rozmawiamy powinno być widoczne. jeżeli nie mamy pewności co do ostatecznego kształtu procesu, nad którym trwa akurat dyskusja, umieśćmy czym prędzej nasze przemyślenia jako HotSpot.

Bądź przygotowany na rozgałęzienia

Oczywistym jest, iż nasz proces będzie miał odgałęzienia, jeżeli byłby to prosty liniowy proces to raczej nie potrzebowalibyśmy EventStormingu żeby go odkryć. Z drugiej strony, ludziom wychodzi raczej kiepsko rozwiązywanie więcej niż jednego problemu na raz. jeżeli więc odkrywamy rozgałęzienie lub zupełnie nową ścieżkę, oznaczamy ją (dowolnie) i idziemy dalej, dążąc do ukończenia aktualnej ścieżki.

Pędź do celu

Szczególne znaczenie ma odtworzenie, zachowując zasady gramatyki, pierwszej głównej ścieżki naszego procesu, tzw. Happy Path, najszybciej jak to możliwe. choćby kosztem niskiej skrupulatności w nazewnictwie czy pozostawienia wątpliwości po drodze (Hot Spots). Przejście przez całość powoduje zastrzyk pozytywnej energii (czyżby endorfiny?) wśród uczestników i buduje przekonanie, iż to wcale nie takie trudne.

Będziemy grać w grę

Dobrym sposobem na podejście do EventStorming Process Level jest potraktowanie warsztatu jako gry. Gry zespołowej, w której uczestnicy podążając ścieżką procesu, muszą przestrzegać określonych reguł, by wspólnie dojść do celu. Celem jest obraz naszego procesu, zaakceptowany przez wszystkich obecnych ekspertów domenowych.

Warto również podkreślić, iż przedstawiona technika jest dość uniwersalna. Niekoniecznie musi być następstwem warsztatu Big Picture. Można ją stosować zupełnie oddzielnie - ad hoc - na danych wycinkach domeny lub na spotkaniach typu Product Backlog Refinement.

Na końcu warto zaznaczyć, iż nie jest to jeszcze projektowanie samego oprogramowania. Obraz uzyskany po warsztacie Process Level stanowi solidną podstawę do przeniesienia go do kodu, jednak brakuje w nim kilku elementów. Do ich zamodelowania służy kolejna z technik EventStorming: Software Design.

Artykuł powstał na podstawie książki Introducing EventStorming której autorem jest Alberto Brandolini