<!--  rating: ⭐️⭐️⭐️ // 1 to 3 stars date: 2023 // when started reading read: 2023 // when finished reading status: undefined, backlog, to read, reading, completed, stopped -->  # Untitled by [[{{author}}]] ## Summary <!-- No more than a couple paragraphs summarizing this BOOK --> {{description}} ## Table of Contents <!--Link to table of contents (TOC) --> - ## Notes ### C1 - What does EventStorming looks like? En cada taller, la màxima prioritat del facilitador és eliminar els obstacles a la col·laboració i el descobriment. Tot el que facis —el que dius, com organitzes la sala, com cronometres cada fase— ha d’ajudar a mantenir el grup en un estat de “flow”. A continuació tens les tàctiques clau: 1. **Posposa els retocs menors** - Aplica la regla dels post-its taronges en passat (“esdeveniment”) només quan redueixi la velocitat del grup. Al principi, enfoca’t en la visió general; marca els “stickies” no estàndard per revisar-los més tard, sense frenar la dinàmica. - Evita corregir massa aviat: és més valuós mantenir l’energia que polir cada verbo. 2. **Proporciona recursos de modelatge il·limitats** - Pre-enganxa rotllos de paper a les parets i posa un gran estoc de post-its i rotuladors a la taula. Quan s’esgoti l’espai o els materials, la dinàmica cau, així que mantén-ho tot a la vista. - Si veus un grup d’esdeveniments encabritat, desperta una nova secció de paper o reposiciona’n una altra perquè no es creïn embussos. 3. **Utilitza eines senzilles “hack”** - Porta una cinta de colors per marcar “Esdeveniments Pivots”, separacions de «swimlanes» o per guanyar espai ràpidament. És flexible, esborra fàcilment i et deixa les mans lliures. - Mantén un “llegendari” en un flip-chart amb convencions (“taronja = esdeveniment”, “groc = actor”, etc.) i afegeix-hi nous símbols (“verd = oportunitat”, “vermell = risc”) sobre la marxa. 4. **Mira la sala, no només la paret** - Mou-te constantment. Observa gestos: qui està quiet? Qui treballa en grups massa petits? Qui mira cap a la porta? L’energia de tothom ha de romandre alta. - Escolta les veus més tímides: si només parlen els més extrovertits, convida amb tacte els altres a afegir algun post-it o fer la seva aportació. 5. **Cronometra estrictament—però sigues flexible** - Fes servir un temporitzador visible. Defineix fases (Exploració, Ordenació, Recorregut, etc.) amb temps assignat per evitar que el taller s’allargui indefinidament. - Però quan aparegui una discussió realment valuosa, atura el rellotge i explora-la: sovint és quan surten les millors idees. 6. **Visualitza i encamina les converses laterals** - Usa post-its violeta per marcar “pistes per resoldre després”. Així, qui vulgui aprofundir pot fer-ho sense desviar tota la reunió. - Si un petit grup s’endinsa en un debat, demana’ls que resumexin la qüestió amb un post-it violeta i la guardareu per al final. 7. **Gestiona el “Godfather”** - Sempre hi haurà qui vulgui afegir “una cosa més” o aportar “insights únics”. Quan parli, agraeix-li’l, fes-li resumir en un post-it i “diposita-l” al mur perquè tothom segueixi avançant. 8. **Planifica els “deures” de software** - A la fi, convida els participants a reflexionar sobre patrons emergents (candidats a bounded contexts, àrees n’hi-nucli, punts de dolor d’integració…) i escriure en targetes “capacitats crítiques” o “requisits must-have”. Aquestes targetes seran la base per al disseny tècnic posterior. En mantenir l’*energia* del grup, tractar (paper, *post-its*, cinta, *rotuladors*) com el teu “codi” principal i ser implacable a l’hora d’eliminar petits entrebancs, aconseguiràs capturar la millor intel·ligència col·lectiva i convertir un taller caòtic en un model clar i accionable. ### C2 - A closer look at the problem space **Resum del Capítol 2 – A closer look at the problem space** En aquest capítol s’exploren les disfuncions organitzatives més habituals (“forces d’«organisational gravity»”) que cal entendre abans de modelar solucions de negoci. Els punts principals són: --- #### 1. Sils (Silos) - **Descripció**: Barreres naturals que s’hi formen quan els experts deleguen tasques especialitzades i es creen departaments tancats. - **Efectes**: - Amb prou feines circula la informació entre departaments, augmenta la “cecitat” envers el funcionament global. - Es prioritzen optimitzacions locals per sobre de les globals. - Facilita la creació de nous silos i jerarquies a mesura que l’empresa creix. - **Clau**: No cal eliminar-los totalment, però cal minimitzar-ne l’impacte alineant tothom sobre un mateix model global. #### 2. Objectius i metes ocultes (Targets and goals) - **Descripció**: Els objectius individuals sovint s’acorden en secret (per exemple, lligats a bonus), generant competència oculta i estratègies paral·leles. - **Efectes**: - Les mesures per “assolir la meta” poden contradir-se entre departaments. - Es prioritzen tasques que asseguren el bonus personal abans que l’èxit global. - **Clau**: Fer visibles i compatibilitzar tots els objectius dins del mateix model estratègic per evitar conflictes d’interessos. #### 3. Cicle de vida de les decisions (Decisions’ lifecycle) - **Descripció**: Les decisions inevitablement s’acumulen (“piling up”) i són molt més complexes de desfer que de prendre. - **Factors**: - **Biaix d’afegir vs. treure**: Tendim a afegir noves regles o processos abans que no pas eliminar-ne (por de trencar coses desconegudes) . - **Cost de retracció**: Cal reharmonitzar interessos, actualitzar procediments i rebre aprovacions de tothom implicat. - **Clau**: Implantar mecanismes constants de revisió i simplificació de processos abans que s’acumulin complexitats inabastables. #### 4. Cost de consens (The cost of agreeing) - **Descripció**: Convé fer decisions entre departaments, però el silenci i la “procrastinació contínua” fan que el consens estratègic sigui car i poc freqüent. - **Clau**: Utilitzar tallers de modelatge transversal (p. ex. Big-Picture EventStorming) per accelerar l’alineament estratègic i afavorir empatia interdepartamental. #### 5. Model global com a eina d’alineació - **Visió**: Un **big behavioural model** (una mena de “mapa” col·laboratiu dels processos i esdeveniments clau) facilita: - Veure interdependències ocultes. - Prioritzar iniciatives d’alt valor estratègic. - Millorar onboarding de nous equips, accelerant la comprensió global. **Objectius del capítol** 1. Els sils són gairebé inevitables, però cal controlar-ne l’impacte. 2. Els objectius individuals, si són opacs, generen conflictes i dificulten el canvi. 3. Les decisions s’acumulen; la seva retracció és costosa. 4. Sense visió compartida, l’autorganització a gran escala no funciona. 5. Millorar el consens interdepartamental reduint el cost de la coordinació. Aquest diagnòstic del “problem space” és la base per després dissenyar models i solucions de software que abordin no sols processos tècnics, sinó també dinàmiques humanes i organitzatives. ### C3 - Pretending to solve the problem writing software Aquí tens un resum dels conceptes principals del Capítol 3, “Pretending to solve the problem writing software”, en català: 1. **El veritable objectiu és l’aprenentatge, no el lliurament de codi** La “gran fal·làcia” consisteix a creure que l’únic valor està en el software acabat. En realitat, el desenvolupament és un procés d’aprenentatge constant; el codi és només un efecte secundari . 2. **Hem optimitzat la velocitat de programació quan ja no era el colls d’ampolla** Hem millorat enormement la productivitat del desenvolupament (IDE, despliegue ràpid…), però no hem avançat en com aprenem el negoci o els processos reals . 3. **Contractistes i coneixement perdut** Si el contractista és considerat només un “llista de tasques”, el coneixement adquirit desapareix amb ells. Cal tractar l’aprenentatge com un actiu, no com una simple entrega . 4. **La il·lusió del model subjacent** Molts equipaments intenten trobar el “model” només recollint noms (entitats, taules), però cada àrea funcional (vendes, enviaments, facturació…) té la seva pròpia visió inconsistent. El programari no suporta aquesta ambigüitat com una conversa humana . 5. **L’error del Product Owner com a únic dipositari de l’aprenentatge** Delegar tota la comprensió al PO crea un sol punt de fallida i aïlla als desenvolupadors de la font directa del coneixement. Cal que els equips també participin en el descobriment i validació amb usuaris reals . 6. **La fal·làcia del backlog** Veure el backlog com una simple cua d’items fa que sempre seguim el mateix ritme (planificació–implementació–lliurament) i no deixem espai per a activitats de veritable descobriment (proves de camp, tallers col·laboratius…) . 7. **Iterar és car i començar bé importa** Tot i que l’iteració és clau en entorns d’alta incertesa, fer molts cicles de prova i error sense un punt de partida raonable pot ser molt ineficient. Cal anticipar tant com sigui possible abans de començar a codificar . 8. **Preparar l’entorn per a l’aprenentatge col·laboratiu** Finalment, s’introdueix la necessitat de metodologies (com EventStorming) que posin el llenguatge i el model de negoci al centre, evitant suposicions i construint un mapa compartit abans de disparar línies de codi. Aquest capítol denuncia les pràctiques que confonen “produir software” amb “aprendre el negoci” i posa les bases per a enfocaments (DDD, tallers d’esdeveniments, etc.) que solucionen aquesta disfunció. ### C4 - Running a Big Picture Workshop El Capítol 4 “Running a Big Picture Workshop” descriu com conduir una sessió d’EventStorming a gran escala per modelar tot el flux de negoci, descobrir problemes i prioritzar on centrar-se. A continuació, n’ofereixo un resum dels punts principals: **1. Objectius del Big Picture Workshop** – Construir un model de comportament de tota una línia de negoci, fent visibles col·laboracions, responsabilitats, actors i sistemes externs. – Detectar i validar el problema més rellevant a resoldre. – Posar en relleu els riscos i oportunitats del flux actual. **2. Elements indispensables** – **Participants**: Cal combinar experts tècnics i de negoci, persones que **sàpiguen** i que **es preocupin** pel procés. – **Facilitador**: Coordina el ritme, evite “plays de poder” i assegura que tothom participi. – **Espai**: Una paret llarga amb paper o pintat de guix per escriure; prou espai per moure’s i sense cadires al mig. – **Material**: Lots de post-its de colors (domini events, problemes, oportunitats), retoladors, i rellotge per fer time-boxing. **3. Fases de la sessió** 1. **Kick-off** (brief check-in) – Presentar-se, alinear objectius i explicar breument el format. 2. **Chaotic Exploration** – Tothom afegeix “domain events” a l’atzar al paper, sense ordre previ. Converses puntuals però treball majoritàriament en silenci. 3. **Enforcing the Timeline** – Organitzar els events sobre una línia de temps única; apareix l’estructura i es detecten “hot spots”. 4. **People and Systems** – Identificar quins rols humans i quins sistemes (interns o externs) intervenen en cada event. 5. **Explicit Walk-through** – Un participant “narrador” camina al davant de la paret explicant el flux; tothom pot interrompre per afegir o corregir. 6. **Reverse Narrative** (opcional) – Repetir el flux en ordre invers per descobrir buits i afegir events que s’hagin passat per alt. 7. **Problems & Opportunities** – Cada un escriu problemes (post-its morats) i oportunitats (post-its verds) en zones caòtiques o problemàtiques. 8. **Pick Your Problem** – **Arrow Voting**: cada participant té 2 fletxes blaves per votar el problema/oportunitat més important. Aquest mecanisme ràpid i simultani fa emergir prioritats clares. 9. **Wrap-up** – Es fotografien els resultats, es recullen conclusions i s’acorda l’acció a fer al dia següent. **4. Quan no votar** No convé fer Arrow Voting si: - No hi ha el grup adequat. - L’abast és massa ampli o massa aviat. - Hi ha limitacions de confidencialitat. --- Aquest procés transforma un caos inicial en un mapa clar de fluxos, responsabilitats i punts crítics, i permet sortir amb un focus compartit de què cal abordar primer. ### C5 - Playing with value **Capítol 5. Playing with Value** _(EventStorming – Nicolàs Modesti)_ En aquest capítol s’introdueix un pas opcional dins del **Big Picture EventStorming**, centrat en la descoberta i exploració del **valor** que es genera (o es perd) al llarg del procés modelat. Els punts principals són: 1. **Quan aplicar-lo** Després d’haver establert el flux bàsic amb els passos de “People & Systems” i “Explicit Walk-through” (capturant esdeveniments, actors i sistemes), i abans o després del pas de “Problems & Opportunities”, podem afegir un enfocament en el valor per desvetllar motius més profunds de les accions de l’organització . 2. **Explorar el valor** - **Moments de creació de valor**: marquem amb pos-its verds els punts on ocorre valor positiu. - **Moments de destrucció de valor**: amb pos-its vermells identifiquem on es perd valor, permetent contrastar bones i males pràctiques . 3. **Descobrir múltiples “monedes” de valor** - Sovint es pensa en termes de diners, però el taller revela altres **“divises”**: seguretat, reputació, orgull, claredat, confort, etc. - Exemple: en un conference EventStorming, els ponents perceben valor no només econòmic (honoraris) sinó també de reputació (“estar a l’escenari”) i aprenentatge . 4. **Contrastar perspectives** - Un mateix pas pot generar valor per uns i perdre’l per a altres (win-win vs. win-lose). Ex.: el pagament d’un bitllet crea seguretat pel viatger però pot generar frustració si el procés és complex . 5. **Explorar el propòsit** - Ens qüestionem el “per què” darrere de cada acció. Si no es troba una raó perquè l’usuari faci una acció, pot indicar un **supòsit sense validar** que cal provar abans de desenvolupar cap solució de software . - També pot sorgir la **pèrdua de propòsit** organitzatiu, quan el públic diu “No veig el propòsit del nostre treball”, revelant incoherències amb la missió formal de l’empresa . 6. **Replantejar l’optimització** - En lloc de centrar-se trivialment en augmentar ingressos, es poden identificar palanques més efectives: simplicitat, velocitat, experiència d’usuari o estat d’ànim. - Canviar acceleradors de valor segons les “divises” identificades pot desbloquejar oportunitats de millora radical . Aquest pas de “Playing with Value” és especialment valuós per: - **Obrir la mirada** més enllà dels indicadors financers tradicionals. - **Fomentar l’empatia** amb tots els actors, descobrint motivacions emocionals i socials. - **Prioritzar millores** no només tècniques sinó de **proposat de valor** (value proposition). En finalitzar, el tallerista haurà de **documentar** els punts de valor i les “divises” identificades, incloent possibles **experiments** per validar suposicions de valor abans de dissenyar solucions de programari. ### C6 - Discovering Bounded Contexts with EventStorming El capítol 6, “Discovering Bounded Contexts with EventStorming”, explica com aprofitar un **Big Picture EventStorming** per identificar candidats a Bounded Contexts en dominis complexos. A continuació, els punts clau: 1. **Per què són tan crucials els Bounded Contexts** - Un mateix concepte (“Order”, “Flight”, “Policy”, etc.) pot tenir significats distintes segons l’àrea de negoci, i compartir-lo sense tenir clar on el model “canvia de sentit” porta a complexitat tècnica, conflictes d’equip i retards en el desenvolupament . - La decisió de “fer bé els límits” d’un projecte de software té més impacte a llarg termini que qualsevol altra elecció d’arquitectura. 2. **Big Picture EventStorming com a eina d’exploració** - Reuneix en una mateixa sala tant stakeholders de negoci com tècnics, sobre un gran mural (rotlle de paper i molts “sticky notes”) i se situa cada **event** (frase en passat) sobre una línia de temps ideal del flux de negoci . - L’objectiu no és produir diagrames “bonics”, sinó generar una visió compartida i fer emergir discrepàncies i punts de fricció. 3. **Estructura bàsica del workshop** 1. **Exploració caòtica**: tothom escriu en silenci els Domain Events que coneix, ordenant-los aproximadament sobre la línia de temps. 2. **Forçar consistència**: es reordenen i netegen els events, apareixen **Hot Spots** (conflictes) i es fa emergir estructura. 3. **Persones i sistemes**: s’afegeixen actors (persones, rols) i sistemes externs (pagaments, APIs, etc.), descobrint restriccions i punts d’integració. 4. **Recompte explícit**: un narrador recorre tota la línia mostrant inconsistències i forçant matisos addicionals. 4. **Heurístiques per derivar Bounded Contexts** - **Pivotal Events**: senyalen transicions de fase de negoci (ex. “Ticket Sold”, “Conference Started”) i acostumen a dividir contextos. - **Swimlanes**: agrupen activitats paral·leles (Sales, Speaker Mgmt, Sponsorship) que sovint corresponen a diferents models. - **Discrepàncies en el llenguatge**: termes homònims (Schedule Published vs Schedule Completed) suggereixen models independents. - **Persones al voltant del mural**: on s’aturen els experts o es generen discussions marca àrees de coneixement aïllat. - **Llenguatge real de la conversa**: buscar verbs, no noms; els noms poden ocultar models diferents (ex. “Talk” en selecció, puntuació, publicació). 5. **“De la sala al codi”** Un cop acabat el workshop, amb tota aquesta informació no solament aprendrem col·lectivament, sinó que podrem **esbossar context maps** i definir contracts entre models, facilitant la **modularitat** i evitant els “monolits” mal delimitats: “Merge the people, split the software” . En resum, capítol 6 proporciona una guia pràctica —amb passos concrets i heurístiques— per descobrir, **visibilitzar** i **separar** models de negoci (i per tant Bounded Contexts) en grans dominis, mitjançant la col·laboració intensa de tots els implicats. ### C7 - Making it happen Al capítol 7, “Making it happen”, s’expliquen les tasques clau del facilitador per tal que el workshop flueixi sense bloquejos i els participants s’impliquin plenament. A grans trets: **1. Gestionar l’experiència dels participants** - **Posposar la precisió:** Tot i que demanem que els esdeveniments (“Domain Events”) es redactin amb un verb en passat, no cal depurar-ne el redactat en la primera passa. El facilitador deixa passar les formulacions incorrectes —sempre que no saturin el mur— i més endavant, un cop establert el model, es revisen i refinen amb calma . - **Recursos d’estampació il·limitats:** Cal assegurar-se que mai no faltin materials: paper (rolls de plotter), retoladors funcionals i notes adhesives de colors. La pèrdua de ritme que produeix un retolador sec o unes notes esgotades pot fer descarrilar la dinàmica . **2. Mantenir la consistència temporal sense rigidesa excessiva** - El “timeline” és l’eix vertebrador per alinear punts de vista, però no cal estricte seguiment: es toleren bucles de feedback, es poden marcar “esdeveniments disparats pel temps” (p. ex. tancaments de mes) i es poden anotar pròpies recurrències quan aportin valor a la conversa . **3. Gestionar conflictes de manera constructiva** - **Fomentar la tensió creativa:** Els desacords —sobre noms, seqüències o responsabilitats— són fonts d’aprenentatge perquè evidencien assumptions ocultes. El facilitador no els xucla sota la catifa; els deixa emergir, ajuda a posar-los de manifest i a connectar-los amb punts de millora del model. - **Diversitat de veus:** Cal convidar participants amb diferents posicions (fins i tot aquells amb opinions molt enfrontades), ja que sovint són ells qui desbloquegen zones “crítiques” d’enteniment. El facilitador ha de gestionar-les sense prejudicis, mantenint el focus en el problema i no en les persones . En resum, fer “happen” un EventStorming és tant obra del facilitador (creant un entorn lliure d’impediments i posant ordre en el caos) com dels participants (amb la seva disposició a explorar, discutir i refinar el model sense por a equivocar-se). ### C8 - Preparing the workshop **Capítol 8: Preparant el taller** — els principals punts a tenir en compte abans de l’EventStorming: 1. **Escollir una sala adequada** - Habilita un espai “lliure” per al modelatge: un mur llarg on enganxar rotlles de paper (mínim ~8 m, però tants com calguin per evitar límits artificials) . - Retira cadires i taules grans per fomentar la mobilitat i implicació; deixa només taules altes petites per escriure retoladors i post-it . - Prova també espais alternatius (corredors amplis, etc.) si són més fàcils d’aconseguir i ofereixen les mateixes condicions. 2. **Superfície de modelatge il·limitada** - Col·loca rotlles de paper al llarg de tot el mur disponible, amb estratègia d’expansió per si el flux de discussió creix més del previst . - Produeix un “efecte sorpresa”: un entorn inusual estimula la curiositat i la participació activa. 3. **Llegenda i materials visibles** - Destina una pissarra o flip-chart a mantenir la llegenda sempre a mà (color de notes, codis, convencions de nom, etc.) . - Assegura’n d’abastir prou: rotlles de paper, post-it (majors i menors), retoladors, cronòmetre visible, aliments i begudes saludables . 4. **Gestió de les invitacions** - Convida un **barreja de perfils**: - _Persones amb preguntes_ (curioses, amb ganes d’aprendre i dissenyar solucions). - _Persones amb respostes_ (experts de domini, que aportin coneixement específic). - _Persones amb punts de vista divergents_ (per identificar tensions i oportunitats). - _Facilitador_ neutral, amb autoritat per desactivar bloquejos i gestionar conflictes . 5. **Agenda i expectatives** - Publica una **agenda visible** amb objectius, fases previstes i horaris aproximats per generar confort i permetre tornar al fil quan calgui . - Planifica fases **time-boxed**, però manté sempre l’espai per a l’exploració caòtica i l’“efecte Goldilocks”: ni massa fàcil, ni massa difícil. 6. **Fenomen “morning after”** - Deixa la sala i el mural accessibles almenys unes hores (idealment un dia i mig) per recollir idees que sorgeixin a posteriori i per implicar els participants més introvertits . Amb aquests passos tindràs un entorn **optimitzat** perquè l’EventStorming surti del format “reunió avorrida” i es converteixi en un taller dinàmic, col·laboratiu i efectiu. ### C9 - Workshop Aftermath Al tancament del workshop, o “Workshop Aftermath”, cal centrar-se en transformar l’experiència i l’artifact visual en accions concretes i aprenentatges duradors. A continuació, els punts clau: 1. **Quan aturar-se?** El taller sol tenir un _timebox_ limitat (≈2 h) per disponibilitat dels participants. L’objectiu no és completar-ho tot, sinó aprofundir en els punts crítics. Cal prioritzar les àrees marcades com a “hot spots” amb notes púrpures . 2. **Com sabem que ha anat bé?** - És una excusa per iniciar la conversa amb les persones adequades. - És una eina per millorar la qualitat d’aquesta conversa. Un bon taller acaba amb els participants “feliçment cansats” i amb la sensació “aquest caos som nosaltres” . 3. **Revisions visuals (Visual Check):** - Hem identificat “hot spots”? (marca morada) - Nombre d’esdeveniments emergits: per a 2 h, 100–200 és raonable; menys, indica superfície massa rasa. - Hem capturat tots els sistemes externs, fonts de variabilitat? - S’ha preguntat “què falta en aquesta imatge?” explícitament? . 4. **Embolcallar i netejar (“Wrapping up”):** - Reservar una estona extra per desmuntar amb calma i discutir remots senyals no verbals abans de plegar . - Ordenar i protegir l’artifact físic. 5. **Què fer amb el mural?** - **Mantenir-lo visible uns dies:** referència per als que no van assistir i punt d’ancoratge per a posteriors reflexions. Pot inspirar noves converses. - **Arxivar-lo:** fer-li fotos panoràmiques i de detall, després enrotllar-lo amb les notes perquè hi puguem tornar si cal . 6. **Gestió emocional (“Feelings”):** - Valorar l’ambient: si hi ha, per exemple, tensió o silenci, pot indicar problemes d’equips o jerarquies que no es resoldran amb software. Abans de codificar, cal tractar qüestions polítiques o de cultura detectades durant el taller . 7. **Prioritzar “hot spots”:** - Un cop identificats, iniciar de seguida les accions per abordar-los. El taller perd impuls si no es canalitza ràpidament cap a una investigació més profunda del col·lapse detectat . 8. **Quant de temps mantenir el mural?** - Normalment una setmana. Un cop desapareixen els punts de tensió i s’inicien millores, el valor de la gran superfície disminueix. Fer fotos i emmagatzemar el rotlle físic per si cal referir-s’hi més endavant . 9. **Documentació i següents passos:** - Fer servir el mural per identificar subdominis, bounded contexts i definir properes històries d’usuari o story maps, però sense obsessionar-se amb la perfecció del model: és un punt de partida per iterar, provar i validar en el món real . En resum, el “Workshop Aftermath” és tot el procés de transformar l’energia i els descobriments del taller en accions concretes, gestió d’emocions, priorització de punts crítics i documentació sostenible, assegurant que el coneixement capturat impulsi veritables millores. ### C10 - Big Picture Variations El capítol 10 “Big Picture Variations” explora diverses adaptacions del format bàsic de Big Picture EventStorming segons l’objectiu i el context: 1. **Software Project Discovery** - **Context**: un equip de desenvolupament extern ha de donar servei a una empresa client i cal explorar ràpidament l’abast i riscos del projecte. - **Reptes**: interessos sovint contradictoris (viabilitat tècnica vs pressupost client), problema de disponibilitat d’actors clau, inèrcia de mètodes tradicionals (waterfall i documents de especificació) . - **Consells**: - No cal presentar-ho com a “EventStorming”: porteu directament papers i notes i comenceu a modelar “com sempre” per evitar resistències. - Considereu el taller com a palanca de negoci (“gateway” a la decisió de contractació), amb acord explícit que participar-hi redueix el risc per ambdues parts. - Penseu que la descoberta pot revelar què és core (projecte estratègic) o només supporting (manteniment), i actueu en conseqüència . 2. **Organization Retrospective** - **Context**: després d’un any de funcionament o un període crític, l’empresa vol revisar processos interns i millorar col·laboració. - **Diferències respecte al Big Picture “standard”**: 1. No podeu tornar a reunir tot l’equip gran cada cop que hi ha noves incorporacions. 2. Encara té sentit “redescobrir” tot el flux: les persones noves omplen el paper amb les seves pròpies hipòtesis, que després es corregeixen en col·laboració amb els veterans . - **Metodologia**: - Convideu només els nous entrants (“proxy experts”) i deixeu-los començar planificant “com ho farien ells”. - Els veterans intervenen per ajustar i validar, garantint la transferència de coneixement. 3. **Induction for New Hires** - **Objectiu**: accelerar la incorporació de persones nouvingudes mostrant-los de manera vivencial com funciona el negoci. - **Enfocament**: igual que en la retrospectiva, es parteix de l’expectativa errònia dels novells i es fa evolucionar el model col·lectivament fins a reflectir la realitat . - **Beneficis**: millora la retenció de coneixement, fa que els nous hires siguin actius des del primer moment i reforça el sentit de pertinença. En resum, el capítol subratlla que el format de Big Picture és altament adaptable. Depenent de si volem descobrir projecte, revisar l’organització o incorporar gent nova, modifiquem la composició de participants, el flux del taller i la manera com introduïm la dinàmica, però sempre conservant l’essència: modelatge col·laboratiu amb esdeveniments per revelar inhibidors i oportunitats. ### C11 - Big Picture in remote mode El capítol **11. Big Picture in remote mode** d’“Introducing EventStorming” descriu com adaptar el format de “Big Picture” a entorns distribuïts i remots, destacant les següents idees clau: #### 1. Canvis principals - **Absència de presència física**: es perd el llenguatge corporal i la proximitat, fet que dificulta la lectura d’emocions i senyals no verbals. - **Sense logística de sala ni viatges**: s’estalvia temps i cost, però també es redueix el compromís que genera la inversió prèvia. - **Artifact digital**: ofereix avantatges (redimensionar, duplicar, canviar colors) però treu l’impacte visual i la monumentalitat del “rollo” físic. - **Connexió remota**: depèn de la càmera, micròfon, amplada de banda i fins i tot de la família a casa . #### 2. Conseqüències inesperades - **Menor compromís i més procrastinació**: sense costos previs ni urgència de viatge, és fàcil ajornar sessions o desconnectar-se. - **Fatiga de Zoom**: sessions de dia sencer són esgotadores; cal dividir en migdies i tenir en compte diferents fusos horaris. - **Manca de “peer pressure”**: els participants poden desconnectar-se sense repercussió social, dificultant la cohesió del grup . #### 3. Nou rol del Big Picture remot Tot i les pèrdues (espontaneïtat, conversa paral·lela), el Big Picture remot segueix sent valuós com a **referència col·lectiva** per: 1. Alinear visió en equips distribuïts. 2. Facilitar el disseny de nous serveis i canals (ex.: redisseny de línies de negoci durant la pandèmia). 3. Detectar fronteres de Bounded Contexts amb marcs (frames) i “stickies” de grandàries diverses . #### 4. Patrons per al Big Picture remot 1. **Split the workshop**: dividir el taller en sessions curtes, a vegades paral·leles, amb experts per grup. Cal sessió introductòria comuna i “seed” d’estructura prèvia per orientar l’exploració . 2. **Anticipate Structure**: predefinir un esbós (pocs events clau o marcs) per evitar l’”exploració caòtica” digital, on desapareix la referència espacial . 3. **Colors as a signature**: assignar colors als participants per reconèixer ràpidament aportacions pròpies; un color addicional pot fer de **progrés indicator** validant events revisats. 4. **Iterate on Copy**: aprofitar la fàcil còpia digital per provar variacions sense perdre l’historial; permet “rollback” ràpid i exploracions segures. 5. **Make Modelling Log Readable**: documentar decisions (per què es descarta una branca) amb notes visibles, assegurant seguiment per nous participants. 6. **Make interests explicit**: recollir què interessa cada persona (avatar + fletxa), donant visibilitat a preocupacions en absència de llenguatge corporal . #### 5. Cap “recepta” fixa No hi ha una solució única: cal adoptar una **cultura d’experiments temporalitzats**, ajustar formats i eines segons la maduresa digital de l’equip i el context orgànic. Els patrons proposats són punts de partida per itera­ cions successives fins trobar el flux òptim . Així, encara que la realitat remota no permet replicar exactament l’experiència presencial, aquests canvis i patrons ajuden a mantenir l’eficàcia del Big Picture mantenint la col·laboració, la visió compartida i la descoberta de contextos malgrat la distància. ### C12 - What software development really is El capítol 12, “What software development really is”, desmunta diverses idees errònies sobre en què consisteix realment el desenvolupament de programari i proposa quatre tesis fonamentals: 1. **El desenvolupament de programari és escriure codi (però no només això)** - Hi ha qui pensa que el progrés es mesura en línies de codi, que a més tipatge i més “tecleig” són sinònims d’eficiència, i que afegir més persones sempre accelerarà la lliurament. Aquestes creences simplistes són irònicament exposades per mostrar que, a l’hora de la veritat, ningú experimentat s’ho creu . 2. **El desenvolupament de programari és aprendre** - Cada projecte és una aventura de descobriment: comprendre el domini, la tecnologia, les restriccions dels usuaris i del negoci. L’aprenentatge real — tant tècnic com de negoci— és el que dóna valor al temps invertit. 3. **El desenvolupament de programari és prendre decisions** - Des de les trivials (com nomenar una variable) fins a les estratègiques (quin llenguatge, arquitectura o biblioteca emprar), els desenvolupadors prenen contínuament decisions que afecten el futur del projecte. És una activitat creativa i mentalment exigent . 4. **El desenvolupament de programari és esperar** - Esperem el compilador, l’usuari que clarifiqui un requisit, els permisos d’infraestructura, el feedback de QA… I sovint, mentre esperem, ens dispersam en altres tasques. Aquesta “accidental complexi­tat” sovint es tradueix en treball duplicat o mal sincronitzat . --- **Objectius del capítol** - Revisar i qüestionar els models mentals equivocats (p. ex., “és com construir una casa”). - Entendre que optimitzar només l’escriptura de codi és estèril si no s’integra aprenentatge, presa de decisions i gestió dels temps d’espera. - Presentar Kanban i la Teoria de les Restriccions com a marcs per millorar el flux de treball i el “throughput”. - Reflexionar sobre on estem invertint l’esforç i com podem enfocar-ho cap a l’aprenentatge i la reducció de les incerteses. En resum, el capítol reivindica que la façana més visible (escriure codi) és només una part de la professió: al cor hi ha un cicle d’aprenentatge, decisions constants i gestió d’espera, i només reconeixent-ho podem millorar realment els nostres processos. ### C13 - Process Modelling as a cooperative game En aquest capítol s’introdueix una versió de l’EventStorming orientada al disseny col·laboratiu de processos, amb dinàmiques i “regles del joc” que faciliten la convergència cap a una solució compartida. #### Context - **Abast acotat**: es treballa un únic procés “extrem a extrem”, tot i que n’explorarem les implicacions completes. - **Equip reduït i interdisciplinari**: es requereix col·laboració estreta per a dissenyar un nou procés —departamental o totalment nou—, fent emergir requeriments i “colls d’ampolla” identificats prèviament en el Big Picture . - **No programari encara**: l’enfocament és sobre el flux de negoci, més endavant s’abordaran les particularitats del disseny de software. #### Joc cooperatiu - **Metàfora de “joc cooperatiu”**: els participants col·laboren contra “el problema”, no entre ells; les regles són senzilles però trobar l’estratègia guanyadora és complex. - **Abandonar la jerga**: cal renunciar als llenguatges especialitzats (tècnics, UX, etc.) i parlar el llenguatge de negoci amb notes adhesives i colors, per fer la sessió inclusiva i efectiva . #### Objectius (“com guanyar el joc”) 1. **Completar tots els camins del procés**: cada branca ha de portar a un estat final estable (System Happy) i/o visible a l’usuari (User Happy) . 2. **Preservar la gramàtica de colors**: `Comanda (blau) → Sistema (rosa) → Esdeveniment (taronja) → Política (lila) → Comanda` no pot haver-hi forats ni inconsistències. 3. **Resoldre tots els “hotspots”**: cada dubte, risc o variació es marca amb un adhesiu groc per tornar-hi després; el joc acaba quan no en queda cap obert . 4. **Stakeholders raonablement satisfets**: maximitzar el valor per a totes les parts, fins i tot en camins “negatius” (anul·lacions, reemborsaments), marcant benefici o fricció amb notes verdes i vermelles . #### Dinàmica de sessió - **“Dispara i arregla”**: primer es traça ràpidament un flux bàsic fins a l’estat final, sense bloquejar-se en detalls; després es col·loquen hotspots i es revisen punt per punt. - **Iteració i refinament**: els esdeveniments i accions es reescriuen tantes vegades com calgui per guanyar precisió, i s’utilitzen les polítiques (lila) per formalitzar regles de negoci obligatòries. - **Inclusivitat i rapidesa**: amb definicions “fuzzy” i eines visuals, es fomenta la participació de perfils molt diversos sense entrar en discussions sagnants sobre notació . **En conjunt**, el capítol proposa convertir la sessió de modelatge de processos en un joc cooperatiu amb regles clares, objectius mesurables i mecanismes per gestionar branques, conflictes i valor, assegurant que tothom col·labori de manera efectiva cap a una solució compartida. ### C14 - Process Modelling Building Blocks En el capítol **14. Process Modeling Building Blocks** s’expliquen els elements bàsics (fuzzy building blocks) que s’utilitzen durant les sessions d’EventStorming de modelatge de processos, amb l’objectiu de facilitar la conversa i l’exploració col·laborativa sense quedar encallats en definicions excessivament formals. Els punts principals són: 1. **Fuzziness vs. Precision** - Els blocs (notes de colors) es defineixen de manera intencionadament difusa per no crear barreres d’entrada a persones no familiaritzades amb notacions formals. Es prioritza la **conversa inclusiva** i la **visibilitat ràpida** sobre la precisió inicial. 2. **La “Imatge que Ho Explica Tot”** - S’ofereix un esquema visual de referència (amb els colors i formes de notes) com a llegenda visible durant tot el taller. Aquesta “imatge” resumeix els tipus de blocs (esdeveniments, comandes, actors, sistemes, polítiques, read models, valor, hotspots). 3. **Esdeveniments (stickies taronges)** - Elements centrals del relat: sempre en passat, representen transicions d’estat. Es poden originar per interaccions d’usuari, sistemes externs, esdeveniments temporals o reaccions en cadena. 4. **Comandes/Accions/Intencions (stickies blaves o violetes)** - Representen decisions o accions iniciades per actors o polítiques. Capturen la intenció que provoca l’esdeveniment i ajuden a identificar punts on el procés rep input actiu. (índex) 5. **Actors i Sistemes (stickies liles i grisos)** - Visualitzen rols humans i components externs que interactuen amb el procés. Permeten explorar perspectives i fronteres del sistema sense confondre’ls amb esdeveniments o comandes. 6. **Polítiques (stickies verd fosc)** - Regles reactives “whenever… then…” que connecten esdeveniments amb comandes. Són llocs on s’ha de discutir obligatòriament la lògica de negoci (manual o automàtica). 7. **Read Models / UI Sketches (stickies verd clar o grocs)** - Capturen les necessitats d’informació per a la presa de decisions o disseny d’interfícies. Ajuden a verificar supòsits i definir quins dades i visualitzacions són necessàries. 8. **Valor (stickies verdes petites)** - Identifiquen friccions i oportunitats d’incrementar valor per als actors. Utilitzades per aprofundir en “monedes” o mètriques que realment importen. (capítol objectiu) 9. **Hotspots (stickies fúcsia)** - Marcadors de temes pendents, objeccions o punts crítics que cal abordar més endavant (“smart procrastination”). Es redueixen progressivament fins arribar a zero per completar el model. En resum, aquest capítol proporciona la “gramàtica de colors” i les convencions mínimes per al procés de modelatge de processos amb EventStorming, amb l’èmfasi en la conversa i la iteració ràpida, deixant la precisió per a etapes posteriors. ### C15 - Process Modelling game strategies En el capítol 15, “Process modeling game strategies”, s’exposen tàctiques avançades per conduir amb èxit una sessió d’EventStorming orientada al modelat de processos: **1. Kicking-off (Inici de la sessió)** - **Framing the problem**: Visualitzar el marc esperat (espai de treball, longitud del “paper roll”, espai abans del trigger…) per anticipar esdeveniments i precondicions inesperades . - **Obertures (Opening moves)**: Tres estratègies per començar: - **Des de l’inici**: anar pas a pas des del trigger fins a l’event final. Reflecteix el relat natural però tendeix a explotar ramificacions (“what-ifs”) que caldrà gestionar amb “rush to the goal” . - **Des del final (reverse narrative)**: definir primer els resultats desitjats i treballar cap enrere aplicant la gramàtica de color per trobar el camí mínim . - **“Make a little mess”**: llençar inicialment només esdeveniments (“orange stickies”), després aplicar la gramàtica de colors per estructurar el flux . **2. Mid-game strategies (Estratègies de mig joc)** - **Reconèixer el “rabbit hole”**: parar atenció a signes de dispersió (participants que deixen de mirar el model, iniciatives “Sí, però si…”) i fer una pausa per tornar amb energia . - **Mantenir-ho tot visible**: tot allò que es discuteix ha d’aparèixer en stickies; els _hotspots_ serveixen per registrar ramificacions o decisions ajornades sense oblidar-les . - **Rush to the goal**: traçar ràpidament un camí bàsic fins al resultat, sense aturar-se a polir detalls, i després inundar el model de _hotspots_ per millorar incrementalment . **3. Dinàmiques d’equip** - **Split & Merge**: si les personalitats xoquen, dividir l’equip en subgrups que treballin en paral·lel amb la mateixa gramàtica de color i després fusionar models per contrastar solucions . - **Equilibri de personalitats**: el facilitador ha de vetllar perquè tothom tingui veu, evitant dominis i garantint que tot es mantingui visible. **4. Com saber quan hem acabat? (Condicions de victòria)** La sessió es considera satisfactòria quan: 1. Tots els camins del procés queden completats i aboquen a un estat estable. 2. La **gramàtica de color** no té forats ni incoherències. 3. S’han tancat tots els **hotspots**. 4. Tots els **stakeholders** estan “raonablement” satisfets . Aquestes estratègies ajuden a manejar la complexitat i a fer que les sessions de Process Modeling siguin efectives, inclusives i orientades al valor. ### C17 - Running a Design-Level EventStorming **Capítol 17: Executant un Design-Level EventStorming** **1. Àmbit i objectius** - **Diferent del Big Picture**: aquí partim d’un comprès col·lectiu del domini, però ens concentrem en dissenyar una o més solucions concretes per a un procés o característica clau; el taller acaba quan tenim un **candidat de disseny robust**, no simplement quan aprenem o descobrim punts calents . - **Participants**: equip de desenvolupament i experts de negoci; el format no està orientat a “tots” (com en Big Picture), sinó als qui faran i validaran la solució. **2. Què fer amb l’arxiu Big Picture** - **Reprendre’l**: aprofitar els events mapejats i els punts calents identificats. - **Començar de zero**: quan volem màxima llibertat i espai, i no cal referenciar contínuament l’exploració prèvia. **3. Fonts dels Domain Events** 1. Accions d’usuari 2. Sistemes externs 3. Esdeveniments temporals 4. Reaccions automàtiques a altres esdeveniments **4. Descobrint agregats** - **Postposar el nom**: primer identifiquem responsabilitats (“Quina és la finalitat? Quina informació necessita?”), després posem nom. - **Procés iteratiu**: definim primer la “unitat de consistència” i només després triem un nom que reflecteixi missió i dades. **5. Quan acabem?** - Quan, “aplanat” el diagrama de flux de Domain Events → Commands → Agregats, tinguem un **flux consistent** que cobreixi tota la història de l’usuari i compleixi els requisits de negoci . Aquests són els passos pràctics i els criteris bàsics per guiar un taller de nivell de disseny amb *EventStorming*, assegurant que l’esforç col·laboratiu generi un model de solució sòlid i coherent abans de passar a la implementació. ### C18 - Design-Level modeling tips Aquí tens un resum dels principals consells per al Design-Level EventStorming tal com s’exposen al capítol “Design-Level modeling tips”: - **Fes visibles les alternatives** Quan hi hagi diverses solucions possibles, posa-les totes sobre la taula amb notes separades. Així podreu comparar-les directament i escollir amb més claredat quina abordar més endavant . - **Tria més tard** No intentis decidir-ho tot al primer cop. Deixa algunes decisions obertes per més endavant, quan tingueu més context i visibilitat de l’impacte real de cada opció . - **Centra’t en un problema concret** Si el flux esdevé massa extens o confús, defineix clarament quin subflux o cas d’ús (el “hot spot”) és el que realment voleu dissenyar ara, i enfoca-hi tota la sessió . - **Reescriu un i altre cop** A mesura que aprofundiu en el disseny, anireu refinant els esdeveniments i comandes. No tingueu por de llençar i reescriure les notes; és molt més barat ara, en paper, que no pas en codi produït . - **Amaga la complexitat innecessària** Un cop hagis resolt un aspecte complex intern, no cal que el model extern (per a usuaris o altres equips) mostri tots els detalls. Dóna’ls una visió simplificada que només exposi el mínim necessari . - **Difereix el nom de l’Aggregate** Fins que no tinguis clares les responsabilitats i la informació que ha de gestionar un agregat, evita justificar-lo amb un nom. Primer defineix què fa i quina informació utilitza, i només aleshores pensa un nom coherent . Aquests consells t’ajudaran a mantenir la col·laboració fluida, a evitar discussions prematures sobre noms i a anar convergint cap a una solució efectiva de manera iterativa i transparent. ### C19 - Building Blocks En aquest capítol es presenten els **blocs de construcció** bàsics per al modelatge de processos amb EventStorming, així com els seus rols i convencions de color: 1. **Domain Events (taronja)** - Representen fets que ja han passat (“Customer Paid”, “Order Shipped”). - Sempre en passat i escrits amb verb + subjecte. Són el **ànima** del model, ja que descriuen el flux real. 2. **Commands (blau)** - Són accions o intencions iniciades per actors o polítiques (“Ship Order”, “Cancel Subscription”). - Cada esdeveniment ha de ser conseqüència explícita d’almenys un command. 3. **Actors & Systems (lila/gris)** - Rols humans (actor, usuari, rol de negoci) o sistemes externs (ERP, passarel·la de pagaments) que emeten commands o consumeixen events. - Ajuda a posar límits clars al procés i a entendre responsabilitats. 4. **Policies (verd fosc)** - Regles reactives “WHEN Event THEN Command” (p. ex. “WHEN Order Overdue THEN Send Reminder”). - Permeten modelar lògica de negoci automatitzada sense dispersar-la en el flux principal. 5. **Read Models / Views (verd clar)** - Necessitats d’informació per a decisions o interfícies (p. ex. “Order Status Screen Updated”). - Indiquen quins **modelats de consulta** haurem de construir posteriorment. 6. **Hotspots (fúcsia)** - Marcadors de dubtes, riscos o punts pendents que cal aprofundir més endavant. - Un cop resolts, s’han d’eliminar tots per donar per complet el model. 7. **Value & Cost (petits verdi/blancs)** - Identifiquen on es crea valor (petits verds) o on s’incorre en cost/fricció (petits blancs). - Faciliten prioritzar millores i enfocar l’esforç en allò que més impacta. Gràcies a aquesta gramàtica de colors i rols, qualsevol equip pot: - **Visualitzar ràpidament** l’estructura del procés. - **Detectar inconsistències** (comandes sense esdeveniments, events sense actors). - **Iterar de forma col·laborativa**, mantenint la conversa centrada i sense perdre punts pendents. ### C20 - Modeling Aggregates En Domain-Driven Design, un **Aggregate** és una unitat de consistència transaccional: un conjunt d’objectes amb estat mutable que, però, sempre han d’exposar un estat coherent com a tot. Aquesta coherència s’aconsegueix imposant **invariants** —regles que mai no poden ser violades. - **Definició d’invariant** > _“El subtotal del carretó de la compra sempre ha de ser la suma de (quantitat × preu unitari) de cada article.”_ Gràcies a aquesta regla, encara que la implementació interna calculi el subtotal al vol o el guardi prèviament en una variable, qualsevol lectura de la propietat `getSubtotal()` serà sempre correcte. - **Propòsit dels Aggregates** - **Encapsulació de comportament**: defineixen un contracte clar amb la resta del sistema; l’única manera de mutar-los és passant per les seves operacions (mètodes públics o “comandes”). - **Lloc únic de la lògica de negoci**: tota validació d’invariants i regles d’estat viu dins de l’Aggregate. Això facilita provar-ne el comportament i evita duplicacions. - **Límit transaccional**: tot canvi en un Aggregate es compromet en una sola transacció, assegurant que no quedi mai en estat parcialment modificat. - **Descobriment d’Aggregates** No hi ha un mètode “mandatori”, però cal buscar **unitats de comportament consistent**, més enllà de simples contenidors de dades. 1. **Evitar obsessionar-se amb l’estructura** de dades (per exemple, agrupar tot allò que mostrarem a pantalla); aquests sovint són Read Models, no Aggregates. 2. **Identificar màquines d’estat**: events i comandes que modifiquen l’estat de manera coherent. 3. **Agrupar esdeveniments i comandes segons responsabilitats**: enquadrat al voltant de l’entitat que ha de garantir la consistència. 4. **Postposar el nom** fins tenir clara la responsabilitat i la informació que cal mantenir accessible. - **Aggregates com a màquines d’estat** Els Aggregates es veuen millor com a **state machines**: cada comanda provoca un event—una transició—i l’Aggregate n’ha de garantir les regles (invariants) abans d’emetre’l. Això els converteix en el millor lloc per col·locar tota la lògica que asseguri la integritat del domini. En resum, **Modeling Aggregates** us ajuda a: 1. **Definir clars límits transaccionals** on codificar totes les regles de negoci. 2. **Encapsular invariants** dins de classes que actuen com a causants únics d’estat. 3. **Descobrir-los** a partir de comportaments consistents i no pas a partir de la pura estructura de dades. Aquest enfocament garanteix que, en el moment d’implementar, qualsevol acció sobre un Aggregate mantingui sempre el sistema en un estat vàlid i coherent. ### C21 - Event Design Patterns El capítol 21, “Event Design Patterns”, se centra en com identificar i modelar adequadament els esdeveniments de domini durant l’EventStorming. A continuació teniu els punts principals: **1. Estratègies de descoberta (Discovery strategies)** - Els esdeveniments de domini més rellevants acostumen a tenir un **“high fan-out”**, és a dir, són produïts per una única font però consumits per molts receptors (per exemple, un **TicketSold** que actua sobre capacitat de sales, càlcul de catering, programes de fidelització, notificacions al formador, etc.) . - Durant l’exploració, convé **“escoltar cap avall”**, és-a-dir, preguntar als equips consums (departaments que rebran l’esdeveniment) què necessiten saber, per enfocar la selecció dels esdeveniments clau. **2. Esdeveniments compostos (Composite Domain Event)** - Quan diversos esdeveniments tècnics o de baix nivell representen junts un fet de negoci únic, podem agrupar-los en un **esdeveniment compost**. Això evita dispersar la lògica en massa missatges i ajuda a mantenir el model més net i comprensible . - Els esdeveniments compostos ens permeten ser **redundants intencionadament** per aclarir la semàntica del domini quan cal, sempre seguint la Wording Obsession de DDD per millorar la comunicació. **3. Objectius del capítol** - Posar en pràctica la **obsessió per la terminologia** de DDD, assegurant noms precisos i coherents amb el llenguatge ubiqüitari. - Entendre que, de vegades, és **necessària certa redundància** per fer els esdeveniments més significatius. - Superar punts morts típics en el modelatge basat en esdeveniments posant èmfasi en el cost-benefici de crear un esdeveniment addicional vers recapitalitzar en massa detalls tècnics. - Tancar el bucle amb els patrons d’integració ja descrits a l’“Enterprise Integration Patterns” per assegurar la correcta propagació i transformació dels esdeveniments entre sistemes . En resum, el capítol 21 ofereix eines pràctiques per **descobrir** els esdeveniments realment útils (els de “high fan-out”) i per **dissenyar-los**—incloent-hi la possibilitat d’**agrupar-los** en esdeveniments compostos—sempre alineant la nomenclatura amb el llenguatge del domini. ### C22 - From paper roll to working code Aquest capítol descriu com **traslladar** els resultats d’un EventStorming—el mural amb esdeveniments, comandes, pol­í­tiques i agregats—cap a una base de codi real i executable. A grans trets: 1. **Identificar Artefactes Clau** - **Domain Events** → classes immutables (`record` o `data class`) amb tots els camps necessaris. - **Commands** → objectes de petició que encapsulen intencions, sovint amb validacions bàsiques al constructor. - **Aggregates** → ar­rel d’agregat cadascuna amb mètodes públics que reben Commands i generen Events. 2. **Esquelet de Codi Automàtic** - Generar amb plantilles (templates) el codi base per a cada esdeveniment i comanda sobre la base del brainstorming: fitxers `.java`/`.cs` amb signatures buides. - Afegir tests buits (test-driven) per a cada invariant identificat a l’EventStorming. 3. **Implementar el Flux Bàsic** - Lògica a l’**Application Service** (o Use Case) que: 1. Carrega l’Aggregate des del repositori. 2. Invoca el mètode corresponent amb el Command. 3. Persisteix els Events generats (Outbox) i després publica. 4. **Persistència i Publicació** - **Outbox Pattern**: desar Events en taula/col·lecció juntament amb l’agregat. - **Relay** o **Poller** que llegeix l’Outbox i publica al **message bus** (Kafka, RabbitMQ…). 5. **Projeccions i Read Models** - Subscriure’s als Domain Events per omplir taules o índexs de **Read Models** (CQRS), definint handlers que actualitzen l’estat de consulta. - Garantir la **idempotència**: cada handler comprova si l’event ja ha estat processat. 6. **Testing i Qualitat** - **Unit tests** per a mètodes d’Aggregate que validin invariants. - **Integration tests** simulant la persistència Outbox → publicació → update de Read Models. - **Contract tests** per assegurar que el published language coincideix amb el model esperat pels consumidors. 7. **Iteració i Refinament** - Cada nova branca afegida al mural es tradueix en un nou test/Command/Event/handler. - S’aprofita el **paper roll** com a referència visual per cobrir tots els camins en el codi. 8. **Documentació Vinculada** - Enllaçar cada fitxer de codi amb l’sticky corresponent (o amb un ID de mural) per mantenir rastreig: “Veure EventStorming #E35 per aquest Event”. Amb aquests passos, el **flux de treball** passa de l’alta col·laboració visual de l’EventStorming a un procés sistemàtic de generació, implementació i prova de codi, assegurant que **el que s’ha discutit en el mural acabi sent exactament el que s’executa en producció**. ### C23 - From EventStorming to UserStories ### C24 - C25 - C26 - C27 - C28 ### C29 - Patterns and Anti-Patterns **Patterns (Bones pràctiques)** 1. **Add More Space** Proporciona sempre suficient superfície per al model: no deixis que la falta d’espai talli la visió global del procés. 2. **Be the Worst** Si ningú s’atreveix a començar, posa a propòsit una nota equivocada: això trenca el gel i anima tothom a corregir-la. 3. **Conquer First, Divide Later** Fes un “ataque massiu” al problema abans de refinar i fragmentar: primer explora de manera ampla, després extreu i delimita subprocés. 4. **Do First, Explain Later** Millor provar sobre el paper abans d’explicar teories: l’experiència directa genera curiositat i preguntes reals. 5. **Fuzzy Definitions** Accepta definicions inicials imprecises per fer confluir totes les perspectives; la precisió vindrà en rondes posteriors. 6. **Guess First** Incita els assistents a endevinar el flux abans d’escoltar l’expert: això fa visibles els malentesos i focalitza les explicacions. 7. **Hotspot** Marca àrees de dubte o conflicte amb “stickies” de color (habitualment lila) per posteriors investigacions. 8. **Icebreaker** Quan el mur estigui buit, inicia amb un aliat o el facilitador mateix perquè tothom vegi com es fa. 9. **One Man One Marker** Proporciona un rotulador per persona per eliminar “colls d’ampolla” i maximitzar l’escriptura paral·lela. 10. **Poisonous Seats** Treu les cadires en tallers curts per fomentar l’intercanvi ràpid i evitar grups aïllats. 11. **Visible Legend** Mantén a la vista un llegendari senzill (colors i formats) perquè tothom recordi la notació sense pensar-hi. 12. **Manage Energy / Make Some Noise** Intervé quan el ritme baixi, encoratjant interaccions més dinàmiques i renovant l’atenció. 13. **Money on the Table** No oblidis d’incloure qüestions econòmiques (“stickies” grogues) per no perdre de vista l’impacte financer. **Anti-Patterns (Errors a evitat)** 1. **Ask Questions First** Evita convertir-ho en una sessió de preguntes-respostes un a un: això serialitza i empobreix el flux. 2. **Big Table at the Center** Un tauló gran amb cadires fa que la gent triï bàndols i limiti la col·laboració. 3. **Committee** Formar petits comitès per consensuar cada nota és lent i filtra idees divergents. 4. **Divide and Conquer** Dividir de seguida talla l’abast de l’exploració i exclou informació rellevant. 5. **Do the Right Thing / Dungeon Master / Follow the Leader / Human Bottleneck / Karaoke Singer** Permetre que una sola veu dirigeixi impedeix el ritme paral·lel i aixafa perspectives. 6. **Precise Notation** Imposar notacions formals exclou els no-experts i redueix la participació. En conjunt, aquest capítol ofereix un catàleg de micro-estratègies per mantenir alta la velocitat i l’energia del taller, maximitzar la diversitat de contribucions i evitar els bloquejos col·lectius típics en processos de modelatge col·laboratiu. ### C30 - Rush to the goal ### C31 - Anti-patterns El capítol 31 (“Anti-patterns”) d’Introducing EventStorming fa una llista de comportaments i configuracions que, tot semblant sentit comú, dificulten la dinàmica i l’eficàcia d’un taller EventStorming. A continuació en tens un resum dels principals anti-patterns descrits: **1. Ask Questions First** Iniciar sempre preguntant a un sol expert converteix la sessió en un diàleg un a un, amb baixa paral·lelització, risc excessiu d’entrar en detalls òbvies i poc throughput de generació d’idees . **2. Big Table at the Center of the Room** Una taula gran al mig obliga els participants a asseure’s segons aliances implícites i dificulta la mobilitat i la interacció lliure . **3. Committee** Formar petits comitès per consens limita el ritme (“one topic at a time”), filtra opcions i tendeix al biaix de confirmació, reduint l’exploració paral·lela . **4. Divide and Conquer** Tallar el problema massa aviat redueix l’abast de l’exploració; en comptes de dividir abans, cal “conquer first, divide later” per capturar tot l’ecosistema . **5. Do the Right Thing** Donar per fet què s’ha de fer o com fer-ho (“Sé el bo”), bloqueja la creativitat i la descoberta col·lectiva . **6. Dungeon Master** Consolidar el control en una sola persona (“el senyor del taller”) frena la participació i la diversitat d’idees. **7. Follow the Leader** Permetre que un participant marqui sempre el ritme o el focus, en comptes de fomentar l’autoorganització i el flux simultani. **8. Human Bottleneck** Dependre d’una sola persona per escriure o capturar idees crea coll d’ampolla i desconnecta els qui no participen activament. **9. Karaoke Singer** Que algú monopolitzi l’atenció parlant sense parar desvia l’atenció de l’objectiu col·lectiu. **10. Precise Notation** Imposar notacions formals (UML, etc.) exclou participants no especialistes; millor notació incremental i visible legend per minimitzar la càrrega cognitiva . **11. Religion War** Entrar en discussions dogmàtiques sobre eines o metodologies en lloc de centrar-se en l’exploració del domini. **12. The Spoiler** Portar documents o especificacions prèvies fa que els participants es limitin a recitar el que ja saben, en comptes de descobrir junts, i elimina la “right to be wrong” necessària per a l’aprenentatge . **13. Start from the Beginning** Començar sempre pel primer esdeveniment (extrem esquerre) utilitza malament l’espai i induïx a pensar que no hi ha res anterior, limitant l’abast . **14. The Godfather** Permetre que només uns pocs parlin (“els que manen”) anul·la la riquesa d’idees de la resta i converteix el taller en un “sota la batuta d’un capo”. --- En conjunt, aquests anti-patterns subratllen la necessitat de fomentar: - **Paral·lelisme i diversitat** (més caps pensant alhora) - **Espai i mobilitat lliure** (sense grans taules ni cadirat ficat) - **Notació senzillíssima** (stickies i llegenda visible) - **Dret a equivocar-se** (postergar preguntes crítiques) - **Descentralitzar el control** (tothom amb marcador, tothom participant) D’aquesta manera, EventStorming manté l’energia i l’eficiència necessàries per explorar grans dominis de forma col·laborativa i creativa. ## Quotes <!-- Notable quotes with reference to their page or location --> ## Bibliography > `= this.bibliography` --- ## Tasks <!-- What remains to be done with this note? --> - ## References <!-- Links to pages not referenced in the content --> -