Event Storming - jak szybko odkrywać nieznane?

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.

Także, do dzieła! Jeśli zainteresował Cię ten temat to polecam moje warsztaty z Event Stormingu lub pozostałe posty z tego tematu:

Comments:

dotnetomaniak.pl - Dec 4, 2018

Event Storming – jak szybko odkrywać nieznane? | Radek Maziarka

Dziękujemy za dodanie artykułu - Trackback z dotnetomaniak.pl