Agiles Entwickeln

DevOps krempelt Hierarchien um

11.01.2016 von Christoph Lixenfeld
Forrester sagt, wer DevOps beherrscht, braucht keine IT der zwei Geschwindigkeiten. Organisation und Strukturen werden sich mit Einführung der Methode ändern.

Die Digitalisierung fast sämtlicher Kundenbeziehungen bietet Unternehmen große Chancen und verursacht zugleich Probleme. Nie war es leichter, neue Kunden zu gewinnen oder vorhandene zu verlieren.

Etablierte Unternehmen fürchten sich vor Startups mit neuen Ideen und innovativen Softwarelösungen, während sie selbst sich mit ihren jahrzehntealten Systemen herumschlagen müssen, die sich nicht in wenigen Wochen oder Monaten erneuern lassen.

In seinem Report: "Forget Two-Speed IT. DevOps enables faster delivery across the board" beschreibt Forrester die Vorteile von DevOps als Entwicklungs- und Implementierungsmethode auch und gerade in historisch gewachsenen Anwendungsumgebungen.

Eine Definition von DevOps

DevOps und Scrum werden oft als Alternative zur klassischen Wasserfall-Entwicklung gepriesen. Dabei geht es um mehr als nur um eine geänderte Art der Softwareentwicklung.
Foto: Marvellousworld - Fotolia.com

DevOps ist ein Kunstwort, das sich aus den ersten Silben von ‚Development‘ und ‚Operations‘ zusammensetzt, also aus Entwicklung und Betrieb.

Der Ansatz ähnelt dem der agilen Softwareentwicklung, nur dass es bei DevOps zusätzlich darum geht, Abteilungsgrenzen aufzulösen. Das macht es schwieriger, solche Ansätze in der Praxis zu etablieren.

Gelingen kann das nur, wenn bei allen Beteiligten Anreize für das sich Einlassen auf das Verfahren bestehen.

Es geht um die Frage, wie sich die ursprüngliche Idee einer Software schnell und stabil zum Kunden bringen lässt. Eine Entscheidung für neue Methoden wie DevOps fällt dabei natürlich nur dann, wenn damit aus Sicht der Unternehmensleitung ein quantitativ messbarer Vorteil gegenüber anderen Vorgehensweisen verbunden ist.

Methodisch lautet das Ziel, eine bessere Zusammenarbeit zwischen Entwicklungsteam, Service und Management zu etablieren, als das in traditionellen, hierarchischen Strukturen normalerweise der Fall ist.

Abteilungsgrenzen und Hierarchien abschaffen

Abteilungsgrenzen und Hierarchien sollen so weit wie möglich ausgeschaltet werden, das heißt Entwickler, Fachabteilungen und Management müssen willens und in der Lage sein, auf Augenhöhe zusammenzuarbeiten. Idealerweise arbeiten dabei so viele Beteiligte wie möglich temporär in denselben Räumen.

Das Vorgehen bei der Entwicklung wird oft mit Hilfe solcher Schaubilder beschrieben. Wer sie versteht, hat die größte Hürde bereits genommen.
Foto: MicroTool

Scrum dient zur Steuerung

Zur Steuerung der abteilungsübergreifenden 'Operations' kommt meistens das Scrum-Verfahren zum Einsatz. Grundannahme dahinter: ist zu komplex, um von vorne bis hinten planbar zu sein. Scrum reduziert die Komplexität erstens durch mehrere Feedbackschleifen, zweitens werden gewünschte Funktionen ständig überprüft und wenn nötig nachgeschärft.

Das Verfahren ist rollenbasiert, die beiden wichtigsten Rollen sind die des Product Owners und des Scrum Masters. Der Product Owner ist für den Erfolg verantwortlich, muss sicherstellen, dass das entwickelte Produkt sauber definiert ist und am Ende das kann, was es können soll. Der Scrum Master moderiert den ganzen Prozess.

Forrester argumentiert nun in seinem Report, dass Entwicklungsabteilungen, die diese Klaviatur beherrschen, sie mit Erfolg in sämtlichen Softwareprojekten anwenden können und so ihre Chance deutlich erhöhen, im Rennen um die besten digitalen Plattformen und Lösungen zu den Gewinnern zu gehören.

Immer den Kunden im Blick

Existenziell ist das vor allem deshalb, sagt Forrester, weil Erlebnisse und Erfahrungen von Kunden in Zusammenhang mit Internetplattformen und mobilen Lösungen darüber entscheiden, ob diese Kunden gehen oder bleiben.

Deshalb sei es so wichtig, Lösungen schnell in höchster Qualität zur Verfügung stellen zu können, und zwar absolut jede Art von Softwarelösung.

So wenige Abhängigkeiten wie möglich

Diese Ansprüche an Schnelligkeit und Nutzerfreundlichkeit lassen sich allerdings nur erfüllen, wenn außer dem Frontend auch das Datenmanagement im Backend den heutigen Anforderungen an Schnelligkeit und Benutzerfreundlichkeit genügt.

Hilfreich sei es dabei, unterschiedliche Anwendungsszenarien softwareseitig in parallel nebeneinander arbeitenden Lösungen abzubilden, das heißt diese Lösungen sollten so wenige gegenseitige Abhängigkeiten wie möglich aufweisen.

Mit agilen Verfahren verbindet sich regelmäßig die Hoffnung, dass sie traditionell hierarchische Strukturen in Unternehmen aufbrechen.
Foto: Bloomua - shutterstock.com

Nur so lassen sich unterschiedliche Kundenansprüche und unterschiedliche Releasezyklen adressieren. Und nur so können Unternehmen bei jeder anstehenden neuen Aufgabe, für die sie eine Lösung suchen, entscheiden, ob sie selbst entwickeln oder zukaufen wollen.

Nie aus den Augen verlieren dürfen Unternehmen dabei die Chance, jede Kundentransaktion zur Gewinnung von Daten zu nutzen. Und diese Daten sollten immer auch dazu dienen, die Performance der eigenen Lösungen zu verbessern.

Als Netzwerk organisierte Entwicklungsarchitektur

Wichtig ist - aus Sicht von Forrester - dass absolut sämtliche Anwendungen, mit denen der Kunde in Berührung kommt, intuitiv und ohne jede Art von Training nutzbar sind.

Ein zentraler Vorteil dieses Vorgehens ist, dass sich mit der unterschiedlichen Art, Software zu entwickeln, auch die Organisations- und Hierarchiestrukturen des entwickelnden Unternehmens verändert. Der Zusammenhang kann, wenn Unternehmen das wollen, ein ganz praktischer sein: Eine eher lose, als Netzwerk organisierte Entwicklungsarchitektur verschafft den Teams mehr Flexibilität und Freiheit.

Wenn große Organisationen sich darauf einlassen, verändern sich auch solche Strukturen, die mit dem eigentlichen Entwicklungsprozess gar nichts zu tun haben. Diese Chance sollten Unternehmen unbedingt nutzen, so Forrester.