Ihr Daten-Template für den Softwareentwicklungszyklus

GitHub
Ihr Daten-Template für den Softwareentwicklungszyklus

Ihr Daten-Template für den Softwareentwicklungszyklus

Dieses Template zeigt Ihnen, wie Sie Daten zum Softwareentwicklungszyklus aus GitHub erfassen und aufbereiten. Es enthält empfohlene Attribute, wichtige Aktivitäten für die Nachverfolgung und praktische Hinweise zur Datenextraktion. Damit erstellen Sie ein präzises Event Log für eine aussagekräftige Prozessanalyse und Optimierung.
  • Empfohlene Attribute für die Erfassung
  • Wichtige Aktivitäten für die Nachverfolgung
  • Hinweise zur Datenextraktion
Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Attribute des Softwareentwicklungszyklus

Diese empfohlenen Datenfelder sollten Sie in Ihr Event Log aufnehmen, um den Softwareentwicklungszyklus umfassend zu analysieren und den Prozess zu entdecken.
3 Erforderlich 5 Empfohlen 15 Optional
Name Beschreibung
Aktivität
ActivityName
Der Name eines bestimmten Ereignisses oder einer Aufgabe im Softwareentwicklungslebenszyklus.
Beschreibung

Der Aktivitätsname bezeichnet einen einzelnen Schritt im Entwicklungsprozess, etwa 'Issue erstellt', 'Code an PR übertragen', 'Pull Request genehmigt' oder 'Bereitstellung erfolgreich'. Diese Ereignisse bilden die Abfolge der Schritte, aus denen der End-to-End-Prozess eines Entwicklungsvorgangs besteht.

Dieses Attribut ist grundlegend für Process Mining, da es zum Aufbau der Prozesslandkarte dient. Die Analyse von Abfolge, Häufigkeit und Dauer der Aktivitäten zeigt den tatsächlichen Prozessablauf, macht häufige Pfade und Abweichungen sichtbar und hilft, Engpässe zu lokalisieren.

Warum das wichtig ist

Dieses Attribut bildet das Rückgrat der Prozesslandkarte und ermöglicht es, die Abfolge der Ereignisse im Entwicklungslebenszyklus zu visualisieren und zu analysieren.

Woher beziehen

Abgeleitet aus dem Feld 'action' in Webhook-Ereignis-Payloads, etwa 'opened' oder 'closed' für ein Issue, oder aus dem Ereignistyp selbst, etwa 'PushEvent' oder 'PullRequestReviewEvent'.

Beispiele
Issue erstelltPull Request eröffnetCode an PR übertragenReview angefordertPull Request zusammengeführt
Entwicklungsvorgang
DevelopmentItemId
Die eindeutige Kennung für eine einzelne Entwicklungseinheit, etwa eine Funktion, eine Fehlerbehebung oder eine Aufgabe. Sie dient als primäre Case-ID.
Beschreibung

Die ID des Entwicklungsvorgangs verfolgt einen Arbeitsvorgang von seiner Erstellung bis zur endgültigen Bereitstellung. Sie verknüpft alle zugehörigen Aktivitäten, etwa die Erstellung eines Branches, Commits, Pull Requests, Reviews und Bereitstellungen, zu einer zusammenhängenden Prozessinstanz.

Bei der Analyse dient diese ID dazu, die End-to-End-Zykluszeit einer Entwicklungsaufgabe zu berechnen. Sie ermöglicht es, den gesamten Verlauf einer Funktion oder Fehlerbehebung nachzuvollziehen und Engpässe, Nacharbeitsschleifen sowie Prozessabweichungen für einzelne Arbeitsvorgänge detailliert zu analysieren.

Warum das wichtig ist

Diese ID ist der zentrale Schlüssel für Process Mining. Sie führt alle zugehörigen Entwicklungsereignisse in einem einzelnen Case zusammen, damit sich der gesamte Softwareentwicklungslebenszyklus präzise visualisieren und analysieren lässt.

Woher beziehen

In der Regel handelt es sich um die Issue-Nummer oder Pull-Request-Nummer aus GitHub. Sie lässt sich aus dem Feld 'number' im Payload zugehöriger Issue- oder Pull-Request-Webhook-Ereignisse beziehungsweise API-Antworten auslesen.

Beispiele
101PR-2345TASK-812
Startzeit
EventTimestamp
Das genaue Datum und die Uhrzeit, zu denen eine bestimmte Entwicklungsaktivität oder ein Ereignis stattgefunden hat.
Beschreibung

Dieser Timestamp markiert den Beginn einer Aktivität. Er ist entscheidend, um Ereignisse chronologisch zu ordnen und den Prozessablauf für jeden Entwicklungsvorgang nachzuvollziehen. Die Reihenfolge und Zeitabstände zwischen diesen Timestamps dienen der Analyse der Prozessleistung.

Bei der Analyse ist dieses Attribut für die Berechnung aller zeitbasierten Kennzahlen erforderlich, darunter Zyklus-, Verarbeitungs- und Wartezeiten. Es macht Verzögerungen zwischen Schritten sichtbar und liefert die Daten für Engpassanalysen und Dashboards zur Leistungsüberwachung.

Warum das wichtig ist

Dieser Timestamp ist entscheidend, um Ereignisse korrekt zu ordnen und alle Leistungskennzahlen zu berechnen, etwa Zykluszeiten und die Dauer von Engpässen.

Woher beziehen

Die Felder 'created_at' oder 'updated_at' in JSON-Payloads der GitHub-APIs und Webhooks enthalten diese Angaben üblicherweise für Objekte wie Issues, Pull Requests und Commits.

Beispiele
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Endzeit
EndTimestamp
Das genaue Datum und die Uhrzeit, zu denen eine bestimmte Entwicklungsaktivität oder ein Ereignis abgeschlossen wurde.
Beschreibung

