Event Storming to dość młoda, ale ciesząca się coraz większą popularnością metoda do zespołowego odkrywania i  modelowania procesów wewnątrz skomplikowanych domen biznesowych. Pokazuje ona jak za pomocą zdarzeń opisywać działanie naszego systemu.

Technika została opisana pierwszy raz w 2013 roku przez Alberta Brandoliniego, bardzo szybko zdobyła serca osób związanych z Domain Driven Design. W najnowszym Technology Radarze ThoughtWorks Event Storming został wskazany jako polecana metoda do modelowania domeny biznesowej w systemach informatycznych.

Warsztat ten jest skierowany i opisywany głównie na podstawie systemów informatycznych, i takie też przypadki będziemy opisywać w tym poście. Można ją również wykorzystywać do ogólnej strukturyzacji wiedzy o procesach w organizacji lub firmie – post na ten temat już wkrótce.

Przeprowadzenie warsztatów nie wymaga specjalistycznej znajomości opasłych ksiąg i dziesiątek video – wszystko zaczyna się od pomarańczowej karteczki.

Zdarzenie domenowe – serce warsztatu

Event Storming opiera się na zdarzeniach domenowych – faktach opisujących pracę naszego systemu. Każde zdarzenie zapisujemy na karteczce i umieszczamy na ścianie. Poniżej moje (lekko niestarannie napisane) zdarzenie- dodanie produktu do koszyka.

Każda karteczka to istotna informacja o wydarzeniu jakie zaistniało w systemie. Wszyscy uczestnicy systemu (prawie), niezależnie od siebie, umieszczają swoje karteczki na wcześniej przygotowanej ścianie. W zależności od ilości zdarzeń ściana po tej fazie pracy może wyglądać np. tak:

Nawet jeśli na pierwszy rzut oka wydaje wam się to przytłaczające, uwierzcie mi – rezultat jest fenomenalny – w kilka chwil nasi koledzy i inni pracownicy są w stanie zrzucić prawie całą / dużą część wiedzy o swoim systemie na wspólną przestrzeń.

Dalej zaczyna się strukturyzacja powyższego rezultatu.

Strukturyzacja

Po umieszczeniu wszystkich zdarzeń na ścianie zaczyna się porządkowanie i układanie powyższych karteczek, w taki sposób, by nasze zdarzenia połączyć we wspólne procesy biznesowe / przypadki użycia. Każdy taki proces możemy analizować osobno, przechodząc go chronologicznie od początku do końca, jak i odwrotnie, by zyskiwać coraz większą wiedzę jak nasz proces zachodzi.

Aby bardziej uwidocznić prawidłowości zachodzące w analizowanym procesie przychodzą nam z pomocą karteczki w innych kolorach, których zadaniem jest zwizualizowanie dodatkowych informacji o systemie:

  • Jasno-żółte – notatki, opisujące jakiś szerszy temat
  • Różowe – problemy / niejasności / ryzyka
  • Liliowy – zewnętrzne systemy
  • Małe żółte – aktorzy / osoby / działy
  • Zielone – szanse na rozwój / poprawę
  • Niebieskie – komendy
  • Inne

Nowe kolory wprowadzamy je do warsztatu stopniowo, kiedy potrzebujemy uzyskać daną informację od naszych kolegów.

Cele warsztatu

Rezultatem dobrze przeprowadzonego warsztatu jest pełny widok naszego systemu, zarysowane procesy biznesowe i sposób ich interakcji z użytkownikami i zewnętrznymi systemami. Taka wiedza pozwala nam na:

  • głębsze zrozumienie systemu nad którym pracujemy, ustalenie wspólnego postrzegania pomiędzy wieloma pracownikami / stakeholderami
  • wizualizację sposobu pracy systemu, która pozwala np. podzielić go na mniejsze części / mikroserwisy
  • odpowiednio szybką wymianę wiedzy, aby np. wdrożyć nowych programistów do pracy nad systemem
  • analizę aktualnych problemów systemu wraz z pomysłami jak je naprawić
  • stworzenie planu na dodanie nowej funkcjonalności do obecnego systemu
  • predykcję możliwości rozwoju naszego systemu i osiągania większych zysków

Przykładowy rezultat warsztatu

Jeden wielu z takich warsztatów przeprowadziliśmy dla naszego klienta. Zadaniem było zrozumieć jak działa duży, monolityczy system i zaplanować podzielenie go na mniejsze części. Poniżej rezultat naszego warsztatu (zdjęcie z 1/2 całości):

Warsztat trwał kilka godzin, a po skończeniu pracy byliśmy w stanie zrozumieć:

  • Jakie części systemu są trywialne i nie musimy się nimi przejmować
  • Jakie części systemy powinny zostać od siebie odseparowane do osobnych modułów / mikroserwisów
  • Gdzie powinny leżeć granice takich modułów
  • W jaki sposób powinny się te moduły komunikować
  • Jak gromadzić dane pomiędzy modułami, by nie mieć zbyt częstej komunikacji
  • Jakie mamy realne i potencjalne problemy z obecnym systemem, które musimy rozwiązać
  • Które systemy zewnętrzne sprawiają problemy

Wszyscy uczestnicy warsztatów byli bardzo zadowoleni z rezultatów, ale jednocześnie zdumieni, że to wszystko udało się osiągnąć w ciągu jednego dnia.

Po takim zastrzyku wiedzy mogliśmy podzielić się dalszą pracą i zacząć implementować lepsze rozwiązanie dla naszego klienta.

Ogólne spojrzenie na Event Storming

Jak widać z przykładu, warsztaty Event Storming pozwalają w prostszy sposób zwizualizować sposób działania naszego systemu poprzez równoczesną i wspólną wymianę wiedzy między współpracownikami. Każda z osób jest zaangażowana, by dzieli się wiedzą o swoim obszarze prac, przekazując jak najwięcej informacji.

Ważne jest, że Event Storming ma bardzo niski próg wejścia, dzięki czemu każdy jest w stanie błyskawicznie rozpocząć w nim czynny udział. Wszystko opiera się na „zdarzeniach biznesowych”. Po krótkim wytłumaczeniu czym jest zdarzenie biznesowe jesteśmy gotowi, by działać.

Dodatkowym aspektem jest tutaj czas. Przez zrównoleglenie prac i podział grupy jesteśmy w stanie pracować efektywniej, dzięki czemu warsztaty są krótsze i dające wymierny efekt.

Jak przeprowadzić taki warsztat

Istnieje wiele materiałów opisujących warsztat Event Stormingu, zarówno w języku angielskim (artykuł / video) jak i polskim (artykuł / video), nie wspominając już o tej najważniejszej książce. Bardzo ciekawy zbiór zawarł Mariusz Gil na GitHubie w repo Awesome EventStorming.

Info na koniec – przedstawiona, zarówno w poście jak i wszelkich materiałach, kolorystyka karteczek jest subiektywna. Możecie używać takich kolorów jakiej potrzebujecie, byle byście byli spójni.

Także, do dzieła!