Przewodnik po prowadzeniu sesji szturmowania zdarzeń

Rozwijanie wszechstronnego zrozumienia systemów biznesowych to ciężka praca. Zwykle wiąże się to z modelowaniem wysokiego poziomu lub mapowaniem złożonych procesów. Może to być bardzo techniczny i pracochłonny proces, który wymaga wielu prób i błędów. Tworzenie diagramów BPMN lub schematów UML może być bardzo przydatne w zrozumieniu szerszego funkcjonowania firmy, ale mają one zasadniczo charakter techniczny i mogą wykluczać ekspertów z dziedziny nietechnicznej.

Projektowanie oparte na domenie

Domain-Driven Design to metodologia, która ustanawia niezależny od technologii język, który pozwala na szczegółowe zrozumienie potrzeb i procesów biznesowych. Pozwala to zainteresowanym stronom na przekazywanie swojej wiedzy dziedzinowej reszcie zespołu w sposób niezależny od języka, aby rozwinąć wspólne rozumienie systemów.

Co to jest burza zdarzeń?

Event Storming to oparte na warsztatach podejście do Domain Driven Design, które łączy technicznych i nietechnicznych interesariuszy w celu eksploracji złożonych dziedzin biznesowych. Koncentruje się na zdarzeniach domeny, które są generowane w kontekście procesu biznesowego lub aplikacji biznesowej. Zwykle obejmuje właścicieli produktów, ekspertów domenowych i programistów.

Metoda burzy zdarzeń została wprowadzona i opublikowana przez Alberto Brandoliniego w Introducing EventStorming. Jest używany jako technika do szybkiego przechwytywania projektu rozwiązania i lepszego zrozumienia projektu przez zespół.

Event Storming jest formą uczenia się grupowego i jest świetnym sposobem na zintegrowanie zespołów programistycznych i produktowych w celu wspólnego tworzenia alternatywnych rozwiązań. Burza zdarzeń może być również przydatna dla zespołów z dojrzałymi produktami, aby uporządkować proces i dowiedzieć się o wąskich gardłach i obszarach konfliktów.

Sesja burzy zdarzeń jest zwykle prowadzona w celu:

• Stwórz model biznesowy rozwoju projektu.
• Uzyskaj świadomość „dużego obrazu” modelu produktu w całej jego złożoności, podkreślając jego cele i potrzeby.
• Wizualizuj model produktu i przeprowadź burzę mózgów na alternatywne rozwiązania.
• Znajdź wąskie gardła i obszary konfliktu w dojrzałych produktach.

Korzyści z burzenia zdarzeń

Podczas budowania produktu ważne jest, aby zespół programistów był dobrze zorientowany w dziedzinie biznesowej, w której działa produkt. Pozwala to na jaśniejszą wstępną analizę i bardziej skoncentrowany build. Warsztaty, takie jak sesja burzy wydarzeń, mogą wzmocnić ogólną współpracę między zespołami biznesowymi i produktowymi.

Szybko: Większość innych technik modelowania procesów biznesowych to dogłębne, głębokie zanurzenie w działania firmy. Obejmują one stosowanie złożonych modeli danych i przedstawienie dokładnego obrazu może zająć tygodnie. Burza zdarzeń to szybkie podejście do modelowania projektowania opartego na domenie. Burza zdarzeń to zwykle jednodniowe wydarzenie, w którym cały proces biznesowy można zmapować w ciągu kilku godzin.

Wspólne zrozumienie między technicznymi i nietechnicznymi interesariuszami : W przeciwieństwie do UML, burza zdarzeń tworzy reprezentację procesu biznesowego, którą można łatwo zrozumieć bez wcześniejszej wiedzy technicznej.

Współpraca: Podstawową koncepcją burzy zdarzeń jest zachęcanie do uczestnictwa i interakcji między ekspertami dziedzinowymi. Tworzy angażujące środowisko do tworzenia modeli biznesowych i skutkuje odkrywaniem bardziej wartościowych spostrzeżeń.

Skuteczność: Największą zaletą szturmu na wydarzenia są rozmowy, które się rozpoczyna. Zespoły mogą wykorzystać wiedzę zdobytą podczas warsztatów do informowania o przyszłych procesach modelowania i tworzenia produktów lub po prostu użyć burzy zdarzeń, aby lepiej zrozumieć procesy biznesowe i podejmować lepsze decyzje w przyszłości.

Prowadzenie burzy zdarzeń

Aby przeprowadzić burzę zdarzeń, musisz zebrać razem różnych interesariuszy z konkretną wiedzą w dziedzinie domeny. Można to zrobić w miejscu fizycznym lub wirtualnie za pomocą narzędzia do współpracy, takiego jak Creately. Pozwala na zdalne przeprowadzenie całej sesji na jednym, nieskończonym płótnie i może służyć jako wspólna przestrzeń, w której interesariusze mogą wymieniać myśli i pomysły w czasie rzeczywistym.

