Ihr Software Development Life Cycle (SDLC) Daten-Template

GitLab
Ihr Software Development Life Cycle (SDLC) Daten-Template

Ihr Software Development Life Cycle (SDLC) Daten-Template

Dieses vollständige Template führt Sie durch die relevanten Datenpunkte, die zur Analyse Ihres Software Development Life Cycle (SDLC) Prozesses erforderlich sind. Es umreißt die wichtigen 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 fundierte Process-Mining-Analysen vorbereiten.
  • Empfohlene Attribute zur Erfassung
  • Wichtige Aktivitäten für das Tracking
  • Extraktionsanleitung
Neu bei Event-Logs? Erfahren Sie wie Sie ein Process-Mining-Event-Log erstellen.

Software Development Life Cycle (SDLC) Attribute

Dies sind die empfohlenen Datenfelder, die Sie in Ihr Event Log (Event Log) aufnehmen sollten, um eine vollständige Analyse und Optimierung des Software Development Life Cycle (SDLC) zu ermöglichen.
3 Erforderlich 5 Empfohlen 12 Optional
Name Beschreibung
`Development Item`
DevelopmentItem
Der eindeutige Identifikator für eine Arbeitseinheit, wie ein Funktion, Bug Fix oder Aufgabe, der als primärer Case-ID dient.
Beschreibung

Das Development Item repräsentiert eine einzelne, verfolgbare Arbeitseinheit, die den Software Development Life Cycle (SDLC) durchläuft. Es verbindet alle zugehörigen Aktivitäten, von der Erstellung bis zum finalen Deployment, zu einem kohärenten Fall. In GitLab wird dies in der Regel 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 Durchlaufzeit, die Identifizierung von Engpässe 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-ID, der alle Process Ereignisse miteinander verknüpft und es so ermöglicht, den gesamten Lebenszyklus jedes beliebigen Work Items nachzuvollziehen.

Datenquelle

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

Beispiele
1024512PRJ-2345
Aktivität
Activity
Der Name des spezifischen Prozessschritts oder Ereignisse, das aufgetreten ist, wie 'Issue Created' oder 'Merge Request Merged'.
Beschreibung

Das Attribut Activity erfasst die einzelnen Ereignisse, die ein Development Item durchläuft. Diese sind in GitLab nicht als einzelnes Feld gespeichert, sondern werden aus verschiedenen Aktionen und Zeitstempel-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 den Antrag bearbeitet.ie Genehmigung eines Merge Request allesamt separate Aktivitäten.

Dieses Attribut ist die Basis für den Aufbau der Prozessdarstellung (Process Map), die Visualisierung des Workflows und die Analyse der Sequenz und Häufigkeit von Ereignisse. Es wird verwendet, um Abweichungen, Engpässe zwischen Schritten und gängige Prozesspfade zu identifizieren.

Bedeutung

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

Datenquelle

Abgeleitet von Event-Typn und State Changes im GitLab Event Stream oder den Antrag bearbeitet.urch die Interpretation von Zeitstempel-Feldern wie 'created_at', 'merged_at' und 'closed_at' bei Issues und Merge Requests.

Beispiele
Problem erstelltEntwicklung gestartetMerge Request gemergtPipeline fehlgeschlagenIn Produktion bereitgestellt
Startzeit
StartTime
Der `Zeitstempel`, 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 Ereignisse in GitLab wird dies in verschiedenen Zeitstempel-Feldern erfasst. Zum Beispiel wäre die StartTime der Aktivität 'Issue Created' der created_at Zeitstempel des Issue, während die StartTime der Aktivität 'Merge Request Merged' der merged_at Zeitstempel des Merge Request wäre.

Dieser Zeitstempel ist das zentrale zeitliche Element im Process Mining. Er wird verwendet, um Ereignisse chronologisch zu ordnen, Zeitspannen zwischen Aktivitäten zu berechnen, Durchlaufzeits zu messen und die Prozess-Performance über die Zeit zu analysierenn.

Bedeutung

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

Datenquelle

Extrahiert aus verschiedenen Zeitstempel-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 den Antrag bearbeitet.em Issue oder Merge Request zum Zeitpunkt des Ereignisse 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 maßgeblich für das Dashboard 'Developer Workload & Allocation'. Sie hilft, die Ressourcenauslastung zu verstehen, überlastete Einzelpersonen oder Teams zu identifizieren und Übergaben zwischen verschiedenen Personen zu analysierenn.

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
Development-Item-Typ
DevelopmentItemType
Die Klassifizierung des Development Items, wie 'Funktion', 'Bug', 'Aufgabe' 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, Fehlerbehebung, technische Schulden und anderen Work Typs zu unterscheiden.

