Po dwóch tygodniach urlopu postanowiłem wrócić do pisania (koniec „byczenia się”). Na pierwszy ogień pójdzie kolejny raz event storming.

Otrzymałem wiadomości, że karteczki na ścianie wciąż się trzymają (w pierwszym tygodniu urlopu), we wtorek się dowiem czy faktycznie jeszcze są na ścianie. We wtorek również się dowiem jak będzie wyglądał proces ustalony przez byznes. Mam nadzieje że będę mógł kontynuować lub zaktualizować „ścianę” bez konieczności zaczynania na nawo.

Po tych dwóch tygodniach zdałem sobie sprawę, że to co stworzyłem na ścianie to nie jest Big Picture ale już Desing Level. Jaka jest różnica? A taka, że Big Picture kierowany jest do wszystkich ponieważ są tam zdarzenia i hot spoty, ścieżki kosztowne i radosne (tudzież bolesne i radosne), są tam zarysowane moduły i procesy, jest pomarańczowo i czerwono (jeżeli istnieją pytania i ścieżki bólu, zielono radości).

Design Level jest przeznaczony bardziej dla programistów i architektów, budujemy aplikacje, za pomocą view modeli, commendów, polityk, agregatów, systemów zewnętrznych. Wyznaczam granice modułów (agregatów), odkrywamy bounded kontekst.  Ściana robi się kolorowa ale te kolory nie koniecznie zrozumiałe są dla ogółu. Ta część event stormingu prowadzi do stworzenia podstaw aplikacji. Ta część skrywa największe tajemnice, które należy odkryć, tu poznasz jak będzie w pełni wyglądał proces, tu również powstanie prawdziwa aplikacja (tak twierdzą). Na podstawie tego etapu nie zbudowałem jeszcze nigdy żadnej aplikacji, dlatego tylko, że w pełni jeszcze nie ogarnołem wszystkich pojęć, wyznaczenie agregatów nie należy do prostych rzeczy, polityki (czyli if-y lub BDD) to też nie jest aż tak trywialne, a przecież to dopiero początek gdzie bounded context? i wiele innych.

Wniosek z pracy na ścianie, a właściwie pytanie, zgromadzenie ludzi chętnych do pracy karteczkami może być trudne, a czasami nie możliwe, czy nie lepiej jest budować ściane samemu z opcją kontaktu z konkretną osobą odpowiedzialną za dany fragment systemu i przedstawieniu jej tego zamodelowanego fragmentu. W tych wszystkich warsztatach jest przedstawiony obraz ludzi, którzy chcą faktycznie się tam znaleźć, bo mają jakiś wspólny cel zbudowanie aplikacji, naukę techniki itp. A co wtedy kiedy spędzamy ludzi, którzy nie chcą tam być, „przyszedłem bo szef kazał ale i tak się ode mnie nic nie dowiesz?”, co wtedy? może faktycznie lepiej kontaktować się w inny sposób a ścianę budować na podstawie zdobytych informacji z kolegami z zespołu?

Podczas pracy na ścianie wynikł jeszcze inne problemy z określeniem prawidłowych zdarzeń, zdarzeń ważnych dla biznesu, szczególnie że ten Event Stroming robiliśmy bez byznesu. Czy można stwierdzić, że pewne zdarzenie jest ważniejsze od innego? czy można nałożyć wagi na zdarzenia?

Co do pierwszego pytania wydaje mi się że na ścianie nie umieszczamy zdarzeń nieważnych, jeżeli jakieś zdarzenie się tam znalazło i przeżyło krok drugi to znaczy że jest istotne  dla działania systemu. Z tego co pamiętam z warsztatów w Warszawie jest krok w ES-gu w którym możemy zmieniać istniejące zdarzenia poprzez głosowanie, otrzymujemy kilka głosów i oddajemy na zdarzenia do zmiany (krok 7 głosowanie). Wybieramy te z największą ilością i zmieniamy? Tylko czy w takiej sytuacji nie rozleci się cały proces?

Sprawa druga, wydaje mi się, że z określeniem wagi zdarzeń może być problem, bo pod jakim kątem mamy określić że dane zdarzenie jest ważniejsze od innego? może się tak zdarzyć, że spróbujemy i dla części ludzi zgromadzonych pod ścianą owszem te zaznaczone zdarzenie będzie ważne ale dla innych nie. Cóż doprowadzi to tylko do konfliktu, więc może lepiej uznać, że nie ma ważnych i ważniejszych zdarzeń? Czy może spróbować określić bez którego zdarzenia system będzie działał? Tylko czy w takim wypadku dodawanie takiego zdarzenia ma sens? Być może takie gdybanie doprowadzi nas do rozwiązania ważnych kwestii i wychwycenia i przeciwdziałania awarii? Pozostawię ten fragment jako pytanie bo nie znam odpowiedzi, a patrząc na ścianę nie widzę rozwiązania.

Co trzeba zrobić aby zrozumieć proces/y, które zachodzą w systemie? Trzeba je opisać za pomocą pomarańczowych (zdarzeń) kartek. Czy to wystarczy?, myślę że tak. Po dwutygodniowej przerwie łatwiej jest „przeczytać” ścianę, a niżeli zagłębiać się w kod i dokumentacje.

Co jeżeli proces ten jednak ulegnie zmianie? bo byznes zmieni koncepcje? pozostanie nam zmienić karteczki, zamiast zmiany kodu. Które łatwiejsze każdy wie.

Podsumowując, myślę że warto było zrobić ścianę ale warto było zatrzymać się dłużej na zdarzeniach i big picture.

Cóż ściana  póki co jest dynamiczna i ulega rozbudowaniu oraz zmianom, gdyż czerwone karteczki znikają, bądź pojawiają się w nowych miejscach.

Garść linków: