Was ist agile Softwareentwicklung?

Die agile Softwareentwicklung ist ein iterativer Ansatz zur Erstellung von Softwareprodukten mit dem Ziel, möglichst schnell ein Minimum Viable Product (MVP) zu veröffentlichen, um anschließend Features und Funktionen anhand des Benutzerverhaltens und Feedbacks hinzuzufügen. Die Methodik wurde entwickelt, da es schwierig bis unmöglich ist, die beste Benutzererfahrung, Features und Funktionalität bereits im Vorfeld akkurat vorherzusagen.

Die agile Softwareentwicklung bildet das Gegenstück zur früher dominierenden Wasserfall-Methodik. Bei der Wasserfall-Methodik erstellen Softwareentwicklungsteams bereits im Voraus detaillierte Spezifikationen und Funktionalitätsanforderungen. Die Software wird anschließend anhand dieses Blueprints erstellt und als „abgeschlossenes“ Produkt freigegeben.

Je komplexer die Software, desto schwieriger wird es, bereits im Vorfeld Spezifikationen zu erstellen, die alle Details beinhalten und die besten Optionen für die Benutzer perfekt vorhersagen. Da Softwareprodukte im Laufe der Jahre immer komplexer geworden sind, ist der Wasserfall-Ansatz zugunsten der agilen Softwareentwicklung immer weiter in den Hintergrund getreten.

Ein iterativer, agiler Ansatz kann dabei helfen, das Risiko des Projektsponsors zu minimieren, Unsummen an Geld in ein Produkt zu investieren, von dem fälschlicherweise angenommen wird, dass Nutzer die Funktionalitäten und Features unbedingt benötigen.

Eine weitere Säule der agilen Methodik besteht in der Förderung von kollaborativen, funktionsfähigen Teams. In einem nicht agilen Softwareentwicklungsprozess wie dem Wasserfall-Ansatz ist die Zusammenarbeit von unterschiedlichen Skill-Sets begrenzt, da der lineare Prozess einer Fließbandproduktion ähnelt.

Ein Produkt besteht hierbei aus detaillierten Spezifikationen, die von einer Gruppe von Spezialisten vorab erstellt wurden. Diese werden anschließend an die Front- und Back-End-Entwickler und Designer weitergeleitet, die separate Arbeitsabläufe vollziehen, die zum Schluss zusammengefügt werden. Das Ergebnis wird dann an QS- und Testteams sowie an Operations-Teams übergeben, die die Live-Software bereitstellen.

Ein agiles Softwareentwicklungsteam ist dagegen weitaus mehr eingebunden, da es ein ständiges Hin und Her zwischen den Spezialisten verschiedener Bereiche gibt. Zuerst wird das MVP als Iteration geplant, entworfen, erstellt, getestet und schnell anhand eines zyklischen Prozesses freigegeben.

Die neuen Features, Funktionen, Änderungen, Korrekturen und Verbesserungen in jedem dieser Schritte benötigen eine ständige Kommunikation und enge Zusammenarbeit zwischen den Spezialisten in jedem Teil der Entwicklungsphase.

Agile Softwareentwicklung als „wissenschaftliche Methode“

Als Softwareentwicklungs- oder Projektmanagements-Methodik wird die agile Softwareentwicklung häufig mit der wissenschaftlichen Methode verglichen. Und dieser Vergleich ist ziemlich präzise.

Denn die wissenschaftliche Methode stellt eine Frage und liefert gleichzeitig potenzielle Antworten. Diese Antworten werden auch als Hypothesen bezeichnet und basieren auf allen bekannten Informationen, die zu Beginn des Prozesses verfügbar sind. Eine Hypothese stellt im Wesentlichen eine fundierte Vermutung dar.

Wissenschaftler versuchen anschließend, diese Hypothesen zu beweisen oder zu widerlegen. Dies geschieht durch messbare empirische Beweise, die aus Experimenten hervorgehen. Diese Experimente bestehen häufig aus Wenn/Dann-Anweisungen. Die Ergebnisse unterstützen oder widersprechen der Hypothese.

Agile Frameworks

