Rawpixel.com - stock.adobe.com
Value-Stream-Management für DevOps: Geschäft und IT vereinen
Value-Stream-Management kann ein gutes Tool sein, um DevOps auf das Unternehmen abzustimmen, da es die Datenanalyse optimiert und die Zusammenarbeit und Berichterstattung verbessert.
Die aktuelle Wirtschaftslage verlangt von Unternehmen eine bessere Ausrichtung von DevOps an Geschäftszielen und Kundenanforderungen, wodurch der Kostendruck auf DevOps-Praktiken größer denn je wird.
Da sich Unternehmen in immer engeren Budgetzyklen befinden, bietet die Zusammenführung von DevOps und Value-Stream-Management (VSM) Entwicklungsprojekten eine neue Verwaltungs- und Berichtsebene zur Lösung von Problemen. Selbst die Auswahl einiger VSM-Best-Practices zum Schließen von Lücken in Ihren aktuellen DevOps-Praktiken kann Kosten senken und die Effizienz verbessern.
Die Beziehung zwischen VSM und DevOps verstehen
VSM (zu deutsch: Wertstrommanagement) ist ein Softwareentwicklungsansatz, der die traditionellen DevOps-Praktiken durch die Optimierung des End-to-End-Softwarebereitstellungsprozesses ergänzen kann. Zu den potenziellen Vorteilen von VSM gehören die Identifizierung und Beseitigung von Verschwendung, die Verkürzung der Vorlaufzeit für neue Funktionen und die Verbesserung des Wertflusses (Value Flow) zum Kunden.
VSM birgt ein großes Potenzial für Unternehmen, die bereits DevOps-Praktiken eingeführt haben. Wie DevOps zielt auch VSM darauf ab, Menschen, Prozesse und Technologien zusammenzubringen, um die Softwareentwicklungspipeline zu visualisieren und zu verwalten und die kontinuierliche Verbesserung zu unterstützen. Und selbst wenn Sie kein vollständiges VSM-Framework einführen möchten, können Sie von VSM-Praktiken lernen, um Ihre DevOps-Workflows zu verbessern.
DevOps Value Streams identifizieren und abbilden
DevOps- und Unternehmensteams müssen bei der Identifizierung von Wertströmen im Softwarebereitstellungszyklus zusammenarbeiten.
Der erste Schritt besteht darin, den gesamten DevOps-Prozess des Unternehmens abzubilden, von der Planung bis zur Bereitstellung. Möglicherweise haben Sie bereits eine solche Dokumentation zur Hand. Andernfalls sollten Sie mit einem visuellen Kollaborations-Tool wie Miro oder Mural beginnen, um diese erste, wichtige Arbeit zu erledigen.
Sie sollten diese Visualisierung nicht in einem Silo erstellen. Kalkulieren Sie die Zeit für Zusammenarbeit und Iteration ein und die Möglichkeit, dass Ihr DevOps-Prozess nicht wie dokumentiert funktioniert. Wenn dies der Fall ist, sollten Sie prüfen, ob bestimmte Bereiche neu überdacht werden müssen, um sie an die Ziele Ihres Unternehmens anzupassen.
Eine Wertstromkarte (Value Stream Map) sollte die verschiedenen Phasen des DevOps-Prozesses Ihres Unternehmens aufzeigen, zum Beispiel die folgenden:
- Inputs
- Outputs
- Ergebnisse und Ausstiegskriterien.
- Übergaben zwischen Teams.
Die heutigen CI/CD-Tool-Ketten (Toolchains) enthalten eine Vielzahl von Daten über die Entwicklungsprojekte eines Unternehmens, einschließlich Vorlaufzeit, Zykluszeit und Durchsatz. Sobald alle Beteiligten diese Daten analysieren und sich darüber einig sind, können Sie für detailliertere Analysen auf VSM-Tools wie CloudBees Flow und Plutora zurückgreifen.
Die Analyse von Pipeline-Daten kann Prozessineffizienzen aufdecken. Diese Informationen versorgen Ihre IT- und Geschäftsteams mit verwertbaren Daten für ein sinnvolles Engagement und lösen das Versprechen von datengesteuertem DevOps ein.
Die Zusammenarbeit mit den Aktionären und anderen Interessengruppen ist bei VSM genauso wichtig wie bei DevOps. Pipeline-Daten liefern wertvolle Erkenntnisse, aber Sie müssen dennoch regelmäßig mit Ihren Kunden, internen Stakeholdern und Entwicklern interagieren.
Identifizieren Sie in diesen Gesprächen die Bereiche, in denen Ihre DevOps-Bemühungen wertschöpfend sind und in denen sie zu kurz greifen. Wenn Sie Ihre Analyse der Pipeline-Daten in die Gespräche mit den Interessengruppen einbringen, können Ihre Teams die am meisten benötigten Verbesserungen priorisieren und Ihren Endkunden einen Mehrwert bieten.
Positive Auswirkungen von VSM auf DevOps-Praktiken
VSM kann Transparenz und Sichtbarkeit in die Daten bringen, die die Tools in Ihrer DevOps-Pipeline täglich generieren. Dank der neuen Visualisierungsebene, die VSM bietet, können Ihre DevOps-Teams Ineffizienzen und Engpässe besser erkennen.
VSM bringt auch die positiven Effekte einer verbesserten Zusammenarbeit und Kommunikation in DevOps-Praktiken. Die Implementierung von VSM mit einem Kooperationsplan ermöglicht es den Teams, Probleme aufgrund verbesserter Tools und Datenberichte früher im DevOps-Prozess zu erkennen und zu beheben.
VSM-Tools und -Daten bieten immer Raum für kontinuierliche Verbesserungen und helfen dabei, die letzten Silos zu beseitigen. Wenn Sie zum Beispiel noch ein Silo zwischen DevOps- und Compliance-Teams haben, kann VSM neue Lernbereiche aufzeigen, die in einem traditionellen DevOps-Modell verborgen geblieben wären.
Mögliche Nachteile von VSM in DevOps
Die Einführung von VSM hat potenzielle Nachteile für DevOps, genauso wie sich das IT-Service-Management negativ auf DevOps auswirken kann, wenn in Ihrem Unternehmen eine Diskrepanz zwischen der Kultur des Backoffice und der Produktbereitstellung besteht.
Einige Fachleute argumentieren, dass VSM in der Vergangenheit feststeckt, weil der Ansatz nicht auf die Natur der modernen Softwareentwicklung eingeht; insbesondere, dass Produkte oft groß und unfokussiert sind und daher eine große und unfokussierte Organisation benötigen, um sie zu liefern. Hier ist zweifellos etwas Wahres dran, und es ist nicht hilfreich, wenn Führungskräfte sich nicht von veralteten Six-Sigma-Prozessen lösen können, die nicht mehr relevant sind.
Antizipieren Sie mögliche Probleme bei der Einführung von VSM
Vermeiden Sie bei der Planung einer Umstellung auf VSM einen allzu präskriptiven Befehls- und Kontrollansatz. Wenn eine interne Organisation außerhalb der IT darauf drängt, VSM zu implementieren, ohne dass die DevOps-Teams einbezogen werden, kann dies den Fortschritt der DevOps-Reise des Unternehmens behindern. Die Implementierung von VSM als starrer Prozess erhöht die Abhängigkeit von einem Team und behindert die Fähigkeit des DevOps-Teams zu experimentieren und zu innovieren.
Ein weiteres Warnzeichen ist, dass Metriken über die Zusammenarbeit gestellt werden. Beim VSM geht es nicht nur um die Verfolgung von Metriken für Entwicklungsprojekte, sondern auch um die Förderung einer besseren Zusammenarbeit zwischen der IT und dem Unternehmen durch Engagement und Metriken. Eine übermäßige Abhängigkeit von Metriken kann Entwickler in eine unfaire Position bringen und sie dazu zwingen, zu erklären, warum sie Metriken nicht erfüllen konnten, die willkürlich von Personen festgelegt wurden, von denen man nicht annimmt, dass sie einen Beitrag zum Projekt leisten.