Rzut historyczny
Chciałbym żebyśmy wspólnie odpowiedzieli sobie na dwa pytania.
Pierwsze z nich to jaki postęp na przestrzeni kilkudziesięciu lat dokonał się w dziedzinie wytwarzania oprogramowania?
Jeszcze w latach 90, chmurę widzieliśmy tylko na niebie, teraz nie możemy sobie wyobrazić funkcjonowania nowoczesnej firmy bez rozwiązań chmurowych zapewniających nieporównywalną szybkość wdrażania, skalowalność i bezpieczeństwo.
Jeszcze niedawno myśląc o kontenerze wyobrażaliśmy sobie dużą puszkę na statku pełną chińskich podróbek. Dziś wyobrażamy sobie nowoczesną platformę umożliwiającą łatwą wirtualizację aplikacji wraz z zależnościami.
Jeszcze parę lat temu mówiąc żonie o SPA miało się na myśli tylko i wyłącznie romantyczny wypad na weekend do pobliskiego kurortu, a nie koniecznie chwalenie się webową aplikacją zbudowaną ostatnio w pracy w oparciu o najnowszy frontendowy framework.
No dobrze, a teraz odpowiedzmy sobie na drugie pytane. Jak na przestrzeni tych kilkudziesięciu lat rozwinęły się metody pozyskiwania informacji, uczenia się czy też zbierania wymagań?
Oczywiście nie jest tak, iż nic się nie zmieniło. Samo spopularyzowanie się metodologii zwinnych w okolicy lat dwutysięcznych miało bardzo duży wpływ na sposób pracy z wymaganiami. Jednakże nie zmienia to faktu, iż tak jak kilkadziesiąt lat temu dość ciężko było porozumieć się przysłowiowemu developerowi z przedstawicielami biznesu tak teraz nie wygląda to wcale znacząco lepiej. A już na pewno nie nastąpił tutaj przeskok na miarę przejścia z kart perforowanych do serverless.
Jak to jest z tym zbieraniem wymagań?
Poniżej parę kwestii które choćby dziś wydają się dość problematyczne, a często wręcz przesądzają o sukcesie czy porażce danego produktu czy projektu.
Błędnie zaprojektowany model domeny potrafi mścić się długo i bezlitośnie. Wie o tym każdy developer. Bardzo często, po zebraniu wymagań, projektując oprogramowanie, wpadamy w pewnego rodzaju pułapkę iluzji poprawności modelu który już zaprojektowaliśmy. Wydaje nam się, iż dany model, dana encja, pasująca i zaprojektowana inicjalnie w jednym obszarze domeny pasuje również jak ulał na jej drugim końcu i często spokojnie w architekturze naszej aplikacji ją tam wykorzystujemy. A dopiero po jakimś czasie okazuje się, iż dane encje, pomimo np. takiego samego nazewnictwa w domenie, różnią się adekwatnościami i zachowaniem. jeżeli mamy już zaimplementowane rozwiązanie, a co gorsza jeżeli jest to już działający kod na środowisku produkcyjnym odwrócenie takich, pochopnie przyjętych założeń, może być bardzo kosztowne.
Drugim aspektem na który chciałbym zwrócić uwagę jest aspekt pozyskiwania i posiadania wiedzy, a mianowicie kto posiada daną wiedze domenową? Oczywistą odpowiedzią jest, iż biznes. A kto w zespole Scrum posiada szeroką wiedze domenową? jeżeli jest to tylko Product Owner który kisi sobie tę wiedzę w swoim słoiku i wydziela ją skromnie co sprint zespołowi developerskiemu w postaci historyjek to należy zadać sobie pytanie czy aby na pewno jest to dobra sytuacja? Zadaniem Product Ownera jest przede wszystkim ustalanie odpowiednich priorytetów. Natomiast w moim odczuciu najważniejsze jest aby to zespół developerski mógł pozyskać szeroko rozumianą wiedze domenową z pierwszej ręki, wejść w interakcje z kluczowymi interesariuszami biznesowymi i mówiąc kolokwialnie 'poczuć krew'.
Trzecim, i chyba najważniejszym aspektem jest odpowiedź na mityczne pytanie czy aby na pewno rozwiązujemy adekwatny problem? Czy przez przypadek ze rogiem nie czai się znacząco poważniejszy kandydat do zaadresowania, a my marnujemy czas na nie ten obszar co trzeba? Czy przez przypadek wdrażając nasze zautomatyzowane rozwiązanie nie przesuwamy tylko problemu procesowego w inne miejsce w organizacji?
Aby spać spokojnie można albo mieć znajomego farmaceutę albo przynajmniej spróbować odpowiedzieć na te pytania zanim napiszemy pierwszą linijkę kodu.
I tak o to dochodzimy do setna, a mianowicie do techniki EventStorming której twórcą jest Alberto Brandolini, a która to technika stara się zaadresować przytoczone problemy, jak i kilka innych aspektów w procesie zbierania wymagań czy też mówiąc szerzej uczenia się. Postaram się przybliżyć Wam tą technikę w kilku kolejnych artykułach.
Myśl przewodnia tego artykułu została zainspirowana książką Introducing EventStorming której autorem jest Alberto Brandolini
