Ihr Software Development Lifecycle Daten-Template

GitLab
Ihr Software Development Lifecycle Daten-Template

Ihr Software Development Lifecycle Daten-Template

Dieses umfassende Template führt Sie durch die wesentlichen Datenpunkte, die zur Analyse Ihres Software Development Lifecycle Prozesses erforderlich sind. Es umreißt die entscheidenden Attribute, die gesammelt werden müssen, die zu verfolgenden Schlüsselaktivitäten und bietet praktische Anleitungen zur direkten Extraktion dieser Informationen aus GitLab. Mit dieser Ressource können Sie Ihre Daten souverän für ein aufschlussreiches Process Mining vorbereiten.
  • Empfohlene Attribute zur Erfassung
  • Wichtige Aktivitäten zur Verfolgung
  • Extraktionsanleitung
Neu bei Event-Logs? Erfahren Sie wie Sie ein Process-Mining-Event-Log erstellen.

Software Development Lifecycle Attribute

Dies sind die empfohlenen Datenfelder, die Sie in Ihren Event Log aufnehmen sollten, um eine umfassende Analyse und Optimierung des Software Development Lifecycle zu ermöglichen.
3 Erforderlich 5 Empfohlen 13 Optional
Name Beschreibung
Aktivität
Activity
Der Name des spezifischen Prozessschritts oder Events, das aufgetreten ist, wie 'Issue Created' oder 'Merge Request Merged'.
Beschreibung

Das Attribut Activity erfasst die einzelnen Events, die ein Development Item durchläuft. Diese sind in GitLab nicht als einzelnes Feld gespeichert, sondern werden aus verschiedenen Aktionen und Timestamp-Feldern in Issues, Merge Requests und CI/CD Pipelines abgeleitet. Zum Beispiel sind die Erstellung eines Issue, das Pushen eines Commits, das Fehlschlagen einer Pipeline oder die Genehmigung eines Merge Request allesamt separate Aktivitäten.

Dieses Attribut ist grundlegend für den Aufbau der Process Map, die Visualisierung des Workflows und die Analyse der Sequenz und Häufigkeit von Events. Es wird verwendet, um Abweichungen, Bottlenecks zwischen Schritten und gängige Prozesspfade zu identifizieren.

Bedeutung

Es definiert die Schritte in der Process Map und ermöglicht die Visualisierung und Analyse des End-to-End Development Workflows.

Datenquelle

Abgeleitet von Event-Typen und State Changes im GitLab Event Stream oder durch die Interpretation von Timestamp-Feldern wie 'created_at', 'merged_at' und 'closed_at' bei Issues und Merge Requests.

Beispiele
Problem erstelltEntwicklung gestartetMerge Request gemergtPipeline fehlgeschlagenIn Produktion deployed
Development Item
DevelopmentItem
Der eindeutige Identifier für eine Arbeitseinheit, wie ein Feature, Bug Fix oder Task, der als primärer Case Identifier dient.
Beschreibung

Das Development Item repräsentiert eine einzelne, verfolgbare Arbeitseinheit, die den Software Development Lifecycle durchläuft. Es verbindet alle zugehörigen Aktivitäten, von der Erstellung bis zum finalen Deployment, zu einem kohärenten Case. In GitLab wird dies typischerweise durch die interne ID (IID) des Issue dargestellt, die innerhalb eines Projekts eindeutig ist.

Die Analyse nach Development Item ermöglicht die Messung der End-to-End Cycle Time, die Identifizierung von Bottlenecks und die Überprüfung der Prozesskonformität. Sie bildet die Grundlage für das Verständnis, wie effizient Arbeit vom Konzept bis zur Produktion geliefert wird.

Bedeutung

Dies ist der essenzielle Case Identifier, der alle Process Events miteinander verknüpft und es so ermöglicht, den gesamten Lifecycle jedes beliebigen Work Items nachzuvollziehen.

Datenquelle

Dies ist typischerweise die interne ID (IID) eines GitLab Issue. Sie kann in der Issues API-Antwort als 'iid'-Feld gefunden werden.

Beispiele
1024512PRJ-2345
Startzeit
StartTime
Der `Timestamp`, der anzeigt, wann eine `Aktivität` oder ein `Event` begann.
Beschreibung

StartTime markiert das genaue Datum und die Uhrzeit, zu der eine spezifische Aktivität aufgetreten ist. Für Events in GitLab wird dies in verschiedenen Timestamp-Feldern erfasst. Zum Beispiel wäre die StartTime der Aktivität 'Issue Created' der created_at Timestamp des Issue, während die StartTime der Aktivität 'Merge Request Merged' der merged_at Timestamp des Merge Request wäre.

Dieser Timestamp ist das zentrale zeitliche Element im Process Mining. Er wird verwendet, um Events chronologisch zu ordnen, Dauern zwischen Aktivitäten zu berechnen, Cycle Times zu messen und die Prozessperformance über die Zeit zu analysieren.