Der End-Timestamp markiert den Abschluss einer Aktivität. Viele Ereignisse in GitHub treten unmittelbar ein, etwa 'Issue erstellt'. Andere Aktivitäten haben eine messbare Dauer, zum Beispiel die Ausführung einer CI-Prüfung. Die Differenz zwischen Endzeit und Startzeit ergibt die Verarbeitungszeit einer Aktivität.

Dieses Attribut dient zur Berechnung der Kennzahl 'ProcessingTime'. Sie ist wichtig, um zu verstehen, wie viel aktive Arbeitszeit Aufgaben wie Code-Reviews oder automatisierte Prüfungen beanspruchen. Die Analyse der Verarbeitungszeiten hilft, ineffiziente Aktivitäten mit übermäßigem Zeitaufwand zu erkennen.

Warum das wichtig ist

Ermöglicht die präzise Berechnung der Verarbeitungszeiten von Aktivitäten und hilft, aktive Arbeitszeit von Wartezeit zu unterscheiden.

Woher beziehen

Der Wert ist bei Check-Run-Objekten unter 'completed_at' zu finden oder lässt sich aus dem Timestamp eines nachfolgenden, logisch abschließenden Ereignisses ableiten.

Beispiele
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Priorität
Priority
Die Prioritätsstufe eines Entwicklungselements, zum Beispiel „Hoch“, „Mittel“ oder „Niedrig“.
Beschreibung

Die Priorität gibt an, wie dringend oder geschäftlich wichtig ein Arbeitselement ist. In GitHub gibt es dafür kein eigenes Feld. Die Priorität wird üblicherweise über Labels festgelegt, zum Beispiel „P1-Hoch“ oder „P2-Mittel“. Damit sich diese Information zuverlässig auslesen lässt, ist ein einheitliches Schema für die Labels erforderlich.

Dieses Attribut ist für die „prioritätsbasierte Prozessflussanalyse“ unverzichtbar. Damit können Analysten prüfen, ob Arbeitselemente mit hoher Priorität tatsächlich schneller bearbeitet werden als solche mit niedriger Priorität. Außerdem lässt sich die Abweichung der Zykluszeit nach Priorität messen. So können Sie die Wirksamkeit der Priorisierung bewerten.

Warum das wichtig ist

Ermöglicht die Analyse, ob Arbeitselemente mit hoher Priorität schneller bearbeitet werden als solche mit niedrigerer Priorität. So lässt sich die Wirksamkeit der Priorisierungsstrategie überprüfen.

Woher beziehen

Wird aus den GitHub-Labels für Issues oder Pull Requests abgeleitet. Dafür ist eine einheitliche Konvention für Prioritäts-Labels erforderlich.

Beispiele
HochMittelNiedrigKritisch
Repository
RepositoryName
Der Name des Code-Repositorys, in dem die Entwicklungsaktivität stattfindet.
Beschreibung

Das Repository dient als Kennung für ein Projekt oder Produkt. Es enthält den gesamten Code, die Issues und die Pull Requests für eine bestimmte Anwendung oder Komponente. So lassen sich Entwicklungsprozesse verschiedener Produkte oder Teams getrennt betrachten und vergleichen.

Bei der Analyse ermöglicht dieses Attribut, die Prozessleistung verschiedener Projekte zu filtern und zu vergleichen. Es hilft bei Fragen wie: „Welches Projekt hat die längste Zykluszeit?“ oder „Wie unterscheidet sich die Fehlerbehebung in Projekt A von der in Projekt B?“ Das Attribut ist eine wichtige Grundlage für das Dashboard 'Durchsatz nach Projekt und Typ'.

Warum das wichtig ist

Ermöglicht es, Entwicklungsprozesse verschiedener Projekte, Produkte oder Teams getrennt zu betrachten und zu vergleichen, um gezieltere Analysen durchzuführen.

Woher beziehen

In nahezu allen GitHub-Webhook- und API-Payloads ist der Wert im Objekt 'repository' verfügbar. Das Feld heißt üblicherweise 'repository.full_name' oder 'repository.name'.

Beispiele
my-org/web-appmy-org/api-servicemy-org/data-pipeline
Typ des Entwicklungsvorgangs
DevelopmentItemType
Die Einordnung des Entwicklungsvorgangs, etwa als Funktion, Fehler, Aufgabe oder Epic.
Beschreibung

Dieses Attribut kategorisiert die Art der ausgeführten Arbeit. Die Angaben werden üblicherweise über Labels oder spezielle Issue-Templates in GitHub verwaltet. Der Arbeitstyp ist wichtig, um passende Leistungserwartungen festzulegen: Für eine Fehlerbehebung kann beispielsweise eine deutlich kürzere Zykluszeit gelten als für eine neue Funktion.

Das Attribut ermöglicht Vergleiche zwischen verschiedenen Arbeitstypen. So lässt sich untersuchen, ob Fehler schneller behoben werden als neue Funktionen entwickelt werden oder wie Ressourcen zwischen technischen Schulden und Neuentwicklung verteilt sind. Es ist eine wichtige Dimension im Dashboard 'Durchsatz nach Projekt und Typ'.

Warum das wichtig ist

Kategorisiert Arbeitsvorgänge und ermöglicht Leistungsvergleiche sowie Analysen dazu, wie unterschiedliche Arbeitstypen, etwa Fehler und Funktionen, den Prozess durchlaufen.

Woher beziehen

Wird üblicherweise aus GitHub-Labels für Issues oder Pull Requests abgeleitet. Dafür ist eine einheitliche Kennzeichnung erforderlich, etwa 'type:bug' oder 'type:feature'.

