Blog

Warum ist DevOps für Führungskräfte wichtig?

MAR 19, 2020

DevOps ist weit mehr als Automatisierung und Pipelines. Es geht darum, eine Kultur zu entwickeln, in der organisatorische Agilität zu kontinuierlicher Wertschöpfung führt.

Tero Pänttönen

Tero is a DevOps Lead at Eficode. With a background in the financial industry, he is now leveraging his experience to generate business benefits and customer value with cross-functional teams.

Als Business Manager verbringt ihr euren Arbeitstag damit, euch mit allem zu beschäftigen – von Umsatzzahlen und Kundenzufriedenheit über die Employee Experience bis hin zum Produktangebot. Wahrscheinlich behaltet ihr auch die Conversion Rate im Online-Vertrieb, den Lieferprozess und die damit verbundenen Marketingkosten genau im Blick. Aber interessiert ihr euch ausreichend für den Mehrwert, die Qualität und die Weiterentwicklung digitaler Services?

Qualität hat viele Facetten: Geschwindigkeit, Zuverlässigkeit, Fehlerfreiheit und Skalierbarkeit für verschiedene Geräte. Liegt die Verantwortung für Qualität allein bei der IT- oder Marketingabteilung? Das sollte nicht der Fall sein, insbesondere wenn es um den Online-Vertrieb geht. Welcher Verkaufs- oder Einkaufsprozess beginnt heutzutage nicht über einen Online-Kanal? Potenzielle Kunden durchlaufen ihren Entscheidungsprozess, während sie die Anbieter kennenlernen. Deshalb gewinnt die Entwicklung digitaler Services besonders an Bedeutung, wenn das Produkt selbst ein digitaler Service ist.

DevOps soll IT-Service-Funktionen rund um Softwareentwicklung, Tests und Wartung automatisieren. Wichtig ist jedoch: Automatisierung bedeutet nicht automatisch niedrigere Kosten. Das DevOps-Modell ermöglicht zwei Dinge, die für Business Manager entscheidend sind: Qualitätsverbesserungen und eine schnelle Bereitstellung von Mehrwert – auch bekannt als Zero Day Delivery.

Testautomatisierung im Softwarebereitstellungsprozess ist entscheidend: Software wird häufig, also systematisch, getestet, und Regressionen oder neue Fehler, die durch Änderungen an der Codebasis entstehen, werden durch automatisierte Tests erkannt. Testautomatisierung und Robotic Process Automation (RPA) lassen sich in den meisten Softwareprojekten umsetzen, erfordern jedoch den Input von Teammitgliedern mit fundiertem Wissen über Automatisierungsmöglichkeiten. Gut konzipierte Testautomatisierung prüft nicht nur kritische Komponenten und grundlegende Funktionen. Sie sollte auch sicherstellen, dass ein Produkt oder Service in ungewöhnlichen Situationen nutzbar ist und wie vorgesehen funktioniert.

Mit DevOps-Praktiken lässt sich der Prozess zwischen Entwicklungs- und Produktionsumgebung automatisieren. Dennoch kann die Unternehmenskultur dazu führen, dass dem Bereitstellungsprozess weiterhin manuelle Schritte hinzugefügt werden. Idealerweise sind die eingesetzten Services integriert, Änderungen und ihre Auswirkungen lassen sich nachvollziehen, und alles kann zurückgerollt werden – auch wenn es besser ist, voranzugehen und Herausforderungen zu beheben. Die größte Herausforderung besteht darin, sich mit dem Business darauf zu einigen, wie eine Änderung mithilfe einer gut konzipierten Delivery Pipeline automatisch verifiziert wird, damit alle Vertrauen in die Softwarequalität haben.

Wenn alles automatisiert ist, sinken dann nicht die Kosten? Ja, langfristig. Die Entwicklung von Automatisierung kostet Zeit und Geld, doch je mehr manuelle Arbeit automatisiert wird, desto günstiger werden die wiederholten Durchläufe verschiedener Aktivitäten.

Die Rolle des Testers entwickelt sich zunehmend in Richtung Automatisierung, doch leider werden manuelle Tester nur selten zu Testautomatisierern. Dennoch sollten sie über Kenntnisse oder zumindest Interesse an Coding oder Scripting verfügen. Manuelle Tester sind gut darin, aus Workflow-Perspektive zu definieren, wie das System funktionieren soll. Die Teammitglieder einigen sich auf praktische Entwicklungsansätze, die Best Practices in der Entwicklung unterstützen und manuelle Arbeit verringern.