Bedeutung

Dieses Attribut liefert die chronologische Sequenz von Events, die essenziell für die Berechnung aller zeitbasierten Metriken und das Verständnis des Process Flow ist.

Datenquelle

Extrahiert aus verschiedenen Timestamp-Feldern in GitLab, wie 'created_at', 'updated_at', 'closed_at' bei Issues und 'merged_at' bei Merge Requests.

Beispiele
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
Assignee
Assignee
Der Benutzer, der dem Issue oder Merge Request zum Zeitpunkt des Events zugewiesen war.
Beschreibung

Der Assignee ist der einzelne Developer oder Nutzer, der zu einem bestimmten Zeitpunkt im Prozess für das Work Item verantwortlich ist. In GitLab wird dies im Feld assignee oder assignees eines Issue oder Merge Request erfasst.

Die Analyse nach Assignee ist entscheidend für das Dashboard 'Developer Workload & Allocation'. Sie hilft, die Ressourcenauslastung zu verstehen, überlastete Einzelpersonen oder Teams zu identifizieren und Handoffs zwischen verschiedenen Personen zu analysieren.

Bedeutung

Verfolgt, wer die Arbeit ausgeführt hat, ermöglicht die Analyse der Arbeitslast, die Effizienz der Ressourcenallokation und die Identifizierung von Verzögerungen durch Übergaben.

Datenquelle

Abgerufen aus den Feldern 'assignee.username' oder 'assignees' in den GitLab Issues und Merge Requests API-Antworten.

Beispiele
jdoeasmithr.williams
Dev Item Typ
DevelopmentItemType
Die Klassifizierung des Development Items, wie 'Feature', 'Bug', 'Task' oder 'Maintenance'.
Beschreibung

Dieses Attribut kategorisiert die Art der ausgeführten Arbeit. In GitLab wird dies üblicherweise durch Labels an einem Issue implementiert. Teams verwenden Labels, um zwischen neuen Funktionalitäten, Defect-Behebung, Technical Debt und anderen Work Types zu unterscheiden.

Die Analyse nach Development Item Type ermöglicht den Vergleich von Process Flows und Cycle Times für verschiedene Arbeitsarten. So kann beispielsweise analysiert werden, ob Bugs schneller behoben werden als Funktionen entwickelt, oder ob Technical Debt Aufgaben einem anderen Review-Prozess folgen.

Bedeutung

Die Segmentierung des Prozesses nach Work Type hilft zu identifizieren, ob bestimmte Arten von Arbeit anfälliger für Verzögerungen, Nacharbeiten oder Abweichungen sind.

Datenquelle

Wird typischerweise von den 'Labels' eines GitLab Issue abgeleitet. Eine Mapping-Logik ist erforderlich, um spezifische Labels in standardisierte Typen zu übersetzen.

Beispiele
FeatureBugAufgabeTechnische Schuld
Endzeit
EndTime
Der Timestamp, der anzeigt, wann eine Aktivität oder ein Event abgeschlossen wurde.
Beschreibung

EndTime markiert das genaue Datum und die Uhrzeit, zu der eine Aktivität abgeschlossen wurde. Für viele atomare Events in GitLab, wie z.B. 'Issue Created', ist die EndTime dieselbe wie die StartTime. Für Aktivitäten, die eine Dauer haben, wie 'Code Review', stellt es den Abschluss-Timestamp dar, zum Beispiel, wenn die endgültige Genehmigung erteilt wird.

Dieses Attribut ist unerlässlich für die genaue Berechnung der Dauer einzelner Aktivitäten (Processing Time). Es hilft bei der detaillierten Engpassanalyse, indem es zwischen der Zeit, die aktiv an einer Aufgabe gearbeitet wurde, und der Wartezeit zwischen Aufgaben unterscheidet.

Bedeutung

Ermöglicht die Berechnung präziser Aktivitätsdauern (Processing Times), was entscheidend ist, um ineffiziente Schritte im Prozess zu identifizieren.

Datenquelle

Bei atomaren Events ist dies identisch mit StartTime. Für dauerhafte Aktivitäten muss es durch das Auffinden eines entsprechenden Abschluss-Events in den Daten abgeleitet werden.

Beispiele
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
Projekt Name
ProjectName
Der Name des GitLab-Projekts, zu dem das Development Item gehört.
Beschreibung

Dieses Attribut identifiziert das spezifische Code-Repository oder Projekt, in dem die Arbeit ausgeführt wird. In GitLab ist jedes Issue und jeder Merge Request in einem Projekt enthalten.

Die Analyse nach Project Name ermöglicht Performance-Vergleiche über verschiedene Produkte, Komponenten oder Services hinweg. Es kann helfen zu identifizieren, ob bestimmte Projekte gesündere SDLC-Prozesse aufweisen als andere, und ist nützlich für das Filtern von Dashboards auf einen spezifischen Interessensbereich.

