Zum Inhalt springen
ENDE
 Pilot anfragen

So funktioniert's

So funktioniert's

Eine Story von Anfang bis Ende. Aus einer Anfrage der Buchhaltung werden drei Stories, ein Sandbox-Run, ein Nachweispaket und ein Pull Request, den euer Team reviewt.

  1. 1. Aufnahme

    Anforderung einfügen oder kanman in Slack taggen. Ihr bekommt Stories mit Akzeptanzkriterien und einem Weg, jedes davon vorzuführen.

  2. 2. Regeln

    Eure Richtlinie legt fest, was kanman anfassen, ausgeben und mergen darf. Große Entscheidungen kommen mit Empfehlung zu euch.

  3. 3. Arbeit

    Claude Code oder Codex schreibt den Code in einer Sandbox. kanman wählt das Modell nach Komplexität, damit kleine Fixes günstig bleiben.

  4. 4. Beweis

    Bevor etwas ins Review geht, läuft eine Akzeptanzspezifikation gegen eine frische Umgebung. Keine Spec, kein Bereit. Kein grüner Durchlauf, kein Review.

  5. 5. Übergabe

    Ein Pull Request mit angehängten Nachweisen. Eure Leute reviewen und mergen, oder eure Richtlinie tut es.

Aufnahme

Aus einer Anforderung werden prüfbare Stories

Jemand fügt eine Anforderung in kanman ein oder taggt kanman in Slack. kanman fragt nach, was unklar ist, und entwirft dann kleine Stories mit Akzeptanzkriterien.

Zu jedem Kriterium gehört ein Weg, es vorzuführen. Daraus wird die Akzeptanzspezifikation, geschrieben, bevor es Code gibt.

  • Stories landen in eurem Tracker, unter euren Spaltennamen
  • Ein Mensch gibt die Stories frei, bevor sie in den Tracker geschrieben werden
  • Die Spec muss zuerst fehlschlagen. Eine Spec, die mit dem heutigen Code grün ist, beweist nichts.

Beispiel

INV-41 Rechnungen als CSV exportieren

Akzeptanzkriterien

  1. AC1Der Export-Button lädt eine .csv-Datei herunter
  2. AC2Eine Zeile pro Rechnung im gewählten Zeitraum
  3. AC3Beträge nutzen den gemeinsamen Geldformatierer
  4. AC4Ein leerer Zeitraum zeigt einen Hinweis und keine Datei

Vorführen

Rechnungsseite öffnen, 1. bis 30. September wählen, CSV exportieren drücken und die heruntergeladene Datei prüfen.

Illustration

Regeln

Eure Richtlinie entscheidet, was als Nächstes passiert

Bevor kanman startet, prüft es die Story gegen eure Richtlinie. Welche Repos und Pfade es anfassen darf, was ein Run kosten darf, ob es jetzt laufen darf.

Ist eine Entscheidung zu groß für die Richtlinie, wird sie zur Entscheidung für euch. Ihr bekommt die Frage, kanmans Empfehlung und die Optionen, in der App oder in Slack.

  • Fünf Presets von Testphase bis Härtung bestimmen Tempo und Eigeninitiative
  • Sandbox und Outcome-Gate sind in jedem Preset gleich
  • Jede Prüfung und jede Entscheidung landet im Audit-Log

kanman

INV-43 · vor 4 Min. gefragt

Entscheidung

INV-43 ändert das Rechnungsschema. Wie soll ich die MwSt.-Spalte ergänzen?

Meine Empfehlung

Eine neue Spalte mit Standardwert. Alte Exporte funktionieren weiter, nichts muss nachgetragen werden.

  • Empfehlung übernehmen
  • Bestehende Rechnungen nachtragen
  • Erst einmal liegen lassen

Antwortet hier oder direkt in Slack.

Illustration

Preset

  • Testphase Für die erste Woche. Arbeitet auch in Repos ohne Akzeptanzspezifikationen und sagt das in jedem Nachweispaket.
  • Fokussiert Arbeitet nur an Stories, die eure Leute angelegt haben. Nichts aus eigener Initiative.
  • Ausgewogen (ausgewählt) Nimmt bereite Arbeit in ruhigem Tempo auf und fragt bei großen Entscheidungen.
  • Autonom Vier Stories gleichzeitig, für Teams mit guter Testabdeckung. Gleiche Gates, gleiche Sandbox.
  • Härtung Ergänzt Wartung in kleinen Dosen. Sicherheitswarnungen, veraltete Dependencies, kaputte Doku-Links.

Presets ändern Tempo, Eigeninitiative und die standardmäßig gesperrten Pfade. Sandbox und Gates sind in jedem Preset gleich.

Illustration

Arbeit

Der Coding-Agent arbeitet in einer Sandbox

kanman übergibt die Story an Claude Code oder Codex, headless in einer frischen Sandbox. In Frankfurt oder auf eurem Self-hosted Runner.

Es wählt das Modell nach Komplexität, damit ein Tippfehler-Fix nicht so viel kostet wie eine Migration. Budgets stoppen einen Run, bevor er teuer wird.

  • Euer Verify-Befehl (Lint, Typen, Tests) läuft vor allem anderen
  • Der Agent hat keinen Schreibzugriff auf die Akzeptanzspezifikation
  • Ein gescheitertes Gate bekommt einen Nachbesserungsversuch, danach kommt es zu euch zurück
  1. sandbox frische Umgebung bereit (fra)
  2. verify npm run lint && npm test bestanden
  3. model nach Komplexität gewählt: kleine Änderung
  4. agent Claude Code, 6 Dateien geändert
  5. budget innerhalb des Laufbudgets
  6. gate Akzeptanzspezifikation auf frischem Checkout eingeplant

Illustration

Beweis

Die Spec läuft auf einem frischen Checkout

Das Outcome-Gate startet eure App vom Commit des Pull Requests, in einer frischen Umgebung, und führt die Spec der Story aus. Nichts aus dem Cache, nichts von der Maschine des Agents.

Das Ergebnis ist das Nachweispaket. Jedes Kriterium mit bestanden oder fehlgeschlagen, die Spec, die es geprüft hat, der Trace, die Dauer und die Kosten.

  • Keine Spec, kein Bereit. Kein grüner Durchlauf, kein Review.
  • In Repos ohne Specs sagt das Preset Testphase das im Nachweispaket klar

Nachweispaket

INV-41 Rechnungen als CSV exportieren

Outcome-Gate bestanden

Akzeptanzkriterien

  • Der Export-Button lädt eine .csv-Datei herunter bestanden
  • Eine Zeile pro Rechnung im gewählten Zeitraum bestanden
  • Beträge nutzen den gemeinsamen Geldformatierer bestanden
  • Ein leerer Zeitraum zeigt einen Hinweis und keine Datei bestanden
Spec
.kanman/acceptance/INV-41/export.spec.ts
Geschrieben
bei der Aufnahme, rot vor Bereit
Lief auf
frischem Checkout von 4e1c9a7
Dauer
41,6 s
Kosten des Runs
0,84 €
Trace-Vorschau: die Rechnungsseite mit gedrücktem Button CSV exportieren und der heruntergeladenen Datei.
Illustration Eine Aufnahme aus der Demo-Sandbox ersetzt sie.

Übergabe

Ein Pull Request, dem eure Leute trauen können

kanman öffnet den Pull Request mit den Nachweisen, aktualisiert die Story in eurem Tracker und schreibt den Audit-Eintrag.

Eure Leute reviewen und mergen, wie heute. Erlaubt eure Richtlinie automatische Merges für kleine Änderungen, werden diese gemerged, sobald alle Gates grün sind.

  • Review-Kommentare, die sich wiederholen, werden zu Team-Konventionen
  • Jede Konvention könnt ihr lesen, ändern und ausmustern

Konventionen

  • Geldbeträge mit dem gemeinsamen Formatierer formatieren.

    Gelernt aus 3 Review-Kommentaren

    Aktiv

  • Neue Endpunkte brauchen einen Rate-Limit-Test.

    Gelernt aus 2 Review-Kommentaren

    Aktiv

  • Keine neuen Dependencies ohne Hinweis im Pull Request.

    Von einem Teammitglied ergänzt

    Angepinnt

  • Event-Namen in snake_case.

    Gelernt aus 4 Review-Kommentaren

    Ausgemustert

Illustration

Probiert es an eurem eigenen Backlog

Ein Pilot dauert sechs Wochen mit einem Team und einem Repo.

Pilot anfragen