Agile ist ein breit gefächerter Begriff, der verschiedene Frameworks und Praktiken für die eigentliche Herangehensweise umfasst. Einige definieren Agile auch als eine Art Mindset, dessen eigentliche „Methodik“ in den Frameworks liegt (manchmal auch als Methodiken bezeichnet), die den Softwareentwicklungsprozess vorantreiben.

Alle agilen Frameworks basieren auf dem im Jahre 2001 veröffentlichten Manifesto for Agile Software Development und folgen den 12 Prinzipien. Dennoch unterscheiden sich die Frameworks voneinander, sodass unterschiedliche Frameworks für bestimmte Organisations- oder Entwicklungsprojekte gegenüber anderen bevorzugt werden.

Insgesamt gibt es über 50 detaillierte agile Frameworks, aber eine große Mehrheit von Softwareentwicklungsteams und -projekten beschränkt sich hierbei auf die geläufigsten. Zu diesen zählen:

• Scrum
• Kanban
• Extreme Programming (XP)
• Feature-Driven Development (FDD)
• Dynamic Systems Development Method (DSDM)
• Adaptive Software Development (ASD)
• Rapid Application Development (RAD)
• Crystal
• Scaled Agile Framework (SAFe)

Scrum

Scrum, ursprünglich ein Begriff aus dem Rugby, der sich mit „angeordnetem Gedränge“ ins Deutsche übersetzen lässt, bildet eine Metapher für ein Team, das sich gemeinsam in eine Richtung bewegt. Die sportliche Metapher kann weiter ausgeführt werden, da ein Team durch positive und negative Erfahrungen über die Summe seiner Bestandteile herauswachsen kann. Im Rahmen der Softwareentwicklung ist Scrum das am häufigsten verwendete agile Framework.

Scrum unterscheidet sich von anderen agilen Frameworks und Prozessen durch die spezifischen Konzepte und Praktiken, die in die Kategorien Rollen, Artefakte und Time-Boxes unterteilt sind. Eine weitere wichtige Eigenschaft ist die Einführung der Rollen Scrum Master und Product Owner, die das Scrum-Team organisieren und verwalten, einschließlich Softwareentwickler, Designer, QS, Tests und Operations.

Sprints als integraler Bestandteil von Scrum sind Zeitintervalle von häufig zwei Wochen, in denen ein im Voraus definierter Teil der Entwicklungsarbeit abgeschlossen wird. Sprints sorgen dafür, dass wichtige Bestandteile der agilen Prinzipien eingehalten werden können, wie beispielsweise die kontinuierliche Lieferung von funktionierender Software oder auch die Fähigkeit, auf Änderungen angemessen reagieren zu können, anstelle nur einem Plan zu folgen.

Quelle: Atlassian Agile Coach

Nach jedem Sprint, der im Idealfall zu einer neuen Iteration auf der in der Produktion freigesetzten Software führt, wird ein agiles Softwareentwicklungsteam die Bedürfnisse und Prioritäten des Projekts neu bewerten. Hierauf basierend wird der nächste Sprint eingeleitet.

Kanban

Der Begriff „Kanban“ stammt aus dem Japanischen und kann mit „Karte“ übersetzt werden. Kanban ist ein Framework für Just in Time (JIT) Prozesse, das seinen Ursprung in den Fabrikhallen von Toyota hat. Tatsächlich hat Toyota aber den Ansatz aus einem bereits bestehenden System übernommen, das von Supermärkten verwendet wurde, um Regale und Lagerhäuser optimal aufzustocken und das perfekte Verhältnis zwischen Kundenbedürfnissen und Lagerüberhängen zu finden.

Wenn bestimmte Komponenten oder Materialien in den Toyota-Fabriken allmählich zur Neige gingen, würde jemand eine Karte bzw. ein Kanban an das zuständige Lager aushändigen, um die Lieferung vorzubereiten. Wenn nötig würde das Lagerhaus bei Bedarf ebenfalls ein Kanban an den eigenen Lieferanten übergeben.

Das System war effizient, da hierdurch sichergestellt wurde, dass die richtigen Ressourcen immer verfügbar waren, während gleichzeitig Redundanz minimiert wurde.

