Quickstart: die Demo-Sandbox

Am schnellsten verstehst du kanman, wenn du zusiehst, wie es eine Story von Anfang bis Ende erledigt. Die Demo-Sandbox ist ein kleines öffentliches Repository, das genau dafür gebaut ist. Du kannst gefahrlos experimentieren: Es enthält keine Secrets, keine Produktivdaten und keine Nutzer.

Am Ende dieses Quickstarts hast du:

• ein Team, das mit deiner Kopie des Sandbox-Repositorys verbunden ist
• drei entworfene Stories mit Akzeptanzkriterien, von denen zwei freigegeben und in GitHub Issues geschrieben sind
• eine Story, die kanman umgesetzt, mit der CI des Repositorys und einem unabhängigen Review geprüft und gemergt hat

Was du brauchst

• Ein kanman-Konto. Wenn dein Unternehmen kanman bereits nutzt, bist du vielleicht schon eingeladen: Melde dich unter app.kanman.ai an. Andernfalls leg unter app.kanman.ai/signup ein Konto an und öffne den Link in der Bestätigungs-E-Mail. Dieselbe Karte fragt dann nach Name und Webadresse deines Workspace, und Workspace anlegen öffnet deinen Workspace: kanman stellt sich dort vor und bietet Team einrichten an. Ein neues Team startet mit einer 14-tägigen Testphase des Team-Tarifs, ohne Kreditkarte (siehe Tarife und Abrechnung).
• Ein GitHub-Konto, das Repositories anlegen darf (persönlich oder in einer Organisation).
• Etwa 15 Minuten. Die meiste Zeit wartest du, während kanman arbeitet.

Docker oder Node brauchst du auf deinem Rechner nicht. kanman stellt alles, was es ausführt, in seiner eigenen Sandbox bereit.

Das Sandbox-Repository

kanman-ai/pilot-sandbox ist ein kleiner Rechnungsdienst in TypeScript: eine Fastify-API, eine einfache HTML-Rechnungsliste, Unit-Tests und ein CI-Workflow. Beträge sind ganzzahlige Cent, die Daten werden bei jedem Start im Speicher angelegt.

Ein gutes erstes Repository ist es wegen des CI-Workflows: kanman beurteilt jede Änderung mit der eigenen CI des Repositorys und mit einem Review durch einen Helfer, der die Änderung nicht geschrieben hat. Siehe Wie kanman seine Arbeit prüft.

Schritt 1: Die Sandbox in dein Konto kopieren

1. Öffne github.com/kanman-ai/pilot-sandbox und klicke auf Use this template (oder Fork).
2. Leg die Kopie in deinem Konto oder deiner Organisation an. Behalte den Namen pilot-sandbox.
3. Öffne im neuen Repository Settings > General > Features und prüfe, dass Issues eingeschaltet ist. GitHub schaltet Issues bei Forks standardmäßig ab, und kanman schreibt Stories in GitHub Issues. Öffne außerdem Actions und aktiviere die Workflows, damit die CI auf den Pull Requests von kanman läuft.

kanman öffnet Pull Requests gegen deine Kopie, nie gegen das Original.

Schritt 2: Das Team anlegen

1. Öffne die Team-Einrichtung. Hast du deinen Workspace gerade angelegt, klicke unter der ersten Nachricht von kanman auf Team einrichten. Andernfalls klicke oben links auf den Namen des Workspace und wähle Neues Team.
2. Tracker: Klicke auf der GitHub-Karte auf Verbinden. Die Anmeldung bei GitHub öffnet sich in einem kleinen Fenster; autorisiere kanman mit dem GitHub-Konto, dem deine Kopie gehört. Schließt sich das Fenster, erscheint deine GitHub-Verbindung in der Liste und ist ausgewählt. (Blockiert dein Browser das Fenster, klicke auf In diesem Tab öffnen: Du kommst mit allen Eingaben zum selben Schritt zurück.) Die Berechtigungen beschreibt GitHub verbinden.
3. Repositories: Trag <dein-konto>/pilot-sandbox als Tracker-Projekt ein, gib dem Team einen Namen, zum Beispiel “Sandbox Team”, füge das Repository <dein-konto>/pilot-sandbox hinzu und behalte den Basis-Branch main.
4. Ausführung: Wähle Claude Code und Über kanman abrechnen.
5. Überspring Aussehen und klicke im letzten Schritt auf Team anlegen.

Das Team bekommt kanmans Standardspalten (Backlog, Verfeinerung, Bereit, In Arbeit, Review, Fertig) und Standard-Limits von selbst; zuzuordnen gibt es nichts.

Der eigene Chat des Teams mit kanman öffnet sich, mit dem Board des Teams daneben (jedes Team hat seinen eigenen Chat; Persönlich ist die Unterhaltung über alle Teams). Sein Kopf zeigt Ruht, und eine Karte Einrichtung, oben im Chat des Teams angeheftet, zeigt deinen Fortschritt: Workspace, Verbindung und Team sind erledigt, als Nächstes kommt deine erste Story. Die Karte führt dich durch den Rest dieses Schnellstarts; sie ist in jedem Browser dieselbe, und Ausblenden entfernt sie für alle im Workspace.

Bis das Team seine erste Story hat, sagt sein Mind (das Board) Noch nichts im Kopf und bietet den einen nächsten Schritt an: Repository verbinden, wenn das Team noch keines hat, sonst Sag mir, woran ich arbeiten soll. Stories macht es genauso, bis kanman gearbeitet und etwas gemessen hat, und wechselt zur echten Ansicht, sobald es etwas zu zeigen gibt.

Schritt 3: Aus einer Anforderung Stories machen

1. Klicke in der Karte Einrichtung auf Beschreiben (oder drück N). Das Eingabefeld im Chat deines Sandbox-Teams erhält den Fokus; der Chip darunter nennt das Team. Schreibst du eine Anforderung stattdessen in Persönlich, bietet kanman an, Weiter in deinem Team zu machen, und nimmt deine Anfrage mit. Siehe Mit kanman sprechen.

2. Füge diese Anforderung ein und drück Enter:

   Customers need to export their invoices as CSV, filtered by date range.
   

3. Nach wenigen Sekunden antwortet kanman mit einer Karte mit drei entworfenen Stories. Klicke auf Review öffnen, um sie vollständig zu lesen: Jede hat Akzeptanzkriterien im Format Given/When/Then, einen Testplan und eine Größe.

4. Pass bei Bedarf ein Kriterium an und klicke dann auf Zurück zur Unterhaltung. Lehne in der Karte die Story, die du nicht brauchst, ab und gib die beiden anderen frei.

5. Klicke auf 2 Stories schreiben. Die Karte meldet “2 Stories geschrieben”.

kanman schreibt die freigegebenen Stories in einem Durchgang mit dem Label kanman in GitHub Issues. Sie erscheinen in der Spalte Backlog mit dem Badge “Bereit für kanman”.

Schritt 4: Eine Story nach Ready verschieben

Klicke in der Karte Einrichtung auf Story auswählen: Die Spalte Bereit leuchtet auf. Zieh die Story “Export invoices endpoint” (der genaue Titel kann abweichen) in die Spalte Bereit, oder nutze Verschieben nach an der Karte.

Eine Story in Ready, die keiner Person zugewiesen ist, bearbeitet kanman. kanman bemerkt die Verschiebung sofort, sieht sich das ganze Board an, plant die Arbeit und gibt sie an einen Helfer. Braucht es etwas, das nur du geben kannst, fragt es dich einmal, in der Zeile über dem Eingabefeld.

Schritt 5: kanman bei der Arbeit zusehen

Der Helfer arbeitet in seiner eigenen Sandbox, auf seinem eigenen Branch. Währenddessen:

• zeigt die Zeile über dem Eingabefeld Arbeite an 1 Sache; wähle sie aus, um zu sehen, was der Helfer gerade tut
• ändert sich die Live-Zeile der Story in der Unterhaltung an Ort und Stelle: geplant, in Arbeit, Prüfungen laufen, im Review, gemergt
• zeigt die Run-Seite, geöffnet über die Story-Karte oder Alle Aufgaben über dem Eingabefeld, den letzten Fortschritt und die Kosten

Desktop Mobile

Schritt 6: Prüfungen und Merge

Ist der Helfer fertig, durchsucht kanman die Änderung nach Zugangsdaten, pusht den Branch und öffnet einen Pull Request in deiner Kopie von pilot-sandbox. Dann:

1. Die CI des Repositorys läuft auf dem Pull Request. Scheitert ein Job wegen der Änderung, liest kanman das Log und lässt die Änderung korrigieren.
2. Ein Reviewer, der die Änderung nicht geschrieben hat, vergleicht den Diff mit den Akzeptanzkriterien der Story und sucht nach entfernten oder abgeschwächten Tests.
3. Ist die CI grün und hat der Reviewer den neuesten Commit freigegeben, mergt kanman den Pull Request.

Soll eine Person jeden Merge freigeben, verlange in der Branch Protection deines Repositorys auf GitHub ein Review; kanman wartet dann wie jede Kollegin und jeder Kollege auf diese Freigabe. Siehe Mergen.

Ist der Pull Request gemergt, wandert die Karte nach Fertig, und die Karte Einrichtung schließt mit zwei nächsten Schritten ab: Team einladen und Budgets festlegen. Mit Fertig klappt die Karte zu.

Wie es weitergeht

• Verschieb die zweite freigegebene Story nach Ready und sieh zwei Helfern nebeneinander zu. Die 14-tägige Testphase des Team-Tarifs erlaubt bis zu fünf Runs gleichzeitig.
• Frag kanman in der Unterhaltung “Warum hast du gemergt?”. Es antwortet aus dem Aktivitätsprotokoll des Teams.
• Lies So läuft eine Story für das Gesamtbild und dann Ein Team einrichten für eines deiner eigenen Repositories.