Die Analyse nach Development Item Typ ermöglicht den Vergleich von Prozessflusss und Durchlaufzeits 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 Typ hilft zu identifizieren, ob bestimmte Arten von Arbeit anfälliger für Verzögerungen, Nacharbeiten oder Abweichungen sind.

Datenquelle

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

Beispiele
`Funktion`BugAufgabeTechnische Schulden
Endzeit
EndTime
Der Zeitstempel, 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 Ereignisse 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-Zeitstempel 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 (Bearbeitungszeit). Es hilft bei der den Antrag bearbeitet.etaillierten 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 (Bearbeitungszeiten), was wichtig ist, um ineffiziente Schritte im Prozess zu identifizieren.

Datenquelle

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

Beispiele
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
Projektname
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 Leistungsfähigkeit-Vergleiche über verschiedene Produkte, Komponenten oder Dienste 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 vereinfacht.

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, in der Regel 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 wichtig für das Dashboard 'Severity Escalation Trends' und den zugehörigen KPI. Die Analyse von Severity-Änderungen über den Lebenszyklus 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
Dev Item Status
DevelopmentItemStatus
Der Status des Development Items zum Zeitpunkt des Ereignisse, wie 'Open', 'In Progress' oder 'Closed'.
Beschreibung

Dieses Attribut reflektiert den Status des primären Work Items, in der Regel 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 maßgeblich für das Verständnis des Case Lebenszyklus. Es hilft zu identifizieren, wie lange Elemente in jedem Status verbleiben, und kann verwendet werden, um in Dashboards wie 'SDLC End-to-End Durchlaufzeit' nach aktiver oder abgeschlossener Arbeit zu filtern.

Bedeutung

Bietet einen Momentaufnahme 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 Durchlaufzeit ist eine berechnete Metrik, die die Gesamtdauer eines Fälle misst. Sie wird in der Regel 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 Durchlaufzeit' und wird verwendet, um Verbesserungen zu verfolgen und langwierige Fälle zu identifizieren, die auf systemische Probleme hinweisen können.

Bedeutung

Dies ist ein zentraler Process Mining KPI, der den Antrag bearbeitet.ie End-to-End-Effizienz des Development Lebenszyklus 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 in der Regel 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 vereinfacht.

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
JaNein
Letzte Datenaktualisierung
LastDataUpdate
Der Zeitstempel, 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 den Antrag bearbeitet.ie Event-Daten zuletzt im Process Mining Datenset extrahiert oder aktualisiert wurden. Es repräsentiert nicht den Zeitpunkt des Ereignisse, sondern den Zeitpunkt der letzten Synchronisierung des Event-Datensatzes.

Diese Information ist maßgeblich 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 Hinweisrmiert 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 Hinweisrmiert sind.

Datenquelle

Dieser Zeitstempel 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-Leistungsfähigkeit im Kontext spezifischer Sprints oder Planungsperioden. Es kann verwendet werden, um zu sehen, ob sich die Durchlaufzeits 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 Leistungsfähigkeit 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 den Antrag bearbeitet.em Event zugeordnet ist, wie 'Opened', 'Merged' oder 'Closed'.
Beschreibung

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

Das Tracking des MR-Status ist maßgeblich für die Analyse der Code-Integrationsphase des SDLC. Es unterstützt Dashboards wie 'Code Review Durchlaufzeit & 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 maßgeblich für die Verbesserung der Entwicklungseffizienz und Code-Qualität.

Bedeutung

Verfolgt den Erfolg und Misserfolg automatisierter Builds und Tests, hebt Nacharbeitsschleifen 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 maßgeblich 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 wichtig ist für die Daten 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 den Antrag bearbeitet.em 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 Funktion zugeordnet werden.

Dies ist wichtig 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 wichtig 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 den Antrag bearbeitet.em 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 den Antrag bearbeitet.as Squad, das für das Development Item verantwortlich ist. Diese Information ist in der Regel kein Standardfeld in GitLab und wird oft aus Projekt-Namenskonventionen, Gruppenstrukturen oder den Antrag bearbeitet.urch die Zuordnung von Assignees zu ihren jeweiligen Teams mittels einer externen Referenztabelle abgeleitet.

