Wartungsmodus

Mit dem Preset Härtung pflegt kanman die Codebasis zwischen den Stories: Abhängigkeiten, Schwachstellen, kaputte Links und Drift, als stetiger, begrenzter Strom kleiner Stories.

Die meisten Teams kennen ihren Wartungs-Backlog und kommen nie dazu. Der Wartungsmodus ist die proaktive Seite von kanman: Er prüft das Repository regelmäßig und macht aus sicheren Befunden, die das Verhalten nicht ändern, kleine Stories, mit derselben Richtlinie, demselben Gate und demselben Budget wie alles andere.

Einschalten

Der Wartungsmodus gehört zum Preset Härtung (hardening): Wählen Sie es im Team unter Einstellungen > Richtlinie. Einstellungen > Wartung zeigt, ob die Wartung an ist, ihre Grenzen und die Funde, mit dem Link In der Richtlinie ändern, um das Preset zu wechseln. Die Einstellungen liegen im Richtlinienobjekt maintenance:

Feld Angezeigt als Bedeutung Standard in Härtung
enabled Status Wartung an oder aus true
dripPerDay Neue Wartungsarbeit pro Tag Wie viele Wartungs-Stories und Vorschläge pro Tag angelegt werden und wie viele Wartungs-Runs pro Tag starten dürfen 2
maxPerRun Höchstens pro Scan Wie viele Befunde ein Scan anlegen darf 1
allowedKinds Ohne Rückfrage angelegt Welche Arten von Befunden ohne Entscheidung zu Stories werden cve, outdated_dep, unused_dep, lockfile_drift, broken_doc_link

Wie oft die Scanner laufen, legt cadence.scannerDays fest (standardmäßig alle 7 Tage). kanman verteilt die Scans verschiedener Teams über diese Tage. Pausierte Teams werden nicht gescannt.

Wonach kanman sucht

kanman liest die Repositorys aus allowed_repos des Teams auf GitHub oder GitLab, ohne sie zu klonen und ohne in sie zu schreiben.

Scanner sind deterministische Werkzeuge, nicht die Meinung eines Modells:

Art Findet
cve Abhängigkeiten mit bekannten Schwachstellen
outdated_dep Veraltete Abhängigkeiten
unused_dep Abhängigkeiten, die nichts importiert
license Lizenzen von Abhängigkeiten, die Aufmerksamkeit brauchen
lockfile_drift Lockfiles, die nicht mehr zum Manifest passen
broken_doc_link Kaputte Links in der Dokumentation
oversized_module Module, die zu groß geworden sind
stale_flag Feature-Flags, die immer an oder immer aus sind

Die Abhängigkeits-Scanner decken npm-Projekte ab.

Kommt in einem späteren Release

Die Suche nach ungenutzten Abhängigkeiten und veralteten Feature-Flags braucht einen Checkout des Repositorys und kommt in einem späteren Release. Paketmanager außer npm folgen ebenfalls später.

Reviewer lesen, ohne etwas zu ändern. Jeder Scan führt einen davon aus, im Wechsel: Nacharbeiten nach dem Merge, ein Architektur-Review, veraltete Dokumentation und Testqualität. Sie sehen sich aktuelle Runs und einige Dateien an. Ihre Befunde werden gemeldet und erreichen Sie als Vorschläge.

Die Funde erscheinen unter Einstellungen > Wartung, gefiltert nach Offen, Angelegt, Verworfen, Erledigt und Duplikate. Ein Scanner-Fund, den ein späterer Scan nicht mehr sieht, gilt als erledigt.

Leitplanken

  • Nur erlaubte Arten. Nur verhaltensneutrale Arten aus allowedKinds werden direkt zu Stories, und nur die fünf Arten aus dem Standard von Härtung können überhaupt erlaubt werden. Sie landen in der Spalte Verfeinerung des Teams (im Backlog, wenn es keine gibt), durchlaufen also die Bereitschaftsprüfung und die Akzeptanz-Spec wie jede Story. Alles andere wird zu einem Wartungsvorschlag. Steht intake_scope auf humans_only, werden auch erlaubte Arten zu Vorschlägen, sodass nur Stories entstehen, die eine Person annimmt.
  • Begrenzung pro Scan. maxPerRun hält die Ausbeute jedes Scans klein und leicht zu prüfen.
  • Keine Duplikate. Jeder Befund hat einen Fingerabdruck, wird also einmal gespeichert und beim erneuten Sehen gezählt. kanman sucht vor dem Anlegen nach ähnlichen offenen Stories und Vorschlägen und räumt jeden Montag doppelte Funde auf.
  • Stetiger Strom. dripPerDay begrenzt, wie viele Wartungs-Stories und Vorschläge pro Tag angelegt werden und wie viele Wartungs-Runs starten, damit Feature-Arbeit Vorrang behält.
  • Nie ausgehungert. Befunde gewinnen mit jedem Tag Wartezeit an Priorität, und ein Befund, der älter als 21 Tage ist, kommt zuerst dran.
  • Dringendes zuerst. Kritische Befunde und als hoch eingestufte Schwachstellen umgehen Tageslimit und Begrenzung und werden als expedite angelegt.
  • Gleiches Gate, gleiches Budget. Wartungs-Stories laufen durch das Outcome-Gate und zählen wie jede andere Story zu den Team-Budgets. Ihre Serviceklasse ist maintenance.

Vorschläge für größere Änderungen

Befunde, die nicht auf der erlaubten Liste stehen, erreichen den Entscheidungseingang als Wartungsvorschläge mit kanmans Empfehlung: Als Story anlegen oder Verwerfen. Ein verworfener Befund bleibt verworfen.

Bei eingeschalteter Wartung liest außerdem ein Stratege alle drei Tage STRATEGY.md, docs/STRATEGY.md oder .kanman/STRATEGY.md in Ihrem Repository und schlägt bis zu drei Features vor, jeweils mit dem Ziel, dem es dient, Nutzen, Aufwand, Risiko und Alternativen. Jeder Vorschlag ist eine Entscheidung Strategievorschlag: Start intake macht daraus eine Anforderung des Teams, die wie jede andere eingeordnet und entworfen wird; Decline merkt sich kanman und schlägt dieselbe Idee nicht erneut vor. Teams ohne Strategie-Datei bekommen keine Vorschläge.

Verwandte Seiten

Zuletzt aktualisiert: January 1, 0001

kanman öffnen