Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Event Storming, czyli jak w 3h poznać system pisany kilka lat

Sprawdź, w jaki sposób Event Storming przyda Ci się jako narzędzie do wymiany wiedzy w zespole.

Event Storming to narzędzie, które może okazać się bardzo pomocne w rozwiązywaniu problemów ludziom, pracującym wspólnie nad jednym projektem. Dzięki prostej, interaktywnej formie, ułatwia zrozumienie procesu biznesowego. Niezależnie od tego, w jaki sposób chcemy wykorzystać Event Storming, jego przejrzysta konstrukcja pozwala na szybkie rozpoczęcie warsztatu, który okaże się bardzo angażujący dla uczestników.

Kiedy okazało się, że dwa zespoły z EDC dołączają do dużego projektu, rozwijanego wcześniej równolegle przez 5 zespołów, zrozumieliśmy, że oprócz zwykłych sesji przekazywania wiedzy, potrzebujemy czegoś więcej. Z jednej strony mamy osoby mające mnóstwo pytań, a z drugiej - znające odpowiedzi na pytania (biznes i programiści rozwijający produkt od 3 lat). Mieliśmy doskonałą okazję na wypróbowanie Event Stormingu w praktyce.


Event Storming i jego rodzaje

O Event Stormingu powiedziano już wiele, ale spróbuję opowiedzieć, jak ja widzę tę technikę. Dla mnie jest to narzędzie do wymiany wiedzy pomiędzy wszystkimi uczestnikami warsztatu. Mam tu na myśli programistów, reprezentantów biznesu, analityków, UX-owców i wszystkich innych, którzy pracują nad danym systemem. Czasami bywa dziwnie, chaotycznie i często niezwykle męcząco – całość trwa co najmniej kilka godzin, a wszyscy stoją przed ścianą bądź tablicą przy której toczone są dyskusje. Niemniej, jest to narzędzie niezwykle skuteczne. To, co otrzymujemy na końcu, jest wspólnym modelem procesu wszystkich uczestników sesji.

Zwykle na sesjach wymiany wiedzy informacje płyną w jedną stronę – od prezentera do słuchaczy. Tutaj, każdy przedstawia swój punkt widzenia, by potem skonfrontować go z innymi. Uczestnicy mają za zadanie zapisać poszczególne kroki procesu (eventy), wyrażone pod postacią krótkich zdań w czasie przeszłym, umieszczonych na pomarańczowych karteczkach. Gdy każdy odtworzy to, jak rozumie system, grupa nadaje chronologię zdarzeniom i tworzy spójną opowieść od początku do końca procesu.

Event Storming to narzędzie niezwykle elastyczne i może być wykorzystane m.in. jako:

  • wstęp do DDD (tak jak opisano w tym artykule)
  • warsztat, na którym złożony system rozbija się na części i pochyla się nad jedną z nich
  • warsztat Big Bicture, na którym uczy się o procesie biznesowym, ale bez szczegółów
  • forma retrospekcji


Big Picture

Na warsztacie Big Picture, którego całość zamknęła się w trzech godzinach, naszym celem było zrozumienie całego procesu biznesowego. Obejmowało to zdarzenia sprzed, ale i po tym, co dzieje się w samej aplikacji. Dzięki temu zespół deweloperski miał szansę zrozumieć podjęte na przestrzeni lat decyzje oraz cele produktu.

Wyzwaniem było dla nas to, że na warsztacie mieliśmy ponad dwadzieścia osób, z czego większość miała tylko mgliste pojęcie o działaniu produktu. Jak się później okazało, wykorzystaliśmy to na swoją korzyść. Zanim przejdę do opisu samego spotkania, chciałbym w kilku słowach napisać o samej notacji i tym, z czego skorzystaliśmy.

W Event Stormingu kolory karteczek sprawiają, że model, który tworzymy, jest coraz bogatszy. Warto zaznaczyć, że sesja pomyślana jest w taki sposób, by tylko jeden kolor został wprowadzony naraz. Ułatwia to skupienie na aktualnym celu i zrozumienie samej notacji. My wykorzystaliśmy tylko trzy elementy:

Jest to bardzo okrojona wersja notacji, jednak dla nas wystarczająca.


Przebieg spotkania

Kiedy przyszło nam prowadzić warsztat z biznesem, byliśmy już po próbnych sesjach (na wymyślonej domenie), które odbyliśmy we własnym gronie. Dzięki temu nauczyliśmy się, że przy licznej grupie potrzeba dużo miejsca, zarówno na zdarzenia na ścianie, jak i do swobodnego poruszania się przy niej.

Mieliśmy szansę dopracować wprowadzenie do warsztatu, na którym pokazaliśmy przykładowe zdarzenia z powszechnie znanej domeny (np. zamówiono przejazd albo oceniono kierowcę w przypadku zdarzeń dla firmy przewozowej).

Po krótkim powitaniu uczestników i przedstawieniu celu spotkania przeszliśmy do pierwszego etapu.


Chaotic Exploration