Im Zusammenhang mit der agilen Softwareentwicklung wurde das Kanban-System als Workflow-Visualisierungssystem übernommen. Kanban-Karten werden digitalisiert und auf einem Kanban-Board platziert. Da die Elemente visuell hervorgehoben werden, können alle Team-Mitglieder den Status jeder Aufgabe schnell einsehen, wobei das Board den „Single Source of Truth“ darstellt.

Ein Kanban-Board verfügt über drei Workflow-Status – To Do, In Progress und Done. Dies hilft dabei, den Workflow zu standardisieren und Abhängigkeiten und Engpässe schnell zu erkennen.

Der Kernunterschied zwischen Kanban und Scrum ist, dass Kanban einen kontinuierlichen Arbeits- und Lieferablauf priorisiert, während Scrum mit Sprints das Entwicklungsprojekt in Einheiten unterteilt. Der Schwerpunkt auf der kontinuierlichen Lieferung und Integration – CI/CD – macht Kanban bei DevOps-Entwicklungsteams besonders beliebt.

Es gibt auch einen Hybrid namens „Scrumban“, der versucht, die beiden Frameworks zusammenzubringen, indem die Sprints des Scrums mit Kanbans Priorisierung von optimalen Arbeitsabläufen und Zykluszeiten kombiniert werden.

Extreme Programming (XP)

Extreme Programming (XP) ist kein traditionelles agiles Framework, da es die technischen Aspekte der Softwareentwicklung und die Umsetzung spezifischer Praktiken stärker betont als die Management- und Organisationsseite.

Ein XP-Softwareentwicklungszyklus besteht aus 5 Stufen:

• Planung
• Design
• Coding
• Test
• Listening (Kunden-Feedback)

XP-Teams beinhalten manchmal auch die einzigartige Rolle von „Trackern“, die oft einem der Entwickler auf Teilzeitbasis zugewiesen wird. Der Tracker folgt Metriken wie Geschwindigkeit, Überstunden, Test-Erfolgsrate oder andere Daten, die für den Erfolg und Fortschritt des Teams von Bedeutung sind.

Die 5 Werte von XP sind:

• Kommunikation
• Einfachheit
• Feedback
• Courage
• Respekt

Die Praktiken umfassen:

• Zusammensitzen
• Komplettes Team
• Informatives Arbeitsumfeld
• Inspirierte Arbeit
• Paar-Programmierung
• Storys
• Wochenzyklen
• Quartalszyklen
• Slack
• Zehn-Minuten-Builds
• Kontinuierliche Integration (CI)
• Test-first-Programmierung
• Inkrementelles Design

Done Wells, der Autor von extremeprogramming.org, sagt, dass XP ein geeigneter agiler Software-Entwicklungsansatz für Projekte mit den folgenden Merkmalen sein kann:

• Softwareanforderungen, die sich dynamisch ändern können
• Risiken, die durch feste Zeitprojekte mit neuen Technologien entstehen
• Kleines, vor Ort erweitertes Entwicklungsteam
• Verwendete Technologie ermöglicht automatisierte Einheiten- und Funktionstests

Feature Driven Development (FDD)

Im Feature-getriebenen Entwicklungsprozess wird die agile Softwareentwicklung rund um die Entwicklung von Features organisiert. Im FDD-Kontext sind Features mit Scrum Storys und weniger mit traditionell definierten Produktmerkmalen vergleichbar. Mike Dixon erklärt Beispiele für FDD-Features auf einer Website für Flash-Videospiele wie folgt:

• Der Benutzer muss ein Spiel auf einer Webseite spielen können
• Ein Benutzer muss in der Lage sein, alle Spiele auf einer Webseite abzuspielen
• Die Seite muss über ein erstklassiges Look and Feel verfügen

Das erste Feature würde folgende Punkte beinhalten:

„… Erstellung einer statischen HTML-Seite mit einem eingebetteten Code, mit dem ein Benutzer ein Spiel abspielen kann. Das Spiel muss sich in einem webgestellten Ordner befinden. Sobald das Feature vollständig getestet wurde, kann es freigegeben werden.“

