© Aleksandr Gavrilychev/Shutterstock.com
Teil 1: Agile und DevOps - Ansätze im Überblick

Gegner oder Freunde?


Agile und DevOps sind Konzepte und Trends gleichermaßen. Sie stehen für eine maximale Flexibilisierung der Projektarbeit und das Zusammenwachsen von Development und Operations. Gibt es eine Schnittmenge zwischen diesen beiden Ansätzen?

Die agile Vorgehensweise – mit dem Ziel einer geplanten Flexibilität des Entwicklungszyklus – und DevOps – als die Zusammenarbeit von Development und Operations – sind umfassende Bausteine einer Transformation der Informationstechnologie im Allgemeinen und der Softwareentwicklung als wichtige Teildisziplin im Speziellen. In vielen Beiträgen findet man agile Methoden ausführlich beschrieben. Es gibt kaum einen Entwickler, der damit noch nicht in Berührung gekommen ist. Ausgangspunkt war die Notwendigkeit, den Entwicklungsprozess deutlich flexibler zu gestalten. Statt mit ungeplanten Überraschungen durch sich ändernde Anforderungen konfrontiert zu sein, wollte man sich auf diese Ereignisse bestmöglich vorbereiten und damit die Änderung zur Norm erklären. Eine ähnlich simple Erklärung gibt es für DevOps. Konnte man traditionell die Entwicklung einer Software (Development) von ihrem Betrieb (Operations) trennen, ist das schon lange nicht mehr zeitgemäß. Sich immer weiter verkürzende Releasezyklen erfordern ein Zusammenarbeiten über die Grenzen der eigenen Abteilung hinaus. DevOps können wir also verkürzend als eine Kulturrevolution der gesamten IT-Landschaft begreifen. Und an welcher Stelle ist die Schnittmenge zwischen beiden Konzepten? Das wollen wir hier untersuchen. In einer zweiteiligen Artikelserie wollen wir die Zusammenhänge zwischen agilem Vorgehen und DevOps-Ansatz herausarbeiten.

Nach einem kompakten Überblick über die agilen Methoden skizzieren wir den Grundgedanken der DevOps-Bewegung, die mehr mit Organisation als mit Technik zu tun hat. Anschließend geht es darum, die Schnittmengen beider Konzepte herauszuarbeiten und zu erkennen, an welcher Stelle die Chancen, aber auch mögliche Stolpersteine der Zusammenarbeit liegen. Beginnen wir mit den agilen Methoden der Softwareentwicklung.

Flexibilität durch agile Methoden

Bekanntermaßen ist die strikte Abarbeitung eines Entwicklungsvorhabens streng nach Phasen gestaffelt eher schwierig. Das Hauptproblem besteht darin, dass eine vollständige und korrekte Erhebung der Anforderungen zu Projektbeginn nahezu unmöglich ist. Das hat mehrere Ursachen. Die wichtigsten sind:

  • Unvollständigkeit der Anforderungen zu Beginn des Projekts

  • dynamische Änderungen in den Geschäftsmodellen während der Projektlaufzeit

  • lange Projektlaufzeiten, teilweise über mehrere Jahre

Es ist eine Tatsache, dass auch die Kunden und späteren Nutzer einer Software oft nur eine ungefähre Vorstellung davon haben, in welcher Form die Software das bestehende Problem lösen soll. Darüber hinaus ist es schwierig, den Entwicklern der Software diese ungefähren Anforderungen zu vermitteln, sie beispielsweise für diesen Zweck auch vollständig und nachvollziehbar zu dokumentieren. Ein weiteres Problem ergibt sich aus der Dynamik der Geschäftsmodelle: Anforderungen und Rahmenbedingungen, die zum Zeitpunkt der erstmaligen Analyse gelten, sind nicht über die gesamte Projektlaufzeit konstant. Dabei ist zu beobachten, dass das Ausmaß an Dynamik im Laufe der Zeit zunimmt. Da die zu erstellenden Anwendungssysteme immer komplexer und umfangreicher werden, nehmen auch die Laufzeiten der Projekte zu. Das wirkt sich ebenso negativ auf die Möglichkeiten einer umfassenden Planung aus. Je länger die Zeitspanne zwischen dem Projektstart und der endgültigen Bereitstellung der Software ist, desto schwieriger wird es, die dann geltenden Kundenanforderungen zu erfüllen.

