Stories
Wie eine Arbeit vom ersten Satz zur gemergten, geprüften Änderung wird.
Eine Story ist eine Arbeit mit Akzeptanzkriterien. Sie kann als Satz im Chat beginnen, als Ticket in deinem Tracker, als Thread in Slack oder als Notiz aus einem Meeting. kanman formt sie, plant sie, schreibt die Änderung mit seinen Helfern, prüft sie mit deiner CI und einem unabhängigen Review, mergt sie und sagt dir, wie es lief.
- 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.
Im Chat ausprobierenIm Chat deines Teams
- Der CSV-Export schneidet Namen nach 50 Zeichen ab. Namen können bis zu 200 Zeichen lang sein. Bitte beheb das und ergänze einen Test.
- Warum brauchte SBX-12 einen zweiten Versuch?
In diesem Bereich
So läuft eine Story
Der Weg jeder Arbeit: Du beschreibst sie, kanman plant sie, Helfer schreiben sie, deine CI und ein unabhängiger Reviewer prüfen sie, kanman mergt sie, und du siehst jeden Schritt live.
Deine erste Story
Bring eine echte Story in deinem eigenen Repository von der Anforderung bis zum gemergten Pull Request, und wisse, was zu tun ist, wenn etwas anhält.
Anforderungen schreiben, die kanman erledigen kann
Wie du Anforderungen und Stories formulierst, damit sie die Bereitschaftsprüfungen bestehen und in einem gemergten Pull Request enden.
Stories und Akzeptanzkriterien
Eine Story ist ein kleines, überprüfbares Stück Arbeit mit Akzeptanzkriterien und einem Demonstrate-Block, der das Ergebnis zeigt.
Laufende Arbeit
Wie die Helfer von kanman an deinen Stories arbeiten: jeder in seiner eigenen Sandbox und auf seinem eigenen Branch, live sichtbar, mit jedem Schritt im Aktivitätsprotokoll des Teams.
So prüft kanman seine Arbeit
Jede Änderung von kanman besteht die CI deines Repositorys und das Review eines Helfers, der sie nicht geschrieben hat, bevor kanman sie mergt. Die Regel wird außerhalb des Modells durchgesetzt.
Browser-Nachweise
Wenn eine Änderung für Menschen sichtbar ist, probiert kanman sie in einem echten Browser aus und zeichnet das auf: ein Video mit jedem Schritt benannt, was bestanden hat und was nicht.
Nach dem Merge
kanman bleibt nach dem Merge an seiner Arbeit dran: Versionshinweise, das Deployment beobachten, Produktion über die Abnahmeprüfung der Story und deine Signale prüfen und allen sagen, wenn es live ist oder was fehlgeschlagen ist.
Meeting-Notizen und Transkripte
Teile Meeting-Notizen, ein Transkript oder die Zusammenfassung einer Aufzeichnung mit kanman. Es schlägt die Stories, Entscheidungen und den Kontext vor, die sich zu behalten lohnen, sagt, wer was gesagt hat, und ändert nichts, bevor du auswählst.