So läuft eine Story | kanman Dokumentation

Jede Arbeit in kanman nimmt denselben Weg. Diese Seite begleitet ein Beispiel durch alle fünf Stufen: den Wunsch eines Kunden, Rechnungen als CSV zu exportieren.

Beschreiben Du beschreibst ein Ziel oder eine Story, im Chat, auf dem Board, in Slack.
Planen kanman liest Code und Board, teilt die Arbeit auf und legt die Reihenfolge fest.
Umsetzen Helfer schreiben Code, jeder in eigener Sandbox, auf eigenem Branch.
Prüfen Deine CI, dann ein unabhängiges Review, nicht vom Autor. Ein Problem, das CI oder Review finden, wird korrigiert und erneut geprüft.
Mergen kanman mergt und zeigt jeden Schritt live und im Aktivitätsprotokoll.
Wartet auf Menschen nur, was kanman nicht selbst herausfindet, einmal gefragt, an einem Ort.

So läuft Arbeit durch kanman

1. Beschreiben: ein Ziel oder eine Story

Es beginnt mit dem, was du willst, in welcher Form auch immer: ein paar Sätze an kanman in der Unterhaltung, eine Story auf dem Board, ein Issue in deinem Tracker oder ein Slack-Thread, in dem kanman erwähnt wird.

Kunden müssen ihre Rechnungen als CSV exportieren können, gefiltert nach Zeitraum.

Aus einer größeren Anfrage wird ein Ziel mit mehreren Stories, aus einer kleinen eine einzelne Story. Jede Story bekommt einen Titel, eine Kurzbeschreibung für die Board-Karte und Akzeptanzkriterien, die sagen, wann sie fertig ist. Du kannst alles davon bearbeiten, und kanman liest deine Änderungen, wenn es das nächste Mal auf das Board schaut. Mehr unter Stories und Akzeptanzkriterien.

Eine Story in Ready, die keinem Menschen zugewiesen ist, bearbeitet kanman. Eine Story, die einer Kollegin zugewiesen ist, bleibt bei ihr (siehe Mit kanman zusammenarbeiten).

2. Planen: kanman schaut auf das ganze Board

kanman arbeitet nicht eine Story nach der anderen für sich ab. Immer wenn sich etwas ändert (eine Story wird angelegt oder verschoben, jemand schreibt eine Notiz, beantwortet eine Frage oder eine Pipeline wird fertig) und mindestens einmal pro Stunde schaut kanman auf das ganze Board des Teams:

was in Ready liegt, was in Arbeit ist und was auf jemanden wartet
was der Code und die Historie des Repositorys über die Anfrage sagen
was seit dem letzten Blick in den Notizen geschrieben wurde

Dann entscheidet es, was als Nächstes passiert und in welcher Reihenfolge: welche Stories parallel laufen können, welche auf eine andere warten müssen und welche etwas brauchen, das nur ein Mensch hat. Jede Entscheidung schreibt es mit ihrem Grund ins Aktivitätsprotokoll des Teams, damit du jederzeit siehst, warum.

3. Umsetzen: Helfer in eigenen Sandboxes

kanman gibt jedes Stück Arbeit an einen Helfer. Ein Helfer ist eine Claude-Code-Sitzung mit einem klaren Auftrag. Jeder Helfer:

arbeitet in seiner eigenen Kopie des Repositorys, in seiner eigenen Sandbox
committet auf einem eigenen Branch, benannt nach der Story
hat keinen Zugriff auf das Token deines Code-Hosts oder auf Modellschlüssel

Ist der Helfer fertig, veröffentlicht kanman den Branch und öffnet einen Merge Request. Bevor etwas die Sandbox verlässt, wird die Änderung nach Zugangsdaten durchsucht.

Du siehst die Helfer bei der Arbeit: Die Zeile über dem Nachrichtenfeld sagt, wie viel gerade läuft, zum Beispiel Arbeite an 3 Sachen, und listet auf, was jeder gerade tut.

4. Prüfen: deine CI und ein unabhängiges Review

kanman prüft jede Änderung auf zwei unabhängige Arten:

Die CI deines Repositorys läuft auf dem Merge Request, genau wie bei deinen Kolleginnen und Kollegen. Schlägt ein Job fehl, liest kanman sein Log, lässt die Änderung korrigieren und wartet auf die nächste Pipeline. Schlägt ein Job auch auf deinem Hauptbranch fehl, aus einem Grund, der mit der Änderung nichts zu tun hat, nennt kanman im Protokoll den Job und den Grund.
Ein unabhängiger Reviewer, ein Helfer, der die Änderung nicht geschrieben hat, liest den Diff gegen die Akzeptanzkriterien der Story. Er sucht nach fehlenden Kriterien, abgeschwächten oder entfernten Tests und Behauptungen, die nicht stimmen. Findet er ein Problem, geht die Änderung zur Korrektur zurück und wird erneut geprüft.

Auch über geänderte Testerwartungen entscheidet der Reviewer, und sein Grund steht im Aktivitätsprotokoll. Mehr unter So prüft kanman seine Arbeit.

5. Mergen: sichtbar, während es passiert

Ist die CI grün und hat der Reviewer die Änderung in ihrem neuesten Commit freigegeben, mergt kanman sie. Diese Regel wird außerhalb des Modells durchgesetzt: Einen anderen Weg zum Mergen hat kanman nicht. Deine geschützten Branches und die Merge-Regeln deines Code-Hosts gelten zusätzlich; verlangt dein Team die Freigabe eines Menschen, wartet kanman darauf.

Die Story wandert nach Done, und das Protokoll hält den Merge mit Links zum Merge Request, zur Pipeline und zum Review fest. Deine Unterhaltung zeigt ihn in der Live-Zeile der Story.

Wo kanman dich fragt

Fakten findet kanman selbst heraus: was die CI sagt, was der Code tut, ob ein Test schon vor der Änderung fehlschlug. Einen Menschen fragt es nur, was niemand sonst klären kann, etwa eine Absicht, eine Wahl zwischen zwei guten Optionen oder einen Zugang, den es nicht hat.

Seine Fragen landen an einem Ort: Sie sind unten in deinem Chat über dem Nachrichtenfeld angeheftet. Die Seite der Story sagt, auf wen sie wartet. Antworte im Chat oder in Slack oder Microsoft Teams. kanman stellt jede Frage einmal; sobald du antwortest, macht es weiter. Siehe Fragen von kanman.

Jeder Schritt, jede Frage, jede Antwort, jedes Review und jeder Merge landet im Aktivitätsprotokoll des Teams, mit wer, was, wann und warum.

Ausprobieren

Der Schnellstart führt eine solche Story auf einem öffentlichen Beispiel-Repository aus, von der Anfrage bis zur gemergten Änderung.