DevOps – weil Development und Operations zusammengehören

Scrum DevOps
Von Sebastian Schneider // 20.02.2022 // 0 Kommentare

Agile Methoden und Frameworks sind in der Softwareentwicklung (Development) längst in größerem Umfang etabliert, aber mit dem in Betrieb (Operations) bringen der Umsetzung haben sich oft Lücken gezeigt. Eine ähnliche Vorgehensweise ist empfehlenswert, wenn es um diese Einführung und Überprüfung einer neuen Funktionalität geht. Die Kombination der Entwicklung und der Betrieb der Software ist unter dem Namen DevOps bekannt. Wie der Name nahelegt, geht es um die Verbindung beziehungsweise das Zusammenwachsen von Development und IT-Operations.

Eine Definition von DevOps 

Eine Standarddefinition gibt es nicht, die Grundidee stellt einen integrierenden Zusammenhang zwischen Entwicklung und dem Betrieb von Software her. Beide Bereiche wurden in der klassisch, traditionellen IT getrennt betrachtet. 

Der durch eine Integration erzielbare Fortschritt besteht darin, dass man beide Bereiche zum gegenseitigen Vorteil miteinander interagieren lassen kann. Das betrifft neben der Entwicklung und dem Betrieb insbesondere auch die Qualitätskontrolle

DevOps ist zuerst eine Denkweise, aus der heraus eine Unternehmenskultur entstehen kann. Diese ist als Voraussetzung notwendig, um darauf technische Abläufe aufsetzen zu können. Ein erstes und einfach zu erkennendes Merkmal besteht darin, dass für Entwicklung und Operations die gleichen Verfahren und Werkzeuge eingesetzt werden, ebenso wie die gleichen Menschen daran arbeiten.

Was ist der Ausgangspunkt für DevOps? 

Um das zu verstehen, kannst du den Gegensatz zu diesem Ansatz betrachten. Er besteht aus einer durchgeplanten Entwicklung. 

Am Anfang werden Ziele im Detail festgelegt. Diese werden in Zwischenziele aufgeteilt und auf einzelne Gruppen von Entwicklern verteilt. Sie arbeiten einen Entwicklungsschritt nach dem anderen ab und am Ende dieses Prozesses werden alle Teile zum Endprodukt zusammengesetzt. Es versteht sich fast von selbst, dass der Betrieb (also Operations) in diesem Prozess keine Rolle spielen und nur nach Abschluss der Entwicklungsarbeit das fertige Produkt und die Dokumentation erhält. 

Meistens endet hier das „Projekt“, es gilt als abgeschlossen, die Entwickler sind in neuen Projekten und meisten auch nicht mehr verfügbar, das erfolgt womöglich mit dem Hinweis, jetzt sei dieses Produkt in der Verantwortung der Operations-Abteilung. 

Dieses Vorgehen kann durchaus auch Vorteile haben, ist aber nicht für alle Projekte geeignet. Die Vorteile spielt es nur dort aus, wo sich Anforderungen wenig ändern, Klarheit über die Aufgaben existiert und Stabilität und Zuverlässigkeit im Vordergrund stehen (Beispiele: „System of Records“ oder „einfache“ Produkte auf dem Stacey Landscape Diagram). Wenn kaum Änderung in den Systemen herrscht, das Umfeld stabil ist und die Qualität das wesentlichste Kriterium ist, kann der Ansatz funktionieren. Updates und Anpassungen sind nur wenige erforderlich und diese erfolgen höchstens in größeren Zeitabständen. 

Das Ergebnis eines solchen Projekts ist das, was geplant wurde. Das ist solange kein Problem, wie das gewünschte Endergebnis von Anfang an bekannt ist und daher auch geplant werden kann (vgl. Stacey Landscape Diagram). 

Dein Problem beginnt dann, wenn diese Anforderungen sich aber doch ändern und du diese nicht mehr erfüllen kannst (z.B. „komplexer“ Bereich beim Stacey Landscape Diagram). Heute wirst du viel öfter mit sogenannten Systems of Engagement zu tun haben. Deine Kunden greifen direkt auf diese Systeme / Produkte zu und damit auf das Angebot Ihres Unternehmens (z.B. bei XaaS). Die Anforderungen an solche Systeme ändern sich viel schneller und darauf musst du reagieren können. 

Ideen zur Umsetzung flexibler Softwareentwicklung

