Bewerten der Prozesseffizienz mit einer Wertstromanalyse
Wenn Sie eine Wertstromanalyse erstellen, können Sie damit Ihren aktuellen Releasezyklusprozess analysieren. Eine Wertstromanalyse soll veranschaulichen, wo ein Prozess gut funktioniert und wo Zeit/Ressourcen verschwendet werden. Das Ziel besteht darin, einen Prozess zu schaffen, der dem Kunden den maximalen Wert bei minimaler Ressourcenverschwendung liefert. Mit einer Wertstromanalyse können Sie die Bereiche bestimmen, die keinen Wert beisteuern oder den Wert des Produkts sogar verringern.
Sehen wir uns an, wie die Situation bei Tailspin ist.
Mara, die neu im Team ist, will eine Wertstromanalyse erstellen, um den bestehenden Prozess zu verstehen. Durch eine Wertstromanalyse kann sie einen Eindruck davon bekommen, an welcher Stelle sich das Team im DevOps-Reifegradmodell befindet. Es zeigt sich, das reifere Teams normalerweise schneller und problemloser Releases veröffentlichen, die weniger Fehler enthalten.
Mara weiß, dass sie noch nicht alles versteht, also wird sie schnell eine Wertstromanalyse auf dem Whiteboard im Besprechungsraum erstellen. Es gibt einige Lücken und offene Fragen, aber das ist nicht weiter schlimm. Zumindest ist es ein Anfang. Sobald sie so viel wie möglich gemacht hat, wird sie mit dem Team über die Analyse sprechen. Die Wertstromanalyse ist ein gemeinsamer Ausgangspunkt für alle, um die ersten Schritte zu identifizieren, mit denen sich Entwicklung und Veröffentlichung der Tailspin-Websites verbessern lassen.
Sehen wir uns ihr Diagramm an.
Verstehen des aktuellen Prozesses
Mara ruft das Team im Meetingraum zusammen, um ihre Wertstromanalyse vorzustellen.
Mara: „Mit einer Wertstromanalyse können wir bestimmen, an welchen Stellen in einem Prozess Mehrwert für den Kunden entsteht und wo Zeit verschwendet wird, ohne dass ein Mehrwert entsteht. Das Diagramm beginnt oben links mit der funktionalen Spezifikation der Software. Verfolgen wir nur ein Feature auf seinem Weg durch den aktuellen Releasezyklus.
Einige Anwesende rollen mit den Augen, aber Mara macht weiter.
Entwicklungsprozesse
Für ein neues Feature wird aktuell als erstes eine Bezeichnung in der Quellcodeverwaltung erstellt 
. Es gibt eine Person, die Bezeichnungen erstellen kann: Andy. Wir fordern eine Bezeichnung per E-Mail an. Wir verwenden ein zentrales Versionskontrollsystem. Andy wartet also, bis der vorhandene Code eingecheckt und stabil ist, bevor er die Bezeichnung erstellt. Nachdem die Bezeichnung erstellt wurde, erhalten wir eine E-Mail, dass wir mit der Arbeit beginnen können. Dieser Vorgang kann bis zu drei Tage in Anspruch nehmen und schafft keinen Mehrwert für den Kunden. Vorgänge, die keinen Mehrwert für den Kunden haben, sollten so wenig Zeit wie möglich in Anspruch nehmen.
Eine Person braucht vier Tage für die Programmierung eines Features, sobald alle benötigten Dateien verfügbar sind 
. Wir müssen Zugriff auf das Unternehmensnetzwerk haben, um auf die Quellcodeverwaltung zugreifen zu können. Diese Zeit hat einen Mehrwert für den Kunden. Er möchte dieses Feature.
Testprozesse
Nachdem der Build stabil ist, wird dies in einer Tabelle angegeben, um Amita zu informieren, dass ein Build getestet werden kann. Außerdem erfährt sie dort, wo sich der Build befindet 
. Es dauert zwei Tage, bis sie benachrichtigt wird.
Amita testet den Build manuell 
. Je größer die Codebasis, desto länger ist dieser Prozess. Gehen wir mal von drei Tagen aus. Dann sendet Amita Fehlerberichte an Andy. Durch das Testen entsteht kein Mehrwert, es ist aber erforderlich.
Dann hat Andy Zeit, die Fehler zu sichten und Arbeitsaufgaben zu verteilen . Es kann weitere drei Tage dauern, bis Andy die Fehler nachvollziehen und den richtigen Entwickler zuweisen kann.
IT-Betriebsprozesse
Wenn Amita einen Build genehmigt, gibt sie ihn an Tim weiter. Tim muss diesen Build auf den Präproduktionsservern für weitere Tests bereitstellen. Häufig wurden die Präproduktionsserver nicht mit den neuesten Patches und Updates synchronisiert, die zum Ausführen der Website erforderlich sind. Es dauert zwei Tage, bis Tim den Build auf den Präproduktionsservern bereitgestellt und einige Tests ausgeführt hat. Auch hier gilt: Die Bereitstellung in der Präproduktion führt zwar zu keinem Mehrwert, ist aber erforderlich 
.
Nachdem ein Build produktionsbereit ist, müssen führende Mitarbeiter den Release genehmigen, bevor er bereitgestellt werden kann. Die Genehmigung erfolgt in einer Besprechung. Es dauert vier Tage, bis sich die führenden Mitarbeiter zu einem Meeting getroffen und den Release geprüft haben.
Anschließend stellt Tim das Feature bereit, und das Feature erreicht in der oberen rechten Ecke der Wertstromanalyse den Kunden. Wenn sich die Produktionsserverkonfiguration geändert hat und nicht mehr mit derjenigen der Präproduktion synchron ist, muss Tim diese erst aktualisieren, was einen weiteren Tag in Anspruch nimmt 
.
Berechnen der Kundenwertmetriken
Jetzt können wir uns die wichtigsten Leistungsmetriken ansehen und herausfinden, wo wir stehen.
Die Gesamtvorlaufzeit beschreibt die Zeit, bis ein Feature einen Kunden erreicht. In unserem Fall beträgt die Gesamtzeit 22 Tage. Die Prozesszeit beschreibt die Zeit, die für ein Feature aufgewendet wird und Mehrwert für den Kunden hat. Hier umfasst die Prozesszeit vier Tage für die Codierung plus einen Tag für die Bereitstellung des Features, was eine Gesamtzeit von fünf Tagen ergibt.
Das Aktivitätsverhältnis ist die Prozesszeit geteilt durch die Gesamtvorlaufzeit:
$${Aktivitätsverhältnis\ =\ }{\dfrac{Prozesszeit}{Gesamtvorlaufzeit}}$$
Das beschreibt die Effizienz. Wenn Sie die Effizienz mit 100 multiplizieren, erhalten Sie einen Prozentsatz. Das Ergebnis ist größer als 0 % und normalerweise weniger als 100 %. Je höher der Prozentsatz, desto höher ist auch die Effizienz.
Wenn wir die Zahlen aus diesem Beispiel einfügen, erhalten wir das folgende Ergebnis:
$${Aktivitätsverhältnis\ =\ }{\dfrac{5 Tage}{22 Tage}}{\ =\ .23}$$
Wenn wir das Ergebnis mit 100 multiplizieren, erhalten wir eine Effizienz von 23 %.
Wie Sie sehen, gibt es einen großen Verbesserungsspielraum. Das Entwickeln eines Features sollte nicht 22 Tage in Anspruch nehmen.
Tim: „Und wie hilft das uns jetzt?“
Wie geht es jetzt weiter?
Mara: „Es hilft uns, zu sehen, an welchem Punkt wir uns gerade befinden, um die Bereiche bestimmen zu können, in denen Ressourcen verschwendet werden. Wir sollten die Zeit, die zu keinem Mehrwert für den Kunden führt, auf einem Minimum halten. Ich bin davon überzeugt, dass wir unsere Effizienz mit einem DevOps-Ansatz verbessern können. Wir können viele dieser Schritte automatisieren, wodurch wir Zeit sparen.
Ich meine damit nicht, dass wir den aktuellen Prozess komplett über den Haufen werfen sollten, aber ich denke dennoch, dass wir in kleinen Schritten auf einen effizienteren Prozess hinarbeiten können, ohne dass unser aktueller Prozess beeinträchtigt wird.
Sehen wir uns einfach mal ein paar Bereiche an, in denen es Verbesserungsspielraum gibt.“
Andy: „Dann fangen wir am besten am Anfang an. Ich brauche sehr lange, bis ich eine Bezeichnung im Code eingefügt habe, damit wir mit der Entwicklung des neuen Features beginnen können. Ich muss zu allen Entwicklern gehen und diese darum bitten, alles Vorhandene einzuchecken, damit wir mit dem Erstellen und Testen beginnen können. Wenn ihr eine Idee habt, wie man das beschleunigen kann, bin ich ganz Ohr.
Außerdem ist mir aufgefallen, dass das Erstellen an sich aktuell nicht vorhanden ist. Im Moment dauert das etwa einen halben Tag. Ich fände es gut, wenn wir diese Zeit verkürzen könnten.“
Amita: „Und die Entwickler aktualisieren nicht immer die Tabelle. Deshalb bekomme ich nicht immer mit, wenn ein neuer Build vorhanden ist, der getestet werden muss. Wir könnten Zeit sparen, wenn wir sicherstellen könnten, dass die Tabelle immer auf dem neuesten Stand ist.“
Mara: Prima! Ich denke, dass uns DevOps bei allen diesen Punkten helfen kann.“
Andy: „Wir haben keine Zeit, den Prozess jetzt zu ändern. Du hast Irwin gehört. Wir befinden uns in einer Krise!“
Mara: Ja, verstanden. Lasst uns für den Moment also genauso wie immer weitermachen. Wir können uns alle Gedanken über unsere Teil in diesem Prozess machen und wie wir diesen verbessern können. Wir können an unserem laufenden Prozess kleine Änderungen vornehmen. Dann können wir feststellen, ob DevOps eine gute Lösung ist, ohne unseren aktuellen Prozess zu beeinträchtigen. Ich werde diese Analyse und die Leistungsmetriken aufbewahren. Sollten wir uns am Ende für Azure DevOps-Methoden entscheiden, können wir uns die Zahlen noch mal ansehen. Vielleicht können wir die Wertstromanalyse auch aktualisieren.“