Nieograniczona moc

„Power! Unlimited power!” - tak właśnie krzyczał Darth Sidious w Star Wars III: Revenge of the Sith. Teraz kiedy myślę o EventStormingu (połączonym z Event Modelingiem) i jego możliwych efektach, czuję dokładnie to samo. Niestety nie zawsze tak było. To jak z wystąpieniami na konferencji, jeśli treści będą zbyt skomplikowane, to uczestnicy mogą wyjść z dwoma rodzajami przemyśleń:

• Nic nie zrozumiałem, ale ten prelegent / EventStorming jest głupi.
• Nic nie zrozumiałem, ale ten prelegent / EventStorming jest mądry.

Niezależnie od wyniku, wiele to nie wnosi w programistyczną codzienność słuchaczy. Ja przez około dwa lata od usłyszenia o EventStormingu, sądziłem, że nie jest to nic specjalnego. Chcę, żeby wpisy na tym blogu były inne i szybko doprowadził Cię do odkrycia benefitów pokazywanych przeze mnie technik. Żeby to mogło się stać, to konieczna jest Twoja praktyka. To z nią przychodzi zrozumienie! Sam też nawet próbowałem go stosować-bez większych rezultatów. Aż w końcu nastąpił moment Aha!, do którego będę chciał też Ciebie doprowadzić. Dodatkiem spinającym wszystko w zrozumiałą całość był EventModeling. Zaznajomię Cię z tą metodą w kolejnych wpisach na tym blogu. Dzięki niej bez problemu przełożysz wyniki warsztatu na działający kod! A przy tym spostrzeżesz wiele zależności i zawczasu rozwiążesz problemy, które dla diagramów UML są nie do wyrażenia. W dalszej części będę używał słowa warsztat czy sesja. Oznacza to spotkanie, na którym przeprowadzasz EventStorming.

EventStorming jest jak pizza? A no ba!

Co ma wspólnego pizza z EventStormingiem? 👨‍🍳 Na szczęście określił to już Alberto Brandolini! Autor tej techniki. Co w takim razie mają wspólnego? Nie tylko to, że Alberto jest Włochem. Odpowiedź znajdziesz dalej.

W poprzednim wpisie TUTAJ zaproponowałem Ci świetne, proste ćwiczenie na obycie się z EventStormingiem. Jeśli jeszcze go nie zrobiłeś to dobrze tam wrócić albo przeprowadzić z uczestnikami na realnym warsztacie.

Jendak naszym głównym zajęciem jako developerów nie jest rozstrzyganie sporów w bajkach, ale… No właśnie, co? Może właśnie spowoduję Twój szok, ale jednym z cytatów, jakim się kieruję, jest: Software development is a learning process. Working code is a side effect.

Akurat nieprzypadkowo pochodzi on z książki Introducing EventStorming (tutaj Brandolini cytuje Dana Northa). Spokojnie, też kiedyś myślałem inaczej. Domain-Driven Design i EventStorming zmienił moje podejście do developmentu o 180 stopni. I nie tylko moje. Możesz posłuchać, co mówi o tym Mariusz Gil (obecnie największy autorytet z zakresu EventStormingu w Polsce) podczas prelekcji na konferencji Boiling Frogs 2018 - Discovering unknown domain with Event Storming. Na prezentacji są też ładne obrazki. Więc chyba warto 😆? Szczególnie jeśli z opisu ciężko Ci sobie wyobrazić jak to wszystko powinno wyglądać.

Jesteś programistą? Twoim zadaniem nie jest pisanie kodu!

