Novemberben félnapos DDD – Event Storming workshopon vehettek részt a téma iránt érdeklődő kollégáink, pár héttel később pedig Kujbusz Péterrel, a Stylers projektvezetőjével arról beszélgettünk, az élményen túl vittek-e valamit tovább magukkal a foglalkozásból.
A DDD a domain-driven design rövidítése, a kifejezés és módszertan pedig Eric Evans 2003-ban megjelent Domain-Driven Design: Tackling Complexity in the Heart of Software című könyvéből származik. Egy olyan szoftverfejlesztési megközelítésről van szó, amely összetett feladatok részletes megértésében nyújt segítséget, és célja, hogy kreatív együttműködésre ösztönözze a résztvevő szakembereket, illetve felszínre hozza és tudatosítsa a kiválasztott domainben felmerülő problémákat. A DDD elvei alapján egy projekt során az üzleti fogalmak és a hozzájuk tartozó logikai kapcsolatok feltérképezése és meghatározása kulcsfontosságú, mert az így kialakított közös nyelv segít összekapcsolni a csapat minden tagját.
2013-ban Alberto Brandolini megalkotta az Event Stormingot, amely egy workshop-alapú, interaktív megközelítési módja a DDD metodológiájának. A módszer igyekszik gyakorlatiasabb módon megközelíteni a DDD komplex rendszerét, alkalmazásához még számítógép sem szükséges, a foglalkozás résztvevői ugyanis különböző színű post-itekkel dolgoznak, ezek segítségével jelenítődik meg (“stormed out”) a falon egy adott üzleti folyamat. Az Event Storming legfőbb célja, hogy közelebb hozza egymáshoz a különböző munkakörökben dolgozó szakembereket a tudásmegosztás érdekében. Ahhoz, hogy a közös tanulás eredményes legyen, fontos, hogy a megfelelő emberek legyenek jelen, így a felmerülő kérésekre megtalálhatják a helyes választ is. A workshop hatékony katalizátor, amely felgyorsítja a tanulási folyamatot, ezáltal a jelenlévők hamarabb juthatnak közös nevezőre, a közös tér pedig abban segít, hogy azok a beszélgetések és viták, amelyek egyébként elszórtan zajlanának le a kérdéses pontokkal kapcsolatban, a foglalkozás során egyszerre történjenek meg.
A workshopot igyekeztünk úgy alakítani, hogy minél több munkakkörből vegyenek részt rajta kollégák, így mi is érzékeltük, hogy valóban segít jobban megértenünk egymást, illetve áthidalja azt a hézagot is, amelyet az egymástól különböző területeink és azok eltérő logikája és nyelve okozott. Megismertünk egy (sokaknak új, másoknak többé-kevésbé ismerős) metodológiát, és persze feltettük magunknak a kérdést: eddig ezt miért nem így csináltuk?
“Sokat segített, hogy ez a megközelítés a vizualizációra épít. Rá voltunk kényszerítve arra, hogy a teret a struktúra átlátásának eszközeként használjuk; kézzel jegyzeteltünk, ezáltal jobban rögzültek a gondolatok, végig mozgásban volunk, beszélgettünk, és végül az elkészült, post-itekkel teleragasztott falat is sokkal jobban át tudtuk látni, mint bármelyik digitális boardot” – avatott be a részletekbe Péter.
“Fontos kiemelni, hogy a módszer hatékony alkalmazásához a fejlesztőcsapaton túl az ügyfél bevonása is szükséges, hogy velük is végig tudjunk menni ezeken a lépéseken. Ez azért hasznos, mert elengedhetetlen, hogy velük is egy nyelvet beszéljünk (vagy legalábbis mindkét félnek legyen egy szótára a másikhoz a megbeszélések során). Rengeteget segít, hogy ezáltal megismerhetjük egymás gondolkodásmódját és perspektíváját, mert nem mindegy, hogy például az alábbi képen ki mit lát.”
Természetesen ennek a módszertannak is megvannak a maga korlátai, például nem lehet a projekt minden szakaszában használni (léteznek egyéb modellezési technikák is, pl. Business Model Canvas, User Story Mapping), de azt is érdemes figyelembe venni, hogy nem mindig hasznos, ha minden folyamatnak a legmélyéig szeretnénk eljutni, ugyanis könnyű elveszni a részletekben. Mi a workshop során leginkább egy új szemléletet tanultunk, amelyet a jövőben igyekszünk majd minél több fejlesztési és ügyfélfolyamat során használni, egyfajta zseblámpaként.
