Mit DevOps und Cloud zu mehr Agilität, Teil 1 Agile Transformation und DevOps-Kultur

DevOps, Cloud und Agile sind in aller Munde. Dahinter steckt häufig ein einfaches Ziel: IT- und Fachabteilungen möchten sich modernisieren, um schneller und effizienter zu werden. Alle drei Aspekte stellen bereits für sich eine gewaltige Transformation dar, doch erst gemeinsam entwickeln sie ihr volles Potential.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FleishmanHillard Germany GmbH c/o DO IT! GmbH

Um die Auswirkungen einer Transformation auf eine bestehende Organisation greifbar zu machen, muss man sich zunächst den Ausgangszustand vergegenwärtigen. Im Kontext der Softwareentwicklung gleicht dieser immer noch häufig dem klassischen Wasserfallmodell, wie es in der vorangestellten Abbildung zu sehen ist.

Fachabteilungen schreiben umfangreiche Anforderungsdokumente, die im ersten Schritt von einem Architektur-Team in ein Grobdesign überführt werden müssen. Anschließend entwickelt ein zweites Team die eigentliche Software in einem – vielleicht monatelangen – Projekt, um das fertige Artefakt schließlich von der Qualitätssicherung gegen die ursprünglichen Anforderungen verifizieren zu lassen. Ist hier alles in Ordnung, wandert die Software weiter zum Betrieb, der sich um das produktive Deployment kümmert.

Die konkrete Ausprägung dieses Prozesses mag in jeder Organisation unterschiedlich sein; was man aber fast immer vorfindet, sind zahlreiche Übergabepunkte mit inhärentem Informationsverlust und dementsprechend unvermeidbare Abweichungen vom ursprünglichen Fachkonzept. Und selbst wenn man von diesem Problem absieht und annimmt, dass am Ende exakt das beim Endkunden landet, was die Fachabteilung bestellt hat – die Durchlaufzeiten für Projekte können extrem lang sein.

In einer Welt mit immer kürzer werdenden Innovations- und Produktlebenszyklen sind schon sechs Monate von der Idee bis zum Rollout eine sehr lange Zeit. Zeit, in der sich der Markt weiterentwickeln und anfangs richtige Annahmen invalidieren kann. Zeit, in der Wettbewerber neue Produkte beim Endkunden positionieren können. Und vor allem Zeit, in der keinerlei Feedback über die Qualität des vorliegenden Konzepts generiert wird.

Die agile Transformation beginnt

Dieses Spannungsfeld ist der Ursprung von jeglichem Streben nach mehr Agilität. Um in dieser Welt die richtigen Dinge zu bauen, müssen sich alle Beteiligten in kurzen Iterationen synchronisieren und den eingeschlagenen Weg kontinuierlich hinterfragen. Agilität bedeutet vor allem Lernen – und das ultimative Ziel ist dabei die schnelle Identifizierung und Erfüllung der aktuellen Kundenbedürfnisse. Mit den etablierten Prozessen ist dies häufig unmöglich, was eine Suche nach Alternativen zur Folge hat: die agile Transformation beginnt.

Im ersten Schritt wird meist ein agiler Prozess wie beispielsweise Scrum im Entwicklungsteam eingeführt. Anstatt mit umfassenden Dokumenten zu arbeiten, basiert die wesentlich engere Abstimmung nun auf persönlicher Kommunikation während und nach jeder Iteration.

Mit DevOps und Cloud zu mehr Agilität, Teil 2

Next Stop „Cloud“

Die nächsten Schritte werden gemeinsam geplant und in funktionierende, Mehrwert schaffende Software überführt, die nach jeder Iteration vorgestellt wird. Alle Verantwortlichen sehen, wie sich das Produkt entwickelt, und jegliches Feedback kann schon in der nächsten Iteration berücksichtigt werden.

Leider stammt dieses Feedback aber nicht vom eigentlichen Kunden oder Nutzer, denn die nachgelagerten Schritte im Wasserfall haben sich durch den ersten Schritt nicht verändert. Nach wie vor kann jeder Release-Candidate erst nach einer aufwändigen Abnahme durch die Qualitätssicherung vom Betrieb in Produktion installiert werden. An diesem Punkt entsteht häufig das Gefühl, dass „Agilität bei uns nicht funktioniert“.

Geduld bei der Transformation zahlt sich aus

Die Steuerung der Projekte fühlt sich gerade bei den ersten Schritten aufgrund der ständigen Anpassung der Requirements wesentlich schwieriger an, da die Abstimmung an den Schnittstellen zwischen agiler und klassischer Welt ein hohes Konfliktpotential birgt. Darüber hinaus sind Anforderer selten damit zufrieden, ein dringend erwartetes Feature auf einer Test-Umgebung sehen zu können – aber erst Monate später beim Kunden.

Hier gilt es, einen langen Atem zu bewahren und das Ziel nicht aus den Augen zu verlieren! Die Transformation steht noch am Anfang und muss dort fortgesetzt werden, wo unweigerlich die größten Probleme entstehen: An der Schnittstelle von der Entwicklung in den nachgelagerten Wasserfall.

Release-Freigaben sind vor allem deshalb so aufwendig, weil in der Regel eine komplette Regression der Bestandsfunktionalität im bestehenden Prozess verankert ist. In einem monolithischen Gesamtsystem ist das keine einfache Aufgabe. Es werden häufig umfassende Testpläne herangezogen, um die Funktionalität in zahlreichen Testfällen zu prüfen. Diese Dokumentation ist häufig nur die Basis für manuelle Tests.

