2 napos, helyszíni workshop tech csapatoknak
A fő cél: csapatként jó architekturális döntéseket hozni
ADR-ek és requirement tisztázás – azt szállítsuk, amire az ügyfélnek valóban szüksége van
Az ADR itt nem adminisztráció, hanem melléktermék: a lényeg, hogy a csapat közösen, tudatosan és következetesen hozzon architekturális döntéseket.
1. nap – Döntések születése (és elrontása)
Cél: megtanulni, hogyan hozzunk csapatként jó architekturális döntéseket; az ADR-dokumentálás ennek következménye, nem célja.
09:00–10:15 - A láthatatlan döntések problémája
Közös nyelv kialakítása arról, miért tűnik el a döntések mögötti indoklás.
- „Ki döntött erről?” mint klasszikus projektvégi kérdés.
- Tipikus tünetek: „Ez mindig is így volt”, „A korábbi csapat döntése”, „Most már nem nyúlunk hozzá”.
- ADR mint szervezeti memória, konfliktusmegelőzés és onboarding-gyorsító.
Gyakorlat: Hozzatok egy valós döntést a saját projektből, amire már senki nem emlékszik pontosan.
10:30–12:30 - Mi az ADR valójában (és mi nem)
A jó ADR könnyűsúlyú, mégis használható szerkezetének begyakorlása.
- ADR nem design doc, nem ticket komment, és nem utólagos magyarázkodás.
- A jó ADR elemei: Context, Decision, Options considered, Consequences (jó és rossz).
- Mélységi szintek: 5 soros micro-ADR, normál ADR, „architectural line in the sand”.
Gyakorlat: Ugyanarra a döntésre 3 különböző mélységű ADR-t írunk.
13:30–15:00 - Mikor kell ADR, és mikor nem?
Döntési keret kialakítása, hogy elkerüljük az ADR mindenhez és az ADR soha szélsőségeit.
- Döntési mátrix: visszafordítható/visszafordíthatatlan, lokális/rendszerszintű, olcsó/drága változtatás.
- YAGNI vs ADR: mikor dokumentálunk előre, és mikor utólag.
- Antipatternök: ADR mindenhez, ADR soha.
Gyakorlat: Backlog elemek besorolása: ADR kell / ADR nem kell / ADR majd később.
15:15–16:30 - Felelősség és döntési jogkörök
Egyértelmű döntési felelősség és jóváhagyási rend kialakítása.
- Ki írhat ADR-t, ki hagyja jóvá, és mi történik konszenzus hiányában.
- ADR mint döntési szerződés a csapat és az érintettek között.
Gyakorlat: Döntési folyamat megrajzolása: ötlet -> vita -> ADR -> implementáció -> review.
2. nap – ADR-ek egy élő rendszerben
Cél: a közös döntéshozatali működés beépítése a napi munkába, ahol a dokumentálás természetes melléktermék.
09:00–10:30 - Rendszerépítés ADR-ekkel
Döntések gyakorlása időnyomás alatt, valós kompromisszumok mentén.
- Fiktív, de valósághű projekt döntései: monorepo vs multirepo, sync vs async, adatbázis-választás, auth megoldás.
- Minden komolyabb döntéshez ADR készül időnyomás alatt.
- Tanulság: mitől lassít, és mitől gyorsít valójában.
10:45–12:00 - ADR-ek életciklusa
Megtanulni, hogyan marad az ADR élő dokumentum, nem pedig archív emlék.
- Életciklus: Draft -> Accepted -> Superseded -> Deprecated.
- Hogyan marad naprakész, és hogyan nem lesz belőle dokumentumtemető.
- A superseding ADR nem szégyen, hanem evolúció.
Gyakorlat: Egy korábbi ADR megdöntése, és új ADR írása rá.
13:00–14:30 - ADR + delivery flow
Az ADR beágyazása a napi szállítási folyamatba.
- Kapcsolódás tickethez, PR-hez és release-hez.
- Minimum integráció: ADR link a PR-ben, ADR ID a commitban.
- Mikor nem kell gate-ként működnie.
Gyakorlat: Mini design: csapat-specifikus ADR workflow megtervezése.
14:45–16:00 - AI, agentek és ADR
Az AI hasznos és káros használatának elkülönítése ADR környezetben.
- ADR mint prompt input és intézményi memória az agentek számára.
- Mikor van értelme: döntési összefoglalás, hatáselemzés.
- Mikor nincs: „Írjuk meg az ADR-t az AI-val”.
Gyakorlat: Egy ADR-ből onboarding összefoglaló és „miért ilyen a rendszer?” válasz készítése.
16:00–16:30 - Zárás: mit változtatunk hétfőtől?
Közös minimum szabályrendszer kialakítása, ami azonnal bevezethető.
- ADR policy v0: mikor kötelező, hol él, ki felel érte.
- 1 dolog, amit elkezdünk, és 1 dolog, amit abbahagyunk.
- Workshop retrospektív.
Mit visztek haza hétfőtől
A workshop végére lesz egy közös döntéshozatali működésmódotok, amelyben az ADR-ek automatikusan, hasznos melléktermékként születnek.
- Döntési mátrix: hogyan választunk opciók között, és mikor kell formális döntés.
- Egyszerű felelősségi modell: ki készít elő, ki review-z, ki dönt.
- Életciklus-szabályok: mikor supersede-elünk, mikor deprecate-elünk.
- PR és commit minimum integrációs szabályok.