Beispiele
FehlerFunktionAufgabeTechnische Schulden
Zugewiesener Benutzer
Assignee
Der Benutzer oder Entwickler, der für einen Entwicklungsvorgang oder eine bestimmte Aufgabe zuständig ist, etwa für das Review eines Pull Requests.
Beschreibung

Dieses Attribut kennzeichnet die Person, die in einer bestimmten Phase für die Arbeit verantwortlich ist. Das kann der einem Issue zugewiesene Benutzer, der Autor eines Pull Requests oder der für ein Code-Review angefragte Reviewer sein. Die Erfassung der Zuständigkeit ist wichtig, um Ressourcenzuweisung und Arbeitslast zu verstehen.

Bei der Analyse dient dieses Attribut dazu, die Arbeitslast von Entwicklern zu überwachen, Ressourcenengpässe zu erkennen und die Effizienz von Übergaben zwischen Teammitgliedern zu untersuchen. Dashboards lassen sich nach zuständigem Benutzer filtern, um die Leistung einzelner Personen oder Teams zu bewerten und die Arbeit ausgewogen zu verteilen.

Warum das wichtig ist

Wichtig für die Analyse der Arbeitslast von Entwicklern, der Teamleistung und der Effizienz von Übergaben zwischen Teammitgliedern.

Woher beziehen

In den JSON-Payloads für Issues, Pull Requests und Review-Ereignisse der GitHub-API ist der Wert im Objekt 'assignee' oder 'user' verfügbar.

Beispiele
john.doejane.smithdev-team-lead
Autor
Author
Der Benutzer, der das Issue, den Pull Request oder den Commit erstellt hat.
Beschreibung

Der Autor ist die Person, die ein bestimmtes Artefakt im Entwicklungsprozess erstellt hat. Der Autor eines Issues hat beispielsweise einen Fehler gemeldet oder eine Funktion angefordert. Der Autor eines Pull Requests ist der Entwickler, der den Code geschrieben hat.

In der Analyse lässt sich anhand des Autors nachvollziehen, woher die Arbeit stammt. Eine Analyse der Autoren von Fehlerberichten kann zum Beispiel Muster aufzeigen, die mit bestimmten Teams oder Funktionen zusammenhängen. Zusammen mit dem Bearbeiter lassen sich außerdem Übergaben untersuchen.

Warum das wichtig ist

Gibt an, wer ein Arbeitselement oder eine Codeänderung erstellt hat. Das kann bei der Analyse von Nacharbeit, Fehlerberichten oder Funktionsanforderungen hilfreich sein.

Woher beziehen

In API-Antworten zu Issues, Pull Requests und Commits im Objekt „user“ des Hauptobjekts verfügbar. Das Feld heißt üblicherweise „user.login“.

Beispiele
sara.jonesmike.leeautomation-bot
Branch-Name
BranchName
Der Name des Git-Branchs, in dem die Codeänderungen für das Entwicklungselement vorgenommen wurden.
Beschreibung

Ein Branch ist eine unabhängige Entwicklungslinie. Er ermöglicht die Arbeit an einer neuen Funktion oder Fehlerbehebung, ohne die Haupt-Codebasis zu verändern. Der Branch-Name enthält häufig nützliche Angaben wie die Issue-Nummer oder eine kurze Beschreibung der Arbeit.

Die Analyse von Branch-Namen kann Aufschluss über Branching-Strategien und die Einhaltung von Entwicklungskonventionen geben. Außerdem lassen sich einzelne Code-Commits einem Entwicklungselement zuordnen, sodass die Codeaktivitäten vollständig nachvollziehbar sind.

Warum das wichtig ist

Gibt Aufschluss über die jeweilige Entwicklungslinie und hilft dabei, Branching-Strategien und Namenskonventionen einzuhalten und zu analysieren.

Woher beziehen

Bei Push-Events im Feld „ref“ verfügbar oder in den Objekten „head“ und „base“ einer Pull-Request-API-Antwort.

Beispiele
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
CI-Prüfstatus
CiCheckStatus
Der Status einer automatisierten Continuous-Integration-Prüfung (CI), zum Beispiel „bestanden“ oder „fehlgeschlagen“.
Beschreibung

Dieses Attribut gibt das Ergebnis automatisierter Builds, Tests und Scans für Codeänderungen in einem Pull Request wieder. CI-Prüfungen sind in modernen Entwicklungs-Workflows eine wichtige Qualitätsschranke.

Die Analyse dieses Attributs zeigt, wie wirksam automatisierte Tests sind. Eine hohe Fehlerquote kann auf Probleme mit der Code-Stabilität, der Testsuite oder der Entwicklungsumgebung hindeuten. Das Attribut unterstützt die Aktivitäten „CI-Prüfungen bestanden“ und „CI-Prüfungen fehlgeschlagen“ und hilft, Verzögerungen durch fehlgeschlagene Builds zu analysieren.

Warum das wichtig ist

Zeigt, ob automatisierte Qualitätsschranken bestanden oder nicht bestanden wurden. So erhalten Sie Hinweise auf die Codequalität und die Wirksamkeit der CI-Pipeline.

Woher beziehen

Wird über die GitHub Checks API oder Statuses API aus dem Feld „state“ oder „conclusion“ von Check-Run- oder Statusobjekten abgerufen.

Beispiele
successfailurependingerror
Commit-Hash
CommitHash
Die eindeutige Kennung (SHA) eines bestimmten Code-Commits.
Beschreibung

Ein Commit-Hash ist ein 40 Zeichen langer SHA-1-Hash, der einen Commit in Git eindeutig identifiziert. Er dient als dauerhafte ID für eine bestimmte Codeversion. Commits sind die kleinsten Änderungseinheiten im Entwicklungsprozess.

