Ihr Software Development Lifecycle Daten-Template
Ihr Software Development Lifecycle Daten-Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Extraktionsanleitung
Software Development Lifecycle Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivität
ActivityName
|
Der Name eines spezifischen Events oder einer Aufgabe, die innerhalb des Software Development Lifecycle aufgetreten ist. | ||
|
Beschreibung
Der Aktivitätsname beschreibt einen einzelnen Schritt im Entwicklungsprozess, wie z. B. 'Issue Created', 'Code Pushed to PR', 'Pull Request Approved' oder 'Deployment Succeeded'. Diese Events bilden die Abfolge von Schritten, die den End-to-End-Prozess für ein Entwicklungselement darstellen. Dieses Attribut ist grundlegend für Process Mining, da es zur Konstruktion der Prozesslandkarte verwendet wird. Die Analyse der Reihenfolge, Häufigkeit und Dauer dieser Aktivitäten offenbart den tatsächlichen Prozessfluss, identifiziert gängige Pfade, hebt Abweichungen hervor und identifiziert Engpässe.
Bedeutung
Dieses Attribut bildet das Rückgrat der Prozesslandkarte und ermöglicht die Visualisierung und Analyse der Ereignisabfolge im Entwicklungslebenszyklus.
Datenquelle
Abgeleitet vom 'action'-Feld von Webhook-Event-Payloads (z. B. 'opened', 'closed' für ein Issue) oder vom Event-Typ selbst (z. B. 'PushEvent', 'PullRequestReviewEvent').
Beispiele
Problem erstelltPull Request geöffnetCode an PR gepushtReview angefordertPull Request gemerged
|
|||
|
Entwicklungselement
DevelopmentItemId
|
Der eindeutige Identifier für eine einzelne Einheit der Entwicklungsarbeit, wie z. B. ein Feature, Bug Fix oder Task. Dies dient als primärer Case Identifier. | ||
|
Beschreibung
Die Development Item ID verfolgt ein Work Item von seiner Erstellung bis zum finalen Deployment. Sie verknüpft alle zugehörigen Aktivitäten, wie Branch-Erstellung, Commits, Pull Requests, Reviews und Deployments, zu einer einzigen, kohärenten Prozessinstanz. In der Analyse wird diese ID verwendet, um die End-to-End Cycle Time einer Entwicklungsaufgabe zu berechnen. Sie ermöglicht die Rekonstruktion der gesamten Reise eines Funktionen oder Bug Fixes und damit eine detaillierte Analyse von Engpässen, Nacharbeitsschleifen und Prozessvariationen für einzelne Work Items.
Bedeutung
Es ist der wesentliche Schlüssel für Process Mining, da es alle verwandten Entwicklungs-Events zu einem einzigen Case verbindet, um den End-to-End-Softwareentwicklungsprozess präzise zu visualisieren und zu analysieren.
Datenquelle
Dies ist typischerweise die Issue Number oder Pull Request Number von GitHub. Sie kann aus dem 'number'-Feld im Payload von Issue- oder Pull Request-bezogenen Webhook-Events oder API-Responses extrahiert werden.
Beispiele
101PR-2345TASK-812
|
|||
|
Startzeit
EventTimestamp
|
Das genaue Datum und die Uhrzeit, zu der eine spezifische Entwicklungsaktivität oder ein Event stattgefunden hat. | ||
|
Beschreibung
Dieser Timestamp markiert den Beginn einer Aktivität. Er ist entscheidend für die chronologische Anordnung von Events, um den Prozessfluss für jedes Entwicklungselement zu rekonstruieren. Die Reihenfolge und Zeitdifferenz zwischen diesen Timestamps werden zur Analyse der Prozessperformance verwendet. In der Analyse ist dieses Attribut essenziell für die Berechnung aller zeitbasierten Metriken, einschließlich Cycle Times, Bearbeitungszeiten und Wartezeiten. Es ermöglicht die Identifizierung von Verzögerungen zwischen den Schritten und liefert die Daten, die für die Engpassanalyse und Performance-Monitoring-Dashboards benötigt werden.
Bedeutung
Dieser Timestamp ist entscheidend für die korrekte Reihenfolge von Events und die Berechnung aller Performance-Metriken, wie Cycle Times und Engpass-Dauern.
Datenquelle
Typischerweise als 'created_at'- oder 'updated_at'-Felder in den JSON-Payloads von GitHub APIs und Webhooks für verschiedene Objekte wie Issues, Pull Requests und Commits gefunden.
Beispiele
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
|
|||
|
Endzeit
EndTimestamp
|
Das genaue Datum und die Uhrzeit, zu der eine spezifische Entwicklungsaktivität oder ein Event abgeschlossen wurde. | ||
|
Beschreibung
Der End-Timestamp markiert den Abschluss einer Aktivität. Während viele Events in GitHub augenblicklich sind (z. B. 'Issue Created'), haben einige Aktivitäten eine messbare Dauer (z. B. ein laufender CI Check). Die Differenz zwischen End Time und Start Time ergibt die Bearbeitungszeit für eine Aktivität. Dieses Attribut wird verwendet, um die Metrik 'ProcessingTime' zu berechnen, die entscheidend ist, um zu verstehen, wie viel aktiver Aufwand für verschiedene Aufgaben wie Code Reviews oder automatisierte Checks aufgewendet wird. Die Analyse der Bearbeitungszeiten hilft, ineffiziente Aktivitäten zu identifizieren, die zu viel Zeit in Anspruch nehmen.
Bedeutung
Ermöglicht die Berechnung präziser Bearbeitungszeiten für Aktivitäten und hilft so, zwischen aktiver Arbeitszeit und untätiger Wartezeit zu unterscheiden.
Datenquelle
Kann als 'completed_at' in Check-Run-Objekten gefunden oder vom Timestamp eines nachfolgenden, logisch abschließenden Events abgeleitet werden.
Beispiele
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
|
|||
|
Priorität
Priority
|
Die Prioritätsstufe, die einem Entwicklungselement zugewiesen wurde, z. B. 'High', 'Medium' oder 'Low'. | ||
|
Beschreibung
Priorität kennzeichnet die Dringlichkeit oder geschäftliche Bedeutung eines Work Items. In GitHub ist Priorität kein natives Feld und wird typischerweise über Labels (z. B. 'P1-High', 'P2-Medium') verwaltet. Ein konsistentes Labeling-Schema ist erforderlich, um diese Informationen zuverlässig zu extrahieren. Dieses Attribut ist essenziell für die 'Priority-Based Flow Analysis'. Es ermöglicht Analysten zu überprüfen, ob hochpriorisierte Elemente tatsächlich schneller verarbeitet werden als niedrigpriorisierte, und die Cycle Time-Varianz basierend auf der Priorität zu messen. Es hilft bei der Bewertung der Effektivität des Priorisierungsprozesses.
Bedeutung
Ermöglicht die Analyse, ob Elemente mit hoher Priorität schneller verarbeitet werden als solche mit niedrigerer Priorität, wodurch die Wirksamkeit der Priorisierungsstrategie validiert wird.
Datenquelle
Abgeleitet von GitHub-Labels, die auf Issues oder Pull Requests angewendet werden. Erfordert eine standardisierte Konvention für Prioritäts-Labels.
Beispiele
HochMittelNiedrigKritisch
|
|||
|
Repository
RepositoryName
|
Der Name des Code-Repositorys, in dem die Entwicklungsaktivität stattfindet. | ||
|
Beschreibung
Das Repository dient als Projekt- oder Produkt-Identifikator, der den gesamten Code, Issues und Pull Requests für eine spezifische Anwendung oder Komponente enthält. Es bietet eine Möglichkeit, Entwicklungsprozesse über verschiedene Produkte oder Teams hinweg zu segmentieren und zu vergleichen. In der Analyse ermöglicht dieses Attribut das Filtern und Vergleichen der Prozessperformance über verschiedene Projekte hinweg. Es hilft, Fragen zu beantworten wie: 'Welches Projekt hat die längste Cycle Time?' oder 'Wie verhält sich der Bug-Fix-Prozess in Projekt A im Vergleich zu Projekt B?'. Es ist unerlässlich für das Dashboard 'Throughput by Project and Type'.
Bedeutung
Ermöglicht die Segmentierung und den Vergleich von Entwicklungsprozessen über verschiedene Projekte, Produkte oder Teams hinweg und ermöglicht so eine gezieltere Analyse.
Datenquelle
Verfügbar im 'repository'-Objekt in fast allen GitHub-Webhook- und API-Payloads. Das spezifische Feld ist typischerweise 'repository.full_name' oder 'repository.name'.
Beispiele
my-org/web-appmy-org/api-servicemy-org/data-pipeline
|
|||
|
Typ des Entwicklungselements
DevelopmentItemType
|
Die Klassifizierung des Entwicklungselements, wie z. B. Feature, Bug, Task oder Epic. | ||
|
Beschreibung
Dieses Attribut kategorisiert die Art der ausgeführten Arbeit. Diese Informationen werden typischerweise über Labels oder spezifische Issue Templates innerhalb von GitHub verwaltet. Das Verständnis der Arbeitsart ist entscheidend für die Festlegung angemessener Performance-Erwartungen, da ein Bug Fix eine viel kürzere erwartete Cycle Time haben könnte als ein neues Feature. Dieses Attribut ermöglicht eine vergleichende Analyse zwischen verschiedenen Arbeitsarten. Es hilft zu analysieren, ob Bug Fixes schneller verarbeitet werden als neue Funktionen, oder die Ressourcenverteilung für Technical Debt gegenüber Neuentwicklungen zu verstehen. Es ist eine Schlüsseldimension im Dashboard 'Throughput by Project and Type'.
Bedeutung
Kategorisiert Arbeitselemente und ermöglicht so Leistungsvergleiche und die Analyse, wie verschiedene Arten von Arbeit (z. B. Bugs vs. Funktionen) den Prozess durchlaufen.
Datenquelle
Typischerweise abgeleitet von GitHub Labels, die auf Issues oder Pull Requests angewendet werden. Erfordert eine konsistente Labeling-Konvention (z. B. 'type:bug', 'type:feature').
Beispiele
BugFeatureAufgabeTechnical Debt
|
|||
|
Zugewiesener Benutzer
Assignee
|
Der Benutzer oder Entwickler, der für die Bearbeitung des Entwicklungselements oder einer spezifischen Aufgabe, wie einem Pull Request Review, zugewiesen ist. | ||
|
Beschreibung
Dieses Attribut identifiziert die für die Arbeit in einer bestimmten Phase verantwortliche Person. Dies könnte der Assignee eines Issues, der Autor eines Pull Requests oder der für einen Code Review angeforderte Reviewer sein. Die Verfolgung des Assignees ist entscheidend, um die Ressourcenverteilung und Workload zu verstehen. Dieses Attribut wird in der Analyse verwendet, um die Entwickler-Workload zu überwachen, Ressourcenengpässe zu identifizieren und die Übergabeeffizienz zwischen verschiedenen Teammitgliedern zu analysieren. Dashboards können nach Assignee gefiltert werden, um die individuelle oder Teamleistung zu bewerten und eine ausgewogene Arbeitsverteilung sicherzustellen.
Bedeutung
Entscheidend für die Analyse der Entwickler-Arbeitslast, der Teamleistung und der Effizienz von Übergaben zwischen verschiedenen Teammitgliedern.
Datenquelle
Verfügbar im 'assignee'- oder 'user'-Objekt innerhalb der JSON-Payloads für Issues, Pull Requests und Review-Events von der GitHub API.
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 der Urheber eines spezifischen Artefakts im Entwicklungsprozess. Zum Beispiel ist der Autor eines Issues die Person, die den Bug gemeldet oder das Feature angefordert hat. Der Autor eines Pull Requests ist der Entwickler, der den Code geschrieben hat. In der Analyse kann der Autor verwendet werden, um die Ursprünge der Arbeit zu verstehen. Beispielsweise könnte die Analyse der Autoren von Bug-Reports Muster aufdecken, die mit bestimmten Teams oder Funktionen zusammenhängen. Sie kann auch in Verbindung mit dem Assignee verwendet werden, um Übergabemuster zu analysieren.
Bedeutung
Identifiziert den Urheber eines Arbeitselements oder einer Codeänderung, was nützlich sein kann, um Quellen von Nacharbeit, Bug-Reports oder Feature-Requests zu analysieren.
Datenquelle
Verfügbar im 'user'-Objekt innerhalb des Hauptobjekts von API-Antworten für Issues, Pull Requests und Commits. Das Feld ist typischerweise 'user.login'.
Beispiele
sara.jonesmike.leeautomation-bot
|
|||
|
Bearbeitungszeit
ProcessingTime
|
Die berechnete Dauer einer Aktivität, die die aktive Arbeitszeit darstellt. | ||
|
Beschreibung
Die Bearbeitungszeit ist die verstrichene Zeit zwischen dem Start und dem Ende einer Aktivität. Sie wird berechnet als 'EndTimestamp' minus 'EventTimestamp'. Diese Metrik misst, wie lange es dauert, eine Aufgabe abzuschließen, wobei die Wartezeit bis zum Beginn der Aufgabe ausgeschlossen ist. Die Analyse der Bearbeitungszeit hilft dabei, zu identifizieren, welche Aktivitäten in Bezug auf den aktiven Aufwand am zeitaufwendigsten sind. Dies unterscheidet sich von der Cycle Time, die Wartezeiten einschließt. Zum Beispiel könnte ein Code Review eine lange Cycle Time, aber eine kurze Bearbeitungszeit haben, was darauf hindeutet, dass der Reviewer beschäftigt ist und der PR in einer Warteschlange liegt.
Bedeutung
Misst die Dauer der aktiven Arbeit und hilft zu unterscheiden zwischen der Zeit, die mit der Bearbeitung einer Aufgabe verbracht wurde, und der Zeit, in der auf deren Beginn gewartet wurde. Dies ist entscheidend für gezielte Effizienzverbesserungen.
Datenquelle
Berechnet durch Subtraktion des 'EventTimestamp' vom 'EndTimestamp' für einen einzelnen Aktivitätsdatensatz.
Beispiele
PT5M15SPT2H30MP1DT12H
|
|||
|
Bereitstellungsumgebung
DeploymentEnvironment
|
Die Zielumgebung für ein Deployment, wie z. B. 'Staging' oder 'Production'. | ||
|
Beschreibung
Dieses Attribut gibt an, wohin der Code deployed wird. Das Tracking von Deployments in verschiedene Umgebungen ist entscheidend, um den gesamten Lebenszyklus, von der Entwicklung bis zum Production Release, zu verstehen. Dieses Attribut ermöglicht die Analyse des Deployment-Subprozesses. Es kann verwendet werden, um die Zeit zu messen, die benötigt wird, um Code von Staging nach Production zu promoten, und um die Erfolgsrate von Deployments in verschiedene Umgebungen zu verfolgen. Es ist essenziell, um zu wissen, wann ein Entwicklungselement wirklich 'done' und an Benutzer ausgeliefert ist.
Bedeutung
Unterscheidet zwischen Pre-Production- und Produktions-Releases, was entscheidend ist, um die tatsächliche 'Time-to-Market' zu messen und Bereitstellungsmuster zu analysieren.
Datenquelle
Diese Informationen werden von der GitHub Deployments API abgerufen, die oft durch CI/CD Pipelines oder andere Automatisierungen ausgelöst wird.
Beispiele
developmentstagingproduction
|
|||
|
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, die erstellt wird, um an einem neuen Feature oder einem Bugfix zu arbeiten, ohne die Hauptcodebasis zu beeinflussen. Der Branch-Name enthält oft nützliche Informationen, wie die Issue-Nummer oder eine kurze Beschreibung der Arbeit. Die Analyse von Branch-Namen kann dazu beitragen, Branching-Strategien und die Einhaltung von Entwicklungskonventionen zu verstehen. Es hilft auch, spezifische Code-Commits mit einem Entwicklungselement zu verknüpfen und so ein vollständiges Bild der Codierungsaktivität zu liefern.
Bedeutung
Bietet Kontext über die spezifische Entwicklungslinie und hilft bei der Durchsetzung und Analyse von Branching-Strategien und Namenskonventionen.
Datenquelle
Verfügbar im 'ref'-Feld für Push-Events oder in den 'head'- und 'base'-Objekten innerhalb 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 (CI) Prüfung, z. B. 'passed' oder 'failed'. | ||
|
Beschreibung
Dieses Attribut spiegelt das Ergebnis automatisierter Builds, Tests und Scans wider, die gegen Code-Änderungen in einem Pull Request ausgeführt werden. CI Checks sind ein kritischer Qualitätssicherungsschritt in modernen Entwicklungs-Workflows. Die Analyse dieses Attributs hilft, die Effektivität des automatisierten Testings zu verstehen. Eine hohe Fehlerquote kann auf Probleme mit der Code-Stabilität, der Testsuite oder der Entwicklungsumgebung hinweisen. Es unterstützt die Aktivitäten 'CI Checks Passed' und 'CI Checks Failed' und hilft bei der Analyse von Verzögerungen, die durch fehlerhafte Builds verursacht werden.
Bedeutung
Zeigt den Erfolg oder Misserfolg automatisierter Qualitätstore an und gibt Einblick in die Codequalität und die Effektivität der CI-Pipeline.
Datenquelle
Ermittelt aus dem 'state'- oder 'conclusion'-Feld von Check-Run- oder Status-Objekten über die GitHub Checks oder Statuses API.
Beispiele
successfailurependingerror
|
|||
|
Commit Hash
CommitHash
|
Der eindeutige Identifier (SHA) für einen spezifischen Code Commit. | ||
|
Beschreibung
Ein Commit Hash ist ein 40-stelliger SHA-1-Hash, der einen Commit in Git eindeutig identifiziert. Er dient als permanente ID für eine spezifische Version des Codes. Commits sind die atomaren Einheiten der Änderung im Entwicklungsprozess. Obwohl hochgranular, bietet der Commit Hash die ultimative Rückverfolgbarkeit. Er ermöglicht es Analysten, ein Prozessereignis direkt mit der exakten vorgenommenen Codeänderung zu verknüpfen. Dies kann für Audits, Compliance oder detaillierte Ursachenanalysen von Produktionsvorfällen von unschätzbarem Wert sein.
Bedeutung
Stellt die granularste Verknüpfung zwischen einem Prozessschritt und der exakten Codeänderung bereit, wodurch eine vollständige Nachvollziehbarkeit für Audits und Debugging ermöglicht wird.
Datenquelle
Verfügbar in Push-Event-Payloads ('head_commit.id') oder über die Commits API für einen Pull Request oder Branch.
Beispiele
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
|
|||
|
Elementstatus
State
|
Der aktuelle Status eines Issues oder Pull Requests, z. B. 'open', 'closed' oder 'merged'. | ||
|
Beschreibung
Dieses Attribut gibt den übergeordneten Status eines Entwicklungselements an. Bei Issues sind die typischen Zustände 'open' und 'closed'. Bei Pull Requests umfassen die Zustände 'open', 'closed' und 'merged'. Dies bietet eine Momentaufnahme des Fortschritts des Elements. In der Analyse wird der Zustand verwendet, um aktive von abgeschlossenen Arbeiten zu unterscheiden. Er ist unerlässlich für Dashboards wie 'Active Development Progress', die laufende Arbeiten überwachen. Er wird auch verwendet, um das Ende eines Prozesses zu definieren, zum Beispiel könnte ein Zustand von 'merged' oder 'closed' den Abschluss eines Case bedeuten.
Bedeutung
Bietet einen klaren Hinweis darauf, ob ein Work Item gerade in Bearbeitung oder abgeschlossen ist, was für die Lebenszyklusanalyse und die Überwachung aktiver Arbeiten von grundlegender Bedeutung ist.
Datenquelle
Direkt verfügbar als 'state'-Feld in den JSON-Payloads für Issues und Pull Requests von der GitHub API.
Beispiele
opengeschlossenmerged
|
|||
|
Entwicklungs-Durchlaufzeit
DevelopmentCycleTime
|
Die gesamte verstrichene Zeit von der Erstellung eines Entwicklungselements bis zu dessen finalem Deployment oder Abschluss. | ||
|
Beschreibung
Dies ist eine Case-Level-Metrik, berechnet als Zeitdifferenz zwischen dem allerersten Event (z. B. 'Issue Created') und dem finalen Event (z. B. 'Deployment Succeeded' oder 'Issue Closed') für ein einzelnes Entwicklungselement. Dies ist einer der wichtigsten KPIs zur Messung der Gesamteffizienz des Entwicklungsprozesses. Er unterstützt direkt das Dashboard 'Overall Development Cycle Time' und den KPI 'Average Development Cycle Time'. Die Reduzierung dieser Metrik ist oft ein primäres Ziel von Prozessverbesserungsinitiativen.
Bedeutung
Repräsentiert die End-to-End 'Time-to-Market' für ein Entwicklungselement, was es zu einem kritischen KPI für die Messung der gesamten Prozessgeschwindigkeit und Effizienz macht.
Datenquelle
Berechnet auf Case-Ebene durch Subtraktion des Timestamps der ersten Aktivität vom Timestamp der letzten Aktivität.
Beispiele
P5DT6H30MP14DT12HP1DT2H
|
|||
|
Ist Nacharbeit
IsRework
|
Ein boolesches Flag, das wahr ist, wenn eine Aktivität eine Regression zu einer vorherigen Prozessphase darstellt. | ||
|
Beschreibung
Dieses Flag wird auf 'true' gesetzt, wenn ein Entwicklungselement im Prozess rückwärts bewegt wird, z. B. wenn ein Pull Request ein 'Changes Requested'-Review erhält oder wenn ein Issue nach dem Schließen wieder geöffnet wird. Es wird durch die Analyse der Abfolge von Aktivitäten abgeleitet. Dieses Attribut ist essenziell für die Quantifizierung von Verschwendung und Ineffizienz. Es unterstützt direkt das Dashboard 'Rework and Regression Loops' und den KPI 'Rework Rate'. Durch das Filtern nach 'IsRework = true' können Analysten die Ursachen für Nacharbeit isolieren und untersuchen.
Bedeutung
Kennzeichnet explizit Aktivitäten, die Nacharbeit darstellen, wodurch es einfach wird, die Ursachen von Prozessineffizienzen zu quantifizieren, zu visualisieren und zu analysieren.
Datenquelle
Dies ist ein abgeleitetes Attribut. Die Logik beinhaltet die Definition eines Standard-Prozessflusses und das Markieren jeder Aktivität, die durch die Rückkehr zu einer früheren logischen Phase abweicht.
Beispiele
truefalsch
|
|||
|
Labels
Labels
|
Eine Liste von Tags oder Labels, die einem Issue oder Pull Request zur Kategorisierung zugewiesen wurden. | ||
|
Beschreibung
Labels in GitHub sind eine flexible Methode, um Issues und Pull Requests Metadaten hinzuzufügen. Sie können verwendet werden, um Priorität, Arbeitsart, Komponenten, Teams oder Status zu kennzeichnen. Die Rohliste der Labels bietet einen reichhaltigen, unstrukturierten Kontext. Während spezifische Attribute wie Priorität und Typ von Labels abgeleitet werden, kann die Beibehaltung der vollständigen Liste für Ad-hoc-Analysen und die Entdeckung anderer Prozessmuster nützlich sein. Sie ermöglicht eine flexible Filterung und Segmentierung von Cases basierend auf jeder Kombination von Labels.
Bedeutung
Bietet eine flexible, reichhaltige Quelle für Metadaten zur Kategorisierung von Work Items, die eine tiefe und vielfältige dimensionale Analyse ermöglicht.
Datenquelle
Verfügbar als 'labels'-Array im JSON-Payload für Issues und Pull Requests von der GitHub API. Jedes Element im Array ist ein Objekt mit einem 'name'-Feld.
Beispiele
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Zeitstempel, der angibt, wann die Daten für diesen Datensatz zuletzt aus dem Quellsystem aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder -aktualisierung. Es liefert Metadaten über die Aktualität der analysierten Daten. Dies unterscheidet sich vom Event-Timestamp, der aufzeichnet, wann das Geschäfts-Event stattfand. In der Analyse ist dieses Feld entscheidend, um die Aktualität der Prozessansicht zu verstehen. Es hilft Benutzern zu wissen, ob sie Echtzeitdaten oder eine Momentaufnahme zu einem bestimmten Zeitpunkt betrachten, was für operative Dashboards und das Monitoring wichtig ist.
Bedeutung
Zeigt die Aktualität der Daten an, was entscheidend ist, um sicherzustellen, dass Analysen und Dashboards auf aktuellen Informationen basieren.
Datenquelle
Dieser
Beispiele
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Prüfer
Reviewer
|
Der Benutzer, der zur Durchführung eines Code Reviews für einen Pull Request angefordert wurde. | ||
|
Beschreibung
Ein Reviewer ist ein Entwickler oder Teammitglied, das zugewiesen wird, um Codeänderungen in einem Pull Request auf Qualität, Korrektheit und Einhaltung von Standards zu prüfen. Ein Pull Request kann mehrere Reviewer haben. Dieses Attribut ist entscheidend für die Analyse des Code-Review-Prozesses. Es hilft, Engpässe im Zusammenhang mit spezifischen Reviewern zu identifizieren, die Verteilung der Review-Arbeitslast zu verstehen und die Zeit zu messen, die Reviewer benötigen, um auf Anfragen zu reagieren. Es ist eine Schlüsselkomponente für die Berechnung des KPIs 'Durchschnittliche Code-Review-Durchlaufzeit'.
Bedeutung
Identifiziert die Personen, die am Qualitätssicherungsprozess beteiligt sind, und ermöglicht so die Analyse von Review-Arbeitslasten, Verzögerungen und der Gesamteffizienz von Code-Reviews.
Datenquelle
Verfügbar im 'requested_reviewers'-Array oder dem 'user'-Objekt eines Pull Request Review-Events von der GitHub API.
Beispiele
alex.chenmaria.garciasenior-dev-team
|
|||
|
Prüfstatus
ReviewState
|
Das Ergebnis eines Code Reviews bei einem Pull Request, wie z. B. 'Approved' oder 'Changes Requested'. | ||
|
Beschreibung
Dieses Attribut erfasst die Entscheidung eines Reviewers. Gängige Zustände sind 'APPROVED', was anzeigt, dass der Code zum Mergen bereit ist, und 'CHANGES_REQUESTED', was darauf hinweist, dass Nacharbeit erforderlich ist. Andere Zustände könnten 'COMMENTED' oder 'PENDING' sein. Dies ist ein kritisches Attribut für die Analyse von Nacharbeit und Qualität. Eine hohe Häufigkeit von 'CHANGES_REQUESTED'-Events kann auf Probleme mit der initialen Codequalität oder unklare Anforderungen hindeuten. Es unterstützt direkt das Dashboard 'Rework and Regression Loops', indem es identifiziert, wann ein Entwicklungselement zur Änderung zurückgesendet wird.
Bedeutung
Zeigt direkt Nacharbeitsschleifen und Qualitätstore innerhalb des Code-Review-Prozesses an und hilft, die Quellen von Ineffizienz und Qualitätsproblemen genau zu bestimmen.
Datenquelle
Verfügbar als 'state'-Feld innerhalb eines Pull Request Review-Objekts von der GitHub API. Zum Beispiel in einem 'PullRequestReviewEvent'-Payload.
Beispiele
GENEHMIGTCHANGES_REQUESTEDCOMMENTED
|
|||
|
Pull Request Nummer
PullRequestNumber
|
Der eindeutige Identifier für einen Pull Request, der mit dem Entwicklungselement verknüpft ist. | ||
|
Beschreibung
Ein Pull Request (PR) ist ein Vorschlag, eine Reihe von Codeänderungen in einen bestimmten Branch zusammenzuführen. Die Pull Request Nummer verknüpft Entwicklungsaktivitäten wie Code-Pushes und Reviews mit dem primären Entwicklungselement oder Issue. Diese ID ist entscheidend für die Verfolgung des Code-Integrations- und Review-Subprozesses innerhalb des gesamten Entwicklungslebenszyklus. Sie ermöglicht eine detaillierte Analyse des Code-Review-Prozesses, einschließlich Review-Zeiten, während des Reviews identifizierter Nacharbeitszyklen und Merge-Raten. Sie verbindet die Planungsphase (Issue) mit der Implementierungsphase (PR).
Bedeutung
Verknüpft Issues mit den spezifischen Code-Änderungen und Review-Prozessen und ermöglicht so eine detaillierte Analyse des Code-Review-Zyklus und dessen Einfluss auf die gesamte Lieferzeit.
Datenquelle
Verfügbar als 'number'-Feld innerhalb des 'pull_request'-Objekts in vielen GitHub API-Antworten oder als Hauptidentifikator von der Pull Requests API.
Beispiele
12345678910
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem die Daten des Entwicklungsprozesses extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut identifiziert den Ursprung der Event-Daten. Für diesen Prozess wäre der Wert konsistent 'GitHub'. In einer komplexeren Umgebung, in der Entwicklungsaktivitäten mehrere Systeme umfassen (z. B. Jira für die Planung, GitHub für Code, Jenkins für Deployment), wird dieses Feld verwendet, um die Quelle jedes Events zu unterscheiden. In der Analyse hilft es, Daten zur Validierung und Fehlerbehebung zu ihrem Ursprung zurückzuverfolgen. Es ermöglicht auch die Analyse von Prozessen, die verschiedene Plattformen überspannen, und bietet einen klaren Kontext für jede Aktivität.
Bedeutung
Identifiziert den Ursprung der Daten, was für die Datenvalidierung und die Analyse von Prozessen, die sich über mehrere integrierte Systeme erstrecken können, unerlässlich ist.
Datenquelle
Dies ist typischerweise ein statischer Wert, der während des Datenextraktions-, Transformations- und Ladevorgangs (ETL-Prozess) hinzugefügt wird, um die Quelle der Datensätze zu kennzeichnen.
Beispiele
GitHubGitHub Enterprise
|
|||
|
Übergabe-Wartezeit
HandoffWaitingTime
|
Die berechnete Leerlaufzeit, die ein Entwicklungselement zwischen Aktivitäten verschiedener Personen wartet. | ||
|
Beschreibung
Diese Metrik misst die Zeit zwischen dem Abschluss einer Aktivität und dem Beginn der nächsten, jedoch nur, wenn die verantwortliche Person wechselt. Zum Beispiel die Zeit zwischen einem 'Review Requested'-Event und einem 'Changes Requested in Review'-Event durch einen anderen Benutzer. Dies ist eine kritische Metrik zur Identifizierung von Kommunikationslücken und Koordinationsproblemen. Sie unterstützt das Dashboard 'Critical Handoff Efficiency' und den KPI 'Average Handoff Waiting Time'. Hohe Wartezeiten an Übergabepunkten sind oft ein Zeichen für Ressourcenengpässe oder ineffiziente Benachrichtigungsprozesse.
Bedeutung
Zeigt Verzögerungen auf, die durch schlechte Koordination oder Ressourcenmangel bei Übergaben zwischen verschiedenen Teams oder Rollen entstehen, welche oft Hauptursachen für Ineffizienz sind.
Datenquelle
Berechnet durch die Identifizierung sequentieller Aktivitäten, bei denen sich das Attribut 'Assignee' oder 'User' ändert, und anschließende Messung der Zeitlücke dazwischen.
Beispiele
PT1H15MP2DT4HPT25M
|
|||
Software Development Lifecycle Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
CI-Prüfungen bestanden
|
Repräsentiert den erfolgreichen Abschluss automatisierter Prüfungen, wie z. B. Builds, Unit Tests oder statische Analyse, die gegen den Code in einem Pull Request ausgeführt wurden. Dieses Event wird aus dem Status der Prüfungen abgeleitet, die von Systemen wie GitHub Actions gemeldet werden. | ||
|
Bedeutung
Dieser automatisierte Qualitätssicherungsschritt ist entscheidend für die Code-Stabilität. Fehler oder lange Laufzeiten können erhebliche Engpässe in der Delivery Pipeline darstellen.
Datenquelle
Abgeleitet von der GitHub Checks API oder Statuses API. Ein Check-Run oder Status-Update meldet einen 'success' oder 'completed' mit einem 'success'-Schluss.
Erfassen
Überwachen Sie die Checks API auf eine 'success'-Conclusion bei den relevanten Check-Suites.
Ereignistyp
inferred
|
|||
|
Problem erstellt
|
Dies markiert den Beginn des Lebenszyklus eines Entwicklungselements und stellt die formelle Erstellung einer Aufgabe, eines Bugs oder einer Feature-Anfrage dar. Dieses Event wird explizit erfasst, wenn ein Benutzer ein neues Issue in einem GitHub Repository erstellt. | ||
|
Bedeutung
Dies ist die primäre Startaktivität für den Prozess, die entscheidend ist, um die gesamte Entwicklungs-Cycle Time zu messen und die initialen Arbeitsquellen zu verstehen.
Datenquelle
Dies ist ein explizites Event, das aus dem GitHub Issues API Event Stream erfasst wird. Der Event-Typ ist typischerweise 'opened' für eine gegebene Issue-Nummer.
Erfassen
Überwachen Sie das 'opened'-Event eines Issues über Webhooks oder API-Polling.
Ereignistyp
explicit
|
|||
|
Pull Request gemerged
|
Die genehmigten Code-Änderungen aus dem Pull Request werden offiziell in den Ziel-Branch, wie z. B. Main oder Develop, integriert. Dies ist eine explizite, finale Aktion bei einem Pull Request, die den neuen Code integriert. | ||
|
Bedeutung
Dies ist ein kritischer Meilenstein, der den Abschluss von Entwicklung und Review darstellt. Für viele Teams ist dies der letzte Schritt vor dem automatisierten Deployment.
Datenquelle
Erfasst aus dem GitHub Pull Request API Event-Stream oder Webhooks. Die Event-Aktion ist 'closed' und das 'merged'-Attribut des Pull Request Payloads ist true.
Erfassen
Überwachen Sie die 'closed'-Aktion eines Pull Requests und prüfen Sie, ob das 'merged'-Flag auf 'true' gesetzt ist.
Ereignistyp
explicit
|
|||
|
Pull Request genehmigt
|
Ein Reviewer hat die Änderungen in einem Pull Request formell genehmigt und damit bestätigt, dass dieser Qualitäts- und Funktionsstandards erfüllt. Dies wird erfasst, wenn ein Reviewer sein Review mit dem Status 'approve' einreicht. | ||
|
Bedeutung
Dies ist ein entscheidender Qualitätssicherungsschritt und ein wichtiger Meilenstein vor dem Mergen. Die Zeit, die benötigt wird, um diesen Zustand ab der PR-Erstellung zu erreichen, ist ein kritischer KPI für die Effizienz des Review-Prozesses.
Datenquelle
Erfasst von der GitHub Pull Request API oder Webhooks, wenn ein Review mit dem Status 'APPROVED' eingereicht wird.
Erfassen
Filtern Sie Pull Request Review-Einreichungs-Events nach dem Status 'APPROVED'.
Ereignistyp
explicit
|
|||
|
Pull Request geöffnet
|
Zeigt an, dass ein initialer Codeblock zur Überprüfung und Integration bereit ist. Ein Entwickler erstellt einen Pull Request (PR), um Änderungen von seinem Feature Branch in einen Main Branch vorzuschlagen. Dies ist ein explizites Event in GitHub. | ||
|
Bedeutung
Dies ist ein kritischer Meilenstein, der das Ende der initialen Entwicklungsphase und den Beginn der Review- und Integrations-Pipeline markiert. Er ist entscheidend für die separate Analyse von Entwicklungs- und Review-Cycle Times.
Datenquelle
Erfasst aus dem GitHub Pull Request API Event-Stream oder Webhooks. Die Event-Aktion ist 'opened'.
Erfassen
Überwachen Sie die 'opened'-Aktion für einen Pull Request über Webhooks oder API-Polling.
Ereignistyp
explicit
|
|||
|
Sachverhalt abgeschlossen
|
Das Entwicklungselement gilt als abgeschlossen, und das entsprechende Issue wird formell geschlossen. Dies kann automatisch geschehen, wenn ein verknüpfter Pull Request gemerged wird, oder manuell von einem Teammitglied durchgeführt werden. | ||
|
Bedeutung
Diese Aktivität dient als definitives Ende des Prozesses für ein Entwicklungselement. Sie ist entscheidend für die Berechnung der End-to-End Cycle Times.
Datenquelle
Dies ist ein explizites Event, das aus dem GitHub Issues API Event Stream erfasst wird. Der Event-Typ ist 'closed'.
Erfassen
Überwachen Sie das 'closed'-Event eines Issues über Webhooks oder API-Polling.
Ereignistyp
explicit
|
|||
|
Änderungen im Review angefordert
|
Ein Reviewer hat seine Code-Überprüfung abgeschlossen und festgestellt, dass Änderungen erforderlich sind, bevor der Pull Request genehmigt werden kann. Der Reviewer reicht sein Review formell mit dem Status 'request_changes' ein. | ||
|
Bedeutung
Dieses Event signalisiert explizit eine Nacharbeitsschleife. Die Analyse seiner Häufigkeit hilft, Qualitätsprobleme, unklare Anforderungen oder Bereiche für Entwicklerschulungen zu identifizieren.
Datenquelle
Erfasst von der GitHub Pull Request API oder Webhooks, wenn ein Review mit dem Status 'CHANGES_REQUESTED' eingereicht wird.
Erfassen
Filtern Sie Pull Request Review-Einreichungs-Events nach dem Status 'CHANGES_REQUESTED'.
Ereignistyp
explicit
|
|||
|
Bereitstellung erfolgreich
|
Die Code-Änderungen wurden erfolgreich in eine bestimmte Umgebung, wie Staging oder Production, deployed. Dieses Event wird typischerweise über die GitHub Deployments API erfasst, oft ausgelöst durch eine GitHub Action nach einem Merge. | ||
|
Bedeutung
Dies kennzeichnet den Übergang von Code aus dem Repository in eine Live-Umgebung. Die Verfolgung ist entscheidend, um die gesamte Lead Time von der Idee bis zur Produktion zu messen.
Datenquelle
Erfasst über die Deployments API. Ein externer Service oder eine GitHub Action erstellt ein Deployment und aktualisiert dann dessen Status auf 'success'.
Erfassen
Überwachen Sie Deployment-Status-Events über Webhooks auf den Status 'success'.
Ereignistyp
inferred
|
|||
|
Branch erstellt
|
Repräsentiert den Beginn der aktiven Entwicklungsarbeit für ein Issue, bei dem ein Entwickler einen neuen Branch vom Main-Codebase erstellt. Dies ist ein explizites Event, das erfasst wird, wenn ein neuer Branch in das Repository gepusht wird und oft die Issue-Nummer im Namen enthält. | ||
|
Bedeutung
Zeigt den Übergang von der Planung zur aktiven Codierung an. Die Messung der Zeit zwischen der Issue-Erstellung und diesem Event hilft, die Entwickler-Aufnahmezeit und anfängliche Backlog-Verzögerungen zu analysieren.
Datenquelle
Erfasst über die GitHub Git API oder Webhooks, die auf 'create'-Events vom Typ 'branch' hören. Es ist oft notwendig, den Branch-Namen über Namenskonventionen, wie 'feature/issue-123', mit einem Issue zu verknüpfen.
Erfassen
Parsen Sie 'create'-Webhook-Events für neue Branches und verknüpfen Sie diese mit einem Issue.
Ereignistyp
explicit
|
|||
|
CI-Prüfungen fehlgeschlagen
|
Repräsentiert das Scheitern einer automatisierten Prüfung, wie z. B. ein Build-Fehler oder ein fehlgeschlagener Unit Test, der gegen den Code in einem Pull Request ausgeführt wurde. Dies wird von einem Fehlermeldungsstatus abgeleitet, der von einem System wie GitHub Actions gemeldet wird. | ||
|
Bedeutung
Diese Aktivität hebt technische Qualitätsprobleme hervor, die ein Eingreifen des Entwicklers erfordern und eine Nacharbeitsschleife erzeugen. Die Analyse der Fehlerhäufigkeit kann Verbesserungen beim lokalen Testing oder der Codequalität leiten.
Datenquelle
Abgeleitet von der GitHub Checks API oder Statuses API. Ein Check-Run oder Status-Update meldet einen 'failure' oder 'completed' mit einem 'failure'-Schluss.
Erfassen
Überwachen Sie die Checks API auf eine 'failure'-Conclusion bei den relevanten Check-Suites.
Ereignistyp
inferred
|
|||
|
Code an PR gepusht
|
Stellt eine Aktualisierung des zur Überprüfung eingereichten Codes dar, entweder als Teil des initialen PRs oder als Reaktion auf Review-Feedback. Dieses Event wird jedes Mal erfasst, wenn ein neuer Commit auf den Branch gepusht wird, der mit einem offenen Pull Request verknüpft ist. | ||
|
Bedeutung
Das Tracking dieser Events ist entscheidend, um Nacharbeitsschleifen zu identifizieren. Mehrere Pushes nach einem Review deuten darauf hin, dass Änderungen erforderlich waren, was die gesamte Cycle Time beeinflusst.
Datenquelle
Dies ist ein explizites Event in der Pull Request Timeline, oft als hinzugefügter Commit bezeichnet. Es kann vom 'push'-Webhook oder durch Überwachung der mit einem PR verknüpften Commits erfasst werden.
Erfassen
Verfolgen Sie 'push'-Events auf einem Branch, der mit einem offenen Pull Request verknüpft ist.
Ereignistyp
explicit
|
|||
|
Issue wiedereröffnet
|
Ein zuvor geschlossenes Issue wird reaktiviert, typischerweise weil der Fix unzureichend war oder eine Regression gefunden wurde. Dies ist ein explizites Event, das den Lebenszyklus des Entwicklungselements neu startet. | ||
|
Bedeutung
Dies signalisiert eine signifikante Nacharbeitsschleife, die auf einen potenziellen 'Production Defect Escape' oder eine unvollständige Korrektur hindeutet. Die Verfolgung ihrer Häufigkeit ist ein Schlüsselmaß für die gesamte Softwarequalität.
Datenquelle
Dies ist ein explizites Event, das aus dem GitHub Issues API Event Stream erfasst wird. Der Event-Typ ist 'reopened'.
Erfassen
Überwachen Sie das 'reopened'-Event eines Issues über Webhooks oder API-Polling.
Ereignistyp
explicit
|
|||
|
Review angefordert
|
Der Autor eines Pull Requests fordert formell spezifische Teammitglieder oder Teams auf, seinen Code zu überprüfen. Dies ist eine explizite Aktion innerhalb der GitHub UI oder API, die Benachrichtigungen an die angeforderten Reviewer auslöst. | ||
|
Bedeutung
Diese Aktivität markiert den offiziellen Beginn der Übergabe an den Code-Review-Prozess. Die Zeit zwischen diesem Schritt und einer Review-Einreichung hilft, die Reaktionsfähigkeit des Reviewers und potenzielle Engpässe zu messen.
Datenquelle
Erfasst aus dem GitHub Pull Request API Event-Stream oder Webhooks. Die Event-Aktion ist 'review_requested'.
Erfassen
Überwachen Sie die 'review_requested'-Aktion für einen Pull Request.
Ereignistyp
explicit
|
|||