Dlaczego powinieneś spróbować Event Stormingu w swojej firmie?

Głównie Event Stormingu używa się w przypadku IT, gdzie tworzy się oprogramowanie. Dzięki temu wspomaga się odkrywanie i konkretyzowanie informacji dla wielu domen biznesowych. Chodzi o płaszczyzny, na których spotykają się eksperci z zakresu programowania oraz eksperci techniczni – niekoniecznie powiązani ze sobą. W końcu ktoś, kto zna się na handlu, niekoniecznie będzie orientował się w potrzebach, jakie niesie za sobą Medycyna. Event Storming sprawia, że jedni i drudzy mogą się spotkać i wzajemnie zrozumieć własne potrzeby oraz wyzwania, jakie przed nimi stoją.

Co musisz wiedzieć o Event Stormingu?

Do przeprowadzenia Event Stormingu będzie Ci potrzebna duża ściana lub tablica i mnóstwo różnokolorowych karteczek – najlepiej samoprzylepnych, żeby łatwiej było je wykorzystać i oczywiście mazak, którym będziecie po karteczkach pisać. Nie dysponujecie dużą wolną powierzchnią na ścianie? To jeszcze nic straconego. Jeśli zależy Ci na Event Stormingu, możesz przeprowadzić go również w Internecie na takich stronach jak Stormboard.com. Choć klasycznie zaleca się, by wszyscy stali skupieni wokół wspomnianej tablicy lub ściany.

Event Storming stosuje się głównie podczas tworzenia oprogramowania. W ten sposób łatwiej prześledzić procesy zachodzące podczas korzystania z gotowego oprogramowania, a programiści mogą zrozumieć potrzeby osób, które zajmują się stroną biznesową, nie samym programowaniem. Oczywiście Event Storming można przełożyć na inne dziedziny, nic nie stoi na przeszkodzie!

Na wspomnianych karteczkach zapisuje się kolejne zdarzenia, czyli Domin Events. Zdarzenia zapisuje się w formie przeszłej, na przykład: „Klient złożył zamówienie” lub „Klient wybrał formę płatności”. Wspomniany już Klient jest tak zwanym aktorem, czyli kimś, kto wywołuje dane zdarzenie lub komendę (w przypadku oprogramowania). To ważne, by pamiętać, że wszystkie zdarzenia, komendy i tak dalej, zapisywać prostym językiem, który zrozumieją wszyscy uczestnicy warsztatu.

Do wywoływania zdarzeń potrzebni są nam tak zwani Aktorzy. To oni sprawiają, że wspomniane zamówienie zostało złożone, a później opłacone, a więc wprawiają w ruch cały proces i inicjują kolejne wydarzenia.

Ostatecznie kolejne zadania i aktorzy nierzadko się ze sobą łączą. Przykładowo zamówienie nie mogłoby zostać złożone, gdyby nie pojawił się Klient. Dlatego też połączone ze sobą elementy na naszej tablicy łączymy w Agregaty.

Kto zwykle uczestniczy w Event Stormingu?

• Programiści,
• Osoby odpowiedzialne za obsługę Klienta,
• Osoba czuwająca nad poprawnym przebiegiem Event Stormingu

Po co to wszystko?

Event Storming może się wydawać kolejnym narzędziem, jakich wiele i na pierwszy rzut oka zrozumienie jego fenomenu nie musi być takie łatwe. Dlaczego coraz częściej i coraz chętniej się z tego korzysta? Co ma w sobie ES, czego nie mają inne metody i rozwiązania?

Przede wszystkim podczas Event Stormingu spotykają się zarówno osoby, które aplikację tworzą, jak i osoby, które odpowiadają za jej późniejsze wykorzystanie w praktyce, zajmujące się obsługą Klienta i tak dalej. Dzięki temu znacznie łatwiejsze jest zrozumienie potrzeb i problemów wszystkich grup, które mają do czynienia z aplikacją lub produktem końcowym oraz na poziomie ich tworzenia lub wdrażania w życie.

Ponadto dzięki Event Stormingowi możesz w krótkim czasie przewidzieć potrzeby i konkretne działania powstające na drodze działania aplikacji. W ten sposób ogranicza się czas na późniejsze poprawki i dodawanie kolejnych kroków, których potrzeba wprowadzenia być może ujawniła się dopiero na etapie testów.

Przebieg realizacji zamówienia

