Zum Inhalt springen

Pilot

Sechs Wochen. Ein Team. Ein Repo. Echte Stories.

Ihr seht kanman an eurem Backlog arbeiten, nach euren Regeln, mit Nachweisen für jede Änderung. Am Ende entscheidet ihr auf Basis von Ergebnissen, nicht einer Demo.

Festpreis ab 5.000 € für 6 Wochen

Die sechs Wochen

Was passiert, Woche für Woche

  1. Woche 1

    Einrichtung

    Wir verbinden gemeinsam euren Tracker und euer Repo, wählen das Preset Testphase, und kanman öffnet den Pull Request mit eurem Akzeptanz-Manifest.

  2. Wochen 2-3

    Erste Stories

    kanman nimmt echte Stories aus eurem Backlog. Jeder Pull Request kommt mit einem Nachweispaket. Ihr reviewt wie gewohnt.

  3. Wochen 4-5

    Eure Regeln

    Wir stimmen die Richtlinie mit euch ab. Was kanman anfassen darf, die Budgets, welche Entscheidungen zu euch kommen. Die meisten Teams wechseln hier auf Ausgewogen.

  4. Woche 6

    Ergebnis

    Eine schriftliche Auswertung, was geliefert wurde, was Nacharbeit brauchte, was es gekostet hat und was wir ändern würden. Alles davon behaltet ihr.

Was euer Team mitbringt

  • Ein Repo auf GitHub oder GitLab, mit GitHub Issues, Jira oder GitLab als Tracker
  • Einen Tech Lead, der kanmans Pull Requests reviewt, etwa zwei Stunden pro Woche
  • Eine CI-Pipeline, die eure Tests ausführt. Ist sie dünn, helfen wir.
  • Zugang zu Modellen, entweder über eure eigenen Schlüssel oder über kanman zum Selbstkostenpreis plus 15 %

Was wir mitbringen

  • Die Einrichtung in einer gemeinsamen Session mit eurem Team
  • Den Pull Request mit dem Akzeptanz-Manifest für euer Repo
  • Jede Woche 30 Minuten Review mit euch
  • Die schriftliche Auswertung am Ende

Was ihr bei jedem Pull Request bekommt

Das Nachweispaket

Akzeptanzkriterien, die Spec, die sie geprüft hat, wo sie lief und was es gekostet hat. Am Pull Request und an der Story.

Nachweispaket

INV-41 Rechnungen als CSV exportieren

Outcome-Gate bestanden

Akzeptanzkriterien

  • Der Export-Button lädt eine .csv-Datei herunter bestanden
  • Eine Zeile pro Rechnung im gewählten Zeitraum bestanden
  • Beträge nutzen den gemeinsamen Geldformatierer bestanden
  • Ein leerer Zeitraum zeigt einen Hinweis und keine Datei bestanden
Spec
.kanman/acceptance/INV-41/export.spec.ts
Geschrieben
bei der Aufnahme, rot vor Bereit
Lief auf
frischem Checkout von 4e1c9a7
Dauer
41,6 s
Kosten des Runs
0,84 €
Trace-Vorschau: die Rechnungsseite mit gedrücktem Button CSV exportieren und der heruntergeladenen Datei.
Illustration Eine Aufnahme aus der Demo-Sandbox ersetzt sie.

Der Ablauf

Was jede Story durchläuft

  1. 1. Aufnahme

    Anforderung einfügen oder kanman in Slack taggen. Ihr bekommt Stories mit Akzeptanzkriterien und einem Weg, jedes davon vorzuführen.

  2. 2. Regeln

    Eure Richtlinie legt fest, was kanman anfassen, ausgeben und mergen darf. Große Entscheidungen kommen mit Empfehlung zu euch.

  3. 3. Arbeit

    Claude Code oder Codex schreibt den Code in einer Sandbox. kanman wählt das Modell nach Komplexität, damit kleine Fixes günstig bleiben.

  4. 4. Beweis

    Bevor etwas ins Review geht, läuft eine Akzeptanzspezifikation gegen eine frische Umgebung. Keine Spec, kein Bereit. Kein grüner Durchlauf, kein Review.

  5. 5. Übergabe

    Ein Pull Request mit angehängten Nachweisen. Eure Leute reviewen und mergen, oder eure Richtlinie tut es.

