SCHNELLER UND AGILER MIT DEVOPS? TEIL 1 - EIN VERGLEICH MIT KLASSISCHEN METHODEN UND SCRUM

DevOps wird als Arbeitsmethode in der Softwareentwicklung eingesetzt, um die Zusammenarbeit zwischen den IT-Teams in der Entwicklung und im Betrieb zu verbessern. Auf diese Weise soll die Bereitstellung neuer Produkte und Projekte beschleunigt werden. Doch was macht dieses Modell so besonders? Was zeichnet es aus und wo liegen seine Schwächen? Im ersten Teil seines Blogbeitrags betrachtet Florian Hieber DevOps im Vergleich zu klassischen Projektmanagement-Methoden und der agilen Vorgehensweise SCRUM.

Was genau ist DevOps?

DevOps beschreibt ein Betriebsverfahren (Vorgehensmodell) für die Entwicklung und den produktiven Betrieb von IT-Systemen. Der Name setzt sich aus Dev (Development) und Ops (Operations) zusammen und zeigt damit schon verbal die größte Neuerung dieses Ansatzes auf. Die IT-Administratoren (operativer Betrieb) und die Entwickler arbeiten von Anfang an zusammen. Dadurch ist der Übergang von Entwicklung und Betrieb fließender und kann viel schneller vollzogen werden. Gleichzeitig soll die Qualität verbessert werden und es können und sollen im Betrieb die Entwicklungszyklen verkürzt und somit Kosten gespart werden.

Woher kommt DevOps?

Im klassischen Projektmanagement wurde (und wird) bei einer Entwicklung das Projekt geplant und dann nach diesem Plan entwickelt. Vorteil ist hier die Kosten- und Zeittransparenz. Dieser Vorteil kann sich jedoch als Nachteil erweisen, sobald die Projekte an Komplexität zunehmen. Oft kommt es zu Fehlkalkulationen in den Zeit- und/oder Kostenplanungen. DevOps geht hier einen anderen Weg und versucht erst gar nicht, Zeiten oder Kosten zu schätzen, wie alle agilen Ansätze. Im klassischen PM steht das Projekt an sich im Vordergrund, deshalb gibt es im Team auch viele unterschiedliche Rollen und Hierarchien.

Unterschied von DevOps zu Scrum

In der agilen Vorgehensweise nach SCRUM steht nicht das Projekt, sondern das Produkt im Fokus. Das Team der Produktentwickler verwaltet sich autark und wird nur durch einen SCRUM Master unterstützt, der entwicklungshemmende und störende Faktoren von außen beseitigen soll. Ansonsten wird das Produkt rein nach den Vorgaben des Produktbesitzers (Product Owner) entwickelt. Der Product Owner holt sich die Funktionalitäten und deren Priorisierung von den Nutzern des Produktes (User Stories), bewertet sie und legt sie in einer Liste ab. Das Team entscheidet mit dem Besitzer, welche Funktionen im nächsten Zyklus (Sprint) bearbeitet werden. Die Abnahme durch den Product Owner am Ende des Zyklus wird durch eine genaue Definition am Anfang der Entwicklung beschrieben (Definition of done). Dadurch ist sichergestellt, dass zu jedem Zeitpunkt jeder unter der Funktionalität (beschrieben in einer User Story) das Gleiche versteht. Innerhalb eines Zyklus (Sprint) wird die Funktionalität nicht geändert, sondern es werden nur die Änderungen vorgenommen, die vorher festgelegt wurden.

Basis des Models DevOps ist die iterative Entwicklung anhand eines Prototyps. 1991 wurde „Rapid Application Development“ mit Prototyping erstmalig vorgestellt. Ganz so neu ist die Idee also nicht, wurde aber 2008 dann als Modell DevOps verfeinert und ist auch ein Ansatz von agilem Vorgehen.

Agile Softwareentwicklung als Allheilmittel?

Im Laufe der Jahre wurden jedoch beim Umgang mit den agilen Vorgehensmodellen einige Schwächen entdeckt. Der Übergang in den Betrieb bleibt auch mit agiler Entwicklung ein herausfordernder Schritt im Prozess. Die Administratoren bringen neue Blickwinkel ein. Sie betrachten das Produkt nicht mehr aus Entwicklungssicht und auch nicht aus der Sicht der Benutzer. Sie betrachten das Produkt aus der Perspektive Sicherheit, Server/ Netzwerkbelastung, Interaktion mit anderen Prozessen, Installation, Konfiguration und Health-Monitoring. Eine Sichtweise, die von den Entwicklern, auch in agilem Vorgehen, nicht Bestandteil einer User Story ist. Einzige Ausnahme wäre es, wenn die Administratoren auch User Stories erstellen dürfen.

Die eigentlichen Entwicklungszyklen sind bei DevOps durch die Verschmelzung von Produktion und Entwicklung deutlich kürzer (bis zu mehreren Zyklen pro Tag) als bei der agilen Entwicklung (die Dauer der Sprints liegt zwischen sieben Tagen und vier Wochen). Daneben werden die Anforderungen aus dem Betrieb gleich mit in das Produkt eingearbeitet.

Welche Voraussetzungen für eine erfolgreiche Umsetzung von DevOps notwendig sind, welche Vorteile sich ergeben können und welche Herausforderungen in der Praxis zu bewältigen sind, werde ich im zweiten Teil meines Blogartikels betrachten.