Agile Vorgehensmodelle

Die Motivation des agilen Ansatzes wird bereits durch die Namenswahl verdeutlicht: Agil bedeutet flink oder beweglich und bezieht sich darauf, schnell auf geänderte Rahmenbedingungen zu reagieren. Die ursprüngliche Bezeichnung lautete »leichtgewichtig«. Sie wurde aber wegen möglicher negativer Assoziationen mit diesem Ausdruck (»lightweight« lässt sich auch als »Dünnbrettbohrer« übersetzen) im Laufe der Entwicklung verworfen.

Wasserfall-Modell


Agile Vorgehensmodelle in der Softwareentwicklung lösen sich von dem klassischen Wasserfall-Modell und dessen Variationen. Anstelle der festen Abfolge »Spezifikation, Konstruktion und Umsetzung« wird das Projekt in sehr enger und direkter Zusammenarbeit mit dem Auftraggeber durchgeführt. Die Spezifikation erfolgt sukzessive während der Umsetzung.

Ein wichtiger Vorteil der agilen Vorgehensmodelle ist die Zusammenarbeit mit dem Auftraggeber. Der Kunde bekommt, was er braucht, nicht was er spezifiziert hat. Das ist ein wichtiger Vorteil bei Projekten, deren Anforderungen zum Projektstart noch unklar sind oder durch externe Einflüsse einer starken Veränderung unterliegen.

Ein weiterer Vorteil ist der Abbau bürokratischer Strukturen. So müssen beispielsweise weniger Dokumente erstellt und gepflegt werden. Ein typischer Kritikpunkt an klassischen Vorgehensmodellen ist die Distanz zum Auftraggeber bzw. Anwender. Während die Spezifikation noch in enger Zusammenarbeit erfolgt, kann der Auftraggeber während der Umsetzung kaum Einfluss auf die Ausgestaltung des Produktes nehmen. Agile Softwareentwicklung hingegen versucht, mit einem geringeren bürokratischen Aufwand und wenigen expliziten Regeln auszukommen.

Das Ziel agiler Softwareentwicklung ist es, den Entwicklungsprozess flexibler und schlanker zu gestalten. Bei der Entwicklung soll der Fokus mehr auf den zu erreichenden Zielen liegen und auf technische und soziale Probleme bei der Softwareentwicklung eingegangen werden.

Die agile Softwareentwicklung ist eine Gegenbewegung zu schwergewichtigen, bürokratischen und als von außen geregelt angesehenen, traditionellen Softwareentwicklungsprozessen: Sie legt Wert darauf, dass Regeln erst durch die Teamarbeit der Entwicklergruppe entstehen und so tatsächlich nötig und ergebnisförderlich sind.

Die Coaches der itemis AG begleiten Sie bei der Einführung und Anwendung von agilen Methoden und helfen Ihnen, den Prozess kontinuierlich zu verbessern - jetzt informieren.

Konkreter wird diese Sichtweise im »Agilen Manifest« dargestellt. Im Jahr 2001 trafen sich führende Vertreter der Agilen Softwareentwicklungs-Bewegung und verabschiedeten das Agile Manifest. Zu den Unterzeichnern zählten neben den Scrum- Mitbegründern Mike Beedle, Ken Schwaber und Jeff Sutherland andere Größen der Szene wie Kent Beck (XP), Alistair Cockburn (Crystal), Ward Cunningham, Martin Fowler, Ron Jeffries, Andrew Hunt (Pragmatic Programmer), Robert C. Martin und Dave Thomas (Ruby on Rails).

Der Text des Agilen Manifests lautet:

[Wir] haben folgendes schätzen gelernt:
Individuen und Interaktionen mehr als Prozesse und Tools
funktionierende Software mehr als umfassende Dokumentation Zusammenarbeit mit Kunden mehr als Vertragsverhandlungen Reaktion auf Änderungen mehr als einen Plan zu befolgen
Obwohl auch die Dinge auf der rechten Seite ihren Wert haben, schätzen wir die auf der Linken höher ein.

Diese Kernaussagen sind bewusst knapp und etwas »plakativ« gehalten. Erläuternd lässt sich zu der Philosophie, die hinter den einzelnen Punkten steht, sagen:

Zwar sind wohl definierte Entwicklungsprozesse und hochentwickelte Entwicklungswerkzeuge durchaus wichtig. Wichtiger sind jedoch die Qualifikation der Mitarbeitenden und eine effiziente Kommunikation zwischen ihnen, denn jede Entwicklung steht und fällt mit der Fähigkeit des Teams. Die Projektmitglieder sollen den agilen Prozess festlegen und ihn an die konkreten Bedürfnisse anpassen.

Eine gut geschriebene Dokumentation kann hilfreich sein, das eigentliche Ziel der Entwicklung ist jedoch die fertige Software. Alle Aktivitäten dienen nur einem Ziel: lauffähige und akzeptable Software zu entwickeln. Der Wissenstransfer von Mensch zu Mensch soll Priorität haben, Dokumentationen sollen kein Selbstzweck sein. Ebenso sollen die einzelnen Entwicklungsphasen nicht streng getrennt werden, da dies in der Realität kaum möglich ist: Entwurf, Dokumentation – wo nötig – und Test sollen eine Einheit bilden. Lauffähige Software ist das wichtigste Fortschrittsmaß, nicht umfangreiche Dokumentationen.

Die Zufriedenheit des Kunden ist der wichtigste Maßstab für den Entwicklungserfolg. Dazu muss die Zusammenarbeit mit ihm im Fokus stehen. Denn erst, wenn ein Kunde das System einmal gesehen und angewendet hat, ist er wirklich in der Lage, explizit zu formulieren, wie sein System im Detail aussehen soll und wo konkret Anpassungsbedarf besteht.

Im Verlauf eines Entwicklungsprojektes ändern sich Anforderungen und Randbedingungen ebenso wie das Verständnis des Problemfeldes auf Kunden- und Entwicklerseite. Das Team muss darauf schnell reagieren können – und vor allem auch wollen. Änderungswünsche oder die Unfähigkeit des Kunden, die kompletten Anforderungen zu Beginn der Entwicklung im Detail ausformulieren zu können, sollen nicht als mangelnde Fachkenntnis oder als »Dummheit« des Kunden aufgefasst werden.

Allgemein ist bei all diesen Grundsätzen zu beachten: »Wichtiger als« bedeutet nicht, dass die »klassischen« Projektmerkmale unwichtig sind. Pläne, Verträge und Dokumentation beispielsweise muss es immer geben. Diese sollten den agilen Werten sowie dem Projektfortschritt aber nicht im Weg stehen und nur dort eingesetzt werden, wo sie tatsächlich einen Nutzen bringen.


Extreme Programming (XP)

Diesen Artikel weiterempfehlen

    

Über den Autor

Die itemis AG ist ein unabhängiges IT-Beratungs­unternehmen, das leistungsfähige Software für Unternehmens­anwendungen, eingebettete Systeme und mobile Applikationen entwickelt – und über diese Themen bloggt.