Dieses Attribut wird verwendet, um die Prozess-Performance auf Teamebene zu analysierenn. 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 Leistungsfähigkeit-Analysen und Prozessvergleiche über verschiedene Teams hinweg und hilft so, teamspezifische Engpässe 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 den Antrag bearbeitet.urch Ableitung aus GitLab-Gruppenhierarchien.

Beispiele
Frontend-AlphaBackend-DienstePlatform-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 Übergaben zwischen verschiedenen Personen oder Teams und deckt versteckte Verzögerungen und Kommunikations-Engpässe auf.

Datenquelle

Berechnet vom Process-Mining-Tool. Es erfordert die Analyse aufeinanderfolgender Ereignisse innerhalb eines Fälle, 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 Durchlaufzeits haben als Merges in einen Funktion 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 Life Cycle (SDLC) Aktivitäten

Dies sind die wichtigen Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um eine präzise Prozessentdeckung und Engpasserkennung zu sicherstellen.
4 Empfohlen 8 Optional
Aktivität Beschreibung
In Produktion bereitgestellt
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 wichtig für die Messung der gesamten End-to-End SDLC Durchlaufzeit und der Release-Frequenz.

Datenquelle

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

Erfassen

Verwenden Sie den 'finished_at' Zeitstempel 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 Antrag bearbeitet.en 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' Zeitstempel in der Tabelle 'merge_requests' oder über die Merge Requests API erfasst wird.

Erfassen

Verwenden Sie den 'created_at' Zeitstempel 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 Durchlaufzeit und als Startpunkt für die Messung der Deployment Lead Time.

Datenquelle

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

Erfassen

Verwenden Sie den 'merged_at' Zeitstempel des Merge Request.

Ereignistyp explicit
Problem erstellt
Diese Aktivität markiert den Beginn des Development Lebenszyklus und repräsentiert die Erstellung eines neuen Work Items, wie eines Funktion, Bug oder Aufgabe. Sie wird explizit erfasst, wenn ein Benutzer ein neues Issue in GitLab erstellt, welches den Creation Zeitstempel 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 Durchlaufzeit.

Datenquelle

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

Erfassen

Verwenden Sie den 'created_at' Zeitstempel 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 maßgeblich für die Verkürzung des gesamten Code Review Zyklus.

Datenquelle

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

Erfassen

Finden Sie den Zeitstempel 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 maßgeblich für die Messung und Optimierung der Deployment Lead Time.

Datenquelle

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

Erfassen

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

Ereignistyp explicit
Entwicklung gestartet
Diese Aktivität kennzeichnet den Beginn der aktiven Coding-Arbeit an dem Issue. Dies wird in der Regel 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 Zeitstempel des ersten Commits auf einem Funktion 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 Zeitstempel des ersten Commits auf einem Branch, der mit der Issue ID verknüpft ist.

Ereignistyp inferred
Freigabe 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 analysierenn und stellt die Einhaltung der Review-Richtlinien sicher.

Datenquelle

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

Erfassen

Verwenden Sie den Zeitstempel 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 Fehler oder einem fehlgeschlagenen Test. GitLab zeichnet explizit den finalen Status jeder Pipeline auf, wodurch Fehler leicht zu identifizieren sind.
Bedeutung

Pipeline-Fehler sind ein zentrale Faktor für Nacharbeiten. Die Analyse ihrer Häufigkeit, Dauer und Ursache hilft, Qualitätsprobleme, instabile Tests und Engpässe 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' Zeitstempel gibt an, wann der Fehler aufgetreten ist.

Erfassen

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

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

Das Tracking von Pipeline-Ausführungen ist wichtig 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'-Zeitstempel eines Pipeline-Datensatzes in der 'ci_pipelines'-Tabelle oder über die Pipelines API.

Erfassen

Verwenden Sie den Zeitstempel aus dem Pipeline-AusführungsDatensatz, der den Antrag bearbeitet.em Branch des MR zugeordnet ist.

Ereignistyp explicit
Sachverhalt abgeschlossen
Stellt den finalen administrativen Abschluss des Work Items dar, in der Regel 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' Zeitstempel in der Tabelle 'issues' oder aus der entsprechenden Systemnotiz erfasst wird.

Erfassen

Verwenden Sie den 'closed_at' Zeitstempel 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 maßgeblich 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 Zeitstempel wird in der Notiz aufgezeichnet.

Erfassen

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

Ereignistyp explicit
Empfohlen Optional

Extraktionsanleitungen

So erhalten Sie Ihre Daten von GitLab