Bedeutung

Ermöglicht die Segmentierung der Prozessanalyse nach Produkt, Anwendung oder Komponente, was gezielte Verbesserungsmaßnahmen erleichtert.

Datenquelle

Abgerufen aus den Feldern 'name' oder 'path_with_namespace' in der Project API, verknüpft über die 'project_id' in Issues und Merge Requests.

Beispiele
platform/api-gatewayfrontend/customer-portalmobile/ios-app
Schweregrad
Severity
Der Severity-Level des Development Items, typischerweise für Bugs oder Incidents.
Beschreibung

Severity gibt den Impact eines Bugs oder Issue an, von kritisch bis geringfügig. GitLab verfügt über kein natives Severity-Feld, daher wird dies fast immer mit Labels implementiert (z.B. 'severity::1', 'severity::2').

Dieses Attribut ist essenziell für das Dashboard 'Severity Escalation Trends' und den zugehörigen KPI. Die Analyse von Severity-Änderungen über den Lifecycle kann Probleme aufzeigen, die anfänglich unterschätzt wurden, oder Prozesse, die Probleme verschärfen.

Bedeutung

Hilft bei der Priorisierung von Aufgaben und der Analyse, ob Elemente mit hoher Severity schneller bearbeitet werden. Die Verfolgung von Änderungen unterstützt den KPI 'Severity Escalation Frequency'.

Datenquelle

Abgeleitet von den 'Labels', die auf ein GitLab Issue angewendet werden. Eine Zuordnung ist erforderlich, um Labels wie 'S1', 'S2' als Severity Levels zu interpretieren.

Beispiele
1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
Bearbeitungszeit
ProcessingTime
Die Dauer einer einzelnen Aktivität, berechnet als die Differenz zwischen ihrer End- und Startzeit.
Beschreibung

Processing Time misst die aktive Arbeitszeit für eine spezifische Aktivität, getrennt von der Wartezeit zwischen den Aktivitäten. Sie wird als EndTime minus StartTime für einen einzelnen Event-Datensatz berechnet. Bei sofortigen Events ist die Processing Time null.

Diese Metrik ist entscheidend für die Stage-Specific Bottleneck Analysis. Durch die Aggregation der Processing Times von Aktivitäten innerhalb einer Phase, wie dem Code Review, können Analysten genau bestimmen, wie viel Zeit aktiv gearbeitet wird, und so ineffiziente Prozessschritte aufzeigen.

Bedeutung

Misst die Dauer einzelner Aktivitäten und hilft dabei, aktive Arbeitszeit von Leerlauf-Wartezeit für eine präzise Bottleneck-Analyse zu unterscheiden.

Datenquelle

Berechnet vom Process Mining Tool als Differenz zwischen der EndTime und StartTime einer Aktivität.

Beispiele
2 Stunden 30 Minuten0 Minuten3 Tage 8 Stunden
Dev Item Status
DevelopmentItemStatus
Der Status des Development Items zum Zeitpunkt des Events, wie 'Open', 'In Progress' oder 'Closed'.
Beschreibung

Dieses Attribut reflektiert den Status des primären Work Items, typischerweise eines Issue in GitLab. GitLab Issues haben einen state, der 'opened' oder 'closed' sein kann. Granularere Status werden oft über Scoped Labels verwaltet (z.B. 'Status::Triage', 'Status::In-Dev', 'Status::In-Review').

Das Tracking von Statusänderungen ist entscheidend für das Verständnis des Case Lifecycle. Es hilft zu identifizieren, wie lange Elemente in jedem Status verbleiben, und kann verwendet werden, um in Dashboards wie 'SDLC End-to-End Cycle Time' nach aktiver oder abgeschlossener Arbeit zu filtern.

Bedeutung

Bietet einen Snapshot des Case-Status, ermöglicht die Analyse der in verschiedenen Phasen verbrachten Zeit und das Filtern nach laufender versus abgeschlossener Arbeit.

Datenquelle

Der primäre Status stammt aus dem 'state'-Feld eines GitLab Issue ('opened', 'closed'). Feiner granulierte Status werden oft von Labels abgeleitet.

Beispiele
openedgeschlossenIn BearbeitungIn Prüfung
Durchlaufzeit
CycleTime
Die gesamte Zeitspanne von der ersten bis zur letzten Aktivität eines Development Items.
Beschreibung

Die Cycle Time ist eine berechnete Metrik, die die Gesamtdauer eines Cases misst. Sie wird typischerweise als die Zeitdifferenz zwischen dem allerersten Event (z.B. 'Issue Created') und dem allerletzten Event (z.B. 'Deployed to Production') für ein einzelnes Development Item berechnet.