Eine neue Datei

Euer Repo bekommt ein Akzeptanz-Manifest

Es sagt kanman, wie eure App startet und wie die Spec einer Story auf einem frischen Checkout läuft. kanman öffnet den Pull Request dafür in der ersten Woche, und ihr reviewt ihn wie jede andere Änderung.

.kanman/acceptance.json
{
  "version": 1,
  "provision": {
    "type": "docker_compose",
    "file": "docker-compose.acceptance.yml"
  },
  "ready_url": "http://localhost:3000/api/invoices",
  "ready_timeout_seconds": 120,
  "setup": "npm ci && npx playwright install --with-deps chromium",
  "run": {
    "command": "npx playwright test",
    "spec_arg": ".kanman/acceptance/{KEY}/",
    "env": { "BASE_URL": "http://localhost:3000" }
  },
  "spec_dir": ".kanman/acceptance/{KEY}",
  "artifacts": ["test-results/**/trace.zip", "test-results/**/*.png"]
}

Beispiel aus der kanman-Pilot-Sandbox: eine Docker-Compose-App mit Playwright-Specs. {KEY} wird durch den Story-Key ersetzt.

Pilot anfragen

Erzählt uns von eurem Team

Wir antworten innerhalb von zwei Werktagen und schlagen ein 30-minütiges Gespräch vor. Keine Folien, nur euer Backlog und unsere Fragen. Der Pilot läuft über ein kurzes Bestellformular nach unseren AGB, und der Auftragsverarbeitungsvertrag ist unterschrieben, bevor kanman Code anfasst.

Wir nutzen die Angaben nur, um diese Anfrage zu beantworten. Mehr dazu in unserer Datenschutz.

FAQ

Fragen zum Pilot

Was kostet der Betrieb, und wie funktionieren Budgets?
Der Team-Plan hat einen festen Preis pro KI-Team, zu finden im Preisabschnitt. Die Modellnutzung kommt dazu, über eure eigenen Schlüssel oder zum Selbstkostenpreis plus 15 %. Ihr setzt Budgets pro Run, pro Tag und pro Monat mit harten Grenzen. Incident-Arbeit wird nie durch ein Budget blockiert. In den Docs lesen (öffnet in einem neuen Tab)
Ist kanman in unseren Slack- oder Microsoft-Teams-Unterhaltungen dabei?
Nur dort, wo ihr es hinzufügt. Es beantwortet Fragen zur Arbeit des Teams mit Links und Quellen und macht aus Wünschen Story-Entwürfe, die eine Teamleitung freigibt, bevor etwas auf das Board kommt. Standardmäßig spricht es nur, wenn ihr es erwähnt. Pro Channel könnt ihr zulassen, dass es sich von selbst meldet, mit Tageslimit, Ruhezeiten und einem Stopp-Button an jeder ungefragten Antwort. In den Docs lesen (öffnet in einem neuen Tab)
Kann es allein nach main mergen?
Nur wenn eure Richtlinie das erlaubt. Standardmäßig reviewt und merged ein Mensch. Automatische Merges könnt ihr für kleine Änderungen freigeben: alle Gates grün und der Diff unter einer Zeilengrenze, die ihr festlegt. Solange main rot ist, hält kanman sie zurück. In den Docs lesen (öffnet in einem neuen Tab)
Wo wird unser Code verarbeitet und gespeichert? Was sehen die Modellanbieter?
kanman läuft in der EU. Der Code entsteht in Sandboxes in Frankfurt, und jeder Run bekommt eine frische Sandbox, die danach verworfen wird. Modellanbieter sehen die Prompts und den Code-Kontext, die ein Run braucht, unter eurem eigenen Vertrag, wenn ihr eigene Schlüssel nutzt. Mit dem Self-hosted Runner bleibt die Code-Ausführung in eurem Netzwerk. In den Docs lesen (öffnet in einem neuen Tab)