< zur Übersicht

Schon seit einiger Zeit gibt es einen Hype um Abkürzungen, die neben DEV und OPS diverse Buchstabenvarianten dazwischen enthalten. Nicht nur Sie fragen sich, „ … brauche ich das, betrifft mich das auch?“

Zur Beantwortung könnten Sie oder zuständige Personen in Ihrem Unternehmen zum Beispiel folgende Aspekte prüfen:

• Der Vertrieb/Anforderer will ständig neue Funktionen, das Entwicklungsteam will auch, aber das Betriebsteam braucht eine Woche zur Vorbereitung und Durchführung der Installation?
• Das Entwicklungsteam hat geliefert, aber das Betriebsteam scheitert bei der Installation?
• Die Software wurde getestet, aber Fehler oder Systemabbrüche im Produktionsbetrieb führen zu wechselseitigen Schuldzuweisungen zwischen Entwicklungsteam und Betriebsteam?
• Es gibt fortlaufend neue Anforderungen/Bedarfe aus dem Vertriebsteam, aber die Entwicklung dauert zu lange?
•  Von Produktidee bis Umsetzung vergeht zu viel Zeit, der Markt oder Wettbewerber ist schneller?
• Sicherheitslücken in der Software werden erst nach Inbetriebnahme festgestellt?
• Das Betriebsteam kann nur noch „Feuer löschen“, aber keine Verbesserungen oder Neuerungen für die Systeme und Services einbringen?

Wenn Sie diese oder ähnliche Fragen bzw. Probleme haben, dann sind die Abkürzungen rund um DEV (= Development, Entwicklung) und OPS (= Operations, Betrieb) weiter nur Abkürzungen, ABER der damit verbundene Lösungsansatz über cross-funktionale Zusammenarbeit, Automatisierung von wiederkehrenden Prozessen und Aufgaben sowie Erfolgsmessung von z. B. Release-Zyklen ist für Sie und Ihr Unternehmen auf jeden Fall relevant.

Wie einsteigen? 

Es ist wie meist im Leben – es scheitert schon an der Kommunikation über das Problem: Wenn Vertreter von Software-Entwickler und Software-Betriebspersonal Begriffe wie „Change“, „Version“, „Release“, „Deployment“ verwenden, dann meinen sie eventuell etwas Ähnliches, aber nicht unbedingt dasselbe. 

Als ersten Schritt zu einer erfolgreichen Zusammenarbeit an der Problemlösung empfehlen wir, gemeinsam mit den am Entwicklungs- und Inbetriebnahme-Prozess Beteiligten, also im Wesentlichen

• Anforderungsmanager/innen,
• Software-Entwickler/innen,
• Tester/innen,
• Build-Manager/innen,
• Betriebsverantwortliche/Applikations-Manager/innen,
• Security-Verantwortliche,
• Software-Projektleiter/innen,
• ggf. System-Architekten/-Architektinnen sowie
• ggf. Enterprise-Architekten/-Architektinnen

anhand des üblichen Software-Bereitstellungsprozesses (siehe Grafik)