Dies ist ein primärer KPI zur Messung der gesamten Prozesseffizienz. Sie ist die Schlüsselmetrik in Dashboards wie 'SDLC End-to-End Cycle Time' und wird verwendet, um Verbesserungen zu verfolgen und langwierige Cases zu identifizieren, die auf systemische Probleme hinweisen können.

Bedeutung

Dies ist ein zentraler Process Mining KPI, der die End-to-End-Effizienz des Development Lifecycle misst.

Datenquelle

Berechnet vom Process Mining Tool durch Subtraktion des minimalen StartTime vom maximalen StartTime für jede eindeutige CaseId.

Beispiele
10 Tage 4 Stunden23 Stunden 15 Minuten35 Tage
Ist Nacharbeit
IsRework
Ein Boolescher Flag, der anzeigt, ob eine Aktivität Teil einer Nacharbeitsschleife ist.
Beschreibung

Dieses berechnete Attribut kennzeichnet Aktivitäten, die einen Rückschritt im Prozess darstellen, wie die Rückkehr zur Entwicklung, nachdem das Testing bereits begonnen hat. Die Logik für dieses Flag beinhaltet typischerweise das Erkennen spezifischer Abfolgen von Aktivitäten, zum Beispiel ein 'Development Started'-Event, das nach einem 'Pipeline Failed'- oder 'QA Testing Started'-Event für denselben Case auftritt.

Dieses Attribut treibt direkt das Dashboard 'Rework & Rerun Analysis' und den KPI 'Rework Rate After Testing' an. Es ermöglicht das einfache Filtern und Quantifizieren von Nacharbeiten und hilft Teams, deren Häufigkeit, Ursachen und Auswirkungen auf Projektzeitpläne zu verstehen.

Bedeutung

Kennzeichnet und quantifiziert Nacharbeiten direkt, was die Analyse der Ursachen und Auswirkungen von Prozessineffizienzen und Qualitätsproblemen erleichtert.

Datenquelle

Berechnet vom Process Mining Tool durch Analyse der Abfolge von Aktivitäten für jeden Case und Identifizierung von Mustern, die auf Nacharbeit hinweisen.

Beispiele
truefalsch
Letzte Datenaktualisierung
LastDataUpdate
Der Timestamp, der angibt, wann die Daten für dieses Event zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung

Dieses Attribut zeichnet Datum und Uhrzeit auf, zu der die Event-Daten zuletzt im Process Mining Dataset extrahiert oder aktualisiert wurden. Es repräsentiert nicht den Zeitpunkt des Events, sondern den Zeitpunkt der letzten Synchronisierung des Event-Datensatzes.

Diese Information ist entscheidend für das Verständnis der Datenfrische und die Validierung der Aktualität der Prozessanalyse. Sie hilft Nutzern, darauf zu vertrauen, dass die Dashboards und KPIs auf aktuellen Daten basieren, und informiert sie über die potenzielle Verzögerung zwischen Quellsystem und Analyse.

Bedeutung

Schafft Transparenz über die Datenfrische und stellt sicher, dass Nutzer über den Aktualitätsgrad der Prozessanalyse informiert sind.

Datenquelle

Dieser Timestamp wird vom Datenextraktionstool oder ETL-Prozess zum Zeitpunkt eines Daten-Refreshes generiert und aufgezeichnet.

Beispiele
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
Meilenstein Titel
MilestoneTitle
Der Titel des Milestones oder Sprints, dem das Development Item zugewiesen ist.
Beschreibung

Ein Milestone in GitLab wird verwendet, um die Arbeit an einem bestimmten Ziel oder innerhalb eines Zeitrahmens, wie z.B. einem Sprint oder einer Release-Version, zu verfolgen. Dieses Attribut erfasst den Namen oder Titel dieses Milestones.

Dieses Attribut ermöglicht die Analyse der Prozess-Performance im Kontext spezifischer Sprints oder Planungsperioden. Es kann verwendet werden, um zu sehen, ob sich die Cycle Times von einem Sprint zum nächsten verbessern oder um die Prozessansicht so zu filtern, dass nur Arbeiten angezeigt werden, die sich auf ein bevorstehendes Release beziehen.

Bedeutung

Verknüpft Entwicklungsarbeit mit Planungszyklen wie Sprints oder Releases und ermöglicht die Analyse der Performance im Vergleich zu geplanten Timeboxes.

Datenquelle

Abgerufen aus dem Feld 'milestone.title' in den GitLab Issues oder Merge Requests API-Antworten.

Beispiele
Q4-2023 ReleaseSprint 23.11Phase 1: MVP
Merge Request Status
MergeRequestStatus
Der Status des Merge Request, der dem Event zugeordnet ist, wie 'Opened', 'Merged' oder 'Closed'.
Beschreibung

Dieses Attribut erfasst den Status eines Merge Request (MR) zum Zeitpunkt eines Events. GitLab MRs haben verschiedene Status: 'opened', 'closed', 'merged' oder 'locked'. Dies ist vom allgemeinen Development Item Status getrennt.

