Ihre erste Story

Bringen Sie eine echte Story in Ihrem eigenen Repository von der Anforderung bis zum geprüften Pull Request, und wissen Sie, was zu tun ist, wenn etwas anhält.

Ihr Team ist eingerichtet. Wählen Sie jetzt eine echte Aufgabe und lassen Sie kanman sie erledigen. Diese Seite zeigt beide Einstiege, was unterwegs passiert und was Sie tun, wenn kanman anhält und fragt.

Eine gute erste Story wählen

Die erste Story soll Vertrauen aufbauen, nicht Grenzen testen. Gute Kandidaten:

  • klein (Größe S), in einem Bereich, den Ihr Team gut kennt
  • mit einem Ergebnis, das ein Mensch sehen oder aufrufen kann: ein neues API-Feld, ein Filter, eine Validierungsmeldung, eine CSV-Spalte
  • ohne Infrastruktur, ohne Migration von Produktivdaten, ohne Sicherheitseinstellungen

Meiden Sie breite Refactorings und alles, was eine Entscheidung von jemandem braucht, der nicht dabei ist. kanman würde anhalten und fragen. Das ist richtig, aber für einen ersten Run langsam.

Weg 1: Mit einer Anforderung starten (Aufnahme)

  1. Öffnen Sie auf der Teamseite den Reiter Anforderungen oder klicken Sie auf Neue Anforderung.
  2. Fügen Sie die Anforderung so ein, wie Sie sie einer Kollegin schreiben würden: ein Satz, ein Absatz aus einer Spezifikation oder ein als Text kopierter Slack-Thread. Klicken Sie auf Senden (oder drücken Sie Strg+Enter).
  3. kanman entscheidet zuerst, was die Nachricht ist. Nur eine Arbeitsanfrage wird zu Stories; eine Statusfrage wird direkt beantwortet, und eine operative Anfrage (Team pausieren oder fortsetzen, einen Run abbrechen, eine Story vorziehen oder zurückstufen) wird ausgeführt. Pausieren und Fortsetzen erfordern Admin-Rechte im Workspace. Ist die Anforderung zu vage, stellt kanman zuerst bis zu drei Fragen; beantworten Sie sie und klicken Sie auf Neu entwerfen.
  4. Für eine Arbeitsanfrage entwirft kanman eine oder mehrere Stories, jeweils mit:
    • Akzeptanzkriterien im Format Given/When/Then
    • einem Demonstrate-Block: konkrete Schritte, die das Ergebnis zeigen
    • einem Testplan, einer Größe (S, M, L), den betroffenen Bereichen und offenen Fragen
    • einem Bereitschaftswert von 0 bis 100
  5. Korrigieren Sie, was nicht stimmt, beantworten Sie offene Fragen, verwerfen Sie, was Sie nicht wollen, und genehmigen Sie den Rest. Nur Stories, die alle Bereitschaftsprüfungen bestehen, lassen sich genehmigen.
  6. Klicken Sie auf N Stories in den Tracker schreiben.

Genehmigte Stories werden in einem Durchgang in Ihren Tracker geschrieben und tragen das Übernahme-Label (standardmäßig kanman). Sie landen in der Spalte Backlog.

Weg 2: Mit einem bestehenden Issue starten

Wenn das Issue schon geschrieben ist:

  1. Setzen Sie am Issue in GitHub, GitLab oder Jira das Übernahme-Label (standardmäßig kanman).
  2. kanman spiegelt das Issue auf das Team-Board, in die Spalte seines Status. Die Story-Seite (/teams/<team>/stories/<KEY>) zeigt die Bereitschaft, und Sie können dort fehlende Akzeptanzkriterien und einen Demonstrate-Block ergänzen.

Eine Story braucht einen Demonstrate-Block, bevor kanman ihre Akzeptanz-Spec schreiben kann. Siehe Stories und Akzeptanzkriterien.

Die Story nach Ready verschieben

Ziehen Sie die Karte in kanman in die Spalte Bereit (oder nutzen Sie Verschieben nach an der Karte), oder verschieben Sie das Issue in Ihrem Tracker in den passenden Status. Die Karte wartet zuerst in der Verfeinerung mit dem Hinweis “Akzeptanzspezifikation wird geprüft”. Was dann passiert, hängt davon ab, ob Ihr Repository ein Akzeptanz-Manifest hat:

Repository Was kanman vor der Umsetzung tut
Mit .kanman/acceptance.json Schreibt aus dem Demonstrate-Block eine Akzeptanz-Spec nach .kanman/acceptance/<KEY>/, führt sie aus und verlangt, dass sie fehlschlägt. Die Story-Seite zeigt Spec: rot (erwartet). Dann startet der Run.
Ohne Manifest, mit Testphase Verschiebt die Story nach Ready und startet den Run. Das Nachweispaket sagt dann klar, dass kein Ergebnisnachweis vorliegt.
Ohne Manifest, andere Presets Lässt die Story in Refining, mit der Begründung, dass das Repository keine .kanman/acceptance.json hat.

Den Plan freigeben

Ist die Plan-Freigabe auf always gesetzt (Standard), legt kanman seinen Plan unter Entscheidungen vor, bevor es Code schreibt: den Ansatz, die Dateien, die es voraussichtlich ändert, und wie es das Ergebnis zeigen wird. Klicken Sie auf Plan freigeben, oder wählen Sie Änderungen anfordern mit einer Notiz: kanman überarbeitet den Plan und fragt erneut. Ablehnen beendet den Run und schiebt die Story zurück in den Backlog.

Den Run verfolgen

Die Run-Seite (/teams/<team>/runs/<run-key>) zeigt die Stufen Planung, Umsetzung, Prüfung, Review und Fertig mit Live-Fortschrittszeilen, den Versuchen und den Kosten im Verhältnis zum Run-Budget. Sie können den Run jederzeit mit Stoppen anhalten und später mit Erneut versuchen wieder starten.

Wenn kanman anhält und fragt

kanman rät nicht bei Dingen, die einen Menschen brauchen. Typische Halte, alle unter Entscheidungen:

Sie sehen Bedeutung Typische Antwort
Plan-Freigabe kanman möchte Ihr OK vor dem Coden Plan freigeben
Rückfrage kanman braucht eine fachliche oder technische Entscheidung und bietet 2 bis 4 Antworten an Antwort wählen; kanmans Empfehlung ist markiert
Richtlinien-Ausnahme Die Arbeit würde einen gesperrten Pfad berühren Einmal erlauben, oder Ablehnen mit Notiz
Budget-Stopp Der Run hat sein Budget erreicht Auf den angebotenen Betrag erhöhen, oder Abbrechen
Prüfung fehlgeschlagen Das Gate ist nach der automatischen Nacharbeit erneut gescheitert Noch einmal versuchen, oder den Run aufgeben

Jede Entscheidung erklärt die Lage und kanmans Empfehlung. Ihre Antwort, Ihr Name und die Uhrzeit landen im Audit-Log.

Prüfen und mergen

Erreicht der Run Review, trägt der Pull Request das Nachweispaket: den Plan, jedes Akzeptanzkriterium mit Ergebnis und Dateiverweisen, die Gate-Ergebnisse mit Artefakten (Playwright-Trace, Screenshots), Tests, CI, Richtlinien-Entscheidungen, Kosten und Dauer. Prüfen Sie den Code wie gewohnt. Der Merge verschiebt die Story nach Done.

Nach der ersten Story

  • Lassen Sie zwei oder drei weitere Stories durchlaufen, bevor Sie Einstellungen ändern.
  • Kalibrieren Sie das Run-Budget anhand von Kosten und Dauer in den Nachweispaketen.
  • Vertraut das Team dem Ablauf, ziehen Sie ein anderes Preset in Betracht: Ein Preset wählen und anpassen.

Zuletzt aktualisiert: January 1, 0001

kanman öffnen