Jak to jest, że jako programiści głównie musimy się uczyć, a powstały kod to tylko skutek uboczny tego procesu? Powiedz, jaka jest wartość dobrego kodu, napisanego na czas i w budżecie, przez kogoś, kto nie zrozumiał problemu do rozwiązania? Można go od razu wyrzucić do kosza. Jako developerzy optymalizujemy naszą aplikację, ale nie proces pozyskiwania wiedzy domenowej. A niestety, aby rozwiązać jakiś problem / zautomatyzować działanie czegoś musimy najpierw dogłębnie zrozumieć o co chodzi. Spisane setki stron analizy biznesowej i diagramy UML tutaj nie pomogą. Wiem to z własnego doświadczenia. Ty pewnie niestety też. EventStorming pomaga w procesie zwanym „knowledge crunching”, czyli wyciągania wiedzy od osób, które ją mają. Ty jesteś developerem, nie klepaczem kodu! Będziesz w stanie wyssać wiedzę z głów ekspertów domenowych, znaleźć ich problemy i zaproponować rozwiązanie za pomocą znanych Ci technologii. Ekspertami domenowymi nazywamy osoby, które są specjalistami w obszarze, jaki modelujemy. W branży medycznej może to być lekarz, przy paczkomatach będzie to kurier czy osoba na sortowni itd.

Ten artykuł pisałem jako część mailingu na tydzień przed prowadzeniem kolejnego EventStormingu, dlatego na prawdziwym przykładzie opiszę Ci jak przygotować się do takich warsztatów i co powinno być ich rezultatem. A domyślasz się, co tym razem będzie Twoim zadaniem? Zrobić dokładnie to samo, korzystając z moich instrukcji 😀. Mam nadzieję, że niedługo podzielimy się wzajemnie swoimi doświadczeniami!

Unlimited power? Unlimited space!

Właśnie tak, nieograniczona (teoretycznie) przestrzeń, to pierwsze co trzeba zapewnić. W przypadku EventStormingu on-line jest to dość łatwe. Nigdy nie doszedłem do maksymalnego rozmiaru pliku na Miro czy w Figmie (dwa narzędzia, które jak dotąd używałem do ES). Na żywo? To trochę bardziej problematyczne. Jakieś 10 metrów ściany to powinno być minimum. Niestety realia bywają tutaj różne, a do sąsiadów się nie przebijemy 🔥.

Tapetowanie karteczkami samoprzylepnymi

Na tej ścianie będą pojawiać się nasze zdarzenia i inne elementy notacji EventStormingu, a także wszystko, co się po prostu przyda 😀. Potrzebne też będzie sporo post-itów odpowiednich kolorów, jeśli chcemy się spotkać na warsztaty fizycznie. W tym przypadku najlepiej mieć kolory: pomarańczowy, czerwony, różowy, zielony, żółty, fioletowy. Z bardziej ograniczonym zasobnikiem też da radę, ale będzie po prostu ciężej 😀. ProTip: Jeśli nie chcesz oderwać razem z karteczką farby ze ściany to lepiej zaopatrzyć się też w folię elektrostatyczną, którą widzisz na zdjęciu powyżej.

Druga rzecz to czas. Choć EventStorming potrafi naprawdę zaangażować, to jednak polecam każdą sesję ograniczyć do około 3 godzin. Jest to czas, w którym powinno się jeszcze utrzymać skupienie ludzi, a zmęczenie czy ból nóg (przy wersji stacjonarnej) nie dają się jeszcze tak bardzo we znaki.

(Programista + Biznes) * EventStorming = Symbioza

Mamy przestrzeń, mamy termin. Super! Tylko co będziemy robić sami w pokoju? Warunkiem koniecznym dla efektywności warsztatów są ludzie z właściwymi pytaniami i ci, którzy potrafią na nie odpowiedzieć. Pytania zazwyczaj będziesz zadawał Ty czy zespół developerski. Kto ma mieć odpowiedzi? Od kogo pozyskiwać wiedzę? Eksperci domenowi to właściwy kierunek. Jak nie pamiętasz, kto to jest to Ctrl+F na tym wpisie Ci pomoże 😀. EventStorming nie jest tylko dla programistów. To świetny czas, kiedy osiąga się symbiozę między ludźmi technicznymi a biznesem.

Wspomniałem o bólu nóg? Jak tylko zaproszeni uczestnicy wejdą do pokoju, niech zobaczą, że to nie jest kolejne z nudnych spotkań, na którym będą siedzieć w nosie z laptopem. Wszelkie laptopy i krzesła powinny w ogóle się tam nie znaleźć, a przynajmniej zostać umieszczone pod ścianą. “Notowanie” w telefonie też jest zabronione — wszystko będzie się pojawiać na wspólnej tablicy :) EventStorming wymaga dużo aktywności, chodzenia — biegania po przygotowanej przestrzeni. Nie mam tutaj jeszcze przepisu na wersję zdalną — ale może stanie przy biurku coś tutaj da 😂? À propos wersji zdalnej. Możesz przeczytać co sądzi o niej Alberto PRZED i PO wydarzeniach ostatnich lat i boomie na pracę zdalną.