Das Tracking des MR-Status ist entscheidend für die Analyse der Code-Integrationsphase des SDLC. Es unterstützt Dashboards wie 'Code Review Cycle Time & Throughput' direkt und hilft, Verzögerungen zwischen MR-Erstellung, Review, Genehmigung und Merging genau zu bestimmen.

Bedeutung

Bietet Transparenz in den Code Review und Merging Prozess, der oft ein kritischer Bottleneck im SDLC ist.

Datenquelle

Abgerufen aus dem Feld 'state' in der GitLab Merge Requests API-Antwort.

Beispiele
openedmergedgeschlossenlocked
Pipeline Status
PipelineStatus
Der Status des CI/CD Pipeline-Laufs, wie 'Success', 'Failed' oder 'Running'.
Beschreibung

Dieses Attribut zeigt das Ergebnis einer CI/CD Pipeline-Ausführung an, die einem Commit oder Merge Request zugeordnet ist. Gängige Status in GitLab sind 'running', 'pending', 'success', 'failed', 'canceled' und 'skipped'.

Diese Daten sind essenziell für das Dashboard 'Rework & Rerun Analysis'. Häufige Pipeline-Fehler können eine erhebliche Quelle für Nacharbeiten und Verzögerungen sein, und die Analyse ihrer Häufigkeit, ihres Standorts und ihrer Auswirkungen ist entscheidend für die Verbesserung der Entwicklungseffizienz und Code-Qualität.

Bedeutung

Verfolgt den Erfolg und Misserfolg automatisierter Builds und Tests, hebt Nacharbeitschleifen sowie Probleme mit der Codequalität oder Testautomatisierung hervor.

Datenquelle

Abgerufen aus dem Feld 'status' in der GitLab CI/CD Pipelines API-Antwort.

Beispiele
successfehlgeschlagenrunningstorniert
Quellsystem
SourceSystem
Identifiziert das System, aus dem die Daten stammen.
Beschreibung

Dieses Attribut spezifiziert den Ursprung der Prozessdaten. Für dieses Datenmodell wird der Wert konsistent 'GitLab' sein.

Die Aufnahme dieses Attributs ist entscheidend in Umgebungen, in denen Prozessdaten aus mehreren Systemen kombiniert werden können, wie Jira für die Planung und GitLab für die Ausführung. Es ermöglicht das Filtern, die Segmentierung und hilft, die Datenherkunft zu erhalten.

Bedeutung

Gewährleistet Klarheit über die Datenherkunft, was entscheidend ist für die Data Governance und beim Integrieren von Daten aus mehreren Enterprise-Systemen.

Datenquelle

Dies ist ein statischer Wert, 'GitLab', der während des Datentransformationsprozesses hinzugefügt wird.

Beispiele
GitLab
Release Version
ReleaseVersion
Der geplante oder tatsächliche Software Version Tag, der dem Deployment zugeordnet ist.
Beschreibung

Dieses Attribut identifiziert die spezifische Software Release, zu der ein Development Item gehört. In GitLab kann dies über einen Milestone, einen geschützten Tag oder einen Eintrag im Releases Feature zugeordnet werden.

Dies ist essenziell für das Dashboard 'Release Schedule Adherence Tracking'. Durch den Vergleich des tatsächlichen Deployment-Datums mit einem geplanten Datum, das der Release Version zugeordnet ist, können Organisationen ihre Fähigkeit zur Einhaltung von Zeitplänen messen und die Ursachen von Release-Verzögerungen diagnostizieren.

Bedeutung

Verbindet Development Items mit einem spezifischen Software-Release, was entscheidend ist für die Verfolgung des Release-Fortschritts und die Einhaltung des Zeitplans.

Datenquelle

Dies kann aus GitLab Releases, dem Namen eines Git Tags oder dem Titel eines Milestones bezogen werden, der für die Release-Planung verwendet wird.

Beispiele
v1.2.0v3.0.0-beta2023.4.1
Teamname
TeamName
Das Entwicklungsteam, das dem Projekt oder Assignee zugeordnet ist.
Beschreibung

Team Name repräsentiert die Gruppe oder das Squad, das für das Development Item verantwortlich ist. Diese Information ist typischerweise kein Standardfeld in GitLab und wird oft aus Projekt-Namenskonventionen, Gruppenstrukturen oder durch die Zuordnung von Assignees zu ihren jeweiligen Teams mittels einer externen Referenztabelle abgeleitet.

Dieses Attribut wird verwendet, um die Prozessperformance auf Teamebene zu analysieren. Es hilft, Effizienz, Workload und Prozesseinhaltung über verschiedene Teams hinweg zu vergleichen und unterstützt Dashboards wie die 'Stage-Specific Bottleneck Analysis' aus einer teambasierten Perspektive.

