Jak każda inna firma, w Easy LMS mamy wiele procesów. Na przykład, w jaki sposób obsługujemy zgłoszenia do pomocy technicznej lub opracowujemy nowe funkcje. Używamy Improvement Kata do optymalizacji naszych procesów. Jednym z pierwszych kroków jest określenie obecnej sytuacji. Okazuje się jednak, że każdy ma swój własny pogląd na to, jaka jest obecna sytuacja. EventStorming to technika, której używamy do jednoznacznego definiowania naszych procesów.
Wyobraź sobie, że jesteś nowym pracownikiem dołączającym do firmy. Zostajesz sparowany z bardziej doświadczonym członkiem zespołu i przechodzisz przez wszystkie, w większości nieudokumentowane, procesy biznesowe. Tworzysz mentalny model procesu, zadając pytania i czytając dokumentację. Im więcej doświadczenia zdobędziesz, tym mniej pytań będziesz musiał zadawać i tym mniej dokumentacji będziesz musiał przeczytać. Większość rzeczy będziesz robić (półautomatycznie).
Mniej aktualna dokumentacja dotycząca danego procesu będzie prowadzić do większych różnic w modelach mentalnych pracowników dotyczących tego procesu.
Następnie, jeśli porównasz sposób, w jaki radzisz sobie z tym procesem z innym członkiem zespołu, zauważysz, że niektóre rzeczy robisz zupełnie inaczej. Dzieje się tak, ponieważ wasze modele mentalne się różnią.
Podczas optymalizacji procesu przy użyciu Improvement Kata, opisanie obecnej sytuacji może być trudne, gdy modele mentalne znacznie się różnią. Gdybyśmy tylko mieli sposób na przekształcenie tych modeli mentalnych w dokumentację.
Jak doszliśmy do EventStorming
Na początku 2020 roku wziąłem udział w konferencji Domain-Driven Design Europ, aby dowiedzieć się więcej o lepszym modelowaniu naszego oprogramowania. Jeden z warsztatów, do którego chciałem dołączyć, dotyczył EventStorming. Czytałem o tym wcześniej i pomyślałem, że może to pomóc nam wydobyć wiedzę specyficzną dla domeny z głów naszych ekspertów w sposób, który można łatwo udostępnić programistom. Dzięki temu moglibyśmy tworzyć lepsze oprogramowanie. Okazało się, że EventStorming jest bardzo przydatny do modelowania oprogramowania, ale także do modelowania procesów biznesowych!
Niestety, pandemia uderzyła. Zamknęliśmy nasze biuro i zaczęliśmy pracować zdalnie. EventStorming obraca się wokół grupy ekspertów w pokoju pracujących na dużej wspólnej powierzchni. Nie było to już możliwe do zorganizowania. Na szczęście Alberto Brandolini, założyciel EventStorming, również zdał sobie z tego sprawę i zorganizował kolejne warsztaty, aby rozwiązać ten problem: Remote EventStorming. Dołączyłem do niego, a potem czekałem na okazję, by poeksperymentować z EventStorming.
Modelowanie naszego procesu rozwoju za pomocą EventStorming
W ciągu ostatnich kilku miesięcy często zmienialiśmy nasz proces rozwoju. Czasami proces zawodził i stawało się jasne, że nikt nie ma już pełnego przeglądu procesu. Idealny proces kandydujący do wypróbowania EventStorming!
Mówię zespołowi, że chcę poeksperymentować z EventStorming. Jestem przekonany, że w ten sposób uzyskamy dobry przegląd bieżącego procesu rozwoju. Zapraszam kilku zainteresowanych deweloperów z obu zespołów i tworzę współdzieloną zdalną tablicę za pomocą Miro. Postępujemy zgodnie z domyślnymi krokami EventStorming:
Eksploracja chaotyczna: utwórz karteczki samoprzylepne dla wszystkich zdarzeń, które mogą wystąpić w procesie.
Wzmocnij oś czasu: uporządkuj zdarzenia od początku procesu do końca.
Wzbogacanie zdarzeń: dodaj metainformacje do każdego zdarzenia. Polecenie (akcja), które uruchamia zdarzenie, potrzebne dane, system, który działa i zasady, które mówią, co robić dalej.
.
Chaotyczna eksploracja
Na początku wydaje się to nieco niezręczne. Ale gdy tylko pojawiają się pierwsze karteczki samoprzylepne, tempo naprawdę wzrasta i wszyscy są w to zaangażowani.
Zaczynamy od rozdania wszystkim uczestnikom ich własnego kawałka tablicy i koloru (ale nie pomarańczowego, więcej o tym później). Mają oni 25 minut na stworzenie karteczek samoprzylepnych dla wszystkich wydarzeń, które przychodzą im do głowy podczas procesu. Wydarzenie to coś, co wydarzyło się w przeszłości i czego nie można już zmienić. Dlatego zapisuje się je w czasie przeszłym. Na przykład: "Utworzone repozytorium kodu" lub "Kod wdrożony do środowiska produkcyjnego".
Zachęcam ich do "oszukiwania" i patrzenia na wydarzenia zapisane przez innych uczestników, ponieważ może to otworzyć zupełnie nową część procesu, o której wcześniej nie myślałeś. Dodawanie wydarzeń, które mają również inni uczestnicy, jest całkowicie w porządku.