Ein FDD-Projektlebenszyklus folgt den fünf Stufen:

1. Entwicklung eines Gesamtmodells
2. Erstellung einer Feature-Liste
3. Feature-Planung
4. Feature-Design
5. Feature-Erstellung

FDD ist normalerweise für große agile Teams mit vordefinierten Entwicklungsstandards und nicht für kleinere Projekte geeignet.

Dynamic Systems Development Model (DMDM)

Das dynamische Systementwicklungsmodell ist eine Weiterentwicklung des Rapid Application Development (RAD) Frameworks, um dem iterativen Ansatz zur Softwareentwicklung zusätzlich mehr Kontrolle und Disziplin zu verleihen.

Es basiert auf der Philosophie, dass „jedes Projekt auf eindeutig definierte strategische Ziele ausgerichtet und sich auf die frühe Lieferung von echten Geschäftsvorteilen konzentrieren sollte.“ DMDM basiert auf 8 Prinzipien:

1. Fokus auf Geschäftsanforderungen
2. Rechtzeitige Lieferung
3. Kooperation
4. Keine Kompromisse in der Qualität
5. Schrittweise Entwicklung auf stabiler Grundlage
6. Iterativ entwickeln
7. Kontinuierliche und klare Kommunikation
8. Kontrolle demonstrieren

Ein DSDM-Agile-Software-Entwicklungslebenszyklus besteht aus 4 Stufen:

• Durchführbarkeit und Wirtschaftsstudie
• Funktionelles Modell / Prototyp-Iteration
• Design- und Build-Iteration
• Implementierung

Adaptive Software Development (ASD)

Die adaptive Softwareentwicklung (ASD) ist ein agiles Softwareentwicklungs-Framework, das von den Projektmanagern John Highsmith und Sam Bayer in den frühen 90er Jahren entworfen wurde. Hierbei handelt es sich um eine schrittweise Evolution des agilen RAD-Frameworks, in dem 1-monatige Projekte in wöchentliche Perioden aufgeteilt werden (vergleichbar mit Scrum-Sprints).

ASD setzt den Fokus auf integriertes Benutzerfeedback, was in unterschiedlichen Phasen des Entwicklungslebenszyklus umgesetzt wird. ASD versucht auch, Emergence zu fördern, womit ungeplante neue Wege und Features umschrieben werden.

Crystal

Crystal wurde im Jahr 1991 von Alistair Cockburn für IBM entwickelt, einem der ursprünglichen Agile-Fürsprecher. Das agile Softwareentwicklungs-Framework konzentriert sich auf Einzelpersonen und ihre Interaktionen anstatt auf Prozesse und Werkzeuge. Es wird von den zwei Kernglauben untermauert:

1. Teams können selbst Wege finden, um ihre Workflows zu verbessern und zu optimieren
2. Jedes Projekt ist einzigartig und ändert sich stetig, weshalb das Projekt-Team am besten dazu geeignet ist, die Arbeit anzugehen

Der Crystal-Ansatz lehnt universelle Entwicklungsprozesse und -strategien ab und bietet stattdessen Richtlinien für die Zusammenarbeit und Kommunikation an, mit denen ein Softwareentwicklungsteam individuelle Prozesse und -strategien gemäß den einzigartigen Anforderungen des Projekts eigenständig planen kann.

Eine Schwäche, die einige im Crystal-Framework finden, ist die Tatsache, dass Dokumentation und Reporting hier nur eine untergeordnete Rolle spielen, was die Transparenz auf Firmenebene und die Möglichkeit, den Fortschritt von Außenstehenden einzuschätzen, weiter einschränkt.

Scaled Agile Framework (SAFe)

Das Scaled Agile Framework (SAFe) ist der vorherrschende Ansatz zur Skalierung agiler Softwareentwicklung für größere Projekte, die gleich mehrere agile Teams beinhalten. Das Framework hat vier Variationen – Essential SAFe, Large Solution SAFe, Portfolio SAFe, and Full SAFe – wobei jede Variation eine andere Form der Skalierung aufweist.