Für Systems of Engagement und Produkten, die grundsätzlich stetigen Änderungen unterliegen, verwendest du agile Softwareentwicklung. Der Name legt die Art des Vorgehens nahe, für den also Beweglichkeit und das Reagieren auf Veränderungen im Vordergrund steht. Agile Teams verfolgen mit ihrem Vorgehen mehrere Ziele. 

  • Ein nutzbares Produkt soll möglichst schnell verfügbar und erlebbar werden. Es wird ausdrücklich akzeptiert, dass diese Version noch kein Endprodukt darstellen muss. Im Extremfall ist es ein MVP (Minimal Viable Product). 
  • Steht ein nutzbares Produkt zur Verfügung, wird dieses in Abstimmung mit den Kunden weiterentwickelt. Dieses Vorgehen kann oft auch mehrmals durchlaufen werden. Abstimmung und Entwicklung gehen Hand in Hand.
  • Die Entwicklungsschritte sind kurz gehalten, damit Feedback schnell genug eingeholt und eingearbeitet werden kann. Agile Teams sind üblicherweise selbstorganisierende Teams.
  • Dass oft Änderungen und Anpassungen vorgenommen werden müssen, ist kein Bug sondern ein Feature. Ein solches Vorgehen wird deshalb als normal angesehen, weil eben zu Beginn des Projekts nicht alle Anforderungen bekannt sind. Du solltest dir darüber im Klaren sein, dass auch der Kunde diese Informationen noch nicht verfügbar hat.

Agilität in der Softwareentwicklung folgt folgenden vier Leitprinzipien.

  • Interaktionen sind wichtiger als Prozesse.
  • Eine funktionierende Software ist wichtiger als eine umfassende Dokumentation. 
  • Der Kontakt mit Kunden ist wichtiger als Vertragsverhandlungen. 
  • Das Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans. 

Zu diesen Prinzipien gehört allerdings auch die Überzeugung, dass die als weniger wichtig bezeichneten Punkte keineswegs völlig unwichtig sind und einfach vernachlässigt werden können. Die Idee der Agilität stellt einfach eine Präferenz in den Raum und kein einfaches Patentrezept. Du wirst in deinem Unternehmen die Gewichtung dieser Punkte nach den dort herrschenden praktischen Gegebenheiten vornehmen. 

Was ist also die Aufgabe für agile Teams? 

Sie sollen die notwendigen Entwicklungsschritte für neue Softwareprodukte und neue Funktionen liefern. Im Gegensatz dazu ist es die Aufgabe der IT-Operations Teams, die Systeme am Laufen zu halten. Aus diesem Gegensatz ergibt sich oft ein mehr oder weniger großer Konflikt. DevOps kannst du dementsprechend als Ansatz zur Überwindung dieses Gegensatzes sehen. 

Scrum als Beispiel für die agile Softwareentwicklung 

Um agile Softwareentwicklung etwas detaillierter herausarbeiten zu können, betrachten wir das agile Framework Scrum. Es geht von folgenden Annahmen aus:

  • Ein Entwicklungsprozess ist in seinem Ablauf nicht vorhersehbar. Er ist zu komplex, um zu Beginn einen festgelegten Plan zu fassen. 
  • Implizites Wissen ist wesentlich. Diese Art von Wissen besteht zwar eben nicht aus in einer Datenbank speicherbaren Detailinformationen. Es ist vielmehr intuitiv und betrifft Abläufe und Prozesse, deswegen aber keineswegs weniger wichtig und kommt am besten in gegenseitiger Abstimmung zur Geltung.

Wird das Framework Scrum eingesetzt, werden die Mitarbeiter in verschiedene Rollen eingeteilt:

  • Product Owner: Dieser verantwortet die Anforderungen, die sich eben auch immer wieder ändern können. Als Owner gestaltet er also das Produkt und überprüft, in welchem Ausmaß die Ziele erreicht worden sind. Er sortiert das sogenannte Product Backlog.
  • Entwickler: Das sind Mitglieder des Scrum Team. Die Idee ist, diese Teams möglichst interdisziplinär zu besetzen. Spezialisten in den verschiedenen Fachgebieten ergänzen sich so gegenseitig. Als sinnvolle Teamgröße gilt eine Zahl von 3 bis 9 Mitgliedern. 
    Mit viel mehr Personen wird die Kommunikation untereinander schwierig und das ist ein wesentlicher Punkt von Scrum. Die Teams erhalten Vorgaben, können aber die Umsetzung in eigener Verantwortung festlegen. Der Scrum Master fungiert als Moderator, Coach und unterstützt die Abläufe zwischen seinen Team-Mitgliedern. 
  • Scrum Master: Dieser ist nicht etwa eine Art Leiter oder Chef eines Teams, sondern ist für die selbstorganisierende und eigenständige Methode und deine Organisation zuständig. Er koordiniert die Teams mit einem dienenden Führungsstil und behebt Störungen, gerade auch in der Kommunikation zwischen Product Owner und den Teams. Er gibt diesen Teams aber keine Anweisungen darüber, wie sie ihre Aufgaben umzusetzen haben. 

