Zurück zum Playbook
Build & VerificationBV-01

Eine Code-Änderung reviewen

Prüft den tatsächlichen Änderungsumfang und die Systemwirkung und trennt belegte Probleme von optionalen Präferenzen.

ProduktstatusVerfügbar

Input3 benötigte InputsVollständiger zugewiesener Diff an der exakten Revision · Beabsichtigtes Verhalten und Akzeptanzkriterien · Fokus der Initiative und freigegebene Product-Brain-Leitlinien
SkillsReview implementation against the ticket · Prepare task context · Review an artifact against agreed criteriaEngineer + Software Engineer Agent
ErgebnisReview-Urteil pro Akzeptanzkriterium mit dem Code, der es erfüllt, nötige Fixes getrennt von Präferenzen und die nicht durchgeführten Prüfungen.Nur Ergebnis

Owner

Engineer

Mensch + Agent

Beteiligte · Agents

QAProduct ManagerSoftware Engineer Agent

Auslöser

EreignisgesteuertEine Code-Änderung an einer identifizierten Revision ist bereit für das Review gegen ihr beabsichtigtes Verhalten.

Benötigter Kontext

CodeVollständiger zugewiesener Diff an der exakten RevisionJiraBeabsichtigtes Verhalten und AkzeptanzkriterienProduct BrainFokus der Initiative und freigegebene Product-Brain-Leitlinien

Optionaler Kontext

ArchitekturRelevantes Design und ADRsFilesTestevidenz und Coding-Konventionen

Skills

Review implementation against the ticketPrepare task contextReview an artifact against agreed criteria

Vorgeschlagener Gesprächsbogen

  1. 1Review-Umfang und Revision festlegenDie exakte Revision, den vollständigen zugewiesenen Diff und das erwartete Verhalten identifizieren; fehlenden Kontext oder Bedarf an Spezialisten-Review offenlegen.Skills: Prepare task context
  2. 2Design und Code-Verhalten analysierenZugewiesene Änderungen im Kontext untersuchen, inklusive Randfällen, Komplexität, Tests, Benennung und Dokumentation. Jeden Befund mit konkreter Evidenz verknüpfen und Spekulation nicht als Defekt behandeln.Skills: Review implementation against the ticket
  3. 3Relevantes Verhalten verifizierenDemonstrationen und passende Testergebnisse für geändertes Verhalten prüfen oder einholen, besonders bei UI- oder nebenläufigkeitskritischen Flows. Exakte Revision und nicht durchgeführte Prüfungen festhalten.
  4. 4Das Review-Ergebnis bestätigenBefunde mit der Verifikation abgleichen, nötige Fixes von Präferenzen trennen und relevante geänderte Revisionen vor der Freigabe erneut prüfen. Frühere Kommentare als Verlauf behalten.Skills: Review an artifact against agreed criteria

Ergebnis

Review-Urteil pro Akzeptanzkriterium mit dem Code, der es erfüllt, nötige Fixes getrennt von Präferenzen und die nicht durchgeführten Prüfungen.

Artefakte

Nur Ergebnis

So sieht gut aus

  • Jeder Befund ist mit konkreter Evidenz im Diff verknüpft.
  • Ein erfülltes Kriterium nennt die Dateien und Symbole, die es erfüllen.
  • Nötige Fixes und optionale Präferenzen bleiben getrennt.
  • Nicht verifizierbares Verhalten wird benannt, samt dem, was es verifizieren würde.

Freigabe

Der reviewende Engineer gibt frei oder fordert Änderungen an; Befunde des Agents gelten nie als Freigabe.

Ziel

GitHubJira

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.

Wähl den Einstieg, der zu deiner Rolle passt.

Leg mit uns die Product-AI-Richtung fest oder teste das gemeinsame Product Brain mit Jira und Code an echter Arbeit.