methodatlas
Session Builder

Meine Session planen

Plane einen konkreten Arbeitsblock mit Agenda, Rollen, Vorbereitung und kopierbarem Ergebnisartefakt.

Async-Arbeitslauf24 bis 72 hasynchronADR File

Session: Architecture Decision Record

Der Plan verteilt Vorbereitung, Review und Ergebnisarbeit über einen asynchronen Arbeitslauf. Die Eingaben fließen direkt in Session Brief und Arbeitsartefakt.

Automatisch abgeleitet

Async-Arbeitslauf mit 1-3. Der Plan nutzt die vorhandene Methodenlogik und das Runsheet.

Runsheet
Beteiligungslogik
Teamrunde, gemeinsames Arbeiten und Alignment

Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

Ergebnislogik
Artefakt fertigstellen

Die Session arbeitet direkt auf ADR File hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

  1. 1

    Brief vorbereiten

    15-30 min

    Arbeitsfrage, Input, Zielartefakt und Reviewfrist für Architecture Decision Record vorbereiten. Verlinke relevante Daten, Quellen und bestehende Artefakte.

    OwnerSession Brief
  2. 2

    Asynchron bearbeiten

    24 bis 72 h

    Teilnehmende arbeiten die Methode entlang der Vorlage durch. Fokus: Beiträge direkt am Artefakt ergänzen, Annahmen markieren und Belege verlinken.

    TeilnehmendeADR File
  3. 3

    Review bündeln

    20-30 min

    Kommentare, Widersprüche und offene Fragen clustern. Unklare Punkte als Entscheidungen, Risiken oder Follow-ups einsortieren.

    FacilitatorReview Notes
  4. 4

    Artefakt finalisieren

    15-30 min

    Eingearbeitete Version erstellen, Status setzen und nächsten Review oder Entscheidungspunkt terminieren.

    OwnerDecision Log
  5. 5

    Artefakt veröffentlichen

    10 min

    Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.

    OwnerADR File
Nutzbares Artefakt

Session Brief

Für Einladung, Board, Ticket, PR-Beschreibung oder Workshop-Notiz.

session-brief.md

Session Brief: Architecture Decision Record

Ziel

Artefakt: ADR File

Arbeitsfrage

Welche Architekturentscheidung trifft das Team jetzt, vor welchen Alternativen, und welche Konsequenzen akzeptiert es dafür?

Kontext

Issue-ID oder Trigger; Nummer des nächsten freien ADR im Repo; relevante frühere ADRs zur Verknüpfung; mindestens zwei identifizierte Optionen inklusive Status quo.

Setup

  • Format: Async-Arbeitslauf
  • Dauer: 24 bis 72 h
  • Modus: asynchron
  • Teilnehmende: Ein Decider mit Vor- und Nachname (kein „Team“, keine Gilde); ein bis zwei Reviewer aus den betroffenen Teams; Verfasser optional dieselbe Person wie der Decider.
  • Owner: Ein Decider mit Vor- und Nachname (kein „Team“, keine Gilde)
  • Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
  • Ergebnislogik: Artefakt fertigstellen

Beteiligungslogik

Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

Ergebnislogik

Die Session arbeitet direkt auf ADR File hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

Input

ADR-Template (MADR oder Nygard-Stil) im Repo unter docs/adr/; Markdown- oder Wiki-Editor; Link auf den Issue-Tracker (Linear, Jira, GitHub Issues).

Vorbereitung

Nächste freie Nummer im Verzeichnis prüfen; Branch nach Muster adr/NNNN-kurztitel anlegen; Reviewer im Pull Request oder Linear-Ticket taggen; Reviewfrist als Datum im PR-Beschreibungsfeld benennen.

