Zurück zum Playbook
BuildQualitätBU-03

Umsetzung gegen den Entscheid prüfen

Erkennt Abweichungen zwischen dem ursprünglichen Produktentscheid, der Story und dem gelieferten Code, bevor sie in die Produktion gelangen.

ProduktstatusVerfügbar

Kontext rein4 benötigte InputsPRD und Jira-Story · Akzeptanzkriterien · Pull Request oder aktueller Code
TransformationQA + QA Agent + Architecture AgentCode Analysis · Atlassian · Local Files
ErgebnisAbgleich-Review mit Erfüllt oder Nicht erfüllt je Anforderung, Abweichungen und empfohlenen Korrekturen.Artefakt: Jira-Story

Warum das zählt

Wurde am Ende gebaut, was wir entschieden haben? Entscheid, Spec, Jira-Story und Pull Request werden von einem zugewiesenen Agent verglichen; ein benannter Mensch gibt frei oder fordert Änderungen.

Owner

QA

Mensch + Agent

Beteiligte · Agents

Product ManagerEngineerQA AgentArchitecture Agent

Auslöser

EreignisgesteuertEin Pull Request ist bereit für den Review oder eine gemergte Umsetzung liegt vor.

Benötigter Kontext

JiraPRD und Jira-StoryJiraAkzeptanzkriterienCodePull Request oder aktueller CodeProduct BrainRelevante Entscheide

Optionaler Kontext

Design SystemUI-EntwurfArchitekturArchitekturentscheidCodeTestergebnisse und Abdeckung

Skills

Code AnalysisAtlassianLocal Files

Methoden in dieser Activity: Spec-Konformitätsprüfung · Test-Impact-Analyse riskanter Bereiche

Schritte

  1. 1Die Änderung zusammenfassen und mit Absicht, Story und Akzeptanzkriterien vergleichen.
  2. 2Den betroffenen Code und die Testabdeckung riskanter Bereiche prüfen.
  3. 3Abweichungen erkennen und gewollte Änderung von Fehler unterscheiden.
  4. 4Korrekturen oder eine Kontext-Aktualisierung vorschlagen.

Ergebnis

Abgleich-Review mit Erfüllt oder Nicht erfüllt je Anforderung, Abweichungen und empfohlenen Korrekturen.

Artefakte

Aktualisiert: Jira-Story, Product Brain

So sieht gut aus

  • Jede Abweichung verweist auf eine Anforderung oder einen freigegebenen Entscheid.
  • Gewollte Änderung ist von Fehler getrennt.
  • Abdeckungslücken in riskanten Bereichen sind benannt.
  • Das Urteil ist eindeutig.

Freigabe

Ein benannter Reviewer gibt wesentliche Umfangsänderungen oder Release-Blocker frei.

Ziel

GitHubJiraProduct Brain

Meist als Nächstes

Menschen und Agents arbeiten mit demselben Product Brain. Der Owner bleibt verantwortlich. Zugewiesene Agents bereiten vor und prüfen. Ein benannter Mensch gibt an der Freigabe frei.

Vertiefung im AI PM Lab

Beiträge, die das Denken hinter dieser Activity erklären.

Zeigt uns genau, wie eure Produktarbeit heute abläuft.

Dreissig Minuten mit einem Founder. Wir vergleichen euren Prozess mit dem Playbook und wählen die erste Activity für euer Jira und euer Repo.