---

Ten post jest częścią Mailingu Domain-Driven Design. Jeśli chcesz dostać więcej tego typu treści i mieć ze mną ułatwiony kontakt, to koniecznie zapisz się TUTAJ. Czytam i odpowiadam na wszystkie maile. To czasochłonne zajęcie, ale karma wraca z prędkością światła. Wszelkie luźne myśli też mile widziane albo cokolwiek innego, co Twoje paluszki chcą właśnie wystukać na klawiaturze.

Gotowy przepis na Twój EventStorming

Wszyscy na miejscu? Narzędzia gotowe? No to zaczynamy! Zebraliśmy się tutaj… no właśnie. EventStorming musi mieć określony cel. Mówi o tym też wspomniany Mariusz Gil w rozmowie z Maćkiem Aniserowiczem.

Cele zazwyczaj są podobne i obracają się wokół usprawnienia aktualnych procesów. Na mój kolejny warsztat mamy kilka celów:

• Zamodelować aktualne procesy kursu CodersCamp. Nazwać problemy, jakie się przy nich pojawiają i z czym są związane.
• Określić jakie szanse / wartości możemy uzyskać, wprowadzając zmiany.
• Znaleźć miejsca, gdzie może pomóc automatyzacja.

Kiedy już je osiągniemy, na kolejnych sesjach, będziemy projektować, jak byśmy chcieli, żeby te procesy wyglądały i gdzie zastosować programowanie 😀. No albo uznamy, że wszystko jest w porządku i żadna aplikacja ani cokolwiek nie jest potrzebne (tak ES też może zadziałać).

Aby jak najbardziej zwiększyć prawdopodobieństwo powodzenia, zaprosiliśmy osoby wymienione poniżej.

• Project Managera obecnej i poprzedniej edycji kursu. To główny organizator. Osoba, która będzie miała najszersze spojrzenie, ale może nie wiedzieć, co działo się na „backendzie” każdego z zespołów działających przy organizacji.
• Dwóch uczestników kursu. To właśnie dla tych osób chcemy robić coś przydatnego i dostarczać wartość. W Twoim przypadku może to być np. użytkownik aplikacji czy pracownik przedsiębiorstwa albo przedstawiciele poszczególnych działów.
• Dwóch mentorów z kursu. To osoby przekazujące za darmo swoją wiedzę podczas kursu. Warto zadbać też o sprawne procesy dla nich.
• Dwóch developerów odpowiedzialnych za wykonanie aplikacji wspomagającej i automatyzującej procesy kursu.

Wcześniejsze warunki spełnione? Wszyscy stoją już w pokoju? Świetnie! W takim razie rozpoczynamy warsztat. EventStorming BigPicture (tak się nazywa część, którą opisuję w tym mailu) składa się z kilku faz. Zatytułowałem je wg. angielskich nazw, jakich Brandolini używa w swojej książce. W kwadratowych nawiasach znajdziesz, ile czasu przeznaczam na każdą z części. To bardzo ważne, aby go pilnować. Jeśli dyskusja trwa za długo, umieszczasz HotSpot (czym to jest wyjaśnię zaraz) na modelu, do którego wrócisz później. Jeśli nie przeprowadzisz warsztatu do końca, to później może już nie nastąpić, bo uczestnicy nie będą mieć ochoty na kolejny, nie widząc efektów.

Ten plan powstał na bazie jego książki i moich własnych doświadczeń. Właśnie tutaj stosuje się analogię do przygotowywania pizzy. Alberto mówi, że Event Storming jest jak pizza. On dał tylko podstawę, a my dodajemy swoje składniki. Notacja i forma nie jest sztywna. Możesz ją dostosowywać pod konkretne potrzeby, a nawet tworzyć na bieżąco w trakcie sesji! Sam podczas prowadzenia takich sesji, mam zawsze przy sobie ściągę w postaci nagłówków poniższych sekcji i czasu, żeby wiedzieć czy damy radę się ze wszystkim wyrobić.