Agenda

  1. Brief vorbereiten (15-30 min) Owner: Owner Aktion: Arbeitsfrage, Input, Zielartefakt und Reviewfrist für Architecture Decision Record vorbereiten. Verlinke relevante Daten, Quellen und bestehende Artefakte. Output: Session Brief

  2. Asynchron bearbeiten (24 bis 72 h) Owner: Teilnehmende Aktion: Teilnehmende arbeiten die Methode entlang der Vorlage durch. Fokus: Beiträge direkt am Artefakt ergänzen, Annahmen markieren und Belege verlinken. Output: ADR File

  3. Review bündeln (20-30 min) Owner: Facilitator Aktion: Kommentare, Widersprüche und offene Fragen clustern. Unklare Punkte als Entscheidungen, Risiken oder Follow-ups einsortieren. Output: Review Notes

  4. Artefakt finalisieren (15-30 min) Owner: Owner Aktion: Eingearbeitete Version erstellen, Status setzen und nächsten Review oder Entscheidungspunkt terminieren. Output: Decision Log

  5. Artefakt veröffentlichen (10 min) Owner: Owner Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen. Output: ADR File

Abschluss

  • Ergebnisartefakt aktualisieren: ADR File
  • Ablageort, Version und Review-Empfänger festlegen.
  • Owner, nächster Schritt und Reviewtermin festlegen.
Nutzbares Artefakt

Arbeitsartefakt

Vorgefüllter Startpunkt auf Basis der passenden Vorlage.

arbeitsartefakt.md

ADR File: Architecture Decision Record

Arbeitsfrage

Welche Architekturentscheidung trifft das Team jetzt, vor welchen Alternativen, und welche Konsequenzen akzeptiert es dafür?

Kontext

Issue-ID oder Trigger; Nummer des nächsten freien ADR im Repo; relevante frühere ADRs zur Verknüpfung; mindestens zwei identifizierte Optionen inklusive Status quo.

Beteiligte

  • Owner: Ein Decider mit Vor- und Nachname (kein „Team“, keine Gilde)
  • Teilnehmende: Ein Decider mit Vor- und Nachname (kein „Team“, keine Gilde); ein bis zwei Reviewer aus den betroffenen Teams; Verfasser optional dieselbe Person wie der Decider.

Input

ADR-Template (MADR oder Nygard-Stil) im Repo unter docs/adr/; Markdown- oder Wiki-Editor; Link auf den Issue-Tracker (Linear, Jira, GitHub Issues).

Vorlage

ADR-0001: Titel der Entscheidung

Status: proposed Datum: YYYY-MM-DD Decider: Vorname Nachname Trigger: Ticket, Incident oder RFC

Kontext

Welche Situation macht die Entscheidung nötig? Welche Constraints, Quality Attributes oder früheren Entscheidungen sind relevant?

Optionen

Option 1: ...

  • Pro:
  • Contra:

Option 2: ...

  • Pro:
  • Contra:

Entscheidung

Wir entscheiden uns für ...

Konsequenzen

Positive Folgen:

  • ...

Negative Folgen und Risiken:

  • ...

Folge-ADRs oder Tickets:

  • ...

Fertigstellungscheck

  • ADR File ist vollständig genug für Review:
  • Ablageort:
  • Version / Status:
  • Review durch:
  • Nächster Schritt:

Nächster Schritt

  • Ergebnis prüfen
  • offene Fragen markieren
  • Review oder Entscheidung terminieren
Vorlagenbasis

ADR Markdown Template

Vorlage ansehenKompakte Vorlage für Architecture Decision Records im Repository oder Wiki.
markdown

adr-markdown.md

Kompakte Vorlage für Architecture Decision Records im Repository oder Wiki.

ADR-0001: Titel der Entscheidung

Status: proposed Datum: YYYY-MM-DD Decider: Vorname Nachname Trigger: Ticket, Incident oder RFC

Kontext

Welche Situation macht die Entscheidung nötig? Welche Constraints, Quality Attributes oder früheren Entscheidungen sind relevant?

Optionen

Option 1: ...

  • Pro:
  • Contra:

Option 2: ...

  • Pro:
  • Contra:

Entscheidung

Wir entscheiden uns für ...

Konsequenzen

Positive Folgen:

  • ...

Negative Folgen und Risiken:

  • ...

Folge-ADRs oder Tickets:

  • ...
Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu ADR File.
  • Idealerweise im Code-Repository neben dem betroffenen Bereich, damit Entscheidung und Implementation zusammen versioniert werden; Owner ist der Decider; angenommene ADRs werden nicht editiert. Änderungen entstehen als neuer ADR, der den alten als `superseded by NNNN` markiert.
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.
SteckbriefRunsheet