Der Commit-Hash ermöglicht eine besonders detaillierte Nachverfolgung. Analysten können damit ein Prozessereignis direkt der konkreten Codeänderung zuordnen. Das ist besonders wertvoll für Audits, Compliance-Prüfungen oder eine detaillierte Ursachenanalyse von Produktionsvorfällen.

Warum das wichtig ist

Stellt die detaillierteste Verbindung zwischen einem Prozessschritt und der konkreten Codeänderung her. So ist die vollständige Nachverfolgung für Audits und die Fehlersuche möglich.

Woher beziehen

In Push-Event-Nutzlasten als „head_commit.id“ verfügbar oder über die Commits API für einen Pull Request oder Branch.

Beispiele
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Deployment-Umgebung
DeploymentEnvironment
Die Zielumgebung für ein Deployment, zum Beispiel „Staging“ oder „Produktion“.
Beschreibung

Dieses Attribut gibt an, wohin der Code ausgerollt wird. Deployments in verschiedene Umgebungen nachzuverfolgen, ist wichtig, um den gesamten Lebenszyklus von der Entwicklung bis zur Produktivsetzung zu verstehen.

Anhand dieses Attributs lässt sich der Deployment-Teilprozess analysieren. Damit können Sie messen, wie lange die Übertragung von Code aus der Staging- in die Produktionsumgebung dauert, und die Erfolgsquote von Deployments in verschiedenen Umgebungen verfolgen. So lässt sich feststellen, wann ein Entwicklungselement tatsächlich abgeschlossen und für Benutzer bereitgestellt ist.

Warum das wichtig ist

Unterscheidet zwischen Vorab- und Produktionsversionen. Das ist entscheidend, um die tatsächliche Markteinführungszeit zu messen und Deployment-Muster zu analysieren.

Woher beziehen

Diese Informationen stammen aus der GitHub Deployments API. Sie wird häufig durch CI/CD-Pipelines oder andere Automatisierungen ausgelöst.

Beispiele
developmentstagingproduction
Entwicklungszykluszeit
DevelopmentCycleTime
Die gesamte Zeit vom Erstellen eines Entwicklungselements bis zu dessen endgültigem Deployment oder Abschluss.
Beschreibung

Diese Kennzahl wird auf Case-Ebene berechnet. Sie entspricht der Zeit zwischen dem ersten Ereignis (zum Beispiel „Issue erstellt“) und dem letzten Ereignis (zum Beispiel „Deployment erfolgreich“ oder „Issue geschlossen“) für ein einzelnes Entwicklungselement.

Sie zählt zu den wichtigsten KPIs für die Effizienz des gesamten Entwicklungsprozesses. Die Kennzahl unterstützt direkt das Dashboard „Gesamte Entwicklungszykluszeit“ und die KPI „Durchschnittliche Entwicklungszykluszeit“. Initiativen zur Prozessverbesserung zielen häufig darauf ab, diesen Wert zu senken.

Warum das wichtig ist

Zeigt die durchgängige Markteinführungszeit eines Entwicklungselements und ist damit eine wichtige KPI für die Geschwindigkeit und Effizienz des gesamten Prozesses.

Woher beziehen

Wird auf Case-Ebene berechnet, indem der Timestamp der ersten Aktivität vom Timestamp der letzten Aktivität abgezogen wird.

Beispiele
P5DT6H30MP14DT12HP1DT2H
Ist Nacharbeit
IsRework
Ein boolesches Kennzeichen, das den Wert „true“ hat, wenn eine Aktivität einen Rückschritt in eine frühere Prozessphase darstellt.
Beschreibung

Dieses Kennzeichen wird auf „true“ gesetzt, wenn ein Entwicklungselement im Prozess zurückgeht, zum Beispiel wenn ein Pull Request im Review den Status „Änderungen angefordert“ erhält oder ein geschlossenes Issue erneut geöffnet wird. Der Wert wird aus der Abfolge der Aktivitäten abgeleitet.

Dieses Attribut ist entscheidend, um Verschwendung und Ineffizienz zu quantifizieren. Es unterstützt direkt das Dashboard „Nacharbeits- und Rückschleifen“ und die KPI „Nacharbeitsquote“. Mit dem Filter „IsRework = true“ können Analysten Nacharbeit isolieren und deren Ursachen untersuchen.

Warum das wichtig ist

Kennzeichnet Aktivitäten, die Nacharbeit darstellen. So lassen sich Ursachen für Prozessineffizienzen einfach quantifizieren, visualisieren und analysieren.

Woher beziehen

Dies ist ein abgeleitetes Attribut. Dazu wird zunächst ein Standardprozessfluss definiert. Anschließend werden Aktivitäten gekennzeichnet, die davon abweichen, indem sie zu einer früheren logischen Phase zurückführen.

Beispiele
truefalse
Labels
Labels
Eine Liste von Tags oder Labels zur Kategorisierung eines Issues oder Pull Requests.
Beschreibung

Labels in GitHub bieten eine flexible Möglichkeit, Issues und Pull Requests mit Metadaten zu versehen. Sie können Priorität, Arbeitsart, Komponenten, Teams oder Status kennzeichnen. Die vollständige Liste der Labels liefert umfangreiche, unstrukturierte Kontextinformationen.

Spezifische Attribute wie Priorität und Typ werden zwar aus Labels abgeleitet, doch die vollständige Liste kann für Ad-hoc-Analysen und zum Entdecken weiterer Prozessmuster hilfreich sein. Sie ermöglicht eine flexible Filterung und Segmentierung von Cases anhand beliebiger Label-Kombinationen.

Warum das wichtig ist

Liefert eine flexible und umfangreiche Metadatenquelle zur Kategorisierung von Arbeitselementen. Damit sind detaillierte Auswertungen nach unterschiedlichen Dimensionen möglich.

Woher beziehen

In der JSON-Nutzlast der GitHub API für Issues und Pull Requests als Array „labels“ verfügbar. Jedes Element des Arrays ist ein Objekt mit einem Feld „name“.