SAFe fördert Ausrichtung, Zusammenarbeit und die Lieferung über eine große Anzahl von agilen Teams und bedient sich hierbei der agilen Softwareentwicklung, Lean-Produktion und Systems Thinking.

Die Werte von SAFe lauten wie folgt:

• Ausrichtung
• Integrierte Qualität
• Transparenz
• Programmausführung
• Führung

Die 9 Prinzipien sind:

1. Ein wirtschaftlicher Fokus
2. Systems Thinking
3. Variabilität und Schaffung von Optionen
4. Schrittweise Entwicklung mit schnellen, integrierten Lernzyklen
5. Basismeilensteine ​​zur objektiven Bewertung von Arbeitssystemen
6. Visualisierung und Limitierung von Work-in-Progress (WIP), Reduzierung von Batchgrößen und Verwaltung von Warteschlangen
7. Synchronisierte Cross-Domain-Planung
8. Entfesselung der intrinsischen Motivation von Wissensarbeitern
9. Dezentrale Entscheidungsfindung

Scaled Agile, Inc., hat eine SAFe Implementierungs-Roadmap entwickelt, die den empfohlenen 12 Schritten folgt:

1. Erreichen des Wendepunkts (Buy-In für Organisationswechsel)
2. Training von Lean-Agile Change-Agents
3. Training von Führungskräften und Managern
4. Erstellung eines Lean-Agile Centre of Excellence
5. Identifikation von Wertströmen und ARTs (Agile Release Trains)
6. Erstellung eines Implementierungsplans
7. Vorbereitung auf die ART-Ausführung
8. Training von Teams und ART- Ausführung
9. Coaching zur ART-Ausführung
10. Mehr ARTs und Wertströme
11. Erweiterung des Portfolios
12. Beschleunigung

Andere Scaled Agile Frameworks, die Variationen von SAFe anbieten, umfassen Large-Scale Scrum (LeSS) und Scrum-of-Scrums (SoS).

Vorteile eines agilen Ansatzes zur Softwareentwicklung

Es ist kein Zufall, dass die agile Softwareentwicklung in ihren verschiedenen Ausführungen zur dominierenden Methodik in der modernen Softwareentwicklung geworden ist. Softwareentwicklungsteams bevorzugen normalerweise die agile Methodik, da diese bei richtiger Umsetzung zu besseren Prozessen und Softwareprodukten führt.

Projekt-Sponsoren bevorzugen die Methodik aus demselben Grund, und weil sie zu schnelleren Releases, und zufriedeneren, integrierten Entwicklungsteams führt. Gleichzeitig wird die Zuteilung teurer Ressourcen optimiert, da Redundanz reduziert wird. Ein PwC-Bericht über agile Projektzustellung im Jahre 2018 bewertete agile Projekte um 28% erfolgreicher gegenüber wichtigen Entscheidungsmerkmalen.

Neun der am häufigsten zitierten Vorteile der agilen Softwareentwicklung sind:

1. Überlegene Produktqualität
2. Kundenzufriedenheit
3. Bessere Kontrolle
4. Verbesserte Projektvorhersage
5. Reduzierte Risiken
6. Erhöhte Flexibilität
7. Kontinuierliche Verbesserung
8. Höhere Teammoral
9. Relevantere Metriken

Auf den ersten Blick können einige dieser Vorteile Fragen aufwerfen. Wenn zum Beispiel eine zentrale Säule der agilen Softwareentwicklung darin besteht, dass User Storys, Features und Funktionen jederzeit auf der Grundlage von Live-Test- und Feedback-Loops geändert werden können, wie kann die Vorhersehbarkeit verbessert werden?

Die Antwort ist, dass sich die Anpassungsfähigkeit und Flexibilität während des gesamten Projekts durch unerwartete neue Informationen verändern kann. Eine bessere Zusammenarbeit und eine erhöhte Transparenz bzgl. der Arbeit von verschiedenen Team-Mitgliedern wirkt sich positiv auf die Vorhersage von Leistung und Risiken aus.

Fallstricke in der agilen Softwareentwicklung

