Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Ratgeber

Scrum oder Devops? Beides!

(Foto: Shutterstock)

Obwohl Scrum immer noch das mit Abstand meistgenutzte agile Vorgehensmodell ist, wird Devops bereits als sein Nachfolger gehandelt. Dabei ergänzen sich beide Systeme perfekt, findet unser Gastautor.

Scrum ist inzwischen 23 Jahre alt und in einer Zeit entstanden, die – in unserer Branche – fast vorsintflutlich anmutet. Kein Wunder also, dass inzwischen die ersten Nachfolger am Start stehen. Devops gilt dabei als aussichtsreicher Kandidat. Aber wie unterscheiden sich beide Modelle eigentlich und könnten sie sich vielleicht auch gut ergänzen? Tatsache ist, dass aufgrund von Missverständnissen Scrum und Devops oft als konkurrierende Methoden betrachtet werden:

1. Missverständnis: „Mit Scrum kann man nur alle zwei Wochen eine neue Version liefern“

Bei Devops geht es um das häufige Liefern von neuen Versionen mit kleinen Verbesserungen. In entsprechenden Fallstudien werden oftmals mehrere Releases pro Tag erwähnt. Scrum kennt zwar keine minimale Zeit für den Planungs-Zyklus (Sprint), jedoch macht es in der Praxis nur selten Sinn, diese kürzer als eine Woche zu wählen. Eignet sich damit Scrum nicht für Continuous Delivery, also der kontinuierlichen Auslieferung neuer Funktionen? Wenn man den Scrum-Guide genau liest, stellt man fest, dass Scrum die Bereitstellung eines sogenannten Done Increments, also einer auslieferbaren Produktversion spätestens am Ende jedes Sprints fordert. Es gibt jedoch keine Regel, die verbietet, während des Sprints auch häufiger ein solches Done Increment bereitzustellen und auch auszuliefern, also gerne auch mehrfach am Tag.

2. Missverständnis: „Devops ist Automatisierung des Deployment-Prozesses“

Ein wichtiger Aspekt von Devops ist, daran zu arbeiten, den oben beschriebenen Devops-Zyklus so schnell und so häufig wie möglich durchlaufen zu können. Das ist nur möglich, wenn ein großer Teil der Abläufe wie zum Beispiel Build, Test, Release und Deployment automatisiert sind. Devops aber auf die Einführung entsprechender Tools zur Automatisierung zu begrenzen, würde bedeuten, den größten Teil des Verbesserungspotenzials außen vor zu lassen. Devops beginnt zunächst mit einem Mindset, mit der systemischen Betrachtung des gesamten Erstellungs- und Betriebsprozesses für Softwareprodukte mit dem Ziel, für die Anwender ein möglichst positives Benutzererlebnis zu schaffen. Dafür müssen unterschiedlichste Perspektiven berücksichtigt werden und verschiedene Konzepte müssen ineinandergreifen. Aus dieser Gesamtbetrachtung entsteht dann an verschiedenen Stellen ein Automatisierungsbedarf, der wiederum Tools notwendig macht. Devops also mit Tools zu beginnen, wäre wie das Pferd vom Schwanz her aufzuzäumen.

Scrum und Devops ergänzen sich

Scrum stellt ein Framework dar, das Rahmenbedingungen für die Planung und Umsetzung von Software-Produkten bis zur Bereitstellung eines auslieferfähigen Inkrements definiert. Mit Devops soll die Zusammenarbeit zwischen verschiedenen Verantwortungsbereichen optimiert und mit möglichst kurzen Feedbackzyklen eine bedarfsgerechte Fokussierung der Entwicklungsinvestitionen erreicht werden. Beide Konzepte entsprechen somit der Philosophie agiler Entwicklung und können sich gut ergänzen. Wie könnte denn nun ein solches kombiniertes Vorgehen aussehen? Das soll anhand eines fiktiven Teams kurz skizziert werden, wobei es sich dabei nicht um eine Blaupause handelt, sondern lediglich als Inspiration dienen soll. Jedes Team muss hier die passende Vorgehensweise für sich selbst finden.

Ein Beispiel: Unser fiktives Team hat ein Product-Backlog, in dem alle möglichen Verbesserungen am Produkt gesammelt werden. Der Product-Owner versucht dabei, die Themen zu identifizieren, die ein optimales Kosten-Nutzen-Verhältnis haben. Das Development-Team hat ein tiefgreifendes Verständnis darüber, wie die Anwender das Produkt nutzen, da es nicht nur für die Implementierung, sondern auch für den Betrieb und den Anwender-Support verantwortlich ist. Product-Owner und Development-Team legen für jeden Sprint ein sogenanntes Sprint-Goal fest, ein Fortschritt, der am Ende des Sprints erreicht werden soll. Gemeinsam suchen sie nach der schnellsten und einfachsten Lösung zu diesem Ziel, um erste Erfahrungen zu sammeln und die so entstandene rudimentäre Lösung dann mit diesen neuen Erkenntnissen sukzessive auszubauen.

