Pewnie wszystkim, którzy pracują przy wytwarzaniu produktów jest znany problem niezrozumienia ich wizji. Często rozpoczynając pracę nad nowym produktem opieramy się tylko na dokumentacji lub na krótkim przedstawieniu zarysu idei przez klienta. Często też rodzi to wiele problemów, na które rozwiązaniem może być poniżej opisany Event Storming.

W jaki sposób zdobyć informację niezbędne do zbudowania wysokiej jakości produktu, którego domeny nie znamy? 

Event Storming jest jedną z metod, która pozwala nam znaleźć odpowiedź na powyższe pytanie. Został wymyślony przez Alberto Brandoliniego do szybkiego odkrywania, analizy i modelowania złożonych domen i problemów. Wywodzi się z Domain-Driven Design (DDD), ale nie trzeba się w nie zagłębiać żeby móc korzystać z Event Stormingu. 

Sesja Event Stormingu

W samej sesji Event Stormingu powinien brać udział właściciel produktu i wszystkie osoby, które mają wiedzę domenową potrzebną przy realizacji wizji (lub tylko wybrani reprezentanci), czyli tzw. eksperci domenowi. Koniecznie na samej sesji powinni znaleźć się też eksperci techniczni, może to być przykładowo programista backendowy, frontendowy etc. Ważne jest też spojrzenie testerskie więc QA na takiej sesji może naprawdę wiele wnieść. Z mojego doświadczenia mogę powiedzieć, że rozwiązanie jeden deweloper z każdej platformy bardzo dobrze sprawdza się w praktyce. Warto, żeby na spotkaniu znalazł się też facylitator, który będzie monitorował przebieg całego procesu, może to być na przykład Scrum Master

Można wyróżnić cztery etapy Event Stormingu, polegające na generowaniu kolejnych jego elementów, mam tu na myśli tworzenie:

  • Zdarzeń domenowych
  • Ról
  • Komend 
  • Agregatów 

Poniżej znajdziecie krótkie omówienie każdej z części wraz z przykładami użycia. Warto przed samym rozpoczęciem sesji ustalić wspólny słownik pojęć, zwłaszcza jeżeli słownictwo tyczy się w branży zupełnie nam obcej. Pozwoli to uniknąć nieporozumień. Oczywiście słownik można, a wręcz trzeba uzupełniać wraz z przebiegiem Event Stormingu. 

Zdarzenia domenowe

Polega na definiowaniu czynności, które mają zachodzić w trakcie działania modelowanego oprogramowania. Inaczej mówiąc są to czynności, które użytkownik jest w stanie wykonać w produkcie. Zdarzenia te powinny być istotne z punktu widzenia ekspertów domenowych i wyrażone w czasie przeszłym. Na przykład: 

  • użytkownik wszedł na stronę główną, 
  • użytkownik zaakceptował zaproszenie. 

Ważne, żeby wszyscy uczestniczyli aktywnie w tworzeniu zdarzeń domenowych, im więcej pomysłów wygenerujemy tym lepiej. Zdarzenia staramy się układać chronologicznie, ale nie jest to konieczność, pod koniec tej części zawsze jest czas na ich pogrupowanie. 

Dobrą praktyką jest zaczęcie tworzenia zdarzeń domenowych od środka naszego produktu, wtedy odpowiadamy sobie na pytania: 

  • Co musiało się zdarzyć wcześniej, żeby użytkownik mógł wejść np. na stronę powiadomień? 
  • Jakie następne akcje użytkownik może wykonać w systemie? 

Posłużę się Instagramem i opcją robienia zdjęć. Co powinno zdarzyć się wcześniej w aplikacji żeby użytkownik mógł zrobić zdjęcie? Co może później zrobić z tym zdjęciem? Konkretnymi przykładami zdarzeń domenowych w tym przypadku mogą być:

event storming
Tworzenie zdarzeń domenowych na podstawie Instragrama – miro.com

W tej części można wyróżnić następujące fazy:

  • Tworzenie zdarzeń domenowych z jednoczesną próbą uporządkowania ich na osi czasu – każde zdarzenie tworzymy na osobnej kartce tego samego koloru i umieszczamy w widocznym dla innych miejscu np. na ścianie. Nadawanie koloru pozwala na łatwiejsze rozróżnieniu zdarzeń domenowych od pozostałych elementów ES. 
  • Porządkowanie elementów na osi czasu – w pierwszej fazie zdarzenia były już przez nas wstępnie uporządkowane ale należy jeszcze raz upewnić się, że wszystko ma sens i łączy się ze sobą.
  • Sprawdzanie spójności zdarzeń i dodawanie brakujących. 

Reguła tworzenia zdarzeń jest prosta: im więcej zdarzeń stworzymy tym lepiej. Nawet jeżeli coś wydaje nam się małą istotną sprawą może mieć bardzo duże znaczenia dla zrozumienia mechaniki działania produktu.

Komendy

Zdarzenia domenowe są punktem wyjścia do tworzenia komend, które mają odpowiadać na pytanie – co należy zrobić żeby miało miejsce konkretne zdarzenie domenowe? “Użytkownik zarejestrował się” jest tylko opisem tego co on może sam zrobić w aplikacji, ale czy coś dzieje się po drugiej stronie produktu? Dla tego przypadku możemy wyróżnić komendę “Utworzono konto”, do której realizacji potrzebujemy konkretnego aktora. Znowu odwołujemy się do reguły jednego koloru i jednej komendy na kartce. Często komendy tworzone podczas Event Stormingu są później konkretnymi metodami w kodzie. 

