Hvem kan lage en ADR?

Tenk på områder som bestemte personer, bestemte roller, bestemte team eller bestemte avdelinger. Vurder også om det finnes personer, roller, team eller avdelinger som kan bestille en ADR, det vil si be om en som noen andre skal skrive.

Eksempelsvar: Alle i organisasjonen vår som har lest README-siden om arkitekturbeslutningslogger, kan foreslå en ADR, det vil si at personen kan begynne å skrive den og dele den med teamet.

Hva berettiger å ta opp en ADR?

Tenk på områder som organisasjonens arbeidsmåter i team, strukturen i programvaresystemet, koordinering på tvers av team, langsiktig vedlikeholdbarhet, eksterne grensesnitt, hvem du vil at skal ha nytte av den, og lignende.

Eksempelsvar: Vi vil lage en ADR når vi vil at framtidige utviklere skal forstå «hvorfor» bak det vi gjør.

Hva berettiger å la være å ta opp en ADR?

Tenk på områder som beslutninger som ikke handler om arkitektur, eller som er bittesmå, for eksempel med minimal risiko, selvstendige eller begrenset til én utvikler, eller som allerede er fullt dekket andre steder, for eksempel av standarder, retningslinjer eller dokumentasjon, eller som er midlertidige, for eksempel omveier, konseptbevis eller eksperimenter.

Eksempelsvar: Vi hopper over en ADR når en beslutning er begrenset i omfang, tid, risiko og kostnad, eller allerede er dekket andre steder.

Hva er livssyklusen til en ADR?

Tenk på områder som opprettingsprosessen, undersøkelsesprosessen, beslutningsprosessen, implementeringsprosessen og avviklingsprosessen. Tenk på hvordan du følger livssyklusen til ADR-en over tid, for eksempel hvordan du flytter ADR-en fra én tilstand til den neste, og hvordan du formidler dette til interessentene.

Eksempelsvar: Vi vil at en ADR skal ha fem livssyklustrinn: Oppstart → Undersøkelse → Evaluering → Implementering → Vedlikehold → Avvikling.

Hva er kriteriene for trinnene i livssyklusen til en ADR?

Tenk på områder som akseptkriterier for en ADR, det vil si hvordan du vet at den er god nok til å gå videre fra ett livssyklustrinn til det neste. Er problemet tydelig formulert? Er alternativene vurdert? Er avveiningene godt nok forstått og dokumentert? Er all relevant kontekst på plass? Er alle relevante interessenter involvert? Er alle tilbakemeldinger innarbeidet?

Eksempelsvar: Vi vil at interessentene skal stemme over en ADR når det aktive teamet har 1) fullført undersøkelsen, 2) fullført evalueringen, 3) publisert ADR-forslaget til interessentene med en forespørsel om kommentarer og en tidsramme på én uke, og 4) alle kommentarer fra interessentene er innarbeidet og besvart.

Hvilke roller og ansvar samhandler med en ADR?

Tenk på roller som forslagsstiller, undersøker, evaluator, gjennomgåer, godkjenner, vedlikeholder og lignende. Tenk på ansvar som kommunikasjon med interessenter, å sikre at forventningene oppfylles, deling på nettstedet eller intranettet, og å gjennomgå arbeidet jevnlig, og særlig når relevante endringer skjer.

Eksempelsvar: Vi vil at hver ADR alltid skal ha en primær kontaktperson, en sekundær kontaktperson og et ansvarlig team. De har ansvar for kommunikasjon, publisering, vedlikehold, jevnlig gjennomgang minst én gang i året og eventuell avvikling ved behov.

Hvordan samhandler styring med en ADR?

Tenk på områder som organisasjonens arbeidsmåter, eventuelle spesielle behov for etterlevelse, for eksempel av juridiske eller personalmessige forhold, og hvordan du vil håndtere konsensus versus konflikt versus eskalering. Finnes det områder, personer eller team som kan ha mer innflytelse enn andre når det gjelder en ADR, for eksempel ved at de kan godkjenne den, stemme over den eller nedlegge veto mot den?

Eksempelsvar: Styringen av en ADR følger denne prioriteringsrekkefølgen: administrerende direktør (CEO), teknisk direktør (CTO), juridisk direktør (CLO), teamet som implementerer en ADR og ekspertene på teamet som kan mest om AD-en. Ingen andre har styring, med mindre det er beskrevet i ADR-en.

Hvilke prinsipper samhandler med en ADR?

Tenk på områder som organisasjonens arbeidsmåter, blant annet å bevege seg raskt versus langsomt, for beslutningskonsensus versus beslutningskonflikt, for risikopreferanser versus sikkerhetspreferanser, offentlig diskusjon versus privat diskusjon og lignende.

Eksempelsvar: Vi bruker lederprinsippene handlingsorientering, uenig-og-forplikt (disagree-and-commit), 70 % sikre anslag er gode nok for beslutninger som lett kan omgjøres og lett kan isoleres, og åpne arbeidsmåter med unntak av konfidensiell informasjon som beskrevet i organisasjonens taushetsavtale.