Ihr Software Development Life Cycle (SDLC) Daten-Template
Ihr Software Development Life Cycle (SDLC) Daten-Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten für das Tracking
- Extraktionsanleitung
Software Development Life Cycle (SDLC) Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
`Development Item`
DevelopmentItemId
|
Der eindeutige Identifikator für eine einzelne Einheit der Entwicklungsarbeit, wie z. B. ein Funktion, Bug Fix oder Aufgabe. Dies dient als primärer Case-ID. | ||
|
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, zusammenhängenden Prozessinstanz. In der Analyse wird diese ID verwendet, um die End-to-End Durchlaufzeit 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-Ereignisse zu einem einzigen Case verbindet, um den End-to-End-Softwareentwicklungsprozess präzise zu visualisieren und zu analysierenn.
Datenquelle
Dies ist in der Regel die Issue Number oder Pull Request Number von GitHub. Sie kann aus dem 'number'-Feld im Payload von Issue- oder Pull Request-bezogenen Webhook-Ereignisse oder API-Responses extrahiert werden.
Beispiele
101PR-2345TASK-812
|
|||
|
Aktivität
ActivityName
|
Der Name eines spezifischen Ereignisse oder einer Aufgabe, die innerhalb des Software Development Life Cycle (SDLC) 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 Ereignisse bilden die Abfolge von Schritten, die den End-to-End-Prozess für ein Entwicklungselement darstellen. Dieses Attribut ist die Basis für Process Mining, da es zur Konstruktion der Prozessablauf verwendet wird. Die Analyse der Reihenfolge, Häufigkeit und Dauer dieser Aktivitäten macht den tatsächlichen Prozessfluss sichtbar, identifiziert gängige Pfade, hebt Abweichungen hervor und identifiziert Engpässe.
Bedeutung
Dieses Attribut ist die Basis der Prozessablauf 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 zusammengeführt
|
|||
|
Startzeit
EventTimestamp
|
Das genaue Datum und die Uhrzeit, zu der eine spezifische Entwicklungsaktivität oder ein Event stattgefunden hat. | ||
|
Beschreibung
Dieser Zeitstempel markiert den Beginn einer Aktivität. Er ist maßgeblich für die chronologische Anordnung von Ereignisse, um den Prozessfluss für jedes Entwicklungselement zu rekonstruieren. Die Reihenfolge und Zeitdifferenz zwischen diesen Zeitstempels werden zur Analyse der Prozess-Performance verwendet. In der Analyse ist dieses Attribut wichtig für die Berechnung aller zeitbasierten Metriken, einschließlich Durchlaufzeits, Bearbeitungszeiten und Wartezeiten. Es ermöglicht die Identifizierung von Verzögerungen zwischen den Schritten und liefert die Daten, die für die Engpassanalyse und Leistungsfähigkeit-Monitoring-Dashboards benötigt werden.
Bedeutung
Dieser Zeitstempel ist maßgeblich für die korrekte Reihenfolge von Ereignisse und die Berechnung aller Leistungsfähigkeit-Metriken, wie Durchlaufzeits 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-Zeitstempel markiert den Abschluss einer Aktivität. Während viele Ereignisse 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 'Bearbeitungszeit' (ProcessingTime) zu berechnen, die wichtig 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 Zeitstempel eines nachfolgenden, logisch abschließenden Ereignisse 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 in der Regel über Labels (z. B. 'P1-High', 'P2-Medium') verwaltet. Ein konsistentes Labeling-Schema ist erforderlich, um diese Informationen leistungsstark zu extrahieren. Dieses Attribut ist wichtig 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 Durchlaufzeit-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 Antrag bearbeitet.en 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 Prozess-Performance über verschiedene Projekte hinweg. Es hilft, Fragen zu beantworten wie: 'Welches Projekt hat die längste Durchlaufzeit?' 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 Typ'.
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 in der Regel '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. Funktion, Bug, Aufgabe oder Epic. | ||
|
Beschreibung
Dieses Attribut kategorisiert die Art der ausgeführten Arbeit. Diese Informationen werden in der Regel über Labels oder spezifische Issue Templates innerhalb von GitHub verwaltet. Das Verständnis der Arbeitsart ist maßgeblich für die Festlegung angemessener Leistungsfähigkeit-Erwartungen, da ein Bug Fix eine viel kürzere erwartete Durchlaufzeit haben könnte als ein neues Funktion. Dieses Attribut ermöglicht eine vergleichende Analyse zwischen verschiedenen Arbeitsarten. Es hilft zu analysierenn, ob Bug Fixes schneller verarbeitet werden als neue Funktionen, oder den Antrag bearbeitet.ie Ressourcenverteilung für Technical Debt gegenüber Neuentwicklungen zu verstehen. Es ist eine Schlüsseldimension im Dashboard 'Throughput by Project and Typ'.
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
Bug`Funktion`AufgabeTechnische Schulden
|
|||
|
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 den Antrag bearbeitet.er für einen Code Review angeforderte Reviewer sein. Die Verfolgung des Assignees ist maßgeblich, 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 analysierenn. Dashboards können nach Assignee gefiltert werden, um die individuelle oder Teamleistung zu bewerten und eine ausgewogene Arbeitsverteilung sicherzustellen.
Bedeutung
Wesentlich 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-Ereignisse von der GitHub API.
Beispiele
john.doejane.smithdev-team-lead
|
|||
|
Autor
Author
|
Der Benutzer, der den Antrag bearbeitet.as Issue, den Pull Request oder den Antrag bearbeitet.en 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 den Antrag bearbeitet.as Funktion angefordert hat. Der Autor eines Pull Requests ist der Entwickler, der den Antrag bearbeitet.en 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 verknüpft. Sie kann auch in Verbindung mit dem Assignee verwendet werden, um Übergabemuster zu analysierenn.
Bedeutung
Identifiziert den Urheber eines Arbeitselements oder einer Codeänderung, was nützlich sein kann, um Quellen von Nacharbeit, Bug-Reports oder Funktion-Requests zu analysierenn.
Datenquelle
Verfügbar im 'user'-Objekt innerhalb des Hauptobjekts von API-Antworten für Issues, Pull Requests und Commits. Das Feld ist in der Regel 'user.login'.
Beispiele
sara.jonesmike.leeautomation-bot
|
|||
|
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 maßgeblich, 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 wichtig, um zu wissen, wann ein Entwicklungselement wirklich 'done' und an Benutzer ausgeliefert ist.
Bedeutung
Unterscheidet zwischen Pre-Production- und Produktions-Releases, was wichtig ist, um die tatsächliche 'Time-to-Market' zu messen und Bereitstellungsmuster zu analysierenn.
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 Funktion 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-Ereignisse 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 den Antrag bearbeitet.er 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 Identifikator (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 den Antrag bearbeitet.etaillierte Ursachenanalysen von Produktionsvorfällen von besonders wertvoll 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 Durchlaufzeit' und den KPI 'Average Development Durchlaufzeit'. Die Reduzierung dieser Metrik ist oft ein primäres Ziel von Prozessoptimierungsinitiativen.
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 Fallebene durch Subtraktion des Zeitstempels der ersten Aktivität vom Zeitstempel 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 'Ja' 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 wichtig 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 = Ja' 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 analysierenn.
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
JaNein
|
|||
|
Labels
Labels
|
Eine Listee 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 Listee für Ad-hoc-Analysen und die Entdeckung anderer Prozessmuster nützlich sein. Sie ermöglicht eine flexible Filterung und Segmentierung von Fälle 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-Zeitstempel, der aufzeichnet, wann das Geschäftsereignis stattfand. In der Analyse ist dieses Feld wichtig, 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 wichtig 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 maßgeblich 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 den Antrag bearbeitet.em 'user'-Objekt eines Pull Request Review-Ereignisse 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'-Ereignisse 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 Identifikator 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 maßgeblich 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 Ereignisse 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, notwendig ist.
Datenquelle
Dies ist in der Regel 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 Wartezeit'. 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 'Benutzer' ändert, und anschließende Messung der Zeitlücke dazwischen.
Beispiele
PT1H15MP2DT4HPT25M
|
|||
Software Development Life Cycle (SDLC) Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
CI-Checks 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 maßgeblich 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 Funktion-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 wichtig ist, um die gesamte Entwicklungs-Durchlaufzeit 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 in der Regel 'opened' für eine gegebene Issue-Nummer.
Erfassen
Überwachen Sie das 'opened'-Event eines Issues über Webhooks oder API-Polling.
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 wichtiger 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-Ereignisse 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 Funktion Branch in einen Main Branch vorzuschlagen. Dies ist ein explizites Event in GitHub. | ||
|
Bedeutung
Dies ist ein kritischer Meilenstein, der den Antrag bearbeitet.as Ende der initialen Entwicklungsphase und den Beginn der Review- und Integrations-Pipeline markiert. Er ist maßgeblich für die separate Analyse von Entwicklungs- und Review-Durchlaufzeits.
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
|
|||
|
Pull Request zusammengeführt
|
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 Antrag bearbeitet.en 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 Ja.
Erfassen
Überwachen Sie die 'closed'-Aktion eines Pull Requests und prüfen Sie, ob das 'merged'-Flag auf 'Ja' gesetzt ist.
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 maßgeblich für die Berechnung der End-to-End Durchlaufzeits.
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-Ereignisse nach dem Status 'CHANGES_REQUESTED'.
Ereignistyp
explicit
|
|||
|
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 analysierenn.
Datenquelle
Erfasst über die GitHub Git API oder Webhooks, die auf 'create'-Ereignisse 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-Ereignisse 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 den Antrag bearbeitet.er 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 Ereignisse ist maßgeblich, um Nacharbeitsschleifen zu identifizieren. Mehrere Pushes nach einem Review deuten darauf hin, dass Änderungen erforderlich waren, was die gesamte Durchlaufzeit beeinflusst.
Datenquelle
Dies ist ein explizites Event in der Pull Request Timeline, oft als hinzugefügter Commit bezeichnet. Es kann vom 'push'-Webhook oder den Antrag bearbeitet.urch Überwachung der mit einem PR verknüpften Commits erfasst werden.
Erfassen
Verfolgen Sie 'push'-Ereignisse auf einem Branch, der mit einem offenen Pull Request verknüpft ist.
Ereignistyp
explicit
|
|||
|
Deployment erfolgreich
|
Die Code-Änderungen wurden erfolgreich in eine bestimmte Umgebung, wie Staging oder Production, deployed. Dieses Event wird in der Regel ü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 maßgeblich, 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-Ereignisse über Webhooks auf den Status 'success'.
Ereignistyp
inferred
|
|||
|
Issue wiedereröffnet
|
Ein zuvor geschlossenes Issue wird reaktiviert, in der Regel 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
|
|||