Der Kunde profitiert von der Automatisierung, wenn das Projekt transparenter wird, Änderungen in die Produktion ausgerollt werden und bekannt ist, welche Funktionen die Endnutzer verwenden. Das Entwicklungsteam kann sich auf seine Arbeit konzentrieren, Herausforderungen lassen sich schnell beheben, und die Veröffentlichung einer korrigierten Version erfordert keinen zusätzlichen Aufwand.

Planbarkeit und Transparenz verbessern

Wäre es nicht großartig, im Voraus zu wissen, wann eine gewünschte Funktion Mehrwert für eure Kunden und damit für euer Business schafft? DevOps verbessert die Planbarkeit sowohl aus technischer als auch aus nichttechnischer Sicht. Wie zuvor beschrieben, werden neue Funktionen automatisch verifiziert, Installationen sind weniger anfällig für menschliche Fehler, und Aktivitäten werden protokolliert. Ebenso wichtig ist Transparenz über künftige Entwicklungsaktivitäten. Die Pflege des Backlogs, seine effiziente Priorisierung und die Dokumentation aller Aktivitäten helfen dabei, die Zukunft des Projekts vorherzusagen und ermöglichen Retrospektiven. Anforderungen werden von jemandem definiert und haben Kriterien. Die Kriterien einer Änderung sollten für alle an den Entwicklungsaktivitäten Beteiligten klar sein.

Jetzt konzentriere ich mich auf den Teil des Prozesses, in dem Entscheidungen getroffen werden. Eine häufig verwendete Methode besteht darin, die zu entwickelnden Themen in vier Ebenen zu unterteilen. Zum Beispiel:

Thema: Geschäftlich ausgerichtetes Ziel für das Produkt. Der Business Owner verantwortet und priorisiert das Thema gemeinsam mit dem Product Owner.

Epic: Ein großer Arbeitsumfang, der es ermöglicht, die Machbarkeit (S–XL) und die Wirtschaftlichkeit (geschäftlicher Mehrwert) einer klar definierten, Mehrwert schaffenden Funktionalität zu bewerten. Der Product Owner verantwortet und priorisiert das Epic gemeinsam mit dem Business Owner.

Story: Etwas, das ein Nutzer mit einer klar definierten „Definition of Done“ (DoD) und einem Aufwand (Story Points) erreichen kann. Der Product Owner verantwortet und priorisiert die Story gemeinsam mit dem Entwicklungsteam.

Task: Ein einzelner Meilenstein zur Fertigstellung der Story, dessen Aufwand zeitlich geschätzt wird. Das Entwicklungsteam verantwortet und priorisiert den Task gemäß der im Team vereinbarten Methodik.

Diese Kategorien beziehen sich auf den Entscheidungsprozess, weil sie dem Business Owner einen Überblick darüber geben, woran das Entwicklungsteam arbeitet. Dadurch kann er das Entwicklungsthema und die darunterliegenden Epics priorisieren und gleichzeitig flexibel die Richtung ändern, falls erforderlich. Wenn sich die Entwicklung in die falsche Richtung bewegt, können unnötige Tasks und Stories einfach verworfen und die Arbeit neu priorisiert werden.

Auch für die Motivation des Entwicklungsteams ist es gut, wenn nicht ständig ungeplante Themen im Sprint Backlog auftauchen. Gleichzeitig sollte Raum für kritische Arbeiten oder Aufgaben reserviert sein, die sofort umgesetzt werden müssen. Ungeplant auftauchende Aufgaben haben selten einen echten Mehrwert. Sie sind oft schlecht vorbereitet und führen zu Zeit- und Geldverschwendung. Systematische Entwicklung braucht Zeit. Wird die Vorbereitung von den relevanten Stakeholdern nicht priorisiert, wird das Ergebnis zwangsläufig schlecht sein.

