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.
• Was erfasst wird, landet im Datensatz Liste technischer Schulden, der in Ihrem Tresor unter Data/Debt List 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: PRs im Protokoll · Diese Woche gemergt · Ihnen zugewiesene Issues · Ihre offenen Reviews · Wer ist dran · Nach Repo · Liste technischer Schulden durchgehen · Die Liste technischer Schulden, nach Stand · Zuletzt ausgeliefert und kaputt · So funktioniert dieses Dashboard.

Die Verknüpfungen auf einen Blick: Dev-Überblick schreibt in PR-Protokoll · Dev-Überblick schreibt in Dev-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 · Verwaltung technischer Schulden schreibt in Liste technischer Schulden · Liste technischer Schulden wird in Dev-Flow angezeigt · Notizen und Berichte liest Dev-Protokoll · Warteschlangen-Leser ist Relay zugeordnet · Notizen und Berichte ist Relay zugeordnet · Verwaltung technischer Schulden 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, und die Ihnen zugewiesenen Issues gezählt.
• Rechnen Sie nur dann mit einer Karte, wenn etwas liegen geblieben ist. Der Dev-Überblick liest jeden Werktagmorgen Ihre Repositorys und legt eine vor, wenn jemand seit Tagen auf ein Review wartet oder niemand Ihren eigenen Pull Request aufgegriffen hat; eine ruhige Warteschlange schickt nichts.
• Fragen Sie Relay vor dem Review, was ein Pull Request tut. Der Warteschlangen-Leser sagt aus dem Pull Request selbst, was dieser zu tun angibt, was er berührt und wie groß er ist; das Review und jeder Kommentar dazu bleiben Ihre Sache.
• Erwähnen Sie Vorfälle, Deployments und Entscheidungen nebenbei — „Prod war zwanzig Minuten down, fehlerhafte Migration“, „api 2.14 ist in Produktion“, „wir haben entschieden, den alten Endpoint abzuschalten“ —, und die Vorfallerfassung hält sie fest. Eine Entscheidung, die Sie bei der Bearbeitung eines Vorfalls getroffen haben, kommt ins Entscheidungsprotokoll von Besprechungen & Aufgaben, wenn Sie dieses Kit führen, damit sie bei Ihren anderen Entscheidungen steht; sonst kommt sie ins Dev-Protokoll. Ist ein Vorfall vorbei, bitten Sie „Notizen und Berichte“ um einen Vorfallbericht ohne Schuldzuweisung.
• Lassen Sie sich von „Notizen und Berichte“ morgens Ihre Stand-up-Notiz schreiben oder die Release Notes zu dem, was seit dem letzten Deployment gemergt wurde. Beides kommt aus dem Protokoll und aus dem, was Sie erzählen, nie aus einer Vermutung.
• Benennen Sie technische Schulden, sobald Sie darüber stolpern, und die Verwaltung technischer Schulden hält sie in Ihren Worten fest. Drücken Sie ab und zu auf dem Dashboard auf „Liste technischer Schulden durchgehen“ und bewerten Sie jeden Eintrag neu.
• Wenn ein Posten eingeplant, abgetragen oder keine Behebung wert ist, sagen Sie es, und die Zeile rückt weiter. Abgetragene Schulden bleiben in der Liste technischer Schulden, als Nachweis dessen, was in Ordnung gebracht wurde. Fragen Sie, was darauf steht, und Relay liest es Ihnen vor, die größte Wirkung zuerst, mit dem, was jeder Posten Sie kostet; was Sie abtragen, entscheiden Sie.
• 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?“. Sagen Sie Relay, welche Repositorys zählen und was als liegen geblieben gilt, und denken Sie daran, dass es hier keinen Blick auf die CI gibt: Das Dashboard zeigt 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.
• Wie Ihre Stand-up-Notiz aufgebaut ist und welche Repositorys die Release Notes abdecken.
• Was als technische Schuld gilt, die festgehalten werden soll, und wie Sie sie bewerten.

Ihr erster Lauf

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

1. Beim Hinzufügen des Kits wird Ihnen der erste Überblick gleich angeboten: Sobald GitHub unter Konnektoren verbunden ist, starten Sie ihn mit einem Tipp, und Relay liest Ihre Repositorys — jeden offenen Pull Request, den Sie geschrieben haben oder prüfen sollen, wer dran ist und wie lange er schon wartet. Lieber ohne ihn anfangen? Erzählen Sie Relay, was ausgeliefert wurde oder kaputtging, und es kommt ins Dev-Protokoll.
2. So oder so geht Relay von dem aus, was 1Presence schon weiß: Ihrem Gedächtnis und allen Vorfallnotizen, Release-Notes oder To-do-Listen in Ihrem Tresor. Relay bietet an, was es findet, und Sie bestätigen es mit einem Ja, bevor etwas in eine Liste kommt; gefragt wird nur nach den Lücken.
3. Wenn der Überblick durch ist, hinterlässt Relay eine kurze Notiz und lädt zu ein paar gemeinsamen Minuten ein, um zu ergänzen, was GitHub nicht zeigen kann: welche Repositorys zählen, was für Sie als liegen geblieben gilt, was zuletzt ausgeliefert wurde, live ging oder kaputtging, eine Entscheidung, die es wert ist, festgehalten zu werden, und technische Schulden, über die Sie immer wieder stolpern.
4. Was noch offen ist, wartet auf der Kit-Seite mit einem Weg zurück zu Relay, und Relay bietet es beim nächsten Gespräch einmal an. Sagen Sie Relay, dass ein Teil für Sie nicht zutrifft oder dass Sie mit der Einrichtung fertig sind, dann hört Relay auf zu fragen.
5. Er meldet nur, was wirklich liegen geblieben ist. Eine Warteschlange in gutem Zustand erzeugt überhaupt keine Karte.
6. Erwähnen Sie nebenbei einen Vorfall, ein Deployment oder eine Entscheidung, und es landet im Dev-Protokoll, in den Worten, die Sie damals gewählt haben.
7. 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