Krok 1: Zdarzenia domeny

Pierwszym krokiem jest identyfikacja zdarzeń domeny. Są to oparte na faktach stwierdzenia dotyczące tego, co wydarzyło się w systemie biznesowym. Uczestnicy przeprowadzają burzę mózgów i spisują wszystkie rzeczy, które wydarzyły się w systemie, które wywołały ważne reakcje. Następnie spisują te wydarzenia jako kolorowe notatki na wirtualnym płótnie. Ważne jest, aby sformułować te stwierdzenia w czasie przeszłym, aby uczestnicy mogli sformułować to jako stwierdzenie „co się stało”. Gdy uczestnicy dodają wydarzenia do płótna, możesz zacząć je porządkować według ram czasowych, w których miały miejsce.

Krok 2 – Polecenia

Następnym krokiem jest określenie przyczyny zdarzenia. Na tym etapie zespół analizuje, co wywołało zdarzenia. Podczas gdy wydarzenia są faktycznymi stwierdzeniami o przeszłości, polecenia wyrażają naszą intencję, aby coś się wydarzyło w przyszłości. Polecenia są zwykle wymienione na niebieskich nutach. Podczas gdy zdarzenia są rejestrowane jako zdania czasu przeszłego, polecenia są wymienione jako intencje czasu teraźniejszego. Polecenia mogą być dokumentowane jako działania zarówno użytkownika, jak i systemu.

Krok 3 – kruszywa

Są to rzeczy, które dzieją się w systemie, które zazwyczaj mają miejsce w grupie zdarzeń. Są to podmioty gospodarcze wyższego rzędu, które powinny być przedstawiane jako rzeczowniki.

Na przykład „Proces zamówienia”. Agregat to zazwyczaj zbiór notatek na płótnie.

Jest reprezentowany przez klaster zdarzeń z odpowiednimi poleceniami i odpowiedzialnym aktorem. Ten agregat można następnie nazwać i umieścić na większej, skoordynowanej kolorystycznie notatce na płótnie.

Krok 4 – Ograniczone konteksty

Jest to struktura wysokiego poziomu, która składa się z kategoryzacji funkcji, które grupują powiązane ze sobą jednostki. Zespół zaczyna grupować moduły w elemencie zwanym kontekstami ograniczonymi, rysując ramkę lub kółko wokół powiązanych modułów. Następnie można rozpocząć mapowanie kontekstu od zilustrowania interakcji modułów w ograniczonym kontekście z innymi kontekstami. Mówiąc najprościej, wszystkie powiązane zdarzenia wpadają w ten sam ograniczony kontekst. Na przykład wszystkie zdarzenia związane z koszykami na zakupy zostaną umieszczone w kontekście ograniczonym do koszyka.

Wskazówki dotyczące prowadzenia sesji szturmowania zdarzeń

• Uczestnicy: Kluczowym aspektem udanej burzy eventowej jest zorganizowanie odpowiednich ludzi. Uczestnicy powinni składać się z kluczowych interesariuszy posiadających wiedzę specjalistyczną w wielu dziedzinach. Skuteczna burza wydarzeń zwykle obejmuje niewielką grupę interesariuszy, aby zapewnić swobodną rozmowę i środowisko współpracy.
• Zaplanuj sesje: Ustal cele i intencje sesji. Pozwala to bardziej skoncentrować się na tym, co powinno być zaangażowane w sesję, a jakie aspekty należy pominąć.
• Wyślij instrukcje z wyprzedzeniem: Pozwól uczestnikom zrozumieć, o co chodzi w ćwiczeniu i czego się od nich oczekuje. Wysyłaj instrukcje dotyczące tego, czym jest klucz i co oznaczają różnokolorowe notatki, aby uczestnicy mieli jasne zrozumienie podczas prowadzenia sesji
• Prowadź dyskusje w języku nietechnicznym : Upewnij się, że rozmowy nie ugrzęzły w szczegółach implementacji. Rozmowy te powinny mieć bardziej konceptualny charakter, aby każdy mógł w nich uczestniczyć, niezależnie od zaplecza technicznego.
• Podaj przykłady : pomocne jest zaprezentowanie ukończonego płótna szturmowego wydarzenia, aby uczestnicy wiedzieli, nad czym muszą popracować.

Masz doświadczenie w prowadzeniu sesji Event Storming? Opowiedz nam o tym.

Czy brałeś udział lub prowadziłeś wcześniej sesję szturmu na wydarzenia, chcielibyśmy usłyszeć o twoich doświadczeniach i niektórych naukach, z którymi wyszedłeś. Daj nam znać swoje przemyślenia w sekcji komentarzy.