Zaczynamy od chronologicznego procesu przebiegu składania zamówienia przez Klienta (Aktora, który wywołuje kolejne zdarzenia). Początkowo są to tylko zdarzenia (żółte karteczki), które krok po kroku po sobie następują tak, jak widzimy to z poziomu użytkownika – w tym wypadku Klienta składającego na stronie zamówienie.

Jak widać, składa się na to ciąg logicznych czynności. Klient wchodzi na stronę, wybiera interesujący go produkt (lub produkty), składa zamówienie, decyduje się, jak chce je odebrać i w jaki sposób za nie zapłacić, a na koniec finalizuje transakcję i płaci za to, co wcześniej umieścił w koszyku. Podczas Event Stormingu musimy się jednak zastanowić, co musi się stać, żeby Klient mógł wykonać te wszystkie kroki. Do zdarzenia (żółta karteczka) dodajemy więc kolejne karteczki z dodatkowymi informacjami. W tym przypadku odpowiadają na pytanie: „co dzieje się, gdy Klient wykonuje daną czynność?” (różowe karteczki). Następnie pojawia się komenda (niebieska karteczka), za której działanie w późniejszym etapie odpowiadać będą programiści.

Niektóre zdarzenia wymagają większej ilości komend i uwagi, ponieważ pozornie proste zdarzenie pociąga za sobą wiele różnorakich czynności. Dobrym przykładem mogą tu być możliwości dostawy. Nie tylko należy pokazać Klientowi i umożliwić wybranie różnych możliwości dostawy, ale po wybraniu konkretnego sposobu system musi doliczyć również odpowiednią kwotę za dostawę do całości zamówienia.

Kiedy już konkretne czynności udało się nam szerzej rozpisać. To jest dojść do tego, co powoduje lub współdziała na konkretne czynności i jakie komendy powinny zaistnieć, by konkretne zdarzenia miały miejsce, możemy zacząć patrzeć na całość procesu w postaci niechronologicznej, ale jak na konkretne agregaty, to jest grupy zdarzeń, które koncentrują się wokół jednego czynniku. Skupmy się tu na generowaniu etykiety oraz paragonu:

Wybór przez Klienta sposobu płatności oraz dostawy, a ostatecznie płatność za całe zamówienie wpływa na generowanie etykiety adresowej oraz paragonu i faktury. W czasie pracy przy Event Stormingu pojawiło się kolejne zdarzenie, ponieważ realizacja nie kończy się na zapłaceniu przez Klienta za usługę lub towar, ale w momencie, w którym otrzyma on je do rąk. Pojawia się więc czynność „zamówienie przyjęto w sklepie”.

Pracownik magazynu, kolejny Aktor, musi mieć jasne wytyczne odnośnie do tego, jak dalej powinno wszystko się dziać. System musi ściągnąć ze stanu sklepu konkretny produkt i pokazać pracownikowi, który produkt ma dostarczyć do pakowania. Podczas pakowania oczywiście potrzebne są paragon/faktura i etykieta adresowa, dalej kolejnym działaniem jest współpraca z dostawcą, aż wreszcie Klient odbiera swoje zamówienie.

Event Storming pomógł nam więc określić obecność kolejnego aktora i wykonywanych przez niego czynności (na screenie poruszamy akurat pracownika magazynowego, którego dalszą rolą byłoby przygotowanie zamówienia do wysyłki, to jest pakowanie go, oklejenie etykietą i przekazanie kurierowi lub Klientowi, jeśli zdecydował się na odebranie towaru osobiście).

Jak pomaga Event Storming?

Dzięki temu, że przeprowadza się Event Storming można nie tylko w łatwiejszy sposób zbadać potrzeby zarówno programistów, jak i osób zajmujących się tym, co programiści stworzą. Można też sprawnie prześledzić, czego zabrakło nam podczas początkowego planowania. Jakie istotne zdarzenia nam umknęły, a jakie można uprościć, zautomatyzować lub pominąć? Jedna kilkugodzinna sesja to mimo wszystko znaczna oszczędność czasu. Dzięki temu nie trzeba bowiem poświęcać czasu na późniejsze poprawianie pierwowzorów aplikacji czy programów, gdy pierwsze problemy „wyjdą w praniu”. Event Storming pomaga bowiem spotkać się na jednej płaszczyźnie zarówno programistom, jak i osobom obsługującym później skończony produkt oraz na wzajemne zrozumienie siebie i swoich potrzeb – dzięki temu jedna i druga strona rozumie, jak wszystko działa, jakie działania trzeba podjąć i jakie funkcjonalności są potrzebne.