DevOps – die nächste Evolutionsstufe der agilen Entwicklung?

DevOps ist derzeit in aller Munde und das Schlagwort schlechthin in Entwicklungsabteilungen. Was verbirgt sich hinter diesem Begriff, und wie bringt man sein Entwicklungsteam und Unternehmen dorthin, DevOps zu leben und zu betreiben? DevOps kombiniert die Entwicklung (Development) und den Betrieb (Operations), doch es verbirgt sich weitaus mehr dahinter.

Quelle: Netzwoche 10 / 8. Juni 2016

Lesen Sie auch das Interview mit Marc Müller: «Wer DevOps einsetzt, schafft mit jedem Software-Release einen Mehrwert»

Der Softwaremarkt und die Erwartungshaltung der Kunden haben sich in den letzten Jahren stark verändert. Die alten Methoden, Software zu entwickeln, die mit langen Planungsphasen und Entwicklungszeiten verbunden waren, funktionieren nicht mehr. Die Organisationen, die flexibel sind und neue Features zu den Kunden bringen, werden sich durchsetzen und überleben. Ein wenig anders formuliert heisst dies, dass eine Organisation mit ihrer Softwareentwicklung kontinuierlich Kundennutzen liefern und somit den Kunden beziehungsweise den Stakeholder ins Zentrum ihrer Tätigkeiten setzen soll. Vielen, die schon seit längerem agil Software entwickeln, dürfte diese Aussage bekannt sein. DevOps ist nicht etwas komplett Neues, sondern basiert auf agilen Methoden und reichert diese mit neuen Möglichkeiten an.

Die wichtigste Erkenntnis, wenn wir uns als Unternehmen DevOps auf die Fahne geschrieben haben, ist, dass wir nicht einen DevOps-Verantwortlichen einstellen können und nun auf Kurs sind. DevOps ist Kultur und Denkweise und kein Programm oder eine einzelne Anstellung. Wir müssen also die ganze Organisation mitsamt ihren Prozessen daraufhin ausrichten. Wir erzeugen Kundennutzen und somit mit jedem Release einen Mehrwert. Um kurze Releasezyklen mit gleichbleibender oder gar gestiegener Qualität zu ermöglichen, ist es wichtig, einen hohen Grad an Automatisierung zu erreichen. Einen neuen Release zu erstellen, darf also keine Schmerzen in Form von hohen Aufwänden und vielen manuellen Schritten verursachen, sondern muss möglichst auf Knopfdruck automatisiert durchgeführt werden können. Dazu zählen die Build- und Release-Automatisierung sowie die Testautomatisierung. Ausserdem müssen wir eine Fail-Fast- Kultur etablieren. Man darf, nein, muss sich sogar trauen, neue Wege zu beschreiten, aber auch den Mut haben, zu erkennen, wenn man sich auf dem falschen Weg befindet, um zum richtigen Zeitpunkt das Steuer herumzureissen.

Eric Ries beschreibt in seiner Lean-Start-up-Methodik den Build- Measure-Learn-Zyklus. Wir erstellen ein Stück Software, einen Kundennutzen, und analysieren (measure) dieses mit verschiedensten Metriken. Wie wird die Software vom Kunden genutzt? Gibt es Fehlerzustände? Welchen Einfluss hat dies auf unsere Infrastruktur und den Betrieb? Wie können wir die Funktionalität verbessern? Aus all diesen Analysedaten führen wir nun die Schlussfolgerungen zusammen, was Einfluss auf unser Backlog und somit die nächsten Entwicklungsphasen hat. Genau dieses Feedback gibt uns auch den Rückhalt, die Richtung nötigenfalls zu wechseln. Wer möchte schon Geld und Zeit in ein Feature investieren, das von den Kunden nicht genutzt wird? Hier haben wir nun eine wichtige DevOps-Ergänzung zur agilen Entwicklung kennengelernt: Wir entwickeln das Backlog weiter (Backlog Grooming), indem wir das Learning (Build-Measure-Learn) aus dem Betrieb einfliessen lassen. Aber nochmals zurück auf Start: Wie kommt man nun also zu einer effizienten und erfolgreichen DevOps- Kultur mit den damit verbundenen Prozessen und dem richtigen Tooling? Als Berater werde ich oft nach einer pfannenfertigen Lösung gefragt. Es dürfte allen klar sein, dass in diesem hochkomplexen Umfeld vielen Einflussfaktoren Rechnung getragen werden muss und es somit nicht die eine Lösung gibt. Wenn wir aber anstelle der pfannenfertigen Lösung, den Köchen ein Kochbuch mit den Grundlagen in die Hand geben, ist dies sicherlich ein guter Start. Es gehört viel Erfahrung und Expertise dazu, den eigenen DevOps-Prozess zu optimieren. Aber wie wir vorhin bereits gelesen haben, ist dies am Ende auch nichts anderes als Build-Measure-Learn. Welche Kapitel beinhaltet nun unser Kochbuch?

Team-Autonomie und Unternehmensplanung in Einklang bringen

