Engineering Analytics - Lieferung und Entwickler

Engineering Analytics macht aus den Daten, die AppArch ohnehin sammelt (Merge Requests, Scans, Deployments, Issues, Incidents), Liefermetriken. Eine Regel gilt auf jedem Bildschirm: Was nicht gemessen werden kann, wird als nicht gemessen gezeigt, nie als Null, und zwei nebeneinander gezeigte Reihen werden nie als Ursache und Wirkung ausgegeben.

Projekt-Gesundheitskarte (/reports/health)

Jede Bewertung, die die Plattform pro Projekt führt, auf einer Karte: ArchScan, ArchSecurity, Compliance, Git Health und der aus SonarQube abgeleitete Wert (Zuverlässigkeits-, Sicherheits- und Wartbarkeitsnoten als A=100 … E=20), jeweils als jüngster 0-100-Wert des Werkzeugs oder ein Strich, wenn es das Projekt nie bewertet hat.

• Konsens - der Durchschnitt der vorhandenen Quellen, immer mit ihrer Anzahl (“aus 3 Quellen”). Kein gewichteter Index; eine fehlende Quelle zählt nie als null.
• Bewertet von - wie viele Projekte jede Linse tatsächlich gesehen hat.
• Werkzeuge widersprechen sich - Projekte, bei denen ArchScan und der Sonar-Wert 20 oder mehr Punkte auseinanderliegen, mit Richtung (“Sonar milder” / “Sonar strenger”). Kein Urteil über ein Werkzeug, sondern ein Ort zum Hinsehen.
• Alle Linsen grün - jede bewertende Quelle bei 80 oder mehr, mit mindestens zwei Quellen.
• Externe Befunde - offene GitLab- und SonarQube-Sicherheitsbefunde pro Projekt (gesamt, kritisch, hoch) als Zahlen unter dem ArchSecurity-Wert; sie gehen nie in den Konsens ein. Eine Kachel summiert die offenen kritischen Befunde der Karte.
• Trendlinien pro Projekt für ArchScan und Sonar im gewählten Zeitraum, Sonar-Quality-Gate, Abdeckung und Duplikation sowie ein Projektgruppenfilter.

MR Insights (/reports/mr-insights)

Jeder Merge Request jedes verbundenen Projekts wird alle 30 Minuten synchronisiert: Autor, Status, Zeiten für Öffnen/Merge/Schließen, wer gemergt hat, Größe (Hinzufügungen, Löschungen, geänderte Dateien) und Zeitpunkt des ersten Reviews.

• Wöchentlicher Durchsatz - geöffnet, gemergt und geschlossen pro Woche.
• Risikoliste - Merges bewertet nach Größe, Self-Merge, fehlender Freigabe und fehlenden Review-Kommentaren; die höchsten zuerst.
• Symptome - große MRs, lange Review-Wartezeiten, Self-Merges, ungeprüfte Merges, jeweils mit den Zahlen dahinter.
• Aktivitäts-Heatmap - “wann landet Arbeit”: 7 Tage x 24 Stunden in der Zeitzone des Betrachters, Öffnen und Merge zusammen. Merges außerhalb Montag-Freitag 08:00-19:59 Ortszeit werden getrennt gezählt - nicht als Urteil, sondern als Frage.
• Review-Abdeckung - Anteil der gemergten MRs (mit synchronisierten Kommentaren), die mindestens einen gezählten menschlichen Kommentar von jemand anderem als dem Autor erhielten; der Rest wurde still gemergt. Nutzt die Review-Kommentar-Urteile, Bestätigungen zählen nicht als Review.

Freigabespalten decken nur die MRs ab, die ArchPilot gesehen hat.

Review-Kommentare (/reports/review-comments)

Jeder menschliche Kommentar an einem synchronisierten Merge Request wird neben ihm gespeichert (GitLab, GitHub, Bitbucket Cloud und Azure DevOps; Systemereignisse wie “2 Commits hinzugefügt” und ArchPilots eigene Kommentare werden nie gespeichert). Die Frage, die der Bildschirm beantwortet, lautet wer wirklich reviewt, und ein Urteil pro Kommentar hält die Zählung ehrlich:

• Nicht beurteilt - zählt als Review-Arbeit, bis jemand etwas anderes sagt.
• Review - substanziell: eine Frage, ein Problem, ein Vorschlag, eine Entscheidung.
• Ausgeschlossen - eine Bestätigung (“danke”, “ok, mache ich”, ein Emoji). Aus jeder Zählung herausgenommen.