Bedeutung

Ermöglicht Performance-Analysen und Prozessvergleiche über verschiedene Teams hinweg und hilft so, teamspezifische Bottlenecks oder Best Practices zu identifizieren.

Datenquelle

Oftmals abgeleitet durch die Zuordnung des Project Name oder Assignee zu einer außerhalb von GitLab definierten Teamstruktur oder durch Ableitung aus GitLab-Gruppenhierarchien.

Beispiele
Frontend-AlphaBackend-ServicesPlatform-Infra
Übergabe-Wartezeit
HandoffWaitTime
Berechnete Leerlaufzeit zwischen zwei aufeinanderfolgenden Aktivitäten, die von verschiedenen Assignees durchgeführt wurden.
Beschreibung

Diese Metrik berechnet die Dauer der Lücke zwischen dem Abschluss einer Aktivität und dem Beginn der nächsten, insbesondere wenn der Assignee wechselt. Zum Beispiel misst sie die Zeit, von dem Zeitpunkt, an dem ein Developer seine Arbeit beendet, bis ein Reviewer den Code Review beginnt.

Dies ist die Schlüsselmetrik für den KPI 'Average Handoff Wait Time'. Sie hilft, versteckte Ineffizienzen in der Ressourcenzuweisung und Kommunikation zwischen Teams oder Einzelpersonen aufzudecken und hebt Verzögerungen hervor, die nicht Teil einer aktiven Arbeit sind.

Bedeutung

Quantifiziert die Leerlaufzeit bei Handoffs zwischen verschiedenen Personen oder Teams und deckt versteckte Verzögerungen und Kommunikations-Bottlenecks auf.

Datenquelle

Berechnet vom Process Mining Tool. Es erfordert die Analyse aufeinanderfolgender Events innerhalb eines Cases, die Überprüfung, ob der 'Assignee' unterschiedlich ist, und dann die Berechnung der Zeitdifferenz.

Beispiele
1 Tag 2 Stunden15 Minuten8 Stunden
Ziel-Branch
TargetBranch
Der Name des Ziel-Branch für einen Merge Request.
Beschreibung

Der Target Branch ist der Branch, in den Änderungen gemergt werden sollen, zum Beispiel 'main', 'develop' oder ein Release Branch wie 'release/1.5'. Dies ist eine zentrale Information für jeden Merge Request.

Die Analyse nach Target Branch kann unterschiedliche Prozessverhaltensweisen für Code aufzeigen, der in verschiedene Ziele gemergt wird. Zum Beispiel können Merges in 'main' einen rigoroseren Genehmigungsprozess und längere Cycle Times haben als Merges in einen Feature Branch. Sie kann auch helfen, Production Deployments von anderen Arten der Code-Integration zu unterscheiden.

Bedeutung

Hilft bei der Unterscheidung zwischen verschiedenen Development- und Release-Workflows, da Prozesse je nach Ziel-Branch erheblich variieren können.

Datenquelle

Abgerufen aus dem Feld 'target_branch' in der GitLab Merge Requests API-Antwort.

Beispiele
maindeveloprelease/v2.1.0hotfix/user-auth-bug
Erforderlich Empfohlen Optional

Software Development Lifecycle Aktivitäten

Dies sind die entscheidenden Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um eine präzise Prozessentdeckung und Engpasserkennung zu gewährleisten.
4 Empfohlen 8 Optional
Aktivität Beschreibung
In Produktion deployed
Diese Aktivität markiert das erfolgreiche Deployment des Codes in die Live Production Umgebung und macht ihn für Endnutzer verfügbar. Dies wird erfasst, wenn ein spezifischer 'deploy to production' Job in einer GitLab CI/CD Pipeline erfolgreich abgeschlossen wird.
Bedeutung

Dies ist das primäre End-Event für den Prozess, das anzeigt, dass Wert geliefert wurde. Es ist essenziell für die Messung der gesamten End-to-End SDLC Cycle Time und der Release-Frequenz.

Datenquelle

Erfasst aus dem 'finished_at'-Timestamp eines erfolgreichen CI/CD Jobs, der speziell für das Production Deployment vorgesehen ist. GitLab's Environments Feature verfolgt dies explizit.

Erfassen

Verwenden Sie den 'finished_at' Timestamp des erfolgreichen Produktions-Deployment CI-Jobs.

Ereignistyp explicit
Merge Request erstellt
Zeigt an, dass die initiale Entwicklungsarbeit abgeschlossen ist und der Code bereit für Review und Integration ist. Dies ist ein explizites, zentrales Event im GitLab Workflow, das erfasst wird, wenn ein Entwickler einen neuen Merge Request (MR) öffnet.
Bedeutung

Dies ist ein kritischer Milestone, der den Handoff von der Entwicklung zum Review und Testing markiert. Es ist der Einstiegspunkt für die Analyse des gesamten Code Review und CI/CD Pipeline-Zyklus.