Egzekwowanie osi czasu
Gdy zauważę, że na tablicy nie pojawiły się żadne nowe karteczki samoprzylepne, przechodzimy do następnego kroku. Rysuję linię na tablicy. Następnie proszę wszystkich o wybranie karteczki samoprzylepnej z wydarzeniem, które ma miejsce jako pierwsze w procesie rozwoju i przeniesienie jej nad oś czasu. Krótko omawiamy, które wydarzenie jest naprawdę pierwsze i umieszczamy je na początku osi czasu. Aby zaznaczyć, że wszyscy zgadzamy się co do tego wydarzenia i jego miejsca na osi czasu, zmieniamy kolor karteczki samoprzylepnej na pomarańczowy (dlatego wcześniej nie było karteczek samoprzylepnych w tym kolorze?). Następnie przechodzimy do następnego zdarzenia.
Wdajemy się w dłuższą dyskusję na temat wydarzenia. Aby utrzymać ciągłość dyskusji, tworzę specjalny rodzaj karteczek samoprzylepnych zwany hotspot. Opisuję na niej problem, a następnie przechodzimy dalej. Do hotspotów wrócimy później. Napotykamy zdarzenie utworzone przez wielu uczestników. Zachowujemy to, które najlepiej opisuje zdarzenie i usuwamy pozostałe. Dodajemy także rozgałęzienia dla zdarzeń warunkowych. Umieszczamy je powyżej lub poniżej osi czasu głównego procesu.
Po dwóch i pół godzinie zatrzymujemy się. Oś czasu jest gotowa, a wszystkie punkty zapalne zostały rozwiązane. Wszyscy są podekscytowani i natychmiast planujemy następne spotkanie, aby uczynić proces bardziej przejrzystym poprzez wzbogacenie wydarzeń o metadane.

Wzbogacanie zdarzeń o metadane
Najlepiej wyjaśnić ten krok za pomocą obrazka:

Na początku naszego (pod)procesu (duża czarna karteczka samoprzylepna) musimy podjąć działanie (niebieska karteczka samoprzylepna), aby podzielić pracę. Aby to zrobić, potrzebujemy informacji (zielona karteczka samoprzylepna) w postaci historii użytkownika, nad którą będziemy pracować. Jira to system (duża różowa karteczka samoprzylepna), którego używamy do tego celu. Po zakończeniu podzieliliśmy historię użytkownika na tak zwane podzadania. To wydarzenie (pomarańczowa karteczka samoprzylepna). Polityka deweloperska (duża fioletowa karteczka samoprzylepna) nakazuje nam wykonać następującą czynność: umieścić podzadanie w postępie w systemie Jira.
Podążamy za osią czasu i wzbogacamy każde wydarzenie. Jeśli nie jesteśmy pewni, jak wzbogacić wydarzenie o metadane, tworzymy hotspot i przechodzimy dalej. Później ponownie sprawdzamy wszystkie hotspoty. Niektórych hotspotów nie możemy naprawić. Na przykład, gdy demonstrujemy historię, ponieważ zależy to od planowania interesariuszy. Lub gdy tworzymy dokumentację dla historii, ponieważ nie jest to jeszcze częścią naszego procesu. To jest w porządku; po prostu opisujemy obecną sytuację naszego procesu. Ale jest to coś, co możemy poprawić!
Eksperyment zakończony pomyślnie
Wszyscy są entuzjastycznie nastawieni do EventStorming i wyników, jakie dzięki niemu osiągnęliśmy.
Byłem przekonany, że możemy uzyskać dobry przegląd obecnego procesu rozwoju, wykonując EventStorm. W końcu rzeczywiście mamy jasny obraz naszego procesu rozwoju:

Teraz łatwo jest wyjaśnić innym, na czym polega nasz obecny proces rozwoju. Wiemy również, że w naszym obecnym procesie brakuje niektórych istotnych elementów.
Nie mogę się doczekać, aż zacznę modelować nasze inne procesy biznesowe!