Dev-Flow

So funktioniert es

Die Mechanik dieses Kits, schlicht gesagt – was wann läuft, wo die Daten landen und worauf Sie schauen.

• Dev-Überblick läuft werktags morgens · 8 Uhr und hält das Dashboard Dev-Flow aktuell. Werktags morgens — wer dran ist und was liegen geblieben ist.
• Was erfasst wird, landet im Datensatz PR-Protokoll, der in Ihrem Tresor unter Data/PR Log liegt — Sie können ihn öffnen, durchsuchen und bearbeiten wie jede andere Datei.
• Was erfasst wird, landet im Datensatz Dev-Protokoll, der in Ihrem Tresor unter Data/Dev Log liegt — Sie können ihn öffnen, durchsuchen und bearbeiten wie jede andere Datei.
• Das Dashboard Dev-Flow liest aus dem Datensatz und zeigt auf einen Blick: Offene PRs · Diese Woche gemergt · Ihre offenen Reviews · Wer ist dran · Nach Repo · Alle offenen PRs · Das Dev-Protokoll.

Die Verknüpfungen auf einen Blick: Dev-Überblick schreibt in PR-Protokoll · Vorfallerfassung schreibt in Dev-Protokoll · PR-Protokoll wird in Dev-Flow angezeigt · Dev-Protokoll wird in Dev-Flow angezeigt · Dev-Flow wird von Dev-Überblick aktuell gehalten · Vorfallerfassung ist Relay zugeordnet · Dev-Rückblick ist Relay zugeordnet.

Das Beste daraus machen

Ein Kit verdient sich seinen Platz, wenn es verändert, worauf Sie schauen und was Sie sagen – nicht mit der Installation. Das ist der Rhythmus, der sich auszahlt.

• Öffnen Sie Dev-Flow, bevor Sie einen Tab öffnen. Der Überblick hat bereits jeden offenen Pull Request danach sortiert, wer dran ist und wie lange er schon liegt.
• Erwähnen Sie Vorfälle und Entscheidungen nebenbei — „wir haben entschieden, den alten Endpoint abzuschalten“, „Prod war zwanzig Minuten down, fehlerhafte Migration“ —, und die Vorfallerfassung hält sie fest.
• Fragen Sie den Dev-Rückblick, wenn die Diskussion beginnt: „Was haben wir im Juni ausgeliefert?“, „Warum haben wir uns für diese Datenbank entschieden?“ — beantwortet aus dem Protokoll.
• Sagen Sie Relay, welche Repositorys zählen und was als liegen geblieben gilt. Der Überblick wird dann leiser.
• Denken Sie daran, was hier nicht zu sehen ist: Es gibt keinen Blick auf die CI, das Dashboard zeigt also den Stand der Pull Requests und nichts weiter.

Machen Sie es zu Ihrem

Nichts hier ist in Stein gemeißelt. Die Teile sind ganz normale Agenten, Routinen, Datensätze und Dashboards – alles, was Sie über deren Gestaltung wissen, gilt auch hier. Legen Sie still, was nichts einbringt.

Was Leute meist zuerst ändern

Sagen Sie eines davon im Chat oder bearbeiten Sie es auf der Kit-Seite in der App.

• Wie viele Tage als liegen geblieben gelten, getrennt für Reviews, die Sie schulden, und Ihre eigene wartende Arbeit.
• Welche Repositorys beobachtet werden.
• Wann der Überblick kommt, oder die Karten abschalten und nur das Dashboard behalten.
• Was ins Dev-Protokoll gehört — manche erfassen nur Vorfälle, manche jede Entscheidung.

Ihr erster Lauf

Bei der Installation beginnt ein kurzes Einrichtungsgespräch – kein Formular. Antworten Sie ungefähr und korrigieren Sie später.

1. Am ersten Werktagmorgen liest der Überblick Ihre Repositorys und füllt das Dashboard mit dem, was offen ist und wer dran ist — ohne weitere Einrichtung, als GitHub zu verbinden.
2. Er meldet nur, was wirklich liegen geblieben ist. Eine Warteschlange in gutem Zustand erzeugt überhaupt keine Karte.
3. Erwähnen Sie nebenbei einen Vorfall oder eine Entscheidung, und es landet im Dev-Protokoll, in den Worten, die Sie damals gewählt haben.
4. Den Build-Status kann er nicht sehen — der Konnektor hat kein CI-Tool —, deshalb meldet er nie, ob ein Build durchlief oder main grün ist.

Sehen Sie sich den ersten Durchgang an und sagen Sie dann, was Sie anders gemacht hätten – diese Korrektur lehrt es mehr als jede Einrichtung.

Das Wesentliche

Lernen, Präferenzen und Laufkosten funktionieren in jedem Kit gleich – deshalb werden sie einmal erklärt, im Kits-Leitfaden.

Mit einem Kit leben – der Kits-Leitfaden →

← Alle Kits