Die Team-Autonomie ist ein wichtiger Bestandteil der agilen Entwicklung. Sie dient der effektiven Umsetzung im Team. Die Herausforderung ist es nun, die Automomie eines Teams mit den Unternehmenszielen beziehungsweise dem Gesamtziel mehrerer Teams und deren Planung in Einklang zu bringen und diese periodisch zu überprüfen und abzugleichen. Die meisten Organisationen arbeiten mit Sprints mit einer Länge von zwei bis vier Wochen. Aus Unternehmens- beziehungsweise Produktsicht müssen wir aber den Horizont weiter aufspannen. Oft wird die Planung in folgende Komponenten unterteilt: kurzfristige Planung (Backlog-Priorisierung) über die nächsten Sprints (in der Regel drei Sprints), Produkt-/Geschäftsziele über die nächsten sechs Monate (Definition der Epics) sowie die Vision für die nächsten ein bis zwei Jahre. Aufgrund dieser Planungszyklen erhalten die Teams ein heruntergebrochenes Product Backlog für die Sprintplanung.

Die technische Schuld beherrschen

Unter technischer Schuld versteht man den Zusatzaufwand, der schlecht geschriebene Software mit sich bringt. Bei sich weiterentwickelnden Anforderungen und der damit verbundenen sich verändernden Softwarearchitektur mittels Refactorings, ist es enorm wichtig, die technische Schuld zu überwachen und aktiv abzuarbeiten. Der Source Code sollte in einem zentralen Integrationsbranch mit kurzen Feature-Branches verwaltet werden. So driften die Code-Stände nicht auseinander und das Zusammenführen gestaltet sich einfach. Daneben sollten wir so viele automatisierte Tests wie möglich auf dem tiefstmöglichen Level erstellen. Dies impliziert einerseits,dass unsere Software und deren Architektur auf Testbarkeit ausgelegt ist und andererseits die Tests in jedem Umfeld – vom Development bis Produktivsystem – ausgeführt werden können. Zudem müssen wir mögliche Probleme frühzeitig erkennen. Eine Methode, abgesehen von der nachfolgend beschriebenen Instrumentalisierung, ist es, ebenfalls den Kunden ins Zentrum zu rücken und sich explizit auf die unzufriedenen Kunden zu fokussieren und zu analysieren, was zu dieser Situation führen konnte.

Kundenfokus

Der Kundenfokus oder auch der Kundennutzen wurde in diesem Artikel bereits mehrfach angesprochen. Ausser der Instrumentalisierung von Applikationen und Services und der damit verbundenen Nutzungsstatistiken können aber auch weitere Methoden und Tools zur Erhebung des Kundenfeedbacks eingesetzt werden. Wir können einerseits den Kunden als Stakeholder in unsere Systemlandschaft integrieren, indem er uns qualifizierte Feedbacks gibt oder über neue Funktionen und Erweiterungen abstimmen kann. Bei all der modernen Technik nicht zu vergessen, ist jedoch das gute alte persönliche Gespräch mit dem Kunden.

Backlog Grooming mit Learning

Mittels der Instrumentalisierung unserer Applikationen möchten wir Learnings aus den erhobenen Daten ziehen und somit die Planung der Weiterentwicklung steuern. Wir können aber das Benutzerverhalten nicht immer voraussagen, deshalb ist es wichtig, Hypothesen aufzustellen und diese dann mit effektiven Daten aus dem Betrieb zu überprüfen. Wichtig hierbei ist, die Entwicklungsarbeiten nicht unnötig kompliziert zu machen. Viele erfolgreiche Software-Teams haben ihren Release-Prozess entschlackt und nur noch ein Release-Gefäss. Doch wie werden Features ausprobiert oder Hypothesen verifiziert ohne Beta-Release? Das Zauberwort heisst Feature-Flags. Die Software wird immer als Ganzes ausgeliefert, jedoch kann über Features-Flags gesteuert werden, wer welches Feature sieht und somit benutzen kann. Somit können feingranular Early Adopters aufgeschaltet werden oder es können auch A/B-Tests, also die Überprüfung und Analyse zweier verschiedener Varianten der Feature-Implementierung, mit dem Zielpublikum durchgeführt werden.

Telemetriedaten aus der Produktion

Ziel der Instrumentalisierung ist es, eine möglichst komplette Gesamtsicht der produktiven Applikation zu erhalten. Dieses Rad muss heutzutage kaum einer mehr neu erfinden, sind doch zahlreiche Tools auf dem Markt, die einem mit Analysedaten und deren Auswertung versorgen. Grosse Softwarekonzerne sammeln heutzutage mehrere hundert Terabyte Daten pro Tag, was im Zeitalter der Cloud zum Glück kein grosses Problem mehr darstellt. Durch die kurzen Release-Zyklen lassen sich erkannte Probleme schnell im nächsten Release beheben oder es kann eine situationsgerechte Neu-Priorisierung des Backlogs erfolgen. Zu guter Letzt stellt sich noch die Frage nach dem Tooling. Es gibt verschiedene Anbieter, die DevOps- und ALM-Plattformen anbieten. In der heutigen schnelllebigen Welt ist es daher wichtig, eine erweiterbare und interoperable Plattform zu haben, die verschiedenste Entwicklungstechnologien unterstützt, die Daten aller Komponenten des DevOps-Prozesses integriert und eine gute Rückverfolgbarkeit derer zulässt. Der Schlüsselfaktor liegt in der Automatisierung des Gesamtprozesses und stellt somit eine wesentliche Anforderung an die Tool-Landschaft dar. Sind nun alle Faktoren berücksichtigt, können wir unser Ziel erreichen: die kundenorientierte Software in kurzen Zyklen automatisiert ausliefern.