Ein Workspace-Owner oder -Admin setzt Urteile von Hand. Mit Moduleinstellungen > ArchPilot > Offene Kommentare mit KI klassifizieren beurteilt der KI-Anbieter der Installation alle 10 Minuten die noch nicht beurteilten Kommentare; das Urteil eines Admins wird nie überschrieben. Der Schalter erscheint nur, wenn der Instanzadministrator einen KI-Anbieter konfiguriert und mindestens eine KI-Funktion eingeschaltet hat. Die KI-Karte der Seite zeigt, was die Klassifizierung bisher gekostet hat (Aufrufe, beurteilte Kommentare, Ein- und Ausgabe-Tokens) und was der letzte Aufruf getan hat; ein Admin kann mit Offene jetzt klassifizieren sofort einen Durchlauf einreihen (bis zu 40 Kommentare, zwei Anbieteraufrufe). Die Klassifizierung verbraucht den KI-Schlüssel der Installation und zählt gegen das Assistenten-Kontingent.

Gezählte Kommentare speisen die Kachel Review-Kommentare und die Verteilung Wer kommentiert in MR Insights sowie den Wert Review-Kommentare im Entwicklerprofil. Kommentare des MR-Autors an seinem eigenen MR werden gelistet, aber nie als gegebenes Review gezählt.

AI Impact (/reports/ai-impact)

Was der KI-Anbieter der Installation diesen Workspace gekostet hat - Befund-Erklärungen, Assistentenantworten und Klassifizierungsaufrufe für Review-Kommentare (Eingabe-/Ausgabe-Tokens, Neuerzeugungen, je Person und Modell; die letzten beiden gelten für den ganzen Workspace und zählen nur in der Ansicht aller Projekte) neben dem, was sich in denselben Wochen geändert hat: ArchScan-Score, ArchPilot-Befunddichte, gemergte Features und Fixes. Die Fußnote sagt es klar: Die Reihen stehen nebeneinander, Kausalität wird nicht behauptet.

DORA (/reports/dora)

Alle vier Metriken werden gezeigt; die zwei, die Incident-Daten brauchen, bleiben leer, bis eine Incident-Quelle verbunden ist.

Metrik	Quelle	Hinweise
Deployment-Frequenz	Deployment-Ereignisse des Katalogs (Argo CD, Kubernetes, Flux)	Der Deployment-Zeitpunkt ist eine Beobachtung mit bis zu 10 Minuten Verzögerung, kein Webhook. Reine Kubernetes-Quellen melden Image-Tags statt Commits und zählen als nicht nachverfolgbar.
Lead Time	Vom Merge (MR-Fakten) bis zum Deployment, das den Commit trägt	Je Umgebung; eine nicht zugeordnete Revision ist unbekannt, nie Null. Die Phasenaufteilung zeigt Warten auf Review, im Review und Warten auf Auslieferung; die zwei nicht gemessenen Phasen werden grau gezeichnet.
Change Failure Rate	Incidents, die innerhalb einer Stunde nach einem Deployment desselben Service geöffnet wurden	Zeitliche Korrelation, kein Ursachenbeweis - die Seite sagt es.
Time to Recover	Von Incident-Öffnung bis Incident-Schluss	Gleiche Quelle.

Die Bänder Elite/hoch/mittel/niedrig sind eine Näherung der wöchentlichen Kadenz und stehen neben der echten Zahl, nie an ihrer Stelle. Phasen-Mediane sind unabhängig; sie summieren sich nicht zum Gesamt-Median.

Issue-Flow (/reports/issue-flow)

Mit einer Jira-Verbindung werden Issues alle 30 Minuten zurückgelesen und der Fluss aus dem Changelog jedes Issues abgeleitet: der erste Übergang aus new startet die Uhr, der letzte Übergang nach done stoppt sie. Durchsatz, Zykluszeit, laufende Arbeit und Alterung werden mit sieben Alarmen berichtet (WIP-Überlast, veraltete laufende Arbeit, alternder Backlog, nicht zugewiesene laufende Arbeit, wiedereröffnet, fehlerlastig, geringe Flow-Abdeckung). Unteraufgaben zählen nicht zum Durchsatz, damit ein Team, das jede Story in sechs Teile zerlegt, nicht sechsmal schneller aussieht.

