Was kanman ist | kanman Dokumentation

kanman ist der eigene Assistent deines Teams. Es lebt im Team-Chat, kennt deinen Code und deine Leute, behält seine Habits bei, während du nicht da bist, und jede und jeder kann auch privat mit ihm sprechen. Die Engineering-Arbeit erledigt es selbst: Du beschreibst, was du brauchst, als Ziel oder als Story, in der App, in Slack oder in Microsoft Teams; kanman plant die Arbeit, lässt sie von Helfern schreiben, die jeweils in einer eigenen Sandbox arbeiten, prüft jede Änderung mit der CI deines Repositorys und einem unabhängigen Review, mergt sie und zeigt dir jeden Schritt, während er passiert. Es fragt dich nur, was es nicht selbst herausfinden kann, und es fragt einmal, an einem Ort.

kanman baut auf Claude Code auf. Es ergänzt alles, was ein Team darum herum braucht: jemanden, der das ganze Board in Bewegung hält, ein zweites Paar Augen auf jeder Änderung, Grenzen, die unabhängig davon gelten, was das Modell sagt, und ein Protokoll darüber, was getan wurde und warum.

Fünf Ideen, die du kennen solltest

Alles in kanman baut auf fünf Ideen auf. Jede hat ihren eigenen Teil dieser Dokumentation.

Idee	In einem Satz
kanman	Ein Teammitglied für das ganze Team, mit dem jede und jeder auch privat sprechen kann. Es erledigt die Arbeit, sagt „ich“ und zeigt seine Nachweise.
Mind	Das Board des Teams mit Outcomes und Stories und sein Gedächtnis: was kanman über deinen Code, deine Konventionen und deine Systeme weiß.
Habits	Was kanman von sich aus weiter tut, für das Team oder nur für dich: wann, was, wo und wie weit es gehen darf.
Stories	Eine Arbeit mit Akzeptanzkriterien, vom ersten Satz bis zur gemergten, geprüften Änderung.
Connections	Ein System, in dem kanman liest und handelt, mit dem, was es dort darf: aus, erst fragen oder automatisch.

Darunter liegen die Grundregeln, die jedes Team festlegt: wer im Team ist, seine Zeiten, sein Budget, seine Modelle, Repositorys und Verbindungen. Sie tun selbst nichts; sie begrenzen, was kanman tun darf.

Du sprichst mit kanman

Dein Workspace öffnet sich mit einer Unterhaltung mit kanman. Dort siehst du, was seit deinem letzten Besuch passiert ist, beantwortest, was auf dich wartet, und übergibst neue Arbeit:

Arbeit beschreiben. Schreib ein Ziel in ein paar Sätzen oder füge eine Anforderung ein. kanman macht daraus Stories auf dem Board des Teams und legt los.
Zusehen, wie es passiert. Die Zeile über dem Nachrichtenfeld zeigt, wie viele Helfer arbeiten und was jeder gerade tut.
Beantworten, was dich braucht. kanmans Fragen warten an einem Ort auf dich, mit den Optionen, die es sieht. Du antwortest einmal, und kanman macht weiter.
Nach dem Warum fragen. Frag „Warum hast du INT-241 gemergt?“, und kanman antwortet aus dem, was es damals festgehalten hat.

kanman antwortet auch in Slack und Microsoft Teams, mit derselben Stimme. Siehe Mit kanman sprechen.

So läuft die Arbeit

Stufe	Was passiert	Wo du beteiligt bist
1. Beschreiben	Du beschreibst ein Ziel oder eine Story oder schiebst eine Story nach Ready.	Du entscheidest, was zählt.
2. Planen	kanman liest das Board, den Code und die Notizen, teilt die Arbeit in Stories und legt die Reihenfolge fest.	Du siehst den Plan im Aktivitätsprotokoll und kannst ihn jederzeit ändern.
3. Umsetzen	Helfer schreiben den Code, jeder in seiner eigenen Sandbox auf seinem eigenen Branch, und öffnen einen Merge Request.	Gib eine Story an dich oder eine Kollegin, sobald ein Mensch sie übernehmen soll.
4. Prüfen	Deine CI läuft auf der Änderung. Danach prüft ein Reviewer, der die Änderung nicht geschrieben hat, sie gegen die Akzeptanzkriterien der Story.	Lies das Review am Merge Request, wenn du möchtest.
5. Mergen	Ist die CI grün und gibt das Review frei, mergt kanman.	Sieh dir die gemergte Änderung an oder frag, warum sie so umgesetzt wurde.