Hat ein agiler Software-Entwicklungsansatz überhaupt Schwächen und mögliche Fallstricke, die es zu vermeiden gilt? Natürlich. Eine Methodik ist nämlich immer nur so gut wie die Ausführung. Im Folgenden werden drei mögliche Risiken erläutert, die man im agilen Entwicklungsprozess vermeiden sollte.

Umfangswachstum und keine klare Richtung

Viele der Vorteile, die sich aus einem agilen Ansatz ergeben, sind ein direktes Ergebnis der Flexibilität und Freiheit, die diese Methodik mit sich bringt. Aber dieser „Wir werden sehen was kommt“-Ansatz, dessen nächste Iteration aus vorherigen Releases und Feedbackschleifen resultiert, bedeutet auch, dass es nie eine wirklich klare Sicht auf das Endprodukt oder auf die Endergebnisse gibt.

Das Fehlen eines Endpunkts kann sich auf agile Teams auswirken, da weder klare Richtung noch Fokus zu einem Intensitätsverlust in der Arbeit und zu verpassten Fristen führen kann. Zudem lässt sich der Fortschritt nur schwer messen.

Kosten, Zeit und Ressourcen lassen sich zu Beginn nur schwer vorhersagen

Das Fehlen einer formalen Design-Phase und die Tatsache, dass dieser Ansatz auf Produktsponsoren und Entwicklungsteams basiert, die alle nicht genau wissen, wie das Endergebnis aussehen wird, machen es schwer, endgültige Kosten, Zeit und Ressourcen vorherzusagen.

Agile Projekt-Manager können sich vor unbemerktem Umfangswachstum schützen und einen Fokusverlust vermeiden, indem projektspezifische KPIs oder eine Produkt-Roadmap erstellt werden. Projektsponsoren, die sich sowohl für agile Softwareentwicklungsteams entscheiden als auch ein ungefähres Budget und Fristen einhalten müssen, können auch einen controlled Agile bzw. agilen Festpreis in Betracht ziehen.

Schwierigkeiten bei der Zusammenarbeit

Agile fördert die Eigeninitiative und Autonomie von Team-Mitgliedern durch Selbstorganisation und funktionsübergreifende Arbeit. Damit der Ansatz jedoch auch ohne einen festen Phasenabschluss koordiniert und effizient bleibt, müssen ein hohes Maß an Kommunikation und Zusammenarbeit aufrechterhalten werden.

Die Aufrechterhaltung effektiver Zusammenarbeit über den gesamten Verlauf eines Entwicklungsprojekts erfordert Anstrengung und Engagement. Das ist dann noch mehr der Fall, wenn ein agiles Team auf verschiedene Orte verteilt ist, beispielsweise durch Fernarbeit.

Verschiedene agile Frameworks haben unterschiedliche Werkzeuge, die ein hohes Maß an Zusammenarbeit fördern, wie beispielsweise Scrum- und Kanban-Boards.

Wie arbeiten Agile und DevOps zusammen?

Menschen reden häufig entweder von agilen oder von DevOps-Softwareentwicklungsteams, doch zunehmend bestehen Softwareentwicklungsteams aus beidem. Doch wo genau besteht der Zusammenhang zwischen Agile und DevOps als Projektmanagement-Philosophien und -Methoden?

Inzwischen sollten Sie ein gutes Verständnis von Agile haben. DevOps übernimmt viel von Agile, hat jedoch einen Kernfokus auf die Vereinigung von Softwareentwicklungsteams mit Operations-Spezialisten, die für den reibungslosen Betrieb einer Softwareanwendung verantwortlich sind, sobald diese bereitgestellt wurde.

In DevOps gibt das Entwicklungsteam nicht einfach nur die in der Entwicklungsumgebung getestete Software an das Operations-Team weiter. Beide Teams arbeiten als eine Einheit mit demselben Ziel und Verantwortung für eine fehlerfreie Benutzererfahrung.

Sie können mehr darüber erfahren, wie Agile und DevOps zusammenarbeiten, aber letztendlich ist DevOps ein agiler Softwareentwicklungs-Ansatz, während die agile Softwareentwicklung nicht unbedingt DevOps ist.