Datenquelle

Dies ist ein explizites Event, das vom 'created_at' Timestamp in der Tabelle 'merge_requests' oder über die Merge Requests API erfasst wird.

Erfassen

Verwenden Sie den 'created_at' Timestamp des Merge Request.

Ereignistyp explicit
Merge Request gemergt
Diese Aktivität kennzeichnet den erfolgreichen Abschluss des Code Review und Integrationsprozesses. Es ist ein explizites Event, das auftritt, wenn ein Benutzer den Branch des Merge Request in den Target Branch mergt.
Bedeutung

Dies ist ein wichtiger Milestone, der anzeigt, dass Entwicklung und Review abgeschlossen sind. Er dient als Endpunkt für die Messung der Development Cycle Time und als Startpunkt für die Messung der Deployment Lead Time.

Datenquelle

Dies ist ein explizites Event, das vom 'merged_at' Timestamp in der Tabelle 'merge_requests' erfasst wird. Eine Systemnotiz wird ebenfalls beim Merging generiert.

Erfassen

Verwenden Sie den 'merged_at' Timestamp des Merge Request.

Ereignistyp explicit
Problem erstellt
Diese Aktivität markiert den Beginn des Development Lifecycle und repräsentiert die Erstellung eines neuen Work Items, wie eines Feature, Bug oder Task. Sie wird explizit erfasst, wenn ein Benutzer ein neues Issue in GitLab erstellt, welches den Creation Timestamp aufzeichnet.
Bedeutung

Dies ist das primäre Start-Event für den End-to-End-Prozess. Die Analyse der Zeit von der Issue-Erstellung bis zum Deployment bietet ein vollständiges Bild der SDLC Cycle Time.

Datenquelle

Dies ist ein explizites Event, das vom 'created_at' Timestamp in der Tabelle 'issues' oder über die Issues API erfasst wird. Systemnotizen zeichnen das Creation Event ebenfalls auf.

Erfassen

Verwenden Sie den 'created_at' Timestamp des Issue.

Ereignistyp explicit
Code Review gestartet
Markiert den Beginn des Peer Review Prozesses für einen Merge Request. Dieses Event wird aus der ersten Review-bezogenen Aktion abgeleitet, wie dem ersten Kommentar oder Thread, der von einer anderen Person als dem Autor gepostet wurde.
Bedeutung

Das Messen der Zeit von der MR-Erstellung bis zum Beginn des Reviews hebt Warteschlangenverzögerungen hervor. Die Reduzierung dieser Wartezeit ist entscheidend für die Verkürzung des gesamten Code Review Zyklus.

Datenquelle

Abgeleitet vom Timestamp des ersten Kommentars oder Review-Threads zum Merge Request, der nicht vom MR-Autor stammt. Diese Daten sind über Systemnotizen oder die Notes API verfügbar.

Erfassen

Finden Sie den Timestamp des ersten Nutzerkommentars zu einem MR von einem Nicht-Autor.

Ereignistyp inferred
Deployment gestartet
Stellt den Beginn des Prozesses dar, Code in eine spezifische Umgebung, wie Staging oder Production, freizugeben. In GitLab entspricht dies dem Start eines 'deploy'-Jobs innerhalb einer CI/CD Pipeline.
Bedeutung

Das Tracking des Deployment-Starts hilft, die Dauer der Deployment-Phase zu isolieren. Es ist entscheidend für die Messung und Optimierung der Deployment Lead Time.

Datenquelle

Erfasst aus dem 'started_at'-Timestamp eines CI/CD Jobs, der als Deployment Job konfiguriert ist. Dies ist Teil von GitLab's Environments und Deployments Feature.

Erfassen

Verwenden Sie den 'started_at' Timestamp aus dem CI Job Log für eine Deployment Task.

Ereignistyp explicit
Entwicklung gestartet
Diese Aktivität kennzeichnet den Beginn der aktiven Coding-Arbeit an dem Issue. Dies wird typischerweise vom ersten Code Commit abgeleitet, der an einen mit dem Issue verbundenen Branch gepusht wird, da GitLab keinen expliziten 'start development'-Button hat.
Bedeutung

Identifiziert den genauen Beginn der wertschöpfenden Entwicklungsarbeit, was eine präzise Messung der reinen Coding-Phase ermöglicht und diese von Planungs- oder Wartezeiten trennt.

Datenquelle

Abgeleitet durch den Timestamp des ersten Commits auf einem Feature Branch, der mit dem Issue verknüpft ist. Dies erfordert die Verknüpfung von Issues mit Branches, oft über Namenskonventionen oder Metadaten.

Erfassen

Finden Sie den Timestamp des ersten Commits auf einem Branch, der mit der Issue ID verknüpft ist.