Die Herausforderung dieses Frameworks Scrum liegt darin, einen flexiblen Ansatz mit gerade so viel Struktur zu versehen, dass diese seine Umsetzung unterstützt. Der Arbeitsablauf von Scrum Teams wird in sogenannte Sprints (Zeitabschnitte) gegliedert. Diese dauern meist eine bis vier Wochen, sie beginnen mit Planung und enden mit der Review des Erreichten. Der springende Punkt eines Sprints ist, dass während seines Ablaufs keine Änderungen der Anforderungen zulässig sind, die das Sprint ziel gefährden. Diese Abwägung soll einen Ausgleich zwischen konzentrierter und zielorientierter Arbeit und vielen Chancen zur Anpassung der Ziele herstellen. 

Die Funktionsweise von DevOps 

DevOps möchte die agilen Abläufe in der Softwareentwicklung auch in den Betrieb dieser Software übernehmen. 

Entwicklung entsteht aus organisatorischen Abläufen und Werkzeugen, die sich auf eine Infrastruktur stützen. Die Idee der Agilität erkennt an, dass es sich dabei um einen dynamischen Prozess handelt, weil ständig neue Anforderungen aufgenommen und bewältigt werden müssen. 

Die IT-Operations bestehen aus der Administration von Systemen, die notwendigerweise nahe am Nutzer und seiner Erfahrung mit diesen Systemen ist. 

Für eine Verbindung dieser zwei Bereiche stellt DevOps die folgenden Prinzipien bereit:

  • Lösungen sollen möglichst in produktionsähnlichen Umständen getestet werden. Dazu wird das Team der Systemadministratoren eingebunden, das auf diese Weise Feedback über die Funktionsweise an die Entwickler melden kann. Das Operations-Team kann seinerseits die Umgebung früh auf ein in Entwicklung befindliches Produkt anpassen. 
  • Sichere Implementierung: Die sogenannte Delivery Pipeline wird dafür mit automatisierten Werkzeugen für Entwicklung und Tests versehen. Der Übergang von neuer Software zu ihrem Test und Einsatz läuft also zumindest zum Teil automatisch ab. 
  • Qualitätskontrolle: Auch diese findet ständig als rollender und kontinuierlicher Prozess statt. 
  • Feedback effektiv einsetzen: Alle Beteiligten sollen zu jeder Zeit Feedback einbringen können, wo immer es verfügbar ist. In dieser Arbeitsweise ist schnelle Innovation möglich, weil Erfahrungen sofort verwertet werden können. 

Voraussetzungen für DevOps 

Das Etablieren einer Unternehmenskultur

Diese unterscheidet sich wesentlich von einer Unternehmensstruktur, die von starren und umfangreichen Planungen ausgeht. Wenn du DevOps in deinem Unternehmen einsetzen möchtest, solltest du das Lernen durch Experimentieren fördern. 

Es ist auch von großem Vorteil, wenn nicht sogar notwendig, das Über-den-Zaun Schauen zu fördern. Implizit ist im Scrum Framework diese Idee durch das Bilden von interdisziplinären Teams bereits integriert. Es kann und soll aber auch eine Rolle in der Kommunikation verschiedener Abteilungen spielen. So darf hier auch kein Silo-Denken im Wege stehen.

Überwinden von Interessenkonflikten

Das Operations-Team kann ein System dann am zuverlässigsten betreiben, wenn es sich möglichst wenig ändert und keine neuen Funktionen integriert werden müssen. Das Interesse liegt bei Operations damit auf Stabilität und Verfügbarkeit von Systemen oder Produkten. Auf der anderen Seite möchten Entwickler tendenziell neue Funktionen implementieren, denn sie werden danach beurteilt, wie gut das System oder Produkt beim Kunden ankommt. Sie haben damit eher das Interesse daran, die Verantwortung für das korrekte Funktionieren dem Operations-Team zu zuschanzen und sich rein auf die Entwicklung zu fokussieren. 

Besser ist es, wenn du beiden Teams die gemeinsame Verantwortung für eine schnelle und zuverlässige Bereitstellung von Funktionen überträgst. Dazu gehört durchaus, sich auf die wichtigsten solchen Funktionen zu beschränken oder sie zumindest zu priorisieren. Auch hier zeigt sich wieder der wesentliche Punkt von DevOps in der Integration dieser zwei Zugänge. 

Wesentliche Elemente von DevOps 

Der Zyklus

In groben Zügen kann der DevOps-Ansatz als Zyklus beschrieben werden. Er beginnt mit der Planung, die einen agilen Ansatz verfolgen wird. Darauf folgt die Erstellung des Quellcodes, für die üblicherweise ein automatisches Versionskontroll-Werkzeug wie Git benutzt wird. Darauf wird der Code in die Auslieferung integriert und damit für den Betrieb freigegeben. 