Durch eine Automatisierung dieser Schritte lässt sich der Prozess extrem beschleunigen: Idealerweise werden schon bei der Entwicklung einer Funktionalität die Tests für deren Verifikation im Softwareprojekt mit implementiert. Und dafür ist es entscheidend, dass die Expertise der Qualitätssicherung im agilen Softwareentwicklungsteam verankert wird. (siehe Abbildung links). Der Schwerpunkt liegt dabei nun auf „Quality Assistance“ statt reiner „Quality Assurance“.

Ziel sollte es sein, dass alle Mitglieder des Teams das nötige Qualitätsbewusstsein entwickeln. Die Tester lernen in der Regel im Bereich Automatisierung und Programmierung dazu, die Entwickler beim Gespür für das Gesamtsystem und der möglichen Identifizierung von Spezialfällen, die besondere Aufmerksamkeit benötigen. Mit einer so erreichten Testabdeckung des Produktes – idealerweise nach Mike Cohns Testpyramide (aus „Succeeding with Agile“ von Mike Cohn) – liefern darauf aufbauende Konzepte wie Continuous Integration die notwendige Sicherheit, dass der Softwarestand der erwarteten Auslieferqualität entspricht.

Nun ist das Team dazu in der Lage, nach jeder Iteration produktionsreife Software zu liefern. Früher oder später entsteht daraus auf natürliche Weise das Bedürfnis, diese auch dem Kunden zur Verfügung stellen zu können. Die dadurch ansteigende Zahl an „Change Requests“ erzeugt im Betrieb eine eventuell erhöhte Arbeitslast, die nicht in diesem Umfang erwartet wurde, und eine mit der agilen Transformation potenziell einhergehende Verunsicherung, da Inkremente mit solchen kurzen Entwicklungszyklen als nicht stabil eingestuft werden.

Häufig wird dieses Problem nicht transparent gemacht, sondern durch in sich bürokratische und langsame Prozesse verschleiert. Am Ergebnis ändert das allerdings nichts: die Konfliktlinie verläuft genau dort, wo der agile Prozess endet und nach wie vor verpufft viel der in den vorherigen Prozessschritten gewonnenen Geschwindigkeit.

DevOps – ein neues Mindset entsteht

An dieser kritischen Stelle kann die Transformation schlimmstenfalls scheitern und man beginnt, den „Water-Scrum-Fall“ zu leben. Im besten Fall entsteht daraus aber ein neues Mindset, das weitere Hürden aus dem Weg räumt: DevOps. Das bedeutet zunächst einmal, dass Entwicklung und Betrieb enger und auf Augenhöhe zusammenarbeiten (siehe Abbildung links).

Konkreter geht es sowohl um das „Dev im Ops“, also die gemeinsame (Teil-)Automatisierung des Deployment-Prozesses, als auch um das „Ops im Dev“, was zum Beispiel die steigende Verantwortung des Entwicklungsteams für die Stabilität der produktiven Systeme bedeutet. Beides entlastet den Betrieb, was kürzere Release-Zyklen möglich macht.

Darüber hinaus führt die Bündelung der Kompetenzen, ähnlich wie zuvor bei der Qualitätssicherung, zu gewaltigen Synergien. Ein ganz konkretes Beispiel dafür ist die Zusammenführung von technischem und fachlichem Monitoring. Während der Betrieb vor allem Deployments, physische sowie virtuelle Ressourcen und die allgemeine Last auf den Systemen im Blick behält, baut das Entwicklungsteam fachliche Metriken in die Applikationen ein. So lassen sich beispielsweise Zusammenhänge – oder deren Abwesenheit – zwischen fachlichen Kennzahlen und Deployment-Zeitpunkten in übersichtlichen Dashboards visualisieren (vgl. Abbildung links).

Die Methode ist altbekannt und wird im Betrieb schon lange eingesetzt, um technische Anomalien zu finden (vgl. Abbildung links). Durch die Kombination von heterogenen Datenquellen kann sie aber wesentlich breiter eingesetzt werden, nämlich zur fachlichen Bewertung der installierten Änderungen. Endlich bekommt die Fachabteilung schnelles und direktes Feedback vom Endkunden und die gesamte Organisation lernt kontinuierlich, während sich das Produkt weiterentwickelt.

Weshalb nun das Operations Team nicht komplett Teil des Entwicklungsteams wird, hat zwei Gründe, die in der Praxis häufig anzutreffen sind: Der SysOps-Betrieb wird fast immer von einer anderen Abteilung oder gar einem anderen Unternehmen geleistet, weshalb eine Zusammenlegung meist strukturell nicht machbar ist. Der zweite und viel wichtigere Grund ist, dass das Umdenken Richtung DevOps neue Probleme schaffen kann, denen sich der Betrieb selbst noch organisatorisch stellen muss.

Der zweite Teil dieses Beitrags befasst sich damit, wie die Cloud dabei hilft, Agilität und DevOps-Kultur im Unternehmen zu stärken.

* Über die Autoren

Benjamin Steinert

Benjamin Steinert beschäftigt sich als Developer Advocate bei comSysto mit Themen Cloud Native, DevOps und Platform-as-a-Service. Seine achtjährige Erfahrung in der agilen Softwareentwicklung mit Java in unterschiedlichen Domänen und Rollen legen die Basis dafür.

Christian Kroemer

Christian Kroemer ist Agile Advocate bei comSysto, um die richtigen Rahmenbedingungen für moderne Softwareentwicklung zu schaffen. In verschiedenen Rollen unterstützt er Teams und Organisationen dabei, sich kontinuierlich zu verbessern und dabei agiler zu werden. Gerne stürzt er sich auch selbst tief in Java-Code und die Infrastruktur für komplexe Systeme.

(ID:45040486)