Ereignistyp inferred
Genehmigung hinzugefügt
Stellt eine formelle Genehmigung der Code-Änderungen in einem Merge Request durch einen Reviewer dar. Dies ist ein explizites Event, das von GitLab erfasst wird, wenn ein Benutzer auf den 'Approve'-Button klickt.
Bedeutung

Genehmigungen sind zentrale Quality Gates. Ihre Verfolgung hilft, die benötigte Zeit für erforderliche Freigaben zu analysieren und stellt die Einhaltung der Review-Richtlinien sicher.

Datenquelle

Erfasst aus Merge Request Approval Events. Diese sind über die Approvals API verfügbar oder können in der Historie der MR eingesehen werden.

Erfassen

Verwenden Sie den Timestamp aus dem Event Log der Merge Request-Genehmigung.

Ereignistyp explicit
Pipeline fehlgeschlagen
Diese Aktivität tritt auf, wenn eine CI/CD Pipeline-Ausführung in irgendeiner Phase fehlschlägt, z.B. bei einem Build Error oder einem fehlgeschlagenen Test. GitLab zeichnet explizit den finalen Status jeder Pipeline auf, wodurch Fehler leicht zu identifizieren sind.
Bedeutung

Pipeline-Fehler sind ein Haupttreiber für Nacharbeiten. Die Analyse ihrer Häufigkeit, Dauer und Ursache hilft, Qualitätsprobleme, instabile Tests und Bottlenecks in der Feedback-Schleife zu Entwicklern zu identifizieren.

Datenquelle

Identifiziert durch den Status 'failed' in einem Pipeline-Datensatz in der Tabelle 'ci_pipelines'. Der 'finished_at' Timestamp gibt an, wann der Fehler aufgetreten ist.

Erfassen

Filtern Sie nach Pipeline-Datensätzen mit dem Status 'failed' und verwenden Sie den 'finished_at' Timestamp.

Ereignistyp explicit
Pipeline gestartet
Stellt die Initiierung einer automatisierten CI/CD Pipeline dar, die typischerweise Builds, Tests und Security Scans durchführt. GitLab erstellt explizit einen Pipeline-Datensatz mit einem Start-Timestamp, wann immer eine Pipeline ausgelöst wird, zum Beispiel durch einen Commit oder die MR-Erstellung.
Bedeutung

Das Tracking von Pipeline-Ausführungen ist essenziell für die Überwachung der Gesundheit und Effizienz automatisierter Testing- und Integrationsprozesse. Es hilft zu identifizieren, wie viel Zeit in der automatisierten Validierung verbracht wird.

Datenquelle

Erfasst aus dem 'created_at'- oder 'started_at'-Timestamp eines Pipeline-Datensatzes in der 'ci_pipelines'-Tabelle oder über die Pipelines API.

Erfassen

Verwenden Sie den Timestamp aus dem Pipeline-Ausführungsdatensatz, der dem Branch des MR zugeordnet ist.

Ereignistyp explicit
Sachverhalt abgeschlossen
Stellt den finalen administrativen Abschluss des Work Items dar, typischerweise nachdem seine Änderungen deployed und verifiziert wurden. Dies ist ein explizites Event, das erfasst wird, wenn ein Benutzer das Issue in GitLab schließt.
Bedeutung

Das Schließen eines Issues bedeutet oft das endgültige Ende aller damit verbundenen Arbeiten. Der Vergleich mit der Bereitstellungszeit kann Verzögerungen bei der Post-Deployment-Validierung oder administrativen Prozessen aufdecken.

Datenquelle

Dies ist ein explizites Event, das vom 'closed_at' Timestamp in der Tabelle 'issues' oder aus der entsprechenden Systemnotiz erfasst wird.

Erfassen

Verwenden Sie den 'closed_at' Timestamp des Issue.

Ereignistyp explicit
Sachverhalt zugewiesen
Stellt die Zuweisung eines Issue an einen spezifischen Developer oder ein Team dar und zeigt an, dass die Verantwortung für die Arbeit festgelegt wurde. Dies ist ein explizites Event, das von GitLab protokolliert wird, sobald das Assignee-Feld eines Issues ausgefüllt oder geändert wird.
Bedeutung

Das Tracking von Zuweisungen ist entscheidend für die Analyse von Ressourcenzuweisung, Team Workload und Handoff-Zeiten. Es hilft, Verzögerungen zwischen der Erstellung und der Übernahme von Arbeit zu identifizieren.

Datenquelle

Erfasst aus GitLab's System Notes für den Issue, die protokollieren, wann ein 'Assignee' hinzugefügt oder geändert wird. Der Event Timestamp wird in der Notiz aufgezeichnet.

Erfassen

Extrahieren Sie 'Assignee Changed'-Events aus den System Notes des Issues.

Ereignistyp explicit
Empfohlen Optional

Extraktionsleitfäden

So erhalten Sie Ihre Daten von GitLab