Wie man DevOps messbar macht: Teil 2

Wie man DevOps messbar macht: Teil 2

Ein Gastbeitrag von Sacha Labourey, CEO, CloudBees und Nigel Willie, DevOps-Experte

DevOps verspricht Agilität. Nicht nur für IT-Abteilungen, sondern für das gesamte Unternehmen, das entsprechende Prozesse einsetzt. Der Erfolg von DevOps kann jedoch nur beurteilt werden, wenn er sich messen lässt. CloudBees, einer der Experten für DevOps im Unternehmenseinsatz, diskutiert für Trend Report die Kennzahlen, die für DevOps sinnvoll sind – aber keineswegs nur dafür, sondern für die IT-Performance im Allgemeinen.

Im ersten Teil der zweiteiligen Serie wurden grundsätzlichen Überlegungen diskutiert, wie man die Leistung von IT-Abteilungen messbar machen kann. Im zweiten Teil geht es nun etwas detaillierter um die einzelnen Kennzahlen und deren Ermittlung.

Vergeudete Zeit

Der Übergang zu einer neuen Arbeitsweise und einer neuen Kultur, wie im Fall von DevOps, ist schwierig. Tatsächlich ist diese Transformation oft weitaus anspruchsvoller als die technischen Herausforderungen. Ein wichtiger Schritt für große Unternehmen ist es, Business und IT (wieder) miteinander zu verbinden. Manchmal beginnt die IT diesen Prozess ohne ausreichende Unterstützung durch das Unternehmen insgesamt. Projekt-/Produktverantwortliche sind gut beraten, hier aktiv zu suchen.

Denn es gilt, die richtigen Initiativen zum richtigen Zeitpunkt in Gang setzen. Um dabei den Erfolg der geschäftlichen Aktivitäten zu messen, sollte beispielsweise die Zeit zwischen der Bereitstellung einer neuen Software für die Freigabe in die Produktion und dem tatsächlichen produktiven Einsatz betrachtet werden. Dabei ist zu beachten, dass sich aufgrund des Freigabe- und Genehmigungsprozesses zusätzliche Herausforderungen ergeben können, die in diesem Kontext nicht gemessen werden.

In diesem Zusammenhang drückt die Kennzahl „vergeudete Zeit“ (auch als Lost Opportunity Time bezeichnet) den Zeitraum aus, der entsteht, wenn die IT-Verantwortlichen nicht an den richtigen Aufgaben arbeiten. Wenn Inhalte entwickelt werden, die nicht für die Produktionsfreigabe benötigt werden, ließe sich schlussfolgern, dass die betroffenen Experten woanders aus Sicht des Unternehmens profitabler eingesetzt werden könnten. Anhand dieser Kennzahl können Abteilungen und Portfoliomanager potenzielle Bereiche identifizieren, in denen der Aufwand besser optimiert würde.

Beispielweise kann sich die Lost Opportunity Time wegen verzögerter Freigaben verlängern.
Dazu ein Beispiel: Wir bei CloudBees haben das Thema Agile Software-Entwicklung in den Vordergrund gestellt und unsere Teams entsprechend auf diese Art des Projektmanagements geschult. Alle Teams arbeiten sehr gewissenhaft und zielstrebig nach diesen Vorgaben. Im Gespräch mit einem der Teams über deren Fortschritte, berichtete dieses Team, dass es bereits vier einzelne Teilprojekte, sogenannte Sprints, fertiggestellt hatten. Diese waren jedoch noch nicht ins Gesamtprojekt integriert, weil das Team niemanden finden konnte, der diese Sprints freigibt. Die Teilprojekte waren abgeschlossen, aber eben längst nicht, wie oben angemerkt, in produktive Nutzung gegangen.

Business Value Points

Das für eine Anwendung oder ein Produkt verantwortliche Team zeichnet den für einen Arbeitsschritt erforderlichen Aufwand in einem Backlog (Rückstandsbericht) auf. Dieser Wert wird dem Produktverantwortlichen in Form von Business Value Points verdeutlicht. Um ein Gleichgewicht an Aufwand und Ertrag sicherzustellen, ist es notwendig, beides – den Aufwand und die Business Value Points – in Einklang zu bringen. Diese Praxis wurde in der Industrie von der Agile Community als Hilfsmittel für die Backlog-Pflege übernommen. Erfahrungsgemäß sollten dabei diese erhobenen Werte innerhalb von Teams genutzt werden und nicht teamübergreifend.

Während es Unternehmen leicht fällt, hoch priorisierte Aufgaben an IT-Experten zur Bearbeitung weiterzugeben, fällt es gemeinhin schwerer, vormals hoch-priorisierte Aufgaben mit einer niedrigeren Dringlichkeit zu versehen. Im Ergebnis führt dies dazu, dass sich Aufgaben mit hoher Priorität häufen und das Team überfordert. Zwar kann eine solche Situation von Zeit zu Zeit zwangsweise entstehen und ein höherer Durchsatz zu einer höheren Kapazität führen, jedoch führt das zur potenziellen Überlastung des Teams – ein erhebliches Risiko. Hier kann das Unternehmen gegensteuern, indem es die Prioritäten ständig neu bemisst und so die Qualität von Entscheidungen und Agilität verbessert.