Celem tej fazy, jak sama nazwa mówi, jest eksplorowanie domeny. Każdy ma za zadanie wypisywać eventy dotąd, aż skończą mu się pomysły.

Tak jak przewidywaliśmy, zaczęło się chaotycznie. Ściana w 20 minut zapełniła się zdarzeniami. Poprosiliśmy uczestników, żeby od razu - w miarę możliwości - starali się rozmieszczać zdarzenia chronologicznie na umieszczonej na ścianie osi czasu. Było to niezwykle przydatne w kolejnej części warsztatu.

Warto zaznaczyć, że podczas pisania zdarzeń, ludzie w większości nie rozmawiali, żeby nie sugerować, ani nie uzgadniać, co powinno się znaleźć na ścianie. Ani podczas sesji próbnych, ani podczas warsztatu, nie musieliśmy nakładać ograniczeń czasowych na tę fazę.

Uczestnicy intensywnie wyrzucali z siebie to, co mają w głowie, ale zazwyczaj nie trwało to na tyle długo, by im przerywać. Warto obserwować zachowanie ludzi i w odpowiednim momencie pytać, czy potrzebują jeszcze czasu na dokończenie.


Enforce the timeline

W teorii niezwykle proste - ułożyć zdarzenia chronologicznie na osi czasu. Niestety przy tak dużej grupie potrzebowaliśmy przyjąć odpowiednią strategię.

Zaczęliśmy od oznaczenia kluczowych zdarzeń w systemie. One podzieliły oś czasu systemu na pięć okresów. Stosownie do ich liczby, podzieliliśmy naszą grupę na pięć podgrup, gdzie zadaniem każdej było układanie zdarzeń tylko dla jednej części systemu, ograniczanej przez wcześniej wytypowane karteczki. Tutaj niezwykle pomocna była wiedza ekspertów, którzy pomogli przy tym wyborze.

To był czas, w którym zaczęły ścierać się koncepcje na temat działania systemu. Okazywało się, że pomyłki z naszej strony były początkiem dyskusji. Kiedy grupy orientowały się, że w ich grupie zdarzeń są karteczki należące do innych grup, przekazywały je sobie.

Był to też moment, w którym zaczęliśmy wprowadzać kolejne rodzaje karteczek. Hot spoty – oznaczające coś, co trzeba wyjaśnić oraz kawałki dokumentacji – opisujące nowe pojęcia, lub ujednolicające słownictwo.

Gdy wszystkie grupy były gotowe, zrobiliśmy przerwę, aby po niej przystąpić do ostatniej części warsztatu.


Explicit walkthrough

W tej rundzie każda grupa wyznaczyła narratora. Jego zadaniem było opowiedzenie historii, która wyłoniła się z uporządkowanych zdarzeń. Był to czas, kiedy omawialiśmy kolejne pytania, dokumentowaliśmy słownik oraz toczyło się najwięcej dyskusji.

Wszyscy uczestnicy warsztatu mogli mieć wątpliwości co do kolejności, czy zasadności zdarzeń. Niektóre usuwaliśmy, inne brakujące dodawaliśmy, a powtarzające się łączyliśmy w jedno.

Z perspektywy facylitatora, ciekawe było obserwowanie osób, które rozwijają system od lat i właśnie próbują zgodzić się co do jego działania, bazując na bardzo prostych zdarzeniach. Była to najdłuższa część warsztatu. Na koniec otrzymaliśmy dosyć prosty obraz całości systemu w postaci ściany zapełnionej karteczkami z odpowiednimi nazwami. Dobrym pomysłem jest również oznaczenie podprocesów.


Czy to wszystko?

Absolutnie nie! Mogliśmy kontynuować warsztat. Gdyby czas na to pozwolił, w fazie Expplicit walkthrough opowiedzielibyśmy również historię od końca. Ta technika pomaga wykryć dziury w rozumowaniu i prowokuje do kolejnych dyskusji.

Zagłębiając się w system, mogliśmy dodać aktorów, zagłosować na miejsca, które są najbardziej problematyczne w procesie, czy poszukać zewnętrznych systemów, z którymi się komunikujemy. Summa summarum, dla naszych potrzeb, sesja zawierająca tylko wycinek całej notacji, była w zupełności wystarczająca.


Co osiągnęliśmy?

To, co udało nam się odkryć, owocowało podczas kolejnych sesji wymiany wiedzy. Kiedy produkt był prezentowany, nasi współpracownicy odwoływali się do Event Stormingu, pytając, czy pamiętamy ten albo inny fragment, który razem ustaliliśmy.

Przydał się również słownik domenowy, który chociaż w części udało nam się stworzyć w czasie warsztatów. Ułatwiło to porozumiewanie się tymi samymi terminami. Co krzepiące, było też zainteresowanie kolejnymi podobnymi sesjami.

Mam nadzieję, że udało mi się chociaż po części przybliżyć Wam temat Event Stormingu i jego wykorzystanie w praktyce. Nasza sytuacja pokazuje, że także duże grono pracujących nad systemem osób może korzystać z tego narzędzia i co więcej – z powodzeniem czerpać z niego wiele korzyści w dalszej współpracy.