Das GitLab Engineering-Team nutzt die eigenen Produkte intern – eine Praxis, die im Englischen als "Dogfooding" bezeichnet wird. Diese Selbstnutzung hat zu Verbesserungen bei der Beschleunigung der Software-Delivery-Zyklen für Kunden geführt. Dieser Artikel beleuchtet einen spezifischen Anwendungsfall, bei dem GitLab Value Stream Management (VSM) Verbesserungen für unser Engineering-Team ermöglicht hat. Es wird gezeigt, wie VSM dabei half, zwei zentrale Herausforderungen anzugehen: die Messung des Wegs von der Idee bis zur Fertigstellung eines Merge Requests und die Optimierung der Deployment-Workflows.
Value Stream Management ist in der deutschen Industrie als Wertstromanalyse etabliert – insbesondere in der Fertigung und Automobilbranche wird diese Lean-Methode zur Identifikation von Verschwendung eingesetzt. GitLabs VSM-Funktionen übertragen diesen systematischen Ansatz auf Software-Entwicklungsprozesse und ermöglichen die Unterscheidung zwischen wertschöpfenden und nicht-wertschöpfenden Aktivitäten im Entwicklungsworkflow.
Die Herausforderung: Engpässe in MR-Reviews identifizieren
Trotz gut definierter Workflows stellte ein Team fest, dass Merge Requests länger als erwartet brauchten, um geprüft und gemerged zu werden. Die Herausforderung bestand nicht nur in den Verzögerungen selbst, sondern darin zu verstehen, wo im Review-Prozess diese Verzögerungen auftraten und warum.
Das Ziel des Teams war klar:
- Identifizieren, wo Zeit vom initialen Konzept bis zum finalen Merge eines MR verbracht wurde
- Spezifische Engpässe im Review-Prozess lokalisieren
- Verstehen, wie MR-Größe, Komplexität oder Dokumentationsqualität die Review-Zeit beeinflussen
Der Ansatz: MR-Review-Zeit in GitLab Value Stream Analytics messen
Value Stream Analytics (VSA) ermöglicht es Organisationen, ihren gesamten Workflow von der Idee bis zur Auslieferung abzubilden und dabei zwischen wertschöpfenden Aktivitäten (VA) und nicht-wertschöpfenden Aktivitäten (NVA) im Prozessfluss zu unterscheiden. Durch die Berechnung des Verhältnisses von wertschöpfender Zeit zur gesamten Lead Time kann das Team verschwenderische Aktivitäten identifizieren, die zu Verzögerungen bei MR-Reviews führen.
Um die notwendigen Metriken zu erhalten, passte das Team GitLab VSA an, um bessere Sichtbarkeit in den MR-Review-Prozess zu erhalten.
1. Custom Stage für MR-Review einrichten
Das Team fügte eine neue Custom Stage in VSA mit dem Namen Review Time to Merge hinzu, um spezifisch die Zeit vom ersten Zuweisen eines Reviewers bis zum Merge des MR zu tracken.
- Start-Event: MR first reviewer assigned
- End-Event: MR merged
Durch die Definition dieser Stage begann VSA, die Dauer des MR-Review-Prozesses zu messen und lieferte präzise Daten darüber, wo Zeit verbracht wurde.
2. Total Time Chart für Klarheit nutzen
Mit der Custom Stage eingerichtet, nutzte das Team das Total Time Chart auf der VSA Overview-Seite (Analyze > Value Stream), um zu visualisieren, wie viel Zeit während der neuen MR-Review-Stage verbracht wurde. Durch den Vergleich der Werte, die durch jeden Bereich im Chart dargestellt wurden, konnte das Team schnell identifizieren, wie diese Stage zur gesamten Software-Delivery-Lifecycle-Zeit (SDLC) beitrug.
3. Für tiefere Erkenntnisse detailliert analysieren
Um spezifische Verzögerungen zu untersuchen, nutzte das Team die Stage Navigation Bar, um tiefer in die MR-Review-Stage einzutauchen. Diese Ansicht ermöglichte:
- MRs nach Review-Zeit sortieren: Die Stage-Tabelle zeigte alle zugehörigen MRs sortiert nach Review-Dauer, sodass langsame MRs leicht erkennbar waren
- Individuelle MRs analysieren: Für jeden MR konnte das Team Faktoren wie Verzögerungen bei der Reviewer-Zuweisung, mehrere Feedback-Runden, Leerlaufzeit nach Approval und MR-Größe/Komplexität untersuchen
Das Ergebnis: Umsetzbare Erkenntnisse und Verbesserungen
Durch die Anpassung von VSA zur Verfolgung der MR-Review-Zeit deckte das Team mehrere zentrale Erkenntnisse auf:
- Verzögerungen bei Reviewer-Zuweisung: Einige MRs erfuhren Verzögerungen, weil Reviewer spät zugewiesen wurden oder Reviewer zu viele MRs in ihrer Queue hatten
- Langsame Review-Start-Zeiten: Selbst nach Zuweisung lagen bestimmte MRs untätig, bevor Reviews begannen – oft aufgrund von Kontextwechseln oder konkurrierenden Prioritäten
- Mehrere Feedback-Schleifen: Größere MRs erforderten oft mehrere Feedback-Runden, was die Review-Zeit erheblich verlängerte
- Leerlaufzeit nach Approval: Einige MRs wurden approved, aber nicht zeitnah gemerged – oft aufgrund von Deployment-Koordinationsproblemen
Für den Engineering Manager im Team erwies sich VSA als wertvoll für die Verwaltung des Team-Workflows: "Ich habe VSA genutzt, um zu begründen, wo wir Zeit bei der MR-Fertigstellung verbrachten. Wir haben VSA auf unsere Bedürfnisse angepasst, und es war sehr hilfreich für unsere Untersuchungen nach Verbesserungsmöglichkeiten."
Aus dieser Dogfooding-Erfahrung entwickeln wir nun eine wichtige Erweiterung zur Verbesserung der Sichtbarkeit in den Review-Prozess. Wir fügen ein neues Event zu VSA hinzu – Merge request last approved at – das eine Stage erzeugt, die MR-Review-Schritte noch granularer aufschlüsselt.
Die Kraft datengestützter Entscheidungen
Durch die Nutzung von GitLabs VSA haben wir nicht nur Engpässe identifiziert – wir erhielten umsetzbare Erkenntnisse, die zu Verbesserungen bei der MR-Review-Zeit und der allgemeinen Entwickler-Produktivität führten. Wir optimierten Merge-Request-Review-Zyklen und erhöhten den Entwickler-Durchsatz, was unser Commitment zu kontinuierlicher Verbesserung durch Messung bestätigt.
Möchtest du erfahren, wie VSA deinem Team helfen kann? Starte eine kostenlose GitLab Ultimate-Testversion, passe deine Value Streams an und sieh, wie du Verbesserungen im gesamten SDLC für deine Teams erreichen kannst. Teile dann dein Feedback und deine Erfahrungen in diesem Issue.