Beispiele
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
Letzte Datenaktualisierung
LastDataUpdate
Der Timestamp gibt an, wann die Daten dieses Datensatzes zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung

Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder -aktualisierung. Es liefert Metadaten zur Aktualität der analysierten Daten. Anders als der Ereignis-Timestamp gibt es nicht an, wann das Geschäftsereignis stattgefunden hat.

Bei der Analyse hilft dieses Feld, die Aktualität der Prozessansicht einzuschätzen. Benutzer erkennen daran, ob sie Echtzeitdaten oder einen Snapshot von einem bestimmten Zeitpunkt betrachten. Das ist für operative Dashboards und die Überwachung wichtig.

Warum das wichtig ist

Das Attribut zeigt, wie aktuell die Daten sind. Das ist entscheidend, damit Analysen und Dashboards auf dem neuesten Informationsstand beruhen.

Woher beziehen

Dieser Timestamp wird während des ETL-Prozesses (Extraktion, Transformation und Laden) erzeugt und hinzugefügt.

Beispiele
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Pull-Request-Nummer
PullRequestNumber
Die eindeutige Kennung des Pull Requests, der dem Entwicklungselement zugeordnet ist.
Beschreibung

Ein Pull Request (PR) ist ein Vorschlag, eine Reihe von Codeänderungen in einen bestimmten Branch zu übernehmen. Über die Pull-Request-Nummer lassen sich Entwicklungsaktivitäten wie Codeübertragungen und Reviews dem zugehörigen Entwicklungselement oder Issue zuordnen.

Diese ID ist entscheidend, um die Codeintegration und den Review-Teilprozess im gesamten Entwicklungszyklus nachzuverfolgen. Sie ermöglicht eine detaillierte Analyse des Code-Reviews, etwa der Review-Zeiten, der dabei festgestellten Nacharbeitszyklen und der Merge-Rate. So verbindet sie die Planungsphase (Issue) mit der Umsetzungsphase (PR).

Warum das wichtig ist

Ordnet Issues den zugehörigen Codeänderungen und Review-Prozessen zu. So lassen sich der Code-Review-Zyklus und seine Auswirkungen auf die gesamte Lieferzeit detailliert analysieren.

Woher beziehen

In vielen GitHub-API-Antworten als Feld „number“ im Objekt „pull_request“ verfügbar oder als primäre Kennung über die Pull Requests API.

Beispiele
12345678910
Quellsystem
SourceSystem
Das System, aus dem die Daten zum Entwicklungsprozess extrahiert wurden.
Beschreibung

Dieses Attribut kennzeichnet die Herkunft der Ereignisdaten. Für diesen Prozess lautet der Wert durchgehend 'GitHub'. In komplexeren Umgebungen, in denen Entwicklungsaktivitäten mehrere Systeme umfassen, etwa Jira für die Planung, GitHub für den Code und Jenkins für die Bereitstellung, unterscheidet dieses Feld die Quelle der einzelnen Ereignisse.

Bei der Analyse hilft es, Daten zur Validierung und Fehlerbehebung bis zu ihrem Ursprung zurückzuverfolgen. Außerdem ermöglicht es die Analyse von Prozessen über mehrere Plattformen hinweg und liefert einen klaren Kontext für jede Aktivität.

Warum das wichtig ist

Das Attribut kennzeichnet die Herkunft der Daten. Das ist wichtig für die Datenvalidierung und für die Analyse von Prozessen, die sich über mehrere integrierte Systeme erstrecken können.

Woher beziehen

Dieser statische Wert wird üblicherweise während des ETL-Prozesses (Extraktion, Transformation und Laden) hinzugefügt, um die Herkunft der Datensätze zu kennzeichnen.

Beispiele
GitHubGitHub Enterprise
Review-Status
ReviewState
Das Ergebnis eines Code-Reviews für einen Pull Request, zum Beispiel „Genehmigt“ oder „Änderungen angefordert“.
Beschreibung

Dieses Attribut erfasst die Entscheidung eines Reviewers. Zu den üblichen Statuswerten gehören „APPROVED“, wenn der Code zum Mergen bereit ist, und „CHANGES_REQUESTED“, wenn Nacharbeit erforderlich ist. Weitere mögliche Statuswerte sind „COMMENTED“ oder „PENDING“.

Dieses Attribut ist für die Analyse von Nacharbeit und Qualität entscheidend. Häufige „CHANGES_REQUESTED“-Ereignisse können auf eine unzureichende anfängliche Codequalität oder unklare Anforderungen hindeuten. Das Attribut unterstützt direkt das Dashboard „Nacharbeits- und Rückschleifen“, indem es zeigt, wann ein Entwicklungselement zur Überarbeitung zurückgegeben wird.

Warum das wichtig ist

Zeigt Nacharbeitszyklen und Qualitätsschranken im Code-Review-Prozess direkt an. So lassen sich Ursachen für Ineffizienz und Qualitätsprobleme gezielt ermitteln.

Woher beziehen

In der GitHub API als Feld „state“ eines Pull-Request-Review-Objekts verfügbar, zum Beispiel in einer „PullRequestReviewEvent“-Nutzlast.

Beispiele
APPROVEDCHANGES_REQUESTEDCOMMENTED
Reviewer
Reviewer
Der Benutzer, der mit einem Code-Review für einen Pull Request beauftragt wurde.
Beschreibung

Ein Reviewer ist ein Entwickler oder Teammitglied, das die Codeänderungen in einem Pull Request auf Qualität, Korrektheit und Einhaltung von Standards prüft. Ein Pull Request kann mehrere Reviewer haben.

