The English translation is coming soon… I promise
Niniejszy tekst powstał jako podsumowanie warsztatu Event Storming który prowadziłem dla jednego z moich klientów. Ot, taka narracja do znakomitego źródła wiedzy o Event Stormingu którą nadzoruje Mariusz Gil. W linkach Mariusza bardzo łatwo utonąć, tutaj (podobno) narracja pozwala tonąć bardziej przewidywalnie. Tekst spotkał się z ciepłym przyjęciem u klienta oraz u kilku osób które pomagały mi redakcyjnie - dlatego zdecydowałem się na szerszą publikację. Może komuś jeszcze się przyda.
Jeżeli jest to dla Ciebie interesujące, czegoś brakuje bądź chiałabyś / chiałbyś wsparcia w przeprowadzeniu takiej sesji w swoim projekcie, to zostaw komentarz na dole lub napisz do mnie bezpośrednio.
Dlaczego event storming?
Jeżeli zastanowić się nad sposobami dostarczania systemu w sposób powtarzalny, ciągły i niezawodny, z czasem zauważamy, iż sprowadzają się one do kilku podstawowych kwestii [1]:
-
zrozumienia: sposobów wsparcia zespołu w zrozumieniu biznesu, minimalizacji różnic pomiędzy przestrzenią problemu biznesowego (domeną) oraz modelem (kodem) reprezentującym tę domenę,
-
dekompozycji: podziału systemu na moduły, logicznie niezależne elementy (mogące być jedną lub wieloma elementami wdrożeniowymi), implementacji: poprawnego przejścia z przestrzeni problemu do przestrzeni rozwiązań, poprzez implementację założeń biznesowych w kontekście istniejących ograniczeń (architecture drivers [2]), w oparciu o odpowiednio dobrane narzędzia,
-
wdrożenia: efektywnego procesu budowy i wdrażania aplikacji na żądanie.
Warsztat event storming bardzo efektywnie adresuje pierwsze dwa elementy: zrozumienie (uwspólnienie języka) i dekompozycję (przeprowadzenie burzy mózgów nt rozwiązania, analiza systemu oraz eliminacja niezweryfikowanych hipotez) oraz daje solidną bazę do implementacji.
Co to jest event storming
Jest to technika warsztatowa zaproponowana przez Alberta Brandoliniego [3], służąca do opisu systemów informatycznych (ale także dowolnych innych procesów w organizacji [4]), szeroko używana do projektowania systemów opartych o mikrousługi [5]. W zależności tego ile czasu chcemy poświęcić na warsztat (czasu poświęconego na analizę domeny), jak dogłębną wiedzą domenową dysponujemy lub w której fazie projektu się znajdujemy, możemy storming rozpatrywać na poziomie:
-
narzędzia wymiany wiedzy w obrębie projektu; Big Picture,
-
modelowania procesowego zachodzącego w systemie informatycznych (i poza nim); Process Level,
-
szczegółowego modelowania systemu; Design Level.
Każdy poziom to oddzielny kawałek warsztatu, opcjonalny w zależności od celów, które należy osiągnąć.
Przygotowanie warsztatu
Warsztat event storming w świecie rzeczywistym (offline) - chociaż w sieci jest dużo dodatkowych wskazówek [6] - to przede wszystkim:
-
odpowiednie miejsce. Duża nieograniczona powierzchnia (ściana), którą można przykryć arkuszem białego papieru. Posłuży ona jako przestrzeń do wyklejania karteczek oraz późniejszych dyskusji.
-
odpowiedni ludzie. Udana sesja to przede wszystkim dobór odpowiednich osób: ekspertów technicznych (programiści, testerzy analitycy), ekspertów domenowych ze strony klienta, biznesu, właścicieli produktu (PO) oraz moderatora, osoby zaznajomione z techniką event stormingu, dbającej o sprawny i prawidłowy przebieg warsztatu [7].
Sama lista zakupów elementów potrzebnych do warsztatu jest bardzo dokładnie opisana na blogu Radka Maziarki [8]. Ostatnim krokiem przygotowań to napisanie opisu systemu, który zostanie przedstawiony (i rozdany uczestnikom warsztatu) [9].
Przeprowadzenie warsztatu online wymaga trochę więcej zachodu. Co więcej, ze względu na wirtualną formę (uczestnicy nie widzą siebie, ograniczone możliwości zaangażowania ludzi przez moderatora) - sam pomysłodawca event stormingu był sceptyczny co do zdalnej formy warsztatu [10]. Z czasem jednak (głównie ze względu na COVID-19) podejście do zdalnych warsztatów event stormingu zaczęło się zmieniać [11].
Kluczem do powodzenia zdalnej sesji event stormingu jest odpowiednie zaplanowanie:
-
relatywnie krótkich sesji - nie jest możliwie wytrzymanie przed ekranem komputera przez 6-8 godzin, jak ma to miejsce na sesjach offline, przygotowanie tablicy z wykorzystaniem odpowiedniego narzędzia (m.in. zawsze widoczna legenda, przygotowany kosz, wirtualne miejsca do pracy) [12]
-
wcześniejsze przygotowanie uczestników, zapowiedzenie sesji oraz wytłumaczenie sposobu pracy pozwala zaoszczędzić cenne minuty podczas warsztatu,
-
wcześniejsze udostępnienie opisu sesji,
-
przygotowanie pracy domowej; prośba do uczestników o przemyślenie systemu który będzie omawiany oraz przygotowanie paru pomysłów na zdarzenia, które później zostaną wykorzystane podczas sesji.
Faza Big Picture
Kwintesencją sesji Big Picture jest zrozumienie całego procesu biznesowego (także dziejącego się poza planowaną aplikacją) oraz konsolidacji wiedzy nierównomiernie rozłożonej pomiędzy uczestnikami spotkania. Warsztat ma za zadanie rozpoznać jak najwięcej różnych procesów zachodzących w systemie (i poza nim), w możliwie najkrótszym czasie. Pozwala to na świadomy wybór najważniejszych procesów i zajęcie się nimi w odpowiedniej kolejności [13].
Systematyzacja wiedzy na poziomie Big Picture odbywa się dzięki 6 składników (chociaż nie wszystkie są koniecznie i zależą od celów, które staramy się osiągnąć):
-
Rozpoczęcie – przedstawienie celów warsztatu;
-
Chaotyczna eksploracja – zapisywanie i przyklejanie na ścianie pomarańczowych karteczek ze zdarzeniami biznesowymi;
-
Wprowadzenie osi czasu – pierwsze sortowanie i grupowanie karteczek. Najprawdopodobniej karteczki znalazły się w losowych miejscach, dlatego istotne jest, aby poukładać je w sposób chronologiczny. To jest także moment na eliminację duplikatów (m.in. tych samych koncepcji opisanych innym językiem);
-
Ludzie i systemy – zdarzenia zwykle nie występują w izolacji i ich źródłem może być konkretna osoba, dział, wewnętrzny albo zewnętrzny system. W fazie Big Picture możemy pokusić o naniesienie ich na tablicę;
-
Problemy i okazje – do tego momentu na event stormingu pojawiły się pewnie karteczki, co do których uczestnicy nie mogli dojść do konsensusu (np. gdzie je umieścić). Miejsca takie nazywane są hotspotami - najważniejsze na tym etapie jest jest oznaczyć i kontynuować dyskusję.
-
Wybór problemów – po kilku godzinach sesji przestrzeń zagadnień staje się rozległa, zbyt duża i zbyt złożona aby pracować nad nią w całości. To jest też moment kiedy podejmujemy decyzję, nad którymi problemami skupiamy się w pierwszej kolejności. Może to być poprzez głosowanie, poprzez wartość biznesową itp.
Kilka przykładów pokazujących przeprowadzone sesje można znaleźć w internecie [14].
Co to jest zdarzenie biznesowe
Podczas sesji posługujemy się pojęciem zdarzenie biznesowe, ale nie jest ono zawsze i dla wszystkich jasne. Zdarzenie to coś, czemu można jednoznacznie przypisać znacznik czasu. W związku z tym najczęściej pojawiającą się wytyczną odnośnie nazywania zdarzeń jest: ma być w czasie przeszłym, w formie dokonanej [15].
Niemniej, podczas sesji regularnie pojawiają się wątpliwości co jest zdarzeniem. Można posiłkować się kilkoma heurystykami dotyczącymi granularności zdarzeń.
Pierwsza pochodzi od systemów event sourced, gdzie zdarzenia (events) potrafią być bardzo drobne i wynikać z pośrednich zmian systemu a nie zdarzeń w rozumieniu biznesu. Na przykład proces rejestracji użytkownika w systemie ma kilka kroków (wypełnienie formularza, wysłanie maila potwierdzającego, podanie kodu weryfikującego itp). Dopiero spełnienie wszystkich kroków jest jednoznaczne ze zdarzeniem biznesowym: zarejestrowano użytkownika [16].
Powyższa wytyczna często nie jest jednak wystarczająca. Innym sposobem rozróżniania zdarzeń jest ich podział na poziomy [17]:
-
zdarzenia środowiskowe – występują poza systemem, w świecie rzeczywistym. Przykładowo: zdarzenie wejścia do sklepu przez klienta. Często są mało istotne z perspektywy warsztatu, ale pomagają złapać kontekst;
-
zdarzenia interfejsowe – poziom UI. Na przykład, przejście przez kolejne kroki formularze, które powodują częściowy zapis, ale nie implikują zmiany stanu systemu. Przykładowo: gdy wybierany jest plan płatności w interfejsie użytkownika, ale ten wybór może zostać zmieniony dowolną liczbę razy, dopóki ostateczny wybór nie zostanie potwierdzony;
-
zdarzenia infrastrukturalne – odnoszą się do rzeczy technicznych i nie mają wpływu na system: „zaktualizowano metrykę”, opublikowano zdarzenie w systemie kolejkowym”;
-
zdarzenia domenowe – serce Event Stormingu i to na takich zdarzeniach skupia się warsztat.
Faza Process Level
Po sesji Big Picture możemy przeprowadzić sesję Process Level Event Storming. W niektórych przypadkach nie jest to konieczne (wystarczy nam ogólne zrozumienie systemu, aby np. wyłonić elementy będące MVP). Z reguły zasadne jest przejście z poziomu problemu na poziom rozwiązania. Skupiamy się na mniejszych kawałkach systemu (modułach) i rozpoczynamy ich modelowanie. Pojawiają się koncepcję komend, modeli tylko do odczytu, interfejsów użytkownika itp.
Po co dzielimy system na moduły?
To jest regularnie pojawiające się pytanie, na które nie ma jednoznacznej odpowiedzi. Przede wszystkim podział (jego istnienie oraz granulacja) wynika z celów, które staramy się osiągnąć poprzez architekturę (architectural drivers). o ile chodzi o mechanika samego podziału, elementami, które nakierowują na odpowiednią dekompozycję może być (między innymi):
-
Zadowolenie odrębnych grup interesów. Jeden moduł to z reguły jeden ekspert domenowy i często jedna grupa użytkowników. Dzięki temu możliwa jest redukcja sytuacji, gdzie opracowywane narzędzie sprzedaży bezpośredniej (B2C) próbuje być wdrożone w innym segmencie (B2B) i może być ograniczone przez np. braki w elementach niezwiązanych z B2B (ale będących nierozerwalną częścią systemów B2C). Klarowny podział na moduły, pomaga w jednoznacznym komunikowaniu celowości poszczególnych elementów systemu.
-
Role użytkowników, ponieważ rzadko zdarza się, iż dwie role muszą korzystać z tego samego kontekstu. Mapowanie ról na strukturę organizacji jest tutaj bardzo pomocnym ćwiczeniem.
-
Podział na odczyt i zapis. W bardziej złożonych systemach (nie CRUD) to przeważnie osobne konteksty - także ze względu na znacząco odmienne charakterystyki skalowalności Spójność, niezmienne elementy modelu. Zastanowienie się jak działałby biznes bez komputerów pomaga zbudować świadomość, które elementy powinny być spójne (consistent), a które ostatecznie spójne (eventually consistent) [18].
Podział na bazie wyników fazy Big Picture
Sortowanie kart w trakcie fazy Big Picture bardzo często wizualnie nakierowuje na podział systemu na elementy. Składowe, na które warto spojrzeć to [19]:
-
Wartość biznesowa. o ile podczas sesji zajmujemy się wartościowaniem elementów ze względu na znaczenie dla całego procesu biznesowego, to z reguły elementy o dużej wartości nie współistnieją w tych samych częściach systemu co elementy o niskiej wartości.
-
Pivotal events. Zdarzenia najważniejsze z punktu widzenia procesu biznesowego, które zmieniają stan procesu w sposób nieodwracalny. Prosto i naiwnie. Czasami podział nie jest ewidentny, wtedy warto zacząć od prostego i naiwnego podziału poprzez dzielenie osi czasu w kolejne sekwencje kroków [20]. Podział nie będzie idealny ani docelowy. Będzie jednak wystarczający, aby zainicjować kolejne dyskusję i odkryć zależności prowadzące do docelowego podziału systemu.
Bounded Context
Hasłem regularnie powracającym przy okazji event stormingu jest Bounded Context, czyli części systemu, które są wewnętrznie spójne, a na zewnątrz komunikują się przez określony zbiór metod.
-
Im aplikacja jest większa, tym trudniej zbudować jeden wspólny model – rozwiązanie problemu. Zasady biznesowe zaczynają się mieszać i przestajemy rozumieć za co nasz model odpowiada.
-
Konteksty mają za zadanie podzielić skomplikowaną dziedzinę biznesową na kilka mniejszych, dostosowanych do problemu jaki aktualnie rozwiązujemy.
-
Dany kontekst zawiera w sobie własny model odwzorowujący konkretne potrzeby, warunki i procesy biznesowe.
-
Pozostałe konteksty nie powinny mieć wpływu na działania zachodzące wewnątrz innego kontekstu – otrzymują jedynie informacje o rezultatach tych działań.
-
Zmienianie danych wewnątrz kontekstu nie powinno być możliwe bez nadzoru samego kontekstu – może to zburzyć wypracowane zasady i sprawić, iż dane nie będą poprawne.
-
Takie działania pozwalają zachować spójność, którymi rządzi się dany kontekst.
Jak dostrzec zmianę kontekstu
Zmienia się język jakim posługują się uczestnicy procesu.
Jak opisać kontekst (moduł)
Np. wykorzystują wspomnianą metodą Nick’a Tune’a: Bounded Context Canvas.
Jakie mogą być domeny
-
Core (binzes który analizujemy, unique selling point który będzie implementowany),
-
Supporting (elementy które powinny zostać zamknięte jako konfiguracja generycznego rozwiązania, rozwiązania wzięte z półki, kupione),
-
Generic (elementy nie związane bezpośrednio z biznesem, nie będące trzonem biznesu) Jeżeli posłużymy się przykładem domeny związanej z medycyną (zarządzaniem dokumentacją medyczną [21]) to podział domen mógłby wyglądać następująco:
-
Patient records - zarządzanie dokumentacją medyczną (core)
-
Scheduling - umawianie wizyt (integracja, konfiguracja istniejącego modułu)
-
Lab - zamawianie test labolatoryjnych (integracja, konfiguracja istniejącego modułu)
-
Identity management - zarządzanie użytkownikami (wybór istniejącego rozwiązania)
-
File archive - repozytoria plikowe (wybór istniejącego rozwiązania)
Jak zweryfikować podział na moduły
Propozycja jakiekolwiek podziału na moduły prowadzi do szeregu dyskusji i wątpliwości. Weryfikacja podziału możliwa jest w oparciu o szereg pytań wspomagających (a co gdyby…?):
-
A co w sytuacji gdyby przenieść daną odpowiedzialność do innego kontekstu?
-
A co w sytuacji gdyby podzielić odpowiedzialność na mniejsze części i jedną z części przenieść do innego kontekstu?
-
A co w sytuacji gdyby podzielić kontekst na kilka mniejszych?
-
A co w sytuacji gdyby usunąć odpowiedzialność z kilku kontekstów i przenieść ją do jednego (potencjalnie do nowego) kontekstu?
-
A co w sytuacji gdyby wprowadzić duplikację funkcjonalności aby usunąć zależności pomiędzy kontekstami?
-
A co w sytuacji gdyby uwspólnić odpowiedzialność i współdzielić ją pomiędzy kilkoma kontekstami?
Faza Design Level
Ostatnią fazą event stormingu jest Design Level, gdzie tworzony jest docelowy model, który niemalże w stosunku 1:1 będzie przenoszony do kodu [22].
Alternatywne podejścia do zdarzeń
Event storming to nie jest jedyny sposób analizy systemu poprzez zdarzenia. Alternatywnym (i bardziej sformalizowanym podejściem) jest event modelling zaproponowany przez Adama Dymitruka [23]. Najlepszym opisem różnic w podejściach jest poniższa analogia:
Są różne systemy prawodawstwa: anglosaski (oparty na precedensach) i europejski (oparty na regulacjach). Oba działają, oba mają dobre i złe strony. Systemy zbudowane w oparciu o event modelling przypominają prawo oparte na precedensach: bazując na przykładach z życia wziętych. Podczas gdy systemy powstające przy wykorzystaniu event stormingu to więcej analogii z prawem opartym o regulacje: wymagają głębszej wiedzy dotyczącej reguł, struktur i analizowanych koncepcji.
Po przeprowadzonych warsztatach
Celem warsztatów event storming nie jest stworzenie dokumentacji technicznej, a współdzielenie wiedzy i zbudowanie mapy systemu, po której wszyscy interesariusze będą się równie efektywnie poruszać. Elementy do natychmiastowego wykorzystania w dalszych pracach to uwspólniony język, podział na moduły oraz różne artefakty techniczne (w zależności od tego przez ile faz event stormingu przechodził warsztat). Dodatkowo można pokusić się o przeprowadzenie dodatkowych elementów [24]:
-
archiwizacja samej sesji do późniejszego wglądu,
-
user story mapping - do przygotowania historyjek dla pracy zespołów programistycznych,
-
specification by example - przygotowanie scenariuszy testowych.
Na zakończenie
Drogi czytelniku, droga czytelniczko - to już koniec. Tak jak pisałem wcześniej, o ile jest to dla Ciebie interesujące, czegoś brakuje bądź należałoby tekst rozszerzyć. A może potrzebujesz wsparcia w przeprowadzeniu takiej sesji w swoim projekcie? Proszę, zostaw komentarz na dole lub napisz do mnie bezpośrednio.
