Wie kanman die Stories eines Ziels ordnet

Ein Ziel mit mehreren Stories ist mehr als eine Liste. Eine Story fügt eine Datenbankspalte hinzu, die nächste baut darauf eine API, eine dritte fügt einen Knopf hinzu, der die API aufruft. In der falschen Reihenfolge oder nebeneinander in denselben Dateien kommt sich die Arbeit in die Quere. kanman stimmt solche Stories ab wie ein erfahrener Lead-Entwickler: Es plant das Ziel als Ganzes, bevor die Stories laufen, hält den Plan aktuell, während sie laufen, und prüft das Ganze, sobald sie fertig sind.

Eine Story, die zu keinem Ziel gehört, oder die einzige Story eines Ziels braucht nichts davon. Sie läuft wie gewohnt, und kanman hält sie trotzdem aus Dateien heraus, die ein anderer Run gerade ändert (siehe Zwei Runs ändern nie gleichzeitig dieselben Dateien).

Der Plan des Ziels

Bevor die Stories eines Ziels starten, schreibt kanman einen Plan für alle:

• Die Reihenfolge: welche Story nach welcher kommt.
• Worauf die Stories aufbauen. Liefert eine Story etwas, worauf eine andere aufbaut, zum Beispiel eine Export-API, die der Knopf aufruft, hält der Plan fest, was genau sie liefert. Die Pläne beider Stories und ihre Prüfungen richten sich danach.
• Was jede Story voraussichtlich ändert: ihre Repositories und Dateien.

Der Plan jeder Story des Ziels baut darauf auf, damit jede Änderung zum Ganzen passt.

Niemand muss ihn freigeben. kanman schreibt den Plan und seine Gründe ins Aktivitätsprotokoll und legt los. Sind Sie mit der Reihenfolge nicht einverstanden, sagen Sie es in den Notizen des Ziels oder in der Unterhaltung, und kanman ändert sie.

Was nach was kommt

Kommt eine Story nach einer anderen, zeigt ihre Karte das leise mit nach SBX-12. Das ist keine Warnung; es verschwindet, sobald SBX-12 gelandet ist. Das eigene Board des Ziels listet seine Stories in der geplanten Reihenfolge.

Eine Story startet nie, bevor das gelandet ist, wonach sie kommt. Solange sie in Bereit wartet, sagt ihre Karte, warum:

Landet eine Story, bekommen die Stories, die darauf aufbauen, bei ihrem nächsten Schritt eine kurze Notiz, was sich geändert hat, und arbeiten auf dem neuen Stand weiter statt auf einem alten.

kanman verschiebt nie eine Story, die Sie selbst platziert haben.

Zwei Runs ändern nie gleichzeitig dieselben Dateien

Das gilt für jede Story eines Teams, innerhalb eines Ziels und über Ziele hinweg.

• Bevor ein Run startet, vergleicht kanman die Dateien, die die Story voraussichtlich ändert, mit den Dateien, die die laufenden Stories des Teams gerade ändern. Überschneiden sie sich, wartet die Story mit Wartet, bis SBX-12 gelandet ist (gleiche Dateien) und startet, sobald SBX-12 gelandet ist.
• Während ein Run arbeitet, kann sich zeigen, dass er eine Datei braucht, mit der niemand gerechnet hat. Beginnt er, Dateien zu ändern, die ein anderer offener Run gerade ändert, hält kanman den späteren Run an einer sicheren Stelle an, behält, was er bis dahin getan hat, und setzt ihn auf der Arbeit der anderen Story fort, sobald diese gelandet ist. Bis dahin sagt seine Karte Wartet, bis SBX-12 gelandet ist (gleiche Dateien).

Sie müssen nichts auflösen: Der wartende Run geht von selbst weiter. Zur Prüfung, die kanman für eine einzelne Story kurz vor dem Start ihres Runs macht, siehe Bevor ein Run startet.

Der Plan bleibt aktuell

Pläne treffen auf die Wirklichkeit. kanman passt den Plan des Ziels an, nicht nur eine Story, wenn:

• Sie eine Anforderung, eine Story oder ein Kriterium hinzufügen oder ändern: im Chat, in einer Anfrage, an der Story oder in Ihrem Tracker;
• ein Run Neues bringt: ein fehlendes Teil, eine Prüfung, die wegen einer anderen Story fehlschlägt, eine Abhängigkeit, die niemand gesehen hat, ein Run, der Dateien einer anderen Story ändert;
• eine Story aufgeteilt, nach Später verschoben oder geschlossen wird oder sich nicht liefern lässt;
• etwas landet, worauf die übrigen Stories aufbauen.

kanman ändert nur den betroffenen Teil. Den Plan einer Story, den Sie schon freigegeben haben, bekommen Sie nur dort wieder vorgelegt, wo er sich geändert hat. Eine laufende Story bekommt die Änderung bei ihrem nächsten Schritt oder wird angehalten, wenn sie auf etwas aufbauen würde, das nicht mehr stimmt.

kanman hält den Plan außerdem ruhig. Arbeit, die läuft oder gleich beginnt, wird nicht verschoben, und viele kleine Änderungen in kurzer Zeit werden zu einer Aktualisierung statt zu vielen: kanman sammelt sie und passt den Plan höchstens etwa jede halbe Stunde an, früher nur, wenn es dem Ziel nützt. Ihre eigenen Änderungen am Plan, ein Widerspruch in einer Anforderung und ein Warnsignal, das kanman für den Plan gesetzt hat, gelten sofort. Solange kanman sammelt, steht es auf der Karte des Ziels, zum Beispiel „Ich halte den Plan seit 10:12 stabil“.

Zu jeder Änderung steht ein Satz auf der Karte des Ziels, eine Woche lang. Zum Beispiel:

Die gemeinsame Prüfung

Jede Story wird für sich geprüft, bevor sie gemergt wird. Sobald die letzte Story eines Ziels gelandet ist, prüft kanman zusätzlich das gemeinsame Ergebnis auf dem Hauptbranch gegen die Zielbeschreibung und die Erfolgskriterien des Ziels. Stories, die einzeln bestehen, können zusammen trotzdem scheitern.

Findet die gemeinsame Prüfung eine Lücke, legt kanman dafür eine Story im selben Ziel an und plant sie ein. Die Karte sagt dann zum Beispiel Die gemeinsame Prüfung auf main hat eine Lücke in SBX-12 gefunden; ich habe SBX-17 hinzugefügt, um sie zu schließen. Besteht die Prüfung, ist das Ziel geliefert, und kanman schreibt sein Debriefing.

Die Schrittliste jeder Story

Innerhalb einer Story arbeitet kanman die Schritte ihres Plans ab, und die Checkliste der Story zeigt sie. Ein Schritt wird erst abgehakt, wenn eine Prüfung ihn belegt hat. Siehe Laufende Arbeit.

Verwandte Themen

• Ziele
• Fluss und Manager-Board
• Laufende Arbeit
• Mit kanman zusammenarbeiten
• Debriefings, Später und ruhigere Updates