Das Development-Team implementiert nun die einzelnen Funktionen, die zur Erreichung des Sprint-Goals erforderlich sind. Dabei fokussiert sich das Team mit seinen interdisziplinären Kompetenzen auf die Fertigstellung einer Funktion statt gleichzeitig an vielen verschiedenen Stellen zu arbeiten. Ist die Funktion fertiggestellt und getestet, so wird sie umgehend auf das Produktivsystem ausgeliefert. Dabei nutzt das Team Techniken wie Feature-Flags und Blue-Green-Deployment. Damit kann die neue Funktion zunächst einem kleinen Anwenderkreis bereitgestellt werden und erst wenn dort keine Probleme auftreten, wird der Kreis der Nutzer erweitert. Bei Problemen wird die Funktion umgehend abgeschaltet und die Anwender können wieder ein stabiles System nutzen. Der Product-Owner ist im Entstehungsprozess kontinuierlich einbezogen. Treten im Betrieb kritische Probleme auf, so kümmert sich das Development-Team umgehend darum. Mit seinen interdisziplinären Kompetenzen aus Infrastruktur und Software kann eine Analyse und Behebung des Problems zügig umgesetzt werden. Noch wichtiger ist allerdings die anschließende Ursachenanalyse, um ähnliche Probleme zukünftig zu vermeiden und den Gesamtprozess robuster zu machen. Diese Erfahrungen wiederum werden auch die Art und Weise der Implementierung beeinflussen.

Am Ende des Sprints findet ein Sprint-Review statt. Dabei fasst das Scrum-Team nochmals zusammen, welche Funktionen in diesem Sprint ausgeliefert werden konnten. Das Ziel dabei ist es, Feedback von den Stakeholdern zu bekommen. Mit diesen Erkenntnissen kann entschieden werden, mit welchen Erweiterungen im nächsten Sprint der Mehrwert des Produktes optimal erweitert werden kann.

Scrum und Devops nicht nur für Web-Startups

Den hier beschriebenen Ablauf kann man sich gut in einem sehr kleinen Unternehmen, etwa in einem Startup, vorstellen. Dort gibt es meist keine klare Abgrenzung der Zuständigkeiten. Alle Beteiligten arbeiten Hand in Hand, um das gemeinsame Produkt und damit die gemeinsame Vision erfolgreich zu gestalten. Jeder bringt hierfür seine Erfahrungen und Kompetenzen ein und legt dort Hand an, wo es gerade notwendig ist. Mit Scrum und Devops können aber auch größere Unternehmen beginnen, eine solche Kultur zu entwickeln. Hierzu ist es meist notwendig, dass nicht nur die Unternehmensstruktur neu definiert wird, sondern auch die Produktmodularisierung muss dazu passen. Bei Unternehmen, die mit einer Devops-Kultur komplexere Produkte mit mehreren Teams entwickeln, beobachtet man häufig eine Architektur, die eine End-to-End-Verantwortung der Teams begünstigt. So wird das Produkt in einzelne Teilbereiche aufgegliedert, für die ein Team dann komplett verantwortlich ist – von der UI bis zur Persistierung der Daten, von der Definition von Mehrwerten durch das Teilmodul bis zum reibungslosen Betrieb.

Devops bedeutet damit viel mehr als nur die Lieferung von neuen Software-Inkrementen in kurzen Zyklen. Es bedeutet die Ausdehnung von agilen Prinzipien auf den Unternehmenskontext und lässt sich somit hervorragend mit Scrum kombinieren.

Mehr über agile Entwicklungsmethoden und deren Einsatz in der Praxis erfahrt ihr auf der Developer Week vom 25. bis 28. Juni 2018 in Nürnberg. Die Developer Week ist seit Jahren die Anlaufstelle für die deutschsprachige Entwickler-Szene und eine der größten, unabhängigen Entwickler-Konferenzen Europas mit über 130 Referenten und mehr als 170 Sessions in 30 Thementracks. Informationen und Anmeldung unter www.developer-week.de

Finde einen Job, den du liebst

Bitte beachte unsere Community-Richtlinien

2 Reaktionen
office11

Hää? Wasndas für ein Titel?!??
Scrum ist eine Methode der Arbeitsorganisation, Devops ein Aufgabengebiet. Was soll sich da ausschließen?

Demnächst auf T3N:
"Bananen oder Geophysik? Beides!" ... "Turnschuhe oder Verfassungsschutz? Beides!"

...
Macht mal halblang mit dem Kiffen. :-)

Antworten
Thomas Schissler

Der Begriff DevOps wird tatsächlich sehr unterschiedlich interpretiert. Ihn aber auf ein "Aufgabengebiet" zu reduzieren, schränkt das Potenzial sehr ein. DevOps ist in erster Linie ein Mindset, dass durch eine enge Zusammenarbeit, kurze Lieferzyklen und eine Feedback-Kultur bessere Produkte entstehen. Der Titel drückt aus, was ich in vielen Gesprächen erfahren habe - die Frage ob Scrum noch relevant ist oder ob DevOps Scrum ablösen wird. Diese Frage entsteht auch durch Unklarheit der jeweiligen Begrifflichkeiten was durch die verschiedenen Interpretationen des DevOps-Begriffs nicht gerade besser wird.

Antworten

Melde dich mit deinem t3n-Account an oder fülle die unteren Felder aus.

Abbrechen