Files
management/verfahren/aar-vorlage.md
T

46 lines
1.5 KiB
Markdown
Raw Normal View History

# AAR — <Vorhaben> <Issue-Referenz>
**Datum:** JJJJ-MM-TT · **Host/Stack:** … · **Auftrag:**
## 1. Ergebnis
Was ist live und verifiziert. Was ist bewusst **nicht** live, und warum.
Diese Trennung steht ganz oben — sie ist die einzige Angabe, die jemand
braucht, der nur eine Zeile liest.
## 2. Befunde
| # | Befund | Schwere | Status |
|---|---|---|---|
| 1 | … | HIGH / MEDIUM / LOW | abgefangen / behoben / notiert · Issue |
Schwere nach Auswirkung, nicht nach Aufwand. Zu jedem Befund gehört, **wie er
sichtbar wurde** — falls das nicht offensichtlich ist, siehe Abschnitt 4.
## 3. Verdachtsfälle mit Entwarnung
Was geprüft und **nicht** bestätigt wurde, mit dem Messwert. Genauso wichtig
wie die Befunde: verhindert, dass dieselbe Vermutung beim nächsten Mal erneut
Zeit kostet.
## 4. Was die Befunde ermöglicht hat
Die Methode, nicht die Chronologie. Wenn ein Befund nur durch eine bestimmte
Prüfung sichtbar wurde, gehört genau die hierher — das ist der Teil, der beim
nächsten Deploy wiederverwendbar ist.
## 5. Offen
Was bleibt, wer entscheidet, was blockiert. Mit Issue-Referenz statt
wiederholtem Inhalt.
---
Regeln:
- Nicht verifizierte Aussagen als solche kennzeichnen — eine Vermutung, die wie
ein Befund aussieht, kostet später mehr Zeit als sie spart (Konvention aus
der [README](../README.md)).
- Zahlen statt Adjektive. „Viele Alarme" ist keine Angabe, „126 CRITICAL" ist eine.
- Kurz. Ein AAR, der nicht gelesen wird, hat keinen Wert.