Die agilen Methoden sind nicht vom Himmel gefallen, sondern die Folge einer längeren zeitlichen Entwicklung (Abb. 1).

krypczyk_bochkor_agil_devops_1.tif_fmt1.jpgAbb. 1: Entwicklungsmethoden in zeitlicher Folge

In den 1980er und frühen 90er Jahren wurde großen Wert auf sorgfältige Projektplanung und formalisierte Qualitätssicherung gelegt. Die Entwicklung erfolgte oft in großen Teams. Im Ergebnis wurde oft mehr Zeit für die Planung aufgewendet als für die tatsächliche Programmentwicklung und die nachfolgenden Tests. Trotz dieses sehr planvollen und stark phasengetriebenen Vorgehens waren die Ergebnisse nicht immer zufriedenstellend. Zu viele Projekte scheiterten oder konnten die Anforderungen und Wünsche der Kunden nicht erfüllen. Als Reaktion wurde ab Mitte der 1990er Jahre erstmals von agilen Methoden gesprochen. Das Ziel war schnell formuliert: Die Entwickler sollten sich verstärkt um ihren eigentlichen Job, die Programmentwicklung, kümmern und nicht mehr so viel Zeit für Entwurf und Dokumentation aufwenden. „Agilität“ steht also für die Fähigkeit, mit Änderungen umzugehen, d. h. schnell und flexibel auf Kundenanforderungen zu reagieren. Änderungen werden nicht mehr als störend aufgefasst, sondern tragen dazu bei, dass das Anwendungssystem frühzeitig in die richtige Richtung gesteuert wird. Ein wesentliches Ziel dieses Vorgehens ist es, in möglichst kurzer Zeit eine erste Version des späteren Endprodukts an den Kunden auszuliefern und schon in sehr frühen Phasen des Entwicklungsprozesses mit Prototypen zu arbeiten. Frühe produktionsfähige Produktversionen sind zwar im Funktionsumfang eingeschränkt, geben jedoch den Anwendern die Möglichkeit, rechtzeitig Feedback zu geben. Dieses Feedback ist wiederum die Ausgangsbasis, um mögliche Modifikationen zeitnah in den weiteren Projektverlauf einzuarbeiten.

Es gibt unterschiedliche Ansätze agiler Entwicklungsmethoden. Scrum gilt heute als sehr weit verbreitet, hat sich vielfach bewährt und ist weithin akzeptiert und stellt zusammen mit Extreme Programming die bekannteste agile Methode dar.

Extreme Programming – oder kurz XP – wurde in den Jahren 1995 bis 2000 von Kent Beck, Ward Cunningham und Ron Jeffries entwickelt. Der Name wurde dadurch geprägt, dass die gut bekannten Praktiken, beispielsweise iterative Entwicklung, „ins Extreme“ gesteigert wurden. Mit XP ist es möglich, mehrere neue Versionen eines Programms an einem Tag zu entwickeln, zu integrieren und zu testen. Ziel ist es, die Entwicklung der Software den gegebenen Bedingungen anzupassen und diese fortlaufend zu verbessern. Die Anforderungen werden in Form von User Stories zusammengefasst und anschließend als eine Folge von Aufgaben implementiert. Welche User Story als nächste in ein Release aufgenommen wird, wird auf Basis der zur Verfügung stehenden Zeit und der zugeordneten Priorität entschieden. Großen Wert wird auf paarweise Zusammenarbeit, d. h. Pair Programming, gelegt. Ergebnisse werden auf diese Weise sofort überprüft. Mit Ihrem Programmierpartner unterstützen Sie sich jederzeit gegenseitig. Statt erst Programmcode zu schreiben und dann umfangreich nach möglichen Fehlern zu suchen, dreht man den Spieß einfach um. Bevor man zum Code schreiben übergeht, werden Tests für die einzelnen Aufgaben entwickelt. Die sollen mit Erfolg abgeschlossen werden, bevor neuer Code in das System integriert wird. Nach Fertigstellung einer Aufgabe ist sie auch sofort in das System zu übernehmen. Diese Art des Vorgehens wird als Test-driven Development bezeichnet. Die Prinzipien von XP sind daher: inkrementelle Planung, einfacher Entwurf und kleine Releases, kollektives Arbeiten, Pair Programming, Test-dr...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang