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:
- Event Storming – Narzędzie usprawniające pracę organizacji
- Event Storming – Mapowanie ograniczeń
- Event Storming – Co dalej?
Comments:
Event Storming – jak szybko odkrywać nieznane? | Radek Maziarka
Dziękujemy za dodanie artykułu - Trackback z dotnetomaniak.pl
