Zrozumienie i znalezienie współczulnego jerzyka z klientem jest odwiecznym problemem. Źle zinterpretowane założenia powodują reperkusje w trakcie projektowania oraz późniejszego wdrażania rozwiązań. Często są przyczyną nie dowiezienia projektu do końca. Tracimy cenne zasoby. Pracownikom spada morale a niektórzy nawet postanawiają odejść – chcąc zapomnieć o kolejnej porażce.
Rozwiązaniem na te wszystkie problemy mogłaby być maszyna czasu. Można by się cofnąć w czasie i zrobić to inaczej ;). Niestety żadna maszyna czasu jeszcze nie powstała – a przynajmniej mi nic o tym nie wiadomo.
Wiec czy jest jakiejś rozwiązanie/narzędzie? Cokolwiek, co choć troszkę odsunie widmo kolejnej porażki. Odpowiedź brzmi jest. A nazywa się Event Storming. Oczywiście nie jest metoda bez wad.
W tym wpisie opiszę pierwszą fazę Event Stormingu zwaną „Modelowaniem”. Sam proces przedstawię na przykładzie z poznanym już w poprzednim wpisanie Panem Grzegorzem w roli głównej. Na koniec wypunktuje co będzie potrzebne do pracy.
Pozostałe wpisy z serii:
- Co poszło nie tak?
- Jak pozyskać wiedzę domenową?
Przykład z wykorzystaniem Event Storming
W poprzednim przykładzie Pan Grzegorz, doświadczył wielu problemów w pracy z klientem. Tym razem zakładam, że Pan Grzegorz zna Event Storming.
Pan Grzegorz spotyka się z klientem. Tłumaczy, że podczas spotkania będą używać różnokolorowych karteczek do notowania. Pan Grzegorz prosi klienta o przyklejenie pomarańczowej karteczki na ścianę i napisanie na niej jakiegoś faktu w procesie planowania jego usług. Klient bierze pomarańczową karteczkę i pisze na niej „Klient zamówił usługę sprzątania” następnie … .
Przy każdym nowym kolorze karteczki zrobię pauzę, omówię co oznacza i jakie ma zastosowanie.
Karteczka Pomarańczowa – Event
Karteczki pomarańczowe są to nasze tytułowe Events (pol. zdarzenia). Pewne fakty
w procesie – w tym przypadku procesie sprzątania – np. „Dodano nowe zlecenie sprzątania”, „Przypisano pracownika do zlecenia”, „Wybrano środki czystości” itd.
W zdarzeniach istotne jest to, by zapisywać je w czasie przeszłym. W trakcie przyklejania staramy się „modelować”, czyli wyznaczać pewne przepływy, oraz bardzo ważne: zadawać dużo mądrych pytań:
- Co powinno się wydarzyć po …
- Dlaczego to jest tutaj …
- Jakie będą konsekwencje po wykonaniu …
- Czy jeśli zajdzie to co jeszcze powinno się wydarzyć …
- Skąd wzięliśmy informacje o …
- Co to robi?
- Co sprawiało?, że wydarzyło się to …
Kontynuujemy zapisywanie Eventów i przyklejanie aż nasz ekspert/eksperci domenowy „wystrzela” się ze wszystkich pomysłów.
W trakcie przyklejania pomarańczowych karteczek – Eventów – wyłaniają się punkty podejmowania decyzji. Pan Grzegorz pyta klienta co jest potrzebne do podjęcia decyzji podczas planowania zlecenia. Klient odpowiada, że jedną z rzeczy jest lista dostępnych pracowników. Pan Grzegorz wyciąga nowe karteczki tym razem zielone
i prosi klienta by napisał na niej „Lista pracowników”. Klient przykleja ją obok zdarzenia „Dodano pracownika do zlecenia”.
Karteczka Zielona – Read Model
W międzyczasie gdy nasze pomarańczowe karteczki wędrują na ścianę, staramy się znaleźć miejsca na przyklejenie zielonych karteczek. Zieloną karteczką możemy np. napisać „Lista pracowników”, „lista detergentów dostępnych na magazynie”. Mogą być to raporty wykonanych zleceń. Email z powiadomieniem w reakcji na zdarzenie. Najczęściej są to niezbędne informacje w formie listy pozwalające na podjęcie pewnej decyzji.
Pan Grzegorz prosi klienta o sprecyzowanie o co dokładnie chodzi z tą powierzchnią sprzątania. Klient odpowiada że jeśli przekracza X to przypisuje dwóch pracowników. Pan Grzegorz bierze fioletową karteczkę i pisze na niej „Jeśli powierzchnia sprzątania jest większa od X to przypisz 2 pracowników”. Następnie pyta klienta co robi jeśli nie ma wystarczającej ilości pracowników do pokrycia zleceń. Klient odpowiada że wysyła informacje do klienta, że nie ma wystarczającej ilości pracowników w danym czasie ale proponuje mu wykonanie zlecenia w innym możliwym terminie. Pan Grzegorz dopisuje na fioletowej karteczce „Jeżeli nie ma dostępnej ilości pracowników to wysyła email
z propozycją nowego terminu”. Dodatkowo Pan Grzegorz dokleja obok zieloną karteczkę z tekstem „Email z propozycją nowego terminu”.
Karteczka Fioletowa – Policy
Fioletowe karteczki oznaczają polityki – polityki to pewne przyjęte zasady które mogą się zmieniać w trakcie cyklu życia aplikacji np.:
- System nie może zaplanować więcej zleceń na dzień niż mamy dostępnych pracowników
- Jeżeli powierzchnia do posprzątania jest większa niż X to przypisz dwóch pracowników
- Klient może wybrać przedział czasowy w jakim usługa ma być wykonana
- jeśli klient zamówił u nas x zleceń to traktuj go jako klienta VIP
Jak nietrudno się domyśleć polityki to będą nasze if-y.
Do tego miejsca szło całkiem sprawnie ale klient zwrócił uwagę na częste problemy
z niedoborem środków czyszczących. Pan Grzegorz wyciąga różową karteczkę pisze na niej problemy z dostępnością środków czystości. Przykleja ja obok listy środków czystości. Będzie trzeba zgłębić ten temat.
Karteczka Różowa/Czerwona – HotSpot
Gorące punkty to takie miejsca gdzie kumulują się Eventy – pomarańczowe karteczki. Bądź mogą wystąpić problemy – nawiązując do przykładu:
- Co jeśli zabraknie pewnego detergentu?
- Kilku klientów zamawia usługę sprzątania w jednym czasie, a my nie dysponujemy większą ilością pracowników, to co w takim razie?
- Jak planować przejazdy pracowników, tak by zaoszczędzić na dojazdach?
- Bądź brak wystarczającej wiedzy do wyjaśnienia pewnej kwestii.
Ogólnie ujmując są to problematyczne kwestie, którym należało by się przyjrzeć
z bliska. Podjąć decyzje w kierunku ich rozwiązania.
Jeszcze nie zaczęliśmy pisać kodu a już rozwiązujemy problemy. Jest to niewątpliwie jedna z najważniejszych zalet Event Stormingu :).
Żółta taśma malarska – Bounded context
Wyznaczanie Bounded Contextów, jedno z trudniejszych zadań podczas etapu modelowania. Musimy tak wydzielać pewne zdarzania, aby tworzyły spójną całość
w danym kontekście. Np. zdarzenia (pomarańczowe karteczki) dotyczące zamawiania zlecenia sprzątania mogą odpowiadać za jeden Bounded context. A te które pasuje do planowania usług za drugi. Wydzielanie robimy przy pomocy żółtej taśmy malarskiej pisząc na niej „Zamawianie usługi sprzątani” lub dla drugiego przypadku „Planowanie wykonania usług”.
Kończąc modelowanie to bardzo ważna część Event Stormingu. Tu dowiadujemy się czego chce klient. Poznajemy jego język. To jak on rozumie pewne specyficzne kwestie swojego biznesu. Na tym etapie klient może już zadecydować od czego zaczniemy
i czy dany feacher znajdzie się na produkcji – WOW.
Czy trzeba trzymać się konwencji?
Nikt nas nie skrzywdzi jeśli będziemy używali innej konwencji. Jednak zalecane jest trzymanie się „standardów”. Jeśli będziemy mieli już więcej sesji Event Stormingu na swoim kącie. To zmiana np. karteczki pomarańczowej na żółtą spowoduje, że będziemy musieli włożyć więcej wysiłku w zrozumienie problemu, nad którym pracujemy.
Zachęcam do eksperymentowanie z nowymi rozwiązaniami. Np. w moim przypadku było to dodanie kontrolek interfejsu użytkownika – w moim obecnym projekcie często wykorzystuje tą technikę do archeologij. Posłużyła mi do tego jasnoniebieska karteczka. Przestałem zastanawiać się, gdzie dany proces ma swój początek. Mogłem się skupić na rzeczach ważnych.
Co będzie potrzebne aby zacząć:
- Na pierwszej sesji robimy tak zwany BigPicture – nie jest to reguła.
- Dobrze mieć eksperta domenowego – często jest niezbędne.
- Potrzebne będą karteczki:
- Pomarańczowe – Event
- Zielone – Read Model
- Fioletowe – Policy
- Czerwone lub różowe – HotSpot
- Żółta taśma malarska – Bounded context
- Coś do pisania – np. czarny pisak, teksy mają być widoczne
- Powierzchnia do przyklejania – warto zaopatrzyć się w tablicę elektrostatyczną