Dieses Attribut ist für die Analyse des Code-Review-Prozesses unverzichtbar. Es hilft, Engpässe bei bestimmten Reviewern zu erkennen, die Verteilung der Review-Arbeit zu verstehen und die Reaktionszeit auf Review-Anfragen zu messen. Außerdem ist es eine wichtige Grundlage für die Kennzahl „Durchschnittliche Zykluszeit des Code-Reviews“.

Warum das wichtig ist

Gibt an, welche Personen an der Qualitätssicherung beteiligt sind. So lassen sich Review-Arbeitslasten, Verzögerungen und die Effizienz von Code-Reviews insgesamt analysieren.

Woher beziehen

In der GitHub API im Array „requested_reviewers“ oder im Objekt „user“ eines Pull-Request-Review-Events verfügbar.

Beispiele
alex.chenmaria.garciasenior-dev-team
Status des Vorgangs
State
Der aktuelle Status eines Issues oder Pull Requests, etwa 'open', 'closed' oder 'merged'.
Beschreibung

Dieses Attribut gibt den übergeordneten Status eines Entwicklungsvorgangs an. Für Issues sind die üblichen Status 'open' und 'closed'. Für Pull Requests gibt es die Status 'open', 'closed' und 'merged'. Damit wird der aktuelle Fortschritt des Vorgangs abgebildet.

Bei der Analyse dient der Status dazu, laufende von abgeschlossenen Arbeiten zu unterscheiden. Er ist wichtig für Dashboards wie 'Fortschritt der aktiven Entwicklung', die laufende Arbeiten überwachen. Außerdem lässt sich damit das Prozessende festlegen: Ein Status wie 'merged' oder 'closed' kann beispielsweise den Abschluss eines Cases kennzeichnen.

Warum das wichtig ist

Zeigt klar an, ob ein Arbeitsvorgang noch läuft oder bereits abgeschlossen ist. Das ist eine wichtige Grundlage für die Analyse des Lebenszyklus und die Überwachung laufender Arbeiten.

Woher beziehen

Der Wert ist direkt im Feld 'state' der JSON-Payloads für Issues und Pull Requests aus der GitHub-API verfügbar.

Beispiele
offengeschlossenzusammengeführt
Wartezeit bei Übergaben
HandoffWaitingTime
Die berechnete Leerlaufzeit, die ein Entwicklungselement zwischen Aktivitäten verschiedener Personen wartet.
Beschreibung

Diese Kennzahl misst die Zeit zwischen dem Abschluss einer Aktivität und dem Beginn der nächsten, jedoch nur, wenn sich die verantwortliche Person ändert. Ein Beispiel ist die Zeit zwischen einem Ereignis „Review angefordert“ und einem Ereignis „Änderungen im Review angefordert“, das von einem anderen Benutzer ausgelöst wurde.

Diese Kennzahl ist wichtig, um Kommunikationslücken und Koordinationsprobleme zu erkennen. Sie unterstützt das Dashboard „Effizienz kritischer Übergaben“ und die KPI „Durchschnittliche Wartezeit bei Übergaben“. Lange Wartezeiten an Übergabepunkten deuten häufig auf begrenzte Ressourcen oder ineffiziente Benachrichtigungsprozesse hin.

Warum das wichtig ist

Zeigt Verzögerungen durch mangelhafte Koordination oder fehlende Ressourcen bei Übergaben zwischen Teams oder Rollen auf. Solche Verzögerungen sind häufig eine wesentliche Ursache für Ineffizienz.

Woher beziehen

Wird berechnet, indem aufeinanderfolgende Aktivitäten ermittelt werden, bei denen sich das Attribut „Assignee“ oder „User“ ändert. Anschließend wird die Zeitspanne zwischen diesen Aktivitäten gemessen.

Beispiele
PT1H15MP2DT4HPT25M
Erforderlich Empfohlen Optional

Aktivitäten im Softwareentwicklungszyklus

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um den Prozess präzise zu entdecken und Engpässe zu identifizieren.
6 Empfohlen 7 Optional
Aktivität Beschreibung
CI-Prüfungen bestanden
Dieses Ereignis steht für den erfolgreichen Abschluss automatisierter Prüfungen, etwa Builds, Unit-Tests oder statischer Analysen, die für den Code eines Pull Requests ausgeführt werden. Es wird anhand des von Systemen wie GitHub Actions gemeldeten Prüfstatus abgeleitet.
Warum das wichtig ist

Dieser automatisierte Qualitätsschritt ist entscheidend für die Stabilität des Codes. Fehlgeschlagene Prüfungen oder lange Laufzeiten können erhebliche Engpässe in der Bereitstellungspipeline verursachen.

Woher beziehen

Das Ereignis wird aus der GitHub Checks API oder der Statuses API abgeleitet. Ein Check-Lauf oder eine Statusaktualisierung meldet 'success' oder 'completed' mit dem Ergebnis 'success'.

Erfassung

Überwachen Sie die Checks API auf ein 'success'-Ergebnis für die relevanten Check-Suites.

Ereignistyp inferred
Issue erstellt
Dieses Ereignis markiert den Beginn des Lebenszyklus eines Entwicklungsvorgangs. Es steht für die formelle Erstellung einer Aufgabe, eines Fehlers oder einer Funktionsanforderung. Das Ereignis wird ausdrücklich erfasst, wenn ein Benutzer ein neues Issue in einem GitHub-Repository erstellt.
Warum das wichtig ist

Dies ist die zentrale Startaktivität des Prozesses. Sie ist wichtig, um die gesamte Entwicklungszykluszeit zu messen und die ursprünglichen Arbeitsquellen zu verstehen.

Woher beziehen

Dies ist ein ausdrücklich erfasstes Ereignis aus dem GitHub-Issues-API-Ereignisstrom. Der Ereignistyp lautet für eine bestimmte Issue-Nummer üblicherweise 'opened'.