Beispiel aus der Praxis: Ein Produktteam durchläuft seit einiger Zeit einen Backlog. Jedes Element im Backlog wurde vom Produktverantwortlichen mit den Business Value Points versehen. Angenommen, es wurden 70 Prozent dieser Punkte aus dem Backlog geliefert. Aus den Aufwandspunkten für die restlichen Anforderungen kann man somit erkennen, dass es sechs Monate dauern wird, den Rest des Backlogs abzuarbeiten. Darüber hinaus wurden vom Produktverantwortlichen für einige Monate keine wesentlichen neuen Anforderungen in den Backlog aufgenommen.

Basierend auf diesen Informationen kann das IT-Management mit dem Unternehmen über die Wahrscheinlichkeit sprechen, dass dieses Produkt bald produktiv genutzt werden kann und die IT-Teams möglicherweise an neuen Initiativen im Unternehmen arbeiten.

Kurz gesagt, die Verwendung solcher Metriken kann es dem Unternehmen ermöglichen, den Zeitpunkt, an dem Produkte von der aktiven Entwicklung zur Nutzung im Alltagsbetrieb wechseln, besser zu identifizieren. Sind die Ressourcen begrenzt, erhalten sie einen Überblick darüber, welche aktuellen Initiativen ergriffen wurden, damit neue Prioritäten gesetzt werden können.

Ampel-Status

In einem großen Unternehmen, insbesondere vor einer DevOps-Transformation, sind technische Experten im Top-Management eines Unternehmens oft unterrepräsentiert. Erfüllung der Zeitvorgaben und des Budgets von Projekten werden immer auf höherer Ebene diskutiert als der technische Status. Um dies zu ändern, sollten als eine der wichtigsten Maßnahmen alle Führungskräfte Zugang zu Dashboards erhalten. In ihnen wird der aktuelle Status der einzelnen Projekte durch jeweils eine Ampel symbolisiert. Dies ist in großen Unternehmen durchaus üblich. Darin stellen Projekt- beziehungsweise Programmmanager einen Status für pünktliche Fertigstellung und einen für die Einhaltung der Budgets zur Verfügung.

Um ein möglichst rundes Gesamtbild zeichnen zu können, ist es empfehlenswert, zusätzliche Experten bei der Erstellung der „Ampel-Meldung“ hinzuzuziehen. Jedem Projekt beziehungsweise Produkt sollte ein für die technische Stabilität verantwortlichen Mitarbeiter zugewiesen werden. Dieser hat Zugang zu den Indizes, die Aufschluss über die Qualität oder den Verlauf der Qualitätsentwicklung geben. Für die Erstellung dieser Metriken sind mehrere Werkzeuge verfügbar. Die Informationen über Mängel, architektonische Konsistenz, Wartbarkeit und dergleichen sind für eine Erörterung auf Top-Managementebene mitunter zu speziell. Daher sollte ein technischer Leiter sein Urteil in die Einordnung, ob ein Status Grün, Gelb oder Rot vorhanden ist, einfließen lassen. Dies kann neben den beiden vorgenannten Indikatoren weiteren Aufschluss über den aktuellen Projektstatus liefern.

Die Beziehung zwischen dem Projektverantwortlichen und dem technischen Leiter ist entscheidend. Der technische Leiter sollte in der Lage sein, dem Projektverantwortlichen eine Empfehlung für Abhilfemaßnahmen oder laufende Arbeiten am Produkt zu geben, anstelle den Fokus auf den reinen Geschäftswert zu legen. Im Gegenzug sollte dieser Projektverantwortliche die Einwände des technischen Leiters berücksichtigen, wenn er gegenüber anderen Interessengruppen innerhalb des Unternehmens beispielsweise zusätzlich notwendige Arbeitsschritte vertreten muss.

Unerwartete Folgen

Es wurde nun ausführlich diskutiert, welche Richtlinien und Themen bei der Definition von Kennzahlen zu beachten sind. Doch allein schon das Messen für diese Indizes ändert das Verhalten der Beteiligten. Daher kann es zu unerwarteten Auswirkungen auf die Metriken führen. So kann es beispielsweise dazu kommen, dass Produktveröffentlichungen erscheinen, in denen nicht alle Ziele umgesetzt wurden. Damit könnten Entwicklungsteams versuchen, ihre verlorene Zeit zu kaschieren. Weitere Beispiele dafür wären die künstliche Heraufsetzung des Geschäftswerts eines Produktes oder Projektes, um das Entwicklerteam bei der Stange zu halten oder die technischen Experten dazu zu verleiten, ihre Einschätzung des Fortschrittes anhand des Ampel-Modells so zu verändern, um schwierigen Diskussionen mit dem Management zu entgehen. Im letzteren Fall könnte das Ziel ausgegeben werden, dass die Qualität nicht den „roten“ Status erreichen darf, also nicht wirklich bedenklich. Jedoch führt dies auch zu einer Unterdrückung von Meldungen auf Eigeninitiative im Falle von auftretenden Problemen.

Weitere Informationen unter:
www.cloudbees.com

Sacha Labourey (li.) ist Gründer und CEO des DevOps-Spezialisten CloudBees. Zusammen mit Nigel Willie, DevOps-Experte bei CloudBees, diskutiert er eine Frage, die viele Unternehmen beschäftigt: Wie kann man den Erfolg von DevOps messen?