Ihr Daten-Template für den Softwareentwicklungszyklus
Ihr Daten-Template für den Softwareentwicklungszyklus
- Empfohlene Attribute für die Erfassung
- Wichtige Aktivitäten für die Nachverfolgung
- Hinweise zur Datenextraktion
Attribute des Softwareentwicklungszyklus
| 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
|
|||
Aktivitäten im Softwareentwicklungszyklus
| 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
|
|||
Anleitungen zur Datenextraktion
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.
Keine Kreditkarte erforderlich. Die Einrichtung dauert nur wenige Minuten.