Erfassung

Erfassen Sie das 'opened'-Ereignis eines Issues über Webhooks oder regelmäßige API-Abfragen.

Ereignistyp explicit
Issue geschlossen
Der Entwicklungsvorgang gilt als abgeschlossen und das zugehörige Issue wird formell geschlossen. Dies kann automatisch geschehen, wenn ein verknüpfter Pull Request zusammengeführt wird, oder manuell durch ein Teammitglied.
Warum das wichtig ist

Diese Aktivität markiert das endgültige Ende des Prozesses für einen Entwicklungsvorgang. Sie ist entscheidend für die Berechnung der End-to-End-Zykluszeit.

Woher beziehen

Dies ist ein ausdrücklich erfasstes Ereignis aus dem GitHub-Issues-API-Ereignisstrom. Der Ereignistyp lautet 'closed'.

Erfassung

Erfassen Sie das 'closed'-Ereignis eines Issues über Webhooks oder regelmäßige API-Abfragen.

Ereignistyp explicit
Pull Request eröffnet
Dieses Ereignis zeigt an, dass ein erster Codeblock zur Prüfung und Integration bereitsteht. Ein Entwickler erstellt einen Pull Request (PR), um Änderungen aus seinem Feature-Branch zur Übernahme in einen Haupt-Branch vorzuschlagen. GitHub erfasst dieses Ereignis ausdrücklich.
Warum das wichtig ist

Dieser wichtige Meilenstein markiert das Ende der ersten Entwicklungsphase und den Beginn des Prüfungs- und Integrationsablaufs. Er ermöglicht es, Entwicklungs- und Review-Zykluszeiten getrennt zu analysieren.

Woher beziehen

Das Ereignis wird aus dem Ereignisstrom der GitHub-Pull-Request-API oder über Webhooks erfasst. Die Ereignisaktion lautet 'opened'.

Erfassung

Erfassen Sie die Aktion 'opened' für einen Pull Request über Webhooks oder regelmäßige API-Abfragen.

Ereignistyp explicit
Pull Request genehmigt
Ein Reviewer hat die Änderungen in einem Pull Request formell freigegeben. Damit bestätigt er, dass sie die Qualitäts- und Funktionsanforderungen erfüllen. Das Ereignis wird erfasst, wenn ein Reviewer sein Review mit dem Status 'approve' einreicht.
Warum das wichtig ist

Dies ist ein wichtiger Qualitätsschritt und ein zentraler Meilenstein vor dem Zusammenführen. Die Zeit von der Erstellung des PR bis zu diesem Status ist eine wichtige Kennzahl für die Effizienz des Review-Prozesses.

Woher beziehen

Das Ereignis wird über die GitHub-Pull-Request-API oder Webhooks erfasst, wenn ein Review mit dem Status 'APPROVED' eingereicht wird.

Erfassung

Filtern Sie Ereignisse zur Einreichung von Pull-Request-Reviews nach dem Status 'APPROVED'.

Ereignistyp explicit
Pull Request zusammengeführt
Die freigegebenen Codeänderungen aus dem Pull Request werden offiziell in den Ziel-Branch, etwa main oder develop, übernommen. Dies ist die abschließende Aktion für einen Pull Request, durch die der neue Code integriert wird.
Warum das wichtig ist

Dieser wichtige Meilenstein markiert den Abschluss von Entwicklung und Review. Für viele Teams ist dies der letzte Schritt vor einer automatisierten Bereitstellung.

Woher beziehen

Das Ereignis wird aus dem Ereignisstrom der GitHub-Pull-Request-API oder über Webhooks erfasst. Die Ereignisaktion lautet 'closed', und das Attribut 'merged' im Pull-Request-Payload hat den Wert true.

Erfassung

Erfassen Sie die Aktion 'closed' für einen Pull Request und prüfen Sie, ob das Flag 'merged' den Wert true hat.

Ereignistyp explicit
Änderungen im Review angefordert
Ein Reviewer hat das Code-Review abgeschlossen und festgestellt, dass Änderungen erforderlich sind, bevor der Pull Request freigegeben werden kann. Der Reviewer reicht sein Review formell mit dem Status 'request_changes' ein.
Warum das wichtig ist

Dieses Ereignis kennzeichnet ausdrücklich eine Nacharbeitsschleife. Die Analyse der Häufigkeit hilft, Qualitätsprobleme, unklare Anforderungen oder Schulungsbedarf bei Entwicklern zu erkennen.

Woher beziehen

Das Ereignis wird über die GitHub-Pull-Request-API oder Webhooks erfasst, wenn ein Review mit dem Status 'CHANGES_REQUESTED' eingereicht wird.

Erfassung

Filtern Sie Ereignisse zur Einreichung von Pull-Request-Reviews nach dem Status 'CHANGES_REQUESTED'.

Ereignistyp explicit
Bereitstellung erfolgreich
Die Codeänderungen wurden erfolgreich in einer bestimmten Umgebung bereitgestellt, etwa in der Staging- oder Produktionsumgebung. Dieses Ereignis wird üblicherweise über die GitHub Deployments API erfasst und häufig nach einem Merge durch eine GitHub Action ausgelöst.
Warum das wichtig ist

Das Ereignis markiert den Übergang des Codes aus dem Repository in eine Live-Umgebung. Seine Erfassung ist wichtig, um die gesamte Durchlaufzeit von der Idee bis zur Produktion zu messen.

Woher beziehen

Das Ereignis wird über die Deployments API erfasst. Ein externer Dienst oder eine GitHub Action erstellt eine Bereitstellung und aktualisiert anschließend deren Status auf 'success'.

Erfassung

Überwachen Sie Bereitstellungsstatusereignisse über Webhooks auf den Status 'success'.