• [10-30 minut] Kick-off
  • Na sam początek wyjaśnij jaki jest cel EventStormingu i co to jest zdarzenie. Zadbaj o to, żeby wykorzystywana notacja, była opisana w widocznym miejscu podczas całego warsztatu, ułatwi to pracę uczestnikom. Przykładową legendę znajdziesz znowu na moim MIRO z przeprowadzanego szkolenia. Z jednym zastrzeżeniem: Do zdarzeń zostały już też dopisane atrybuty. Będą one dodawane dopiero podczas EventModelingu. Teraz raczej się nimi nie zajmujemy 😀 Jeśli wolisz Figma.com, to korzystając z mojego autorskiego SZABLONU, też wszystko będziesz mieć pod ręką. Uczestnicy mają się czuć komfortowo. Oni są zaproszeni jako Twoi goście. Zadbaj o coś do jedzenia (np. pizzę), przekąski, napoje itd. To ma być też dobra zabawa, która wytęża szare komórki uczestników. W nich leży rozwiązanie wszystkiego, jak mówił Herkules Poirot w książkach Agaty Christie. Każdy z uczestników opowiada też coś o sobie, jeśli się nie znamy 😀. Opcjonalnie przeprowadzam modelowanie właśnie Kopciuszka, na rozruszanie, przełamanie lodów i zapoznanie z metodą. Tutaj dyskusje są często zaciekłe — ile uczestników, tyle wersji wydarzeń czy zdarzeń (serio!), więc dbajcie o czas ⏱️!
• [20 minut] Chaotic Exploration
  • Pierwsze około 10 minut uczestnicy wypisują zdarzenia sami. Definicja zdarzenia nie musi być dokładnie określona. Dzięki temu eksperci domenowi nie będą czuli się wrzuceni w jakieś ramy i może wyjść coś, czego nikt się nie spodziewał. A dokładnie o to chodzi na Stormingu! Na tym etapie nie musimy filtrować zdarzeń. Posłuchaj Mariusza o ich różnych poziomach w filmiku EVENTSTORMING i 4 poziomy zdarzeń. Game changerem może być też skupienie się na wydarzeniach „z życia” potencjalnych klientów — zakwalifikowałbym je jako “zdarzenie środowiskowe”. Wtedy wiesz, jaki jest kontekst, w którym będą używać produktu i może warto się skupić na czymś z tym związanym? Ten przypadek opisuje Tomasz Stolarczyk na blogu DevStyle. Pod koniec tej fazy zachęcam, żeby już podglądać, co piszą inni, konsultować się razem i próbować sortować zdarzenia na wspólnej przestrzeni.
• [30 minut] Enforcing the timeline
  • Sortowanie wszystkich karteczek wg. osi czasu. Na temat samego sortowania mógłbym chyba napisać kilka maili 😀. Robimy to wszyscy razem, na głos. To też czas, kiedy powinny pojawić się wątpliwości / pytania i pierwsze HotSpoty. Nie bój się tych czerwonych karteczek. Powinno się od nich zaroić! HotSpotem będzie wszystko, co jest niejasne albo na co można ponarzekać. Nikogo tutaj nie ograniczaj. Możesz też sam je wyłapywać, kiedy ktoś głośno westchnie przy jakiś zdarzeniu 😀. EventStorming to prawdziwy dynamizm w praktyce! Polecam książkę Alberto, która dużo Ci wyjaśni. Jest bardzo pomocna jako przygotowanie do pierwszej sesji. Potem już sam dobierasz składniki do pizzy 😀. Jeśli w trakcie pojawią się jakieś rozbieżności w rozumieniu konkretnych słów i terminów, to warto na tablicy dodawać też ich definicje. Pracowałem kiedyś w domenie, gdzie wszystkim myliło się ciągle, czym jest paczka, a czym przesyłka 😂. Side effectem EventStormingu będzie słownik pojęć używanych w domenie, tzw. Język Wszechobecny. Te terminy powinny pojawić się w późniejszej implementacji.