Incident-Quellen

Dynatrace- und New-Relic-Incidents werden in den Workspace geholt und über den Namen Services zugeordnet. Nicht zugeordnete Incidents werden gezählt und angezeigt; eine verbundene Plattform ohne einen einzigen gespeicherten Incident erhält eine eigene Warnung, denn ein auf das falsche Konto beschränkter Token validiert einwandfrei und liefert dann nichts - was DORA sonst als 0 % Fehlerrate lesen würde.

Compliance- & Git-Health-Verlauf (/reports/score-history)

Beide Werte über die Zeit. Der Wochenwert eines Projekts ist sein letzter erfolgreicher Scan dieser Woche; die Gesamtlinie ist der Mittelwert über die in der Woche gescannten Projekte und nennt deren Zahl. Wochen ohne Scan sind Lücken, nie fortgeschrieben. Je Projekt: letzter Wert, Änderung zwischen erstem und letztem Scan im Zeitraum, Scananzahl und Trendlinie; Kacheln zeigen den aktuellen Durchschnitt, die mittlere Änderung und die Zahl verbesserter und verschlechterter Projekte.

Trend der Sicherheitsbefunde (/reports/security-trend)

GitLab- und SonarQube-Befunde als Lebenszyklus. Das Erkennungsdatum stammt vom Anbieter; ein Befund gilt als geschlossen, sobald eine Synchronisation ihn nicht mehr offen sieht (gelöst oder verworfen). Aus diesen beiden Daten rekonstruiert die Seite je Woche und Quelle neue, geschlossene und am Wochenende offene Befunde - rekonstruiert, nicht gesampelt, daher gibt es Verlauf für Wochen vor dem ersten Öffnen der Seite. Kacheln: jetzt offen (mit kritischen), neu und geschlossen im Zeitraum, Nettoänderung, Median der Tage bis zur Schließung. Tabellen je Quelle und Projekt. AppArchs eigene ArchSecurity-Scans sind Momentaufnahmen je Lauf und nicht Teil dieses Lebenszyklus.

ADR-Lebenszyklus (/reports/adrs)

Architekturentscheidungen als Prozess: Anzahl je Status, offene Vorschläge mit medianem Alter, Entscheidungen je Monat nach Ergebnis, mittlere Tage von Anlage bis Entscheidung, Annahmequote, ersetzte Entscheidungen, Tags und Verteilung je Projekt. Vorschläge älter als 30 Tage werden älteste zuerst gelistet - ein Vorschlag, den niemand entscheidet, ist eine Entscheidung per Voreinstellung.

Zugriff vs. Beitrag (/reports/developer-access)

Für jeden synchronisierten Entwickler: die Projekte, in denen er laut Anbieter Mitglied ist, die, in denen er im Zeitraum aktiv war (Merge Request eröffnet oder gezählter Review-Kommentar geschrieben), und die ruhenden Mitgliedschaften - Zugriff ohne Aktivität. Auch umgekehrt: Beiträge in Projekten, in denen der Anbieter ihn nicht als Mitglied führt. Ruhen wird nur für Projekte mit synchronisierten Merge Requests behauptet; die Seite nennt deren Zahl. Dienstkonten werden gelistet, aber aus den Kacheln ausgenommen.

Entwickler (/developers)

Jede Person, die ein verbundenes Repository berührt (Mitglieder und MR-Autoren), wird je Projekt synchronisiert - nur für Projekte, in denen die Entwickler-Synchronisation eingeschaltet ist (standardmäßig aus). Jeder Entwickler bekommt ein Profil (/developers/{id}) mit den berührten Projekten, den verfassten MRs und einem ArchPilot-basierten Review-Score. Bots werden aus Provider-Signalen erkannt und als Service-Konten markiert; die Markierung lässt sich von Hand setzen oder entfernen, und eine manuelle Markierung wird von der Synchronisation nie überschrieben.

Voraussetzungen

• Git-Zugangsdaten mit Pull-Request-Zugriff für MR Insights, die Heatmap und Entwickler.
• Eine Deployment-Quelle (Argo CD, Kubernetes, Flux) für Deployment-Frequenz und Lead Time.
• Jira für den Issue-Flow; Dynatrace oder New Relic für Change Failure Rate und Time to Recover.
• AI Impact braucht den KI-Anbieter der Installation, den der Betreiber einrichtet (KI); einen Schlüssel pro Workspace gibt es nicht.