DevOps ermöglicht zudem ein gewisses Maß an Kostentransparenz. Gute Arbeit konzentriert sich darauf, den Kundennutzen zu maximieren und unnötige manuelle Aufgaben zu automatisieren, um Geschäftsergebnisse zu verbessern. In diesem Fall setzen Business Owner und Product Owner ihr Budget sinnvoll ein, und die Ergebnisse zählen. Den Kundennutzen zu messen, ist schwierig. In einem E-Commerce-Shop lässt sich jedoch beispielsweise leicht betrachten, welche Einnahmen und Conversions erzielt werden, und diese den Entwicklungskosten gegenüberstellen.

Kultur verändern

Veränderung wird nicht verwaltet. Veränderung wird umgesetzt. Ein Hindernis für eine erfolgreiche Transformation entsteht, wenn das Topmanagement einer einzelnen Person die Aufgabe überträgt, die Arbeitsweise der Organisation zu verändern. Das Management selbst begleitet die Veränderung dann über Steuerungsgruppensitzungen, Management-Meetings und PowerPoint-Präsentationen. Dieser Ansatz wird vermutlich nicht zum bestmöglichen Erfolg führen.

Stattdessen sollte das Management Sprints in der eigenen Arbeit einsetzen. So sammelt es unmittelbare Erfahrungen mit den neu eingeführten Arbeitsweisen. Es wird klarer, was von der gesamten Organisation verlangt wird, und das Management erlebt die Vorteile einer systematischen, zielorientierten und strukturierten Arbeitsweise direkt. Natürlich ist es nicht realistisch, alle Aufgaben des Topmanagements für ein oder zwei Wochen zu planen. Einige lassen sich jedoch als Sprints behandeln.

Auch der Einsatz von Tools, ohne ihren Mehrwert zu verstehen, führt nicht zum Erfolg. Lean geht beispielsweise oft schief, wenn der Fokus auf Tools und Methoden statt auf Lean-Werten liegt. SAFe wird in einigen Teilen der Organisation eingesetzt, weil es im Softwaremarkt im Trend liegt.

Eine Form des Kulturwandels ist das frühe Scheitern. Es ist der beste Weg, bei der Entwicklung viel Geld zu sparen. Werden Konzepte häufig und frühzeitig validiert, gelangen nur wertvolle Features ins Development Backlog. Dennoch verlassen sich Menschen oft zu sehr auf ihre eigenen Ideen und Erkenntnisse und zögern, unfertige Lösungen Endnutzern zu zeigen – obwohl dies sinnvoll und effektiv wäre. In dieser Phase sind kostengünstige Entwicklungsansätze und der zu entwickelnde Service besonders relevant für die Bedürfnisse des Kunden.

DevOps und Agile Entwicklung

DevOps wird oft als eine Reihe von Tools und Praktiken verstanden, etwa Testautomatisierung, Optimierung von Release-Pipelines und die Sichtbarmachung des Deployment-Status für Entwickler durch Monitoring. Das stimmt zwar, doch dabei handelt es sich nicht um einmalige Entwicklungsaktivitäten. Stattdessen sollten sie kontinuierlich weiterentwickelt und an sich ändernde Anforderungen angepasst werden.

Ein guter Ansatz wäre, gelegentlich einen eigenen „technischen Sprint“ durchzuführen, der sich auf technische Verbesserungen, Tool-Korrekturen und Ähnliches konzentriert. Möglicherweise kann nicht das gesamte Entwicklungsteam daran beteiligt sein, dennoch sollte es eine Teamaktivität sein. Das heißt: Bei Bedarf werden relevante Experten hinzugezogen, um Probleme zu lösen, die andere nicht effizient lösen können. Wichtig ist jedoch, „Wartungsaufgaben“ in die Sprint-Planung einzubeziehen. So seid ihr auf Unterbrechungen bei der Nutzung eurer Tools vorbereitet und das gesamte Team kann auf einen Blick sehen, welche Änderungen vorgenommen wurden.

DevOps ermöglicht Agile Entwicklung. Kontinuierliche Wertschöpfung in Vollzeit ist nur möglich, wenn Zeit und Energie nicht für manuelle Arbeitsschritte oder Probleme mit Tools verschwendet werden. Um diese Idee vollständig umzusetzen, muss das Management mit gutem Beispiel vorangehen und selbst praktizieren, was es fordert. Mehr dazu erfahrt ihr in diesem Blog: „Agile vs. DevOps: die große Debatte.“

  • DevOps
  • Agile

Subscribe to our newsletter