• [20 minut] People and Systems
  • Zdarzenia nie pojawiają się znikąd. Wszystko na świecie ma swoją przyczynę. Kto je powoduje? Zdarzenie „Złożono zamówienie” może robić Klient. Jednak za „Wystawiono fakturę” odpowiada już „Pani Krysia z Księgowości”. Modelujesz to tak, jak zastałeś 😀. Może panią Krysię docelowo zastąpi integracja z systemem faktur, ale na teraz musi sobie dać radę sama. Ludzie, to karteczki żółte z narysowanym symbolem człowieka i podpisem (CEO / Pani Krysia / Użytkownik / Administrator). Systemy zewnętrzne umieszczamy na karteczkach różowych. Są to np. Przelewy24 / GitHub / Slack itd. Systemem może być też Ministerstwo Zdrowia (czy cokolwiek innego co ma na wpływ na działanie naszych procesów), które jest źródłem „Ogłoszono nowe obostrzenia”, co z kolei powoduje zdarzenie „Zmniejszono limit miejsc na sali”.
• [20 minut] BREAK
  • Dajcie ludziom odpocząć. Spojrzeć na model z innej perspektywy. Najlepiej, jeśli ES odbywa się na żywo. Właśnie w tym momencie dostawca powinien zadzwonić dzwonkiem i przynieść zamówioną wcześniej pizzę 🍕. Uczestnicy będę chodzić wzdłuż modelu rozciągniętego po całym pomieszczeniu i możliwe, że coś się jeszcze pojawi, będą spontaniczne dyskusje. ES powinien wyzwolić emocje! Ciężko to zrobić online, ale warto też próbować 😀. Zrób obiad przy kamerkach i przeznacz ten czas luźne rozmowy. Rekomenduję uczestnikom, że jeśli mają dwa ekrany, na jednym warto mieć model.
• [20 minut] Explicit Walk-through and Reverse Narrative
  • Patrzymy, co zmieniło się od ostatniego razu. Teraz przechodzimy przez wszystko chronologicznie. Jest to sposób walidacji powstałego modelu. Kolejne osoby przyjmują rolę narratora na pewną część systemu i próbują opowiedzieć historię na podstawie zdarzeń. Jeśli coś się nie skleja albo nie został zachowany ciąg przyczynowo-skutkowy, to prawdopodobnie zostanie wyłapane. Dobrym sposobem jest też opowiedzenie historii od końca, wtedy zobaczysz czy nie brakuje np. zdarzenia, które powoduje coś, o czym aktualnie mówisz.
• [30 minut] Money & Explore Values
  • Jak nie wiadomo, o co chodzi, to… chodzi o pieniądze ;) ? Teraz przyklejamy małe karteczki z potencjalnymi wartościami. Dokładnie to, co opisałem w drugiej części poprzedniego zadania z modelowaniem Kopciuszka. Nie udało Ci się jeszcze go zrobić? I tak wciąż cierpliwie czekam na Twoje maile 😀. Zadań nie musisz realizować w kolejności wysyłania, ale możliwe, że będę się odnosił do poprzednich tak jak teraz. Wartością są nie tylko pieniądze, ale może to być też czas / zadowolenie. Stratą jest oczywiście upływ gotówki, ale też nieprzespana nos, stres, niezadowolenie klienta. Wzrost wartości oznacz zieloną karteczką, a utratę wartości-fioletową.
• [20 minut] Problems and Opportunities
  • Patrzymy na oznaczone wcześniej HotSpoty i wartości. W pokoju mamy przecież też developerów, którzy mają nie tylko programować — ale dać nam rozwiązania! To czas, żeby każdy wyraził opinię i pomysły co można zrobić z aktualnym procesem. Np. HotSpotem może być wolne działanie wyszukiwania w aktualnej aplikacji. Wtedy od programistów od razu może pojawić się propozycja na ulepszenie przy pomocy ElasticSearch.
• [10 minut] Pick the right problem & Voting
  • Każdy otrzymuje kilka małych karteczek (zależnie od wielkości modelu i liczby uczestników), np. 4. Za ich pomocą głosujemy, czym należy zająć się w pierwszej kolejności.