• je Prozessschritt wesentliche Begriffe zu benennen und zu erklären,
• von jedem Rollen-Vertreter für jeden Prozess-Schritt vorurteilsfrei die Erwartungen abzufragen. (Ja, es kann ein, dass Anforderer wenig Know-How über Software-Betriebsprozesse haben (aber: Erwartungen haben sie trotzdem und können diese auch formulieren),
• jeweils gemeinsam die benötigten Rollen, Aufgaben und Bedingungen zu benennen, um diese Erwartungen erfüllen zu können. 

 

Anhand dieser Erkenntnisse können schon erste Ideen für Verbesserungsmaßnahmen und notwendige Rollen/Skills für das DevOps-(Kern-)Team zusammengestellt werden. (Kern-Team deshalb, um den DevOps-Ansatz mit einer Applikation zu verproben und bei Erfolg für weitere Applikationen anzuwenden, das Kern-Team wird als Multiplikator tätig.)

In einem zweiten Schritt können für die Prozessschritte jeweils aktuell genutzte Tools und Hilfsmittel sowie Kommunikations-wege/-kreise und aktuell etablierte Entscheidungsgremien zusammengestellt werden. Es gibt sicher Gründe dafür, dass die eingesetzten Tools nicht von allen verwendet werden. Zusammenarbeit bedeutet auch Transparenz und Verständnis für die Aufgaben des jeweils anderen. Über eine Diskussion zu den Möglichkeiten, zumindest in einzelnen Prozessschritten ein von allen genutztes Tool zu verwenden, kann der Aufbau einer Tool-Kette gestartet werden. Nur so können  alle Bedarfe zusammengeführt und priorisiert abgearbeitet werden.

Ein dritter Schritt ist nun, eine geeignete Applikation, ein geeignetes Vorhaben für den DevOps-Start zu finden, um Kommunikationswege, Prozessschritte, notwendigen Entscheidungsspielraum zu etablieren und notwendige Maßnahmen für eine Verkürzung der Prozess-Laufzeiten zu erarbeiten. Wenig oder gar nicht geeignet sind über Jahrzehnte gewachsene, kaum oder schlecht dokumentierte „Bestandssysteme“. Im besten Fall kann schon für die gewählte Applikation überlegt werden, wie angestrebte Verbesserungen messbar werden.

Als vierter Schritt sollten für die Messbarkeit der angestrebten Verbesserungen schon hier Messgrößen (KPIs / Key Performance Indicators) festgelegt und technische Möglichkeiten zur Messung dieser Größen gefunden werden.

Voraussetzung für den Erfolg – das Commitment der Führungsetage: Führungskräfte und bestmöglich auch ein „Sponsor“ unterstützen das Vorgehen und den Personaleinsatz, geben dem DevOps-Team den notwendigen Entscheidungsfreiraum für Aktivitäten und Kommunikation.  

Ansätze zur praktische Umsetzung 

Schritt 1: Ist-Situation, erste Handlungsbedarfe erkennen

Hilfreich ist es sicher, dieses über mehrere vorbereitete und moderierte Workshops durchzuführen und Vorgehen sowie Ergebnisse zu dokumentieren. Vermeiden Sie dabei unbedingt Stress und Anschuldigungen. „Vergangenheitsbewältigung“ ist kein Thema in diesen Workshops; es geht um Zusammenarbeit im Team und gemeinsame Verantwortung.

Schritt 2: Aufbau einer Tool-Kette beginnen

Nach Zusammenstellung der aktuell je Prozessschritt genutzten Tools und Hilfsmittel, Kommunikations-wege/-kreise und Entscheidungsgremien kann zunächst das Anforderungsmanagement in einem Tool zusammengeführt werden. Das bedeutet, dass alle funktionalen und nicht-funktionalen Anforderungen in einem Tool erfasst, priorisiert und zur Bearbeitung zugewiesen werden können – und das Software-System-unabhängig. Wichtig ist, dass auch alle betrieblichen Aufgaben wie Software-Updates und andere Wartungsaufgaben in diesem Tool erfasst, priorisiert und zugewiesen werden können.

Die Kommunikations- und Entscheidungswege werden so angepasst, dass Verantwortliche aus allen nun zusammengeführten Anforderungsbereichen beteiligt werden und die Priorität der Abarbeitung, ggf. auf Basis einer Entscheidungsmatrix, festlegen.

Schritt 3: Applikation/Vorhaben, erste Maßnahmen festlegen

Für die Erprobung und Etablierung des DevOps-Ansatzes wird die Weiter- oder Neuentwicklung einer Applikation gewählt, deren Personalbedarf und System-Abhängigkeiten (Stichwort Schnittstellen) überschaubar sind, und deren Verantwortliche/Beteiligte Neuem offen gegenüberstehen. „Überzeugen durch Erfolg“ und nicht „Überzeugen durch Zwang“ ist das Motto.

Nach Auswahl der Applikation gibt es folgende mögliche Maßnahmen für einen DevOps-Ansatz:

• Anforderungsmanagement in einem Tool,
• Aufbau einer Continuous Delivery Pipeline durch
• Konfigurationsmanagement mit Sourcecode-Check-Out / -Check-In,  
• Software-Deployments auf Knopf-Druck,
• Automatisierungsmaßnahmen, wie z. Bsp.
• automatische Tests mit einem Minimal-Set an Testfällen nach jedem Software-Deployment,
• automatische Funktionstests bei Software-Check-In und vor Übernahme in die Deployment-Version,
• automatische Tests beim Deployment inkl. Deployment-Abbruch fehlerhafter Komponenten und Fehlerzuweisung.

Wie bereits oben erwähnt, sind jahrelang gewachsene, kaum dokumentierte Bestandssysteme nicht geeignet für erste DevOps-Maßnahmen. Falls es nur solche „monolithischen“ Systeme geben sollte, dann könnte als Ansatz das Herauslösen von Funktionsbausteinen mit APIs überlegt werden.

Schritt 4: Erfolgsmessung

Wie bei jeder neuen Vorgehensweise ist die Durchsetzungskraft vom Erfolg der Startphase abhängig. Daher ist es hilfreich, ausgehend von der Zielstellung Erfolgsparameter (Messgrößen) für die angestrebten Verbesserungen zu finden, die je nach Vorhaben für eine Erfolgsbewertung – auch außerhalb des DevOps-Teams – geeignet sind und auch nicht mit vielen Worten erklärt werden müssen.

Für die Messbarkeit sind Messgrößen (KPIs / Key Performance Indicators) sowie Messpunkte, also  technische oder organisatorische Möglichkeiten zur Messung dieser Größen, festzulegen, ggf. auch zu implementieren und kontinuierlich auszuwerten. 

So können z.B. je nach Problemstellung folgende Messungen – im besten Fall automatisiert - durchgeführt werden:

• Durchlaufzeiten von der (Produkt-)Anforderung bis zur Produktiv-Setzung,
• Anzahl an Software-Deployments,
• %-Zahl fehlerhafter Software-Deployments,
• Anzahl an neuen Software-Funktionen,
• Anzahl der Fehler in einer Software,
• Anzahl automatischer Tests,
• Zufriedenheit der DevOps-Team-Mitglieder.

Sie können so nachweisen, dass der Lösungsansatz und die Vorgehensweise zu einer kontinuierliche Verbesserung führen. Und weitere DevOps-Vorhaben sowie ein breiterer Anwenderkreis lassen sich so sicher auch gewinnen.

Über allem steht: Commitment, Team-Verantwortung und Kommunikation

Sofern für die vorbereitete DevOps-Maßnahme noch ein Commitment der „Führungs-Etage“ erforderlich ist, kann dieses durch die Benennung eines Kernteams, die Zusammenfassung der Zielstellung, durch Abschätzung des erforderlichen Aufwands/des Budgets und geeignete Berichtstermine zum Fortschritt erreichen.

Zum Kernteam gehören nicht alle in die vorherigen Schritte einbezogenen DevOps-Team-Mitglieder, sondern diejenigen, die auf Basis der Vorbereitung zwingend für die erfolgreiche Durchführung der Maßnahme erforderlich sind und die Ergebnisverantwortung übernehmen. Weitere DevOps-Team-Mitglieder werden bei Bedarf hinzugezogen. Der erforderliche Personalaufwand sollte so kalkulierbar sein. 

Für die Zusammenarbeit empfehlen wir „agile“ Kommunikationsformen, also kurze Daily-Meeting-Termine, im besten Fall auch ein Sprint-basiertes Vorgehen mit Planungs- und Ergebnis-Review-Terminen. Entscheidungen sollten vom Kernteam vorbereitet und mit allen im DevOps-Team geprüft und ggf. angepasst werden. So getroffene Entscheidungen werden  nachvollziehbar dokumentiert.

Über Unternehmens-interne Blog-Artikel, ein Projekt-Wiki o.ä. lassen sich der Zweck, das Vorgehen und bestmöglich auch erfolgreiche Zwischenergebnisse und die Begeisterung über den Modus der DevOPs-Zusammenarbeit kommunizieren und so Nachahmer für weitere Maßnahmen zur Verbesserung von Prozessen gewinnen. 

< zur Übersicht