Überwachung und Feedback schließen den Zyklus, der mit der Planung der notwendigen Korrekturen und Änderungen neu beginnen kann. 

Delivery Pipeline

Diese beschreibt den Ablauf der eigentlichen Entwicklungsarbeit. Die Details werden natürlich auf die genauen Anforderungen und Gegebenheiten deines Unternehmens angepasst. Zu erwarten ist aber auf jeden Fall die Verwendung einer IDE (integrierten Entwicklungsumgebung) und zur Verbindung der Arbeit mehrerer Entwickler ein Versionskontrollsystem wie das bereits erwähnte Git. In der Build-Phase werden aus dem so erstellten Quellcode die Binärdateien erzeugt und getestet. 

Dieses Testen verwendet im DevOps-Ansatz automatisierte Tools. Zu diesen gehört insbesondere auch Virtualisierung, also eine Art Simulation eines Prozesses auf einem geeignet programmierten Rechner. 

Eine solche Virtualisierung ist besonders nützlich für die Darstellung von Komponenten, die sonst nicht einfach verfügbar sind. 

Der Test muss aber das Zusammenwirken des Endprodukts auch mit diesen Komponenten umfassen. Zu den wesentlichen Zielen von DevOps gehört, dass diese Pipeline reibungsloser und schneller funktioniert als mit einem Ansatz zu globaler Planung am Beginn eines Projekts.

Testen in Produktionsumgebung

Dieser Aspekt wird der Erfahrung nach nicht immer so einfach möglich sein. Du wirst aber eine der Produktion möglichst ähnliche Umgebung wählen wollen. Dafür sind Dienste aus der Cloud nützlich, in der die geforderte Umgebung oft viel einfacher bereitgestellt werden kann als auf eigenen Servern. 

Microservices

Als weiteres technisches Element existieren Microservices, also individuell programmierte Dienste, auf die alle Programme in einem Projekt zugreifen können. Diese Microservices sind für DevOps nicht notwendig, sie lassen sich aber sinnvoll in diesen Ansatz integrieren. 

Vorteile von DevOps

DevOps bietet viele Aspekte, die bei der Softwareentwicklung und bei der Projektplanung klare Vorteile bringen für alle Beteiligten. Im Folgenden werden die positiven Auswirkungen in dem Sinne näher beschrieben.

Einbindung aller Stakeholder

Alle Parteien mit Interesse am Projekt können und sollen schon von Beginn an in den Ablauf integriert werden. Neben den Entwicklern selbst und dem Operations-Team sind das auch Partner, Zulieferer, Kunden und alle Geschäftssparten in Ihrem Unternehmen, die mit diesem Projekt zu tun haben oder zu tun haben werden. 

Beherrschung der Komplexität.

Heutige Unternehmensanwendungen erstrecken sich auf verschiedene Technologien und stützen sich fast notwendigerweise auf eine intensive Vernetzung von Komponenten. Das bringt eine Komplexität mit sich, die mit zentraler Planung kaum mehr unter Kontrolle gehalten werden kann. DevOps ist ein Ansatz, der diesem Umstand Rechnung trägt. 

Stärkung der Innovationsfähigkeit. 

Wird wenig Verwertbares schnell verworfen, werden Ressourcen für vielversprechende Ansätze frei. Diese Wirkung von schnellem Feedback und sofortiger Reaktion darauf legt also mehr Kreativität und Innovation frei. 

Schnellere Wertschöpfung

Ist ein verwertbares Produkt schnell erstellt, erhältst du nicht nur schnelles Feedback. Du hast auch schneller ein Produkt, das wirtschaftlich verwertbar ist, auch wenn es sich um eine erste Version handelt (vgl. auch WSJF und Verzögerungskosten)

Vorteile für Kunden

Weil die Kunden von Anfang an mit einbezogen werden, fühlen sie sich ernst genommen und entwickeln eine stärkere Kundenbindung. Feedback an die Entwickler des von ihnen in Zukunft verwendeten Produkts macht es wahrscheinlicher, dass sie an Bord bleiben und das so entstehende Endprodukt auch erwerben und verwenden.

Eine kurze Zusammenfassung

DevOps ist ein Begriff, der eine Kultur der Zusammenarbeit zwischen Softwareentwicklern und dem Betrieb (Fachleute) oft innerhalb der Informationstechnologie beschreibt. Ziel ist es, die Zeit für die Bereitstellung von Softwareänderungen zu verkürzen, indem die Barrieren zwischen Softwareentwicklung und IT-Betrieb abgebaut werden. DevOps zielt auch darauf ab, die Qualität der Softwarebereitstellung zu verbessern und die Geschwindigkeit der Problemlösung zu erhöhen.

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>