• [10 minut] Wrapping up
  • Przy HotSpotach zapisujemy Action Pointy (ja używam tej notacji — to mój dodatek do pizzy), gdzie na żółtych karteczkach piszemy np.: “Bartek porozmawia z Kasią z działu prawnego, aby to doprecyzować”. Mamy też wybrany pierwszy proces do ulepszenia. Nim zajmiemy się na EventModelingu. Gratulacje! Jest też duża nadzieja, że wszyscy wyjdą z lepszym zrozumieniem aktualnych procesów. Wiele osób dowie się co, inni właściwie robią albo nawet lepiej zrozumie sens swojej pracy, szczególnie na tle całej organizacji. Pojawią się też praktyczne pomysły na polepszenie działania procesów już dzisiaj!

Dlaczego tak ważne jest modelowanie za pomocą karteczek? Dlaczego nie lepiej od razu siadać do kodu i wykonać Proof of Concept?
Czas programistów jest drogi-zmiana procesu w kodzie pociąga za sobą gigantyczne koszty. A ile kosztuje przeklejenie karteczki z miejsca na miejsce? Czy po prostu pogniecenie i wyrzucenie? Zbieraj te karteczki, które ostatecznie nie znalazły się na modelu. To będzie dobra metryka, żeby zobaczyć jakie złe wyobrażenia rozwiał Event Storming 😀.

ZADANIE PRAKTYCZNE - Pizza do pieca! A Kopciuszek wraca między bajki

Dostałeś już gotową instrukcję i listę składników. Czas pieczenia też jest dobrze znany. Więc na co czekasz? Wrzucaj składniki do pieca i zorganizuj swój pierwszy EventStorming!

Dzisiaj proponuję Ci, żebyś włożył poprzedni ES Kopciuszka STĄD między bajki, albo przynajmniej przesunął go gdzieś na bok na MIRO. Ostatnie ćwiczenie to była tylko zabawa. Chociaż książę zapewne też dysponował górami złota, to czas zacząć stosować EventStorming w prawdziwych problemach, gdzie w grę wchodzą często niewyobrażalne kwoty. Sam zdajesz sobie sprawę, ile teraz pieniędzy jest inwestowanych w branże IT. Poniżej znajdziesz kilka propozycji, w jaki sposób przeprowadzić swój EventStorming. Nawet jeśli nigdy wcześniej tego nie robiłeś-to z pewnością dasz radę! Jesteś też tutaj po to, żeby Ci pomóc. Instrukcja może wydawać się długa, ale trzymanie się jej krok po kroku naprawdę jest bardzo proste. To o wiele łatwiejsze niż postępowanie bez żadnego planu. Niezależnie od tego, który wariant wybierzesz, podziel się ze mną efektami Twojej sesji, a także wszystkimi wątpliwościami i pytaniami, jakie się pojawiają, nawet już teraz 😀.

Wariant #0 - Mariusz Gil (nieprzypadkowo po raz 4 w tym wpisie - policzyłem!), Skrzynkomaty i Domain Explorers

O co w tym wszystkim chodzi, dowiesz się na oficjalnej stronie tej inicjatywy. Wysokiej jakości filmiki i występujący w nich “ekspert domenowy” - jeden w co najmniej trzech osobach wdroży Cię w sposób działania skrzynkomatów. Tym razem Mariusz mnie wyręczy i też przedstawi Ci szczegóły Twojego zadania. Obecnie inicjatywa Mariusza trochę ledwo dycha, niczym Internet Explorer, ale sam autor obiecał, że będzie lepiej. Trzymam za słowo 😀! Nawet jak zdecydujesz się na inny wariant to i tak warto obejrzeć to, co przygotował Mariusz 😀.

Wariant #1 - Twoja domena z zespołem