Ereignistyp inferred
Branch erstellt
Dieses Ereignis steht für den Beginn der aktiven Entwicklungsarbeit an einem Issue. Ein Entwickler erstellt dazu einen neuen Branch aus der Haupt-Codebasis. Das Ereignis wird ausdrücklich erfasst, wenn ein neuer Branch in das Repository übertragen wird. Häufig enthält sein Name die Issue-Nummer.
Warum das wichtig ist

Das Ereignis kennzeichnet den Übergang von der Planung zur aktiven Programmierung. Die Zeit zwischen der Erstellung des Issues und diesem Ereignis zeigt, wie lange es dauert, bis ein Entwickler die Arbeit aufnimmt, und macht anfängliche Rückstände sichtbar.

Woher beziehen

Das Ereignis wird über die GitHub-Git-API oder Webhooks erfasst, die auf 'create'-Ereignisse vom Typ 'branch' reagieren. Häufig muss der Branch-Name anhand einer Namenskonvention, etwa 'feature/issue-123', einem Issue zugeordnet werden.

Erfassung

Werten Sie 'create'-Webhook-Ereignisse für neue Branches aus und ordnen Sie diese einem Issue zu.

Ereignistyp explicit
CI-Prüfungen fehlgeschlagen
Dieses Ereignis steht für das Scheitern einer automatisierten Prüfung, etwa eines Builds oder eines Unit-Tests, der für den Code eines Pull Requests ausgeführt wird. Es wird aus einem von einem System wie GitHub Actions gemeldeten Fehlerstatus abgeleitet.
Warum das wichtig ist

Diese Aktivität macht technische Qualitätsprobleme sichtbar, die ein Eingreifen der Entwickler erfordern und eine Nacharbeitsschleife auslösen. Die Analyse der Fehlerhäufigkeit kann Verbesserungen bei lokalen Tests oder der Codequalität unterstützen.

Woher beziehen

Das Ereignis wird aus der GitHub Checks API oder der Statuses API abgeleitet. Ein Check-Lauf oder eine Statusaktualisierung meldet 'failure' oder 'completed' mit dem Ergebnis 'failure'.

Erfassung

Überwachen Sie die Checks API auf ein 'failure'-Ergebnis für die relevanten Check-Suites.

Ereignistyp inferred
Code an PR übertragen
Dieses Ereignis steht für eine Aktualisierung des zur Prüfung eingereichten Codes, entweder im ursprünglichen PR oder als Reaktion auf Review-Feedback. Es wird jedes Mal erfasst, wenn ein neuer Commit in den Branch eines offenen Pull Requests übertragen wird.
Warum das wichtig ist

Die Erfassung dieser Ereignisse ist wichtig, um Nacharbeitsschleifen zu erkennen. Mehrere Übertragungen nach einem Review weisen darauf hin, dass Änderungen erforderlich waren und sich dadurch die gesamte Zykluszeit verlängert.

Woher beziehen

Dies ist ein ausdrücklich erfasstes Ereignis in der Zeitleiste des Pull Requests, das häufig als hinzugefügter Commit bezeichnet wird. Es lässt sich über den 'push'-Webhook oder durch Überwachung der mit einem PR verknüpften Commits erfassen.

Erfassung

Erfassen Sie 'push'-Ereignisse für einen Branch, der einem offenen Pull Request zugeordnet ist.

Ereignistyp explicit
Issue erneut geöffnet
Ein zuvor geschlossenes Issue wird wieder aktiviert, meist weil die Fehlerbehebung nicht ausgereicht hat oder eine Regression festgestellt wurde. Dieses ausdrücklich erfasste Ereignis setzt den Lebenszyklus des Entwicklungsvorgangs erneut in Gang.
Warum das wichtig ist

Dieses Ereignis weist auf eine erhebliche Nacharbeitsschleife hin und kann auf einen in die Produktion gelangten Fehler oder eine unvollständige Fehlerbehebung hindeuten. Die Häufigkeit ist ein wichtiger Indikator für die allgemeine Softwarequalität.

Woher beziehen

Dies ist ein ausdrücklich erfasstes Ereignis aus dem GitHub-Issues-API-Ereignisstrom. Der Ereignistyp lautet 'reopened'.

Erfassung

Erfassen Sie das 'reopened'-Ereignis eines Issues über Webhooks oder regelmäßige API-Abfragen.

Ereignistyp explicit
Review angefordert
Der Autor eines Pull Requests bittet bestimmte Teammitglieder oder Teams formell darum, den Code zu prüfen. Diese Aktion wird in der GitHub-Benutzeroberfläche oder über die API ausgelöst und benachrichtigt die angefragten Reviewer.
Warum das wichtig ist

Diese Aktivität markiert den offiziellen Beginn der Übergabe an den Code-Review-Prozess. Die Zeit bis zur Einreichung eines Reviews zeigt, wie schnell Reviewer reagieren und wo mögliche Engpässe liegen.

Woher beziehen

Das Ereignis wird aus dem Ereignisstrom der GitHub-Pull-Request-API oder über Webhooks erfasst. Die Ereignisaktion lautet 'review_requested'.

Erfassung

Erfassen Sie die Aktion 'review_requested' für einen Pull Request.

Ereignistyp explicit
Empfohlen Optional

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus GitHub

Möchten Sie loslegen?

Bereiten Sie Ihre Daten mit diesem Template auf und beginnen Sie, Ihren Softwareentwicklungszyklus zu optimieren. Entdecken Sie Ineffizienzen und sorgen Sie noch heute für schnellere und reibungslosere Releases.

Verbessern Sie Ihren SDLC: Erkennen Sie Ineffizienzen sofort

Verkürzen Sie die Zykluszeit um 30 % und optimieren Sie Ihren GitHub-Entwicklungsprozess.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Die Einrichtung dauert nur wenige Minuten.