Tworzenie komend na podstawie Instragrama – miro.com

Jednym z ważniejszych elementów Event Stormingu jest tak naprawdę dyskusja. Podczas tworzenia komend jesteśmy do niej ponownie zaproszeni. To dzięki niej często możemy odkrywać miejsca w których wydawane komendy będą się powtarzać, definiując tym samym zależności. Taka dyskusja znacznie ułatwi nam późniejszą implementację. 

Role

Ta część polega na definiowaniu aktorów, którzy są odpowiedzialni za wykonanie wcześniej zdefiniowanych komend. Często pozwala nam to wyróżnić różne typu użytkowników (administrator, właściciel, zwykły użytkownik), czy też inne komendy lub systemy które inicjują dane zdarzenia. Role są bardzo zależne od specyfiki produktu. Przykładowo jeżeli byśmy rozwijali aplikację dla warsztatu samochodowego jako aktora z pewnością moglibyśmy wyróżnić – mechanika. W takim przypadku moglibyśmy stworzyć user story:

  • Jako mechanik chcę wybrać rodzaj uszkodzenia pojazdu aby szybciej wygenerować raport. 

Zdefiniowanie aktorów pozwala twórcom mocniej wejść w skórę klienta i lepiej zrozumieć budowany produkt. Tutaj ponownie należy wybrać inny konkretny kolor karteczek i trzymać się konwencji jednego aktora na jednej kartce. Aktorów można później wykorzystać przy tworzeniu user stories – nie mamy wtedy zwykłego usera, a konkretnie nazwaną postać.

event storming
Tworzenie ról na podstawie Instragrama – miro.com

Agregaty

Wyróżnianie agregatów polega na grupowaniu zdarzeń domenowych, aktorów i komend w większe grupy. Przy tym punkcie musimy stworzyć zbiory zawierające informacje dotyczące jednej funkcjonalności. Agregatem tak jak w poniżej zamieszczonym przykładzie może być np. Rejestracja – oznaczona różowym kolorem. Ważne żeby poprzez te jedno, góra dwa słowa osoba patrząca z boku mogła bez problemu odczytać czego ten zbiór dotyczy. Ponownie wracając do przykładu Instagrama, agregatem może być publikacja zdjęcia, w skład której może wchodzić szereg zdarzeń domenowych, komend i aktorów, którzy wspólnie muszą tworzyć całość, tak żeby wspomniana publikacja była możliwa. 

event storming
Tworzenie agregatów na podstawie Instragrama – miro.com

Agregaty, podobnie jak komendy, aktorzy i zdarzenia domenowe, mogą być później wykorzystane w pracy nad projektem. Możemy użyć ich jako epiki opisujące dużą funkcjonalność, zawierającą wiele user stories. 

“Epics are large bodies of work that can be broken down into a number of smaller tasks (called stories)”

Atlassian

W skład agregatu może wchodzić wiele komend, aktorów i zdarzeń domenowych. Warto jednak pamiętać, że tworząc agregaty powinno się łączyć tylko te najbardziej do siebie pasujące elementy by zminimalizować niepotrzebne rozbudowanie epików. 

Czy to wszystko?

I tak i nie. Powyżej przedstawiłam wersję Event Stormingu, którą stosowałam wraz z zespołami w praktyce. Na pewno można ją znacznie rozszerzyć lub też odrobinę okroić. Zdarzało mi się brać udział w sesjach, w których część tworzenia komend była pomijana. Dla samego poznania domeny produktu nie ma ona aż tak wielkiego znaczenie o ile rzetelnie podejdziemy do pozostałych części Event Stormingu. Jego przebieg jest bardzo mocno uzależniony zarówno od wielkości produktu, którym mamy się zajmować – lub od jego poszczególnej funkcjonalności – jak i również od czasu jakim dysponujemy. 

Optymalny czas trwania ES należy określić na podstawie informacji jakie mamy na temat produktu. Z doświadczenia mogę powiedzieć, że 4-5 godzin to min. długość na sesję jaką zaproponowałabym na średniej wielkości produkt. Jeżeli organizujemy całe 2-3 dniowe warsztaty produktowe, którym towarzyszy wykorzystanie szeregu innych narzędzi takich jak Product Canvas, User Journey Map, metoda Moscow, czy wiele innych, warto zrobić sobie “noc” przerwy i wrócić do rozbijania produktu na części na kolejnym dniu. Pozwoli to ekspertom domenowych zastanowić się czy nie pominęli jakiejś ważnej części produktu. Z kolei ekspertom technicznym da czas na analizę tego co już wiedzą i znalezienie rzeczy o które warto jeszcze dopytać. Taka przerwa może dać szansę całemu zespołowi warsztatowemu na wygenerowanie nowych pomysłów, ugruntowanie wiedzy i dopracowanie najistotniejszych elementów. 

Podsumowanie

Event Storming  jest cennym narzędziem w obszarze poznania produktu na samym początku jego tworzenia. Świetnie też sprawdza się w momencie gdy następuje zmiana koncepcji produktu, wtedy jest swoistym zaproszeniem do dyskusji o systemie. Dzięki takiej sesji możemy poznać różne punkty widzenia i upewnić się, że wszyscy rozumieją całość tak samo. Event Storming można zastosować również przy rotacji czy dołączeniu nowych członków do zespołu. Tak naprawdę zastosowań może być bardzo wiele bo ta metoda jest łatwym sposobem na zweryfikowanie produktu bez użycia kodu, co w efekcie końcowym ma zapewne wpływ na budżet. 

Źródło: giphy.com

Sprawdź nasze ostatnie wpisy: