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. kanman Bescheid sagen
Beschreibt die Arbeit in der App, in Slack oder in Microsoft Teams. kanman fragt nach, was unklar ist, und entwirft Stories mit Akzeptanzkriterien und einem Weg, jedes davon vorzuführen.
-
2. Regeln
Eure Richtlinie legt fest, was kanman anfassen, ausgeben und mergen darf. Große Entscheidungen kommen mit Empfehlung zu euch.
-
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. 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. Rückmeldung
kanman sagt euch, dass der Pull Request bereit ist, mit angehängten Nachweisen. Eure Leute reviewen und mergen, oder eure Richtlinie tut es.
kanman Bescheid sagen
Aus einer Anforderung werden prüfbare Stories
Jemand sagt kanman, was gebraucht wird, in der App, in Slack oder in Microsoft Teams. 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, oder auf dem kanman-Board des Teams
- 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.
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, in Slack oder in Microsoft Teams.
- 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
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
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
Rückmeldung
Ein Pull Request, dem eure Leute trauen können
kanman öffnet den Pull Request mit den Nachweisen, aktualisiert die Story in eurem Tracker, schreibt den Audit-Eintrag und sagt euch im Gespräch, dass die Story bereit fürs Review ist.
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
Probiert es an eurem eigenen Backlog
Startet mit dem Team-Plan, 14 Tage kostenlos und ohne Karte.