Zbierz twój aktualny zespół i otwórz swojego Boarda. Jeśli wszyscy nie będą chętni, to najlepiej mieć chociaż jedną dodatkową osobę. A całą resztę odesłać na tego bloga 😀. Możesz też wziąć kogoś spoza zespołu, chętnego do rozwoju i zajaranego tematami DDD. Może to być też osoba nietechniczna. Nie musi Ci pójśc od razu wszystko książkowo. Nawet jeśli nie będziesz w stanie zaangażować ekspertów domenowych, to może znajdziecie HotSpoty, które warto z nimi wyjaśnić? Albo już tyle siedzicie w tym projekcie, że sami jesteście ekspertami 😀? Problemem będzie, jeśli Twoja domena nie jest procesowa. Czyli np. programujesz algorytmy albo CRUD do bazy danych. EventStorming do tego pierwszego się nie nadaje, a do drugiego wiele nie wniesie. Wtedy pozostają Ci inne warianty 😀.

Wariant #2 - Twoja domena / procesy w pracy i nowy kolega w zespole

Bardzo przyjemnym sposobem na EventStorming jest też wdrożenie nowego pracownika. Przychodzi ktoś nowy do zespołu? Spotkajcie się razem przed tablicą i przynieś pomarańczowe karteczki albo odpal MIRO! To ma sens też dla Ciebie, żebyś na nowo przeprowadził proces odkrywania domeny, nad którą pracujesz. Może Ty sam dojdziesz do jakiś nowych odkryć? Ogólnie, ważną zasadą w EventStormingu jest to, że samo pokazywanie wyników poprzednich sesji nie działa dobrze. Sam wynik jest tylko podsumowaniem. Dla osoby, która nie była obecna podczas modelowania, nie będzie znaczył wiele więcej niż tapeta na ścianie. Jednak dla uczestnika warsztatów będzie dobrym streszczeniem i konkretne karteczki będą mu przypominać dyskusje, jakie się działy podczas modelowania. Zamodelować możecie nie tylko domenę, ale np. procesy w trakcie dnia pracy. Flow od zadania na JIRA do deploymentu itd.

Wariant #3 - Używany przez Ciebie system

Możesz przeprowadzić EventStorming np. dla systemu rezerwacji biletów na jakieś wydarzenie albo jakiejkolwiek innej aplikacji, którą używasz 😀. Jednak ciężko, żebyś w tym przypadku miał wiedzę eksperta domenowego.

Niezbędnik każdego “Stormingtroopera”

W tym wpisie zawarłem pigułę niezbędnej wiedzy do przeprowadzenia sesji EventStormingu. Mam nadzieję, że proces zmiany Twojego programistycznego JA czy dążenia do bycia “rzemieślnikiem” zachowującym jakość, postępuje coraz bardziej wraz z kolejnymi artykułami 😀. Chcesz go przyśpieszyć? Lubisz uczyć się z książek? Już dzisiaj proponuję Ci prawdziwy niezbędnik każdego Stormingtroopera! Książka Alberta Brandoliniego to po prostu MUST HAVE, dla przyszłego prowadzącego warsztaty, jeśli nie chcesz być tylko klepaczek kodu, ale prawdziwym partnerem biznesowym! Możesz ją kupić TUTAJ. Nie patrz na to, że jest dokończona tylko w 70%. To nie ma znaczenia 😀. EventStorming ma tyle różnych składników, że ciężko byłoby postawić ostatnią kropkę. Alberto już otwarcie mówi, że nie można go pytać, kiedy to nastąpi. Przeczytałem ją w tej formie i naprawdę BYŁO WARTO!. Z samej treści ciężko się domyślić, że może w niej czegoś brakować (bardziej wymaga trochę refaktoringu i posprzątania).

Jak zawsze, jestem po drugiej stronie monitora i czekam na efekty Twoich sesji! A może już masz pierwsze doświadczenia za sobą i podobny schemat na warsztat, którym mógłbyś się podzielić? Z chęcią wymienię się spostrzeżeniami w komentarzach! Życz mi dokładnego poznania domeny na nadchodzącym EventStormingu!

PS. Nie możesz znaleźć nikogo chętnego na modelowanie razem? To dodaj komentarz do tego artykułu z kontaktem do Ciebie. Może uda się kogoś znaleźć do wspólnego “stormowania” 😀.

🤔 Nie masz pomysłu na przykładową domenę? Co powiesz na Heroes III? ZOBACZ JAK TO ROBIĘ TUTAJ.