Tym razem warsztaty organizowane przez „Stowarzyszenie Inżynierii Wymagań”  lokalizacja Katowice, tytuł „Event Storming między biznesem a zespołem” .

Meetup Katowice

Warsztaty prowadził Paweł Skiścim

Głównym tematem, oprócz kilku słów wstępu do idei ES-gu, było zamodelowanie sklepu spożywczego. Na pierwszy rzut oka temat błachy i nudny, pozory jednak  mylą. Każdy z nas był kiedyś w takim sklepie (większość) i dokonywał zakupów więc ma pewne pojęcie jak funkcjonuje taki sklep i jakie zdarzenia tam zachodzą. Temat ten świetnie wpasował się w te warsztaty, dzięki niemu spotkanie nabrało dynamizmu, a ludzie chętnie się udzielali.

Przekrój osób obecnych na warsztatach był dosyć spory mieliśmy analityków, programistów, architektów, ludzi nie związanych z branżą (murarz, tynkarz,tapeciarz). Tak duży rozjazd okazał się zbawienny w skutkach gdyż bardzo szybko ludzie się zintegrowali w celu za modelowania tego problemu (sklepu spożywczego).

Do dzieła

Praca na ścianie.

Warsztaty oprócz ścian miały stół i to właśnie stół był takim pierwszym krokiem przy którym wszyscy wspólnie obradowaliśmy i rzucaliśmy kolejne zdarzenia. Na stole był papier karteczki, oczywiście przeważają pomarańczowe oraz mazaki.

Główno dowodzący pełni rolę facilitatora (wodzireja DDD i ES-gu).

Pierwszym krokiem było wrzucenie zdarzeń na stół (ścianę), kolejność nie gra roli, czy się powtarzają to też nie ma znaczenia, ważne, że są to zdarzenia biznesowe typu zakupiono towar, dostarczono towar z magazynu (czas przeszły tryb dokonany  jest istotną częścią ES) itp.

Pierwszy etap zakończył się dosyć szybko, to akurat nic nie zwykłego, gdyż pierwszy etap nie powinien trwać zbyt długo.  Powinien nawet mieć ustalony limit czasu. Pierwsza część to chaos zdarzeń, to takie pierwsze podejście do zapoznania się z systemem i ludźmi obok. W tym etapie nie ma znaczenia że coś się powtarza, kolejność nie gra roli, pomysły są różne nic nie usuwamy.

Etap drugi to poukładanie zdarzeń w czasie, pogrupowanie ich w pewne zbiory (konteksty). W tym etapie  można było zweryfikować sens zdarzeń gdyż wybrane osoby na głos czytały treść zapisaną na karteczkach, a reszta grupy mogła wyrazić opinię na temat konkretnego zdarzenia i ułożyć go w czasie. Powtarzające karteczki się nie wyrzuca kładzie się jedna na drugą ale chybione zdarzenia się usuwa. Do tego etapu doszły karteczki z pytaniami (czerwony kopnięty kwadrat), pytania tudzież zagwózdki, nad którymi pochylimy się później.

Etap trzeci, ten etap dla większości był pracą wspólną, ja należałem do dwuosobowej grupy, która uznała, że oddzieli się od stada i na własną rękę będzie rozwijać jeden ze zbiorów, który zaznaczył się w poprzednim etapie. Wybraliśmy tak błachy temat  jak „weryfikacja wieku kupującego”. W tym etapie doszły kolejne karteczki aktorzy (żółta karta), policy (polityka łosoś), read model ( zielona), command (niebieska) i system zewnętrzny(kolor którego nie znam).

  • aktorzy – postacie w systemie, które inicjują zdarzenia ale nie muszą
  • read model (view model) zestaw danych jaki otrzymujemy w tej części pod systemu (danym kontekście)
  • policy (polityki) – warunki jakie mogą się w systemie pojawić ze względu na aktorów i w naszym przypadku restrykcje związane z wiekiem i sprzedażą np alkoholu, polityki to też nic innego jak BDD (given when then) z czego z when otrzymujemy commendy
  • commedy – to również zdarzenia ale już nie w czasie przeszłym te zdarzenia są bardziej konkretne i odnoszą się już do kodu  i wykonania tam pewnej czynności
  • system zewnętrzny – informacje otrzymywane z systemu zewnętrznego lub zlecamy wykonanie pewnych czynności do systemu zewnętrznego.

View model -> Event -> Policy (BDD) -> Command

Nasz dwuosobowy drim tim od czasu do czasu powiększał się o kolejną osobę, która wnosiła jakiś nowy pomysł do naszego rozwiązania tudzież burzyła nasz „domek z kart”. Zaletą ES-gu jest właśnie to, że tak wiele koncepcji można przejrzeć w tak krótkim czasie i tak niskim nakładem finansowym (karteczki, mazaki, ściana) bez napisania linii kodu.

Minusem naszej pracy na osobnej ścianie było nie branie udziału w kolejnym etapie jakim była analiza wsteczna czyli przejście całego procesu od końca do początku. Ten etap może pokazać nam tę właściwą ścieżkę i odseparować ją od reszty mniej właściwych.

Zakończenie

Za względu na ramy czasowe nie został przeprowadzony pełny event storming (wyznaczenie agregatów, bounded  context) ale w tych warsztatach te kroki nie były ważne przynajmniej z mojej perspektywy i wydaje mi się, że te ćwiczenie miało na celu przybliżenie nam podstawowych kroków tej jakże ciekawej metodologi.

Czego mi brakowało? czasu, spędzilibyśmy tam jeszcze kilka dni albo miesięcy ale kto by z nami wytrzymał. Atmosfera była bardzo miła, prowadzący chętnie odpowiadał na pytania, sugerował lub wprost podpowiadał rozwiązania co akurat w naszym przypadku było bardzo pomocne. Mogę dodać jeszcze od siebie że w końcu zrozumiałem polityki (policy) i ich znaczenie w systemie.

Podsumowanie

Z mojej strony polecam warsztaty prowadzone przez Paweł Skiścim, temat okazał się bardzo ciekawy, część teoretyczna nie była nudna, a część praktyczna prawie doskonała ;-).

P.S. Linki do warsztatów

 

Kategorie: Archiwum