Deine erste Story

Dein Team ist eingerichtet. Wähle jetzt eine echte Aufgabe und lass kanman sie erledigen. Diese Seite zeigt beide Einstiege, was unterwegs passiert und was du tust, 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 dein 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

Meide 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 (in der Unterhaltung)

1. Öffne deinen Workspace (er öffnet sich mit der Unterhaltung mit kanman) oder drück überall N. Prüfe, dass dein Team im Chip neben dem Eingabefeld steht.
2. Füge die Anforderung so ein, wie du sie einer Kollegin schreiben würdest: ein Satz, ein Absatz aus einer Spezifikation oder ein als Text kopierter Slack-Thread. Drück Enter.
3. kanman entscheidet zuerst, was die Nachricht ist. Nur eine Arbeitsanfrage wird zu Stories; eine Statusfrage wird beantwortet, und eine operative Anfrage (Team pausieren oder fortsetzen, einen Run abbrechen, eine Story vorziehen oder zurückstufen) kommt als Karte zurück, deren Schaltfläche die Änderung nennt, zum Beispiel Team pausieren; ein pausiertes Team setzt du auf derselben Karte mit Team fortsetzen fort. Pausieren und Fortsetzen erfordern Admin-Rechte im Workspace. Ist die Anforderung zu vage, stellt kanman zuerst bis zu drei Fragen; beantworte sie im Review und klicke auf Neu entwerfen.
4. Für eine Arbeitsanfrage entwirft kanman eine oder mehrere Stories, jeweils mit:
   • Akzeptanzkriterien im Format Given/When/Then
   • einem Testplan, einer Größe (S, M, L) und den betroffenen Bereichen
   • den Details, die kanman selbst entschieden hat (Meine Annahmen), und den Fragen, die nur du beantworten kannst, jeweils markiert mit Blockiert die Freigabe oder Blockiert nicht
   • einem Bereitschaftswert von 0 bis 100
5. Die Entwürfe kommen als Karte. Braucht ein Entwurf eine Antwort, sagt kanman das in einem Satz und listet die Fragen darunter: Antworten, kanman entscheiden lassen oder Nicht relevant, oder du antwortest im Chat (“1: …, 2: nicht relevant”). Siehe Fragen von kanman beantworten. Lehne ab, was du nicht willst, und gib den Rest frei; Review öffnen zeigt alle Details, um Fehler zu korrigieren. Nur Stories, die alle Bereitschaftsprüfungen bestehen, lassen sich freigeben; Inhaber und Admins können auch eine Story freigeben, die nur noch offene Fragen aufhalten.
6. Klicke in der Karte auf N Stories schreiben (oder im Review auf N Stories in den Tracker schreiben).

Genehmigte Stories werden in einem Durchgang in deinen Tracker geschrieben und tragen das Übernahme-Label (standardmäßig kanman). Sie landen in der Spalte Backlog. Das Schreiben startet die Arbeit nicht: kanman sagt dir das im Gespräch („PU-43 liegt im Backlog. Sag „start“ oder zieh die Story nach Ready, dann lege ich los.“), und jede geschriebene Story in der Karte bietet Jetzt starten. Das verschiebt die Story nach Ready, genau wie das Ziehen. Du kannst also auch „starte PU-43“ sagen (oder direkt nach dem Schreiben nur „start“). Bei mehreren geschriebenen Stories fragt kanman, welche du meinst. Im Local-Plan sind Runs nicht enthalten, deshalb erklärt kanman das und verlinkt auf Plan wählen; sind alle Run-Plätze des Teams belegt, wandert die Story trotzdem und wartet auf einen freien Run-Platz.

Weg 2: Mit einem bestehenden Issue starten

Wenn das Issue schon geschrieben ist:

1. Setz 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 du kannst dort fehlende Akzeptanzkriterien ergänzen.

Gegen die Akzeptanzkriterien prüft der unabhängige Reviewer die Änderung. Siehe Stories und Akzeptanzkriterien.

Die Story nach Ready verschieben

Klicke im Gespräch bei der geschriebenen Story auf Jetzt starten, sag „start“ mit dem Key, zieh die Karte in kanman in die Spalte Bereit (oder nutze Verschieben nach an der Karte), oder verschieb das Issue in deinem Tracker in den passenden Status.

Eine Story in Ready, die keiner Person zugewiesen ist, bearbeitet kanman. kanman bemerkt die Verschiebung sofort, sieht sich das ganze Board des Teams an, plant die Arbeit (und teilt sie, wenn sie für eine Änderung zu groß ist) und gibt jedes Teil an einen Helfer. Der Helfer arbeitet in seiner eigenen Sandbox auf seinem eigenen Branch. Siehe So läuft eine Story.

Den Run verfolgen

Die Zeile über dem Eingabefeld sagt, wie viele Helfer arbeiten, zum Beispiel Arbeite an 1 Sache; wähle sie aus, um zu sehen, was jeder gerade tut. In der Unterhaltung ändert sich die Live-Zeile der Story an Ort und Stelle: geplant, in Arbeit, Prüfungen laufen, im Review, gemergt.

Die Run-Seite (/teams/<team>/agents/<run-key>, in Alle Aufgaben über dem Eingabefeld) zeigt, was kanman gerade tut, die Kosten und den letzten Fortschritt, siehe Die Run-Seite. Du kannst den Run jederzeit Stoppen und später Erneut versuchen. Um die ganze Arbeit des Teams auf einmal anzuhalten, pausierst du das Team.

Wenn kanman anhält und fragt

Fakten findet kanman selbst heraus: was die CI sagt, was der Code tut, wie dein Deployment funktioniert. Es fragt dich nur, was es nicht herausfinden kann: was du beabsichtigst, eine Wahl zwischen Optionen oder einen Zugang, den es nicht hat.

Seine Fragen an dich sind unten im Chat über dem Nachrichtenfeld angeheftet, und die Zeile über dem Nachrichtenfeld sagt zum Beispiel 1 Story wartet auf Menschen · 1 auf dich. Jede Frage nennt die Story, sagt, warum sie wichtig ist, und bietet die Optionen, die kanman sieht; du kannst auch in eigenen Worten antworten, oder in Slack oder Microsoft Teams. kanman stellt jede Frage einmal und macht weiter, sobald du antwortest. Siehe Fragen von kanman.

Manche Schritte muss eine Person ausführen, zum Beispiel einen Zugang gewähren. kanman weist dir die Story dann mit einer Notiz zu; schreib “@kanman done” in die Notizen, wenn du fertig bist. Siehe Arbeit hin- und hergeben.

Prüfen und mergen

Ist der Helfer fertig, durchsucht kanman die Änderung nach Zugangsdaten, pusht den Branch und öffnet den Pull Request. Deine CI läuft darauf, und ein Reviewer, der die Änderung nicht geschrieben hat, prüft sie gegen die Akzeptanzkriterien und sucht nach entfernten oder abgeschwächten Tests. Ist die CI grün und hat der Reviewer den neuesten Commit freigegeben, mergt kanman, und die Story wandert nach Fertig. Bei einem neuen Team schließt dann die Karte Einrichtung ab.

Soll in deinem Team eine Person jeden Merge freigeben, verlange das in der Branch Protection deines Code-Hosts; kanman wartet dann wie jede Kollegin und jeder Kollege auf diese Freigabe. Siehe Wie kanman seine Arbeit prüft.

Nach der ersten Story

• Lass zwei oder drei weitere Stories durchlaufen, bevor du Einstellungen änderst.
• Sieh dir die Kosten jedes Runs an, um das Tagesbudget des Teams einzuschätzen.
• Frag kanman zu allem, was es getan hat, “Warum?”; es antwortet aus dem Aktivitätsprotokoll des Teams.