Was ist Agilität?

Nachdem sich die bisherigen Artikel eher um das Thema Scrum gedreht haben, soll dieses Mal der Fokus auf Agilität an sich liegen:

Was ist Agilität, und wodurch unterscheidet sie sich von den “traditionellen” Vorgehensweisen wie dem Wasserfall- oder auch dem V-Modell?

Zunächst fällt mir hier einmal eine grundsätzlich andere Herangehensweise an ein Problem ein: Beim Wasserfall-Modell etwa wird man zuerst mit einer Konzeptionsphase beginnen, im Laufe derer man das Problem möglichst vollständig zu durchdringen sucht. Darauf folgt dann die Phase der Implementierung. Am Ende diese Phase steht dann idealerweise das gewünschte Produkt, das noch vom Kunden abgenommen wird. Man geht also quasi von 0 auf 100. Zuerst hat man lange Zeit nichts vorzuweisen (zumindest nichts, das bereits produktiv wäre), um dann auf einen Schlag das komplette Endprodukt auszuliefern.

Agiles Vorgehen sieht hier ein wenig anders aus. Hier wird das Endprodukt nicht in einem einzigen Schritt, sondern iterativ in mehreren Schritten ausgeliefert. Die Dauer einer Iteration ist prinzipell nicht festgeleft, jedoch haben sich Werte zwischen einer Woche und 3 Monaten mittlerweile fest eingebürgert. Anschließend führt man dann einfach so viele Iterationsschritte durch, bis man mit der jeweils ausgelieferten Version zufrieden ist (oder andere Gründe für einen Abbruch existieren).

“Make it right the last time, not the first time” ist hier ein bekannter Ausspruch von Jim Highsmith, einem der Pioniere agiler Softwareentwicklung.

Man führt vorab keine große Konzeptionsphase mehr durch, sondern verteilt diese auf mehrere kürzere Planungsmeetings zu Beginn einer jeden Iteration. Dabei sortiert man die Anforderungen an das Produkt in einer nach Priorität sortierten Liste und arbeitet pro Iteration so viele Listeneinträge ab, wie man denkt leisten zu können. Iterationen haben immer eine zuvor festgelegte Länge, und damit auch einen verbindlichen Liefertermin. Stellt man also fest, daß man sich verschätzt hat, so verschiebt man Features auf die nächste Version, niemals jedoch den Auslieferungstermin!

Aus meiner Sicht ergeben sich bereits daraus einige ganz wesentliche Vorteile:

• Man kann zu Beginn einer jeden Iteration leicht in eine andere Richtung steuern, falls dies aufgrund veränderter Anforderungen nötig sein sollte.
• Man muß den Elefanten nicht gleich zu Beginn komplett zerlegen, sondern kann mit dem beginnen, was man versteht.
• Man muß keine umständlichen und schwer zu handhabenden Modelle mehr bauen, da die fachliche Diskussion anhand eines echten Systems laufen kann (auch wenn dieses evtl. noch nicht den vollständigen Umfang hat).
• Der Kunde kann sich auf verbindliche Auslieferungstermine verlassen, auch wenn dort u.U. nur Teile des Systems geliefert werden.
• Das System kann schrittweise anhand von tatsächlich ausgelieferter Funmtionalität abgenommen werden. Langwierige Reviews sind nicht mehr notwendig.

In agiler Softwareentwicklung zählt das tatsächliche Produkt wesentlich mehr als jede Art von Papier, die man produzieren kann. Dokumente und Konzepte sind zwar ganz nett (und ab und zu auch hilfreich), werden aber nur dann erstellt, wenn es unbedingt sein muß, und auf keinen Fall dauerhaft gepflegt.

Mit Ausnahme vielleicht der Bedienungsanleitung, aber auch nur, wenn eine solche Teil der Anforderung ist.

Das fehlende Papier wird stattdessen durch (wenn möglich direkte) Kommunikation ersetzt. Dies betrifft sowohl die Kommunikation im Team, als auch mit dem Kunden. Üblich ist es hier sogar, einen “Customer on site” zu fordern, d.h. einen Verteter der Kundenseite, der Vollzeit im Projekt mitarbeitet und bei Bedarf schnelle, verbindliche Entscheidungen trifft.

Da die Komplexität von Kommunikation bei zunehmender Teamgröße quadratisch ansteigt, sind agile Modelle eher auf kleinere Teamgrößen ausgelegt (max. 10 Personen). Bei mehr als 10 Personen im Team wird empfohlen, auf die entsprechende Anzahl kleinerer Teams aufzuteilen. Dieser Ansatz scheint auch aufzugehen: Es hat sich aber in der Vergangenheit schon desöfteren gezeigt, daß agile Teams mit 10 Personen teilweise schneller und besser vorangekommen sind als traditionelle Projektteams mit bis zu 50 Mitarbeitern.

Agile Modelle ziehen die Unsicherheit in der Softwareentwicklung aktiv in das Modell mit ein. Sie folgen somit Ziv’s “Uncertainty Principle in Software Engineering”, wonach Unsicherheiten in allen Stufen der Softwareentwicklung existieren und unausweichlich sind (siehe Ziv, H; Richardson, D.: “The Uncertainty Principle in Software Engineering”; In Proceedings of 19th International Conference of Software Engineering (ICSE’97). IEEE, 1997). Veränderungen werden bei agilen Modellen deswegen nicht als unwillkommene Abweichungen von einem vorher aufgestellten Plan behandelt, sondern sind vielmehr wichtiger Bestandteil des Systems.

Für ein Projekt bedeutet dies, daß das Ergebnis immer mehr oder weniger stark von dem abweichen wird, was man zu Beginn angenommen hat: Am Anfang existiert noch eine große Unsicherheit, die erst im Laufe des Projekts kleiner werden wird. Ein iteratives Vorgehensmodell unterstützt einem dabei jedoch sehr gut, da man zu Beginn jeder Iteration in die gewünschte Richtung steuern kann.

Dieses Vorgehen berücksichtigt auch Humphrey’s Unsicherheitsprinzip für Anforderungen (Humphrey, W.S.: Introduction to the personalized software process; Addison Wesley,1996), wonach die Anforderungen an ein neues System sind solange nicht vollständig bekannt sind, bis die Nutzer damit gearbeitet haben, und Wegner’s Lemma (mathematischer Beweis), welches besagt, daß es unmöglich ist ein interaktives System vollständig zu spezifizieren (Wegner, P.: “Why Interaction Is More Powerful Than Algorithms”, Communications of the ACM, Vol. 40, No. 5, Mai 1997, S.80-91).

Fasst man all dies zusammen, so kommt man auf vier grundlegende Prinzipien der Agilität:

• Personen und Interaktionen sind wichtiger als Prozesse und Tools
• Funktionierende Software ist wichtiger als vollständige Dokumentation
• Mitarbeit des Kunden ist wichtiger als umfangreiche Vertragsverhandlungen
• Reagieren auf Veränderungen ist wichtiger als das Befolgen eines Plans

Diese vier Prinzipien stammen natürlich nicht von mir, sondern wurden bereits 2001 im Rahmen eines Treffens in Utah von einer Reihe von bekannten Software-Entwicklern formuliert.

Man kennt sie als das “Agile Manifest” (siehe http://agilemanifesto.org).

Es dient als Grundlage aller agilen Prozesse, darunter etwa Scrum, Extreme Programming, die Crystal Methodologies, Adaptive Software Development, Testgetriebene Entwicklung oder Feature Driven Development (um nur ein paar zu nennen).

Seitdem befinden sich agile Prozesse langsam aber sicher auf dem Vormarsch: Während 2005 laut Forrester Research erst 19% aller Unternehmen agile Prozesse zur Softwareentwicklung einsetzten und weitere 14% darüber nachdachten, waren es 2008 laut einer Marktstudie bereits 36%, die agil vorgingen (gefunden in ObjektSpektrum Ausgabe Mai/Juni 2008, S. 10-14). Weitere 28% hatten bereits erste Erfahrungen mit Agilität, und 12% dachten über einen Einsatz nach.

Und immerhin 93% der in der Studie Befragten kannten agile Softwareentwicklung im Allgemeinen.

Es scheint also, als würde Agilität langsam aber sicher im Mainstream ankommen. Wer weiß, vielleicht lernen die Informatikstudenten der Zukunft V-Modell und RUP ja nur noch aus Geschichtsbüchern, und nicht aus Lehrbüchern.

Ich bin schon mal gespannt…

BFE