So läuft eine Story zeigt ein Beispiel mit Diagramm.

Was kanman verantwortet und was es nutzt

kanman verantwortet die Teile, die ein KI-Teammitglied im Team sicher machen: die Planung über das ganze Board, das unabhängige Review, die Grenzen um jede Änderung, die Fragen an Menschen und das Protokoll darüber, was passiert ist.

Es nutzt, was du bereits hast:

Claude Code schreibt den Code, auf Wunsch mit deinem eigenen Vertrag bei einem Modellanbieter.
Den Tracker. GitHub Issues, GitLab Issues oder Jira, oder kanmans eigenes Board, wenn du keinen hast.
Den Code-Host und die CI. GitHub oder GitLab, auch selbst betriebenes GitLab, und die CI-Pipelines, die deine Repositorys bereits haben.

Du ziehst weder dein Backlog noch deine Repositorys noch deinen Review-Prozess in kanman um.

Ein Teammitglied, keine Horde von Bots

In deinem Workspace gibt es genau ein kanman. Es sagt „ich“, erscheint neben deinen Kolleginnen und Kollegen in Zuweisungslisten, Notizen und auf dem Board, und jede seiner Aktionen wird unter seinem Namen festgehalten. Für die Arbeit nutzt es Helfer, die du bei der Arbeit siehst, aber du verwaltest nie eine Liste von Coding-Werkzeugen.

Grenzen, die halten

Die wichtigen Grenzen sind keine Anweisungen an ein Modell; sie werden dort durchgesetzt, wo die Aktion passiert:

kanman arbeitet nur an den Repositorys deines Teams und pusht nur eigene Branches. Deine geschützten Branches und die Merge-Regeln deines Code-Hosts gelten immer.
Eine Änderung wird nur gemergt, wenn die CI grün ist und ein Reviewer, der sie nicht geschrieben hat, sie freigegeben hat. Einen anderen Weg zum Mergen hat kanman nicht.
Tokens des Code-Hosts und Modellschlüssel erreichen die Helfer, die den Code schreiben, nie, und jede Änderung wird vor dem Push nach Zugangsdaten durchsucht.
Jeder Helfer arbeitet in seiner eigenen Sandbox, nie direkt auf der Maschine.
Jedes Team hat ein Tagesbudget. Ist es aufgebraucht, hält kanman an und sagt es.

Soll bei euch ein Mensch jeden Merge freigeben, verlange Freigaben auf dem Code-Host: kanman wartet dann wie jedes andere Teammitglied auf diese Freigabe. Siehe So prüft kanman seine Arbeit.

Für wen kanman gedacht ist

kanman ist für Engineering-Teams von etwa 5 bis 50 Personen gebaut, die bereits GitHub, GitLab oder Jira nutzen, Coding-Werkzeuge einzeln ausprobiert haben und nun ein Teammitglied wollen, das das Board des Teams gemeinsam mit dem Rest des Teams abarbeitet. Eingerichtet wird es meist von einer Engineering-Leitung, einem CTO oder einem Tech Lead. Täglich arbeiten die Entwicklerinnen und Entwickler damit, die Arbeit beschreiben, Fragen beantworten und Stories hin- und hergeben.

kanman ist kein allgemeines Projektmanagement-Werkzeug, und seine Unterhaltung ist kein Chat-Assistent für alles. Es spricht über die Arbeit deines Teams und erledigt Engineering-Arbeit, innerhalb deines Prozesses.

Wo kanman läuft

kanman Cloud: Die Arbeit läuft auf isolierten Maschinen in Frankfurt, Deutschland.
Selbst gehosteter Runner: dieselbe Umgebung als Container in deiner eigenen Infrastruktur. Er verbindet sich von innen nach außen mit kanman, du öffnest keine eingehenden Ports.

Details unter Hosting und Datenresidenz.

Nächste Schritte

Ausprobieren: Deine erste Stunde hat sechs kurze Schritte, jeder mit etwas, das du in den Chat einfügen kannst.
Den Weg der Arbeit sehen: So läuft eine Story.
kanman auf deinem eigenen Code einrichten: Ein Team einrichten.