Die Kunst der agilen Entwicklung

1Was ist Agilität?

Agilität ist überall und paradoxerweise nirgendwo.

In den 20 Jahren, in denen die Agilität wie eine Dampfwalze in das Bewusstsein von Softwareentwicklern1 eingedrungen ist, stieg die Zahl der Unternehmen, die sich selbst »agil« nennen, beachtlich an. Gilt dasselbe auch für die Anzahl der Teams, die wirklich ein agiles Vorgehen für ihre Arbeit verwenden? Leider nicht. Der inflationär verwendete Begriff »Agilität« ist enorm erfolgreich. Die tatsächlichen Ideen hinter Agilität jedoch werden meistens ignoriert.

Das müssen wir ändern!

1.1Die Entstehung von Agilität

In den 1990er-Jahren schien sich die Softwareentwicklung in einer Krise zu befinden. Tatsächlich wurde genau dieser Begriff verwendet: »die Softwarekrise«. Softwareprojekte überschritten ihre Budgets, waren verspätet und erfüllten nicht die an sie gestellten Anforderungen. Nach dem oft zitierten und ominös benannten »CHAOS Report« wurde nahezu ein Drittel der Projekte komplett abgebrochen [Standish 1994].

Agilität war nicht im Entferntesten eine Antwort auf diese Krise. Agilität war eine Antwort auf die Antwort.

Um die Softwareentwicklung unter Kontrolle zu bringen, hatten große Organisationen sehr detaillierte Prozesse definiert, die genau beschrieben, wie Software erstellt werden sollte. Alles wurde streng kontrolliert, damit (zumindest theoretisch) keine Fehler gemacht werden konnten.

Zuerst würden Business-Analysten verschiedene Stakeholder2 befragen, um die Anforderungen an das System zu dokumentieren. Im Anschluss würden Softwarearchitektinnen die Systemanforderungen lesen und mithilfe detaillierter Dokumentation sowohl den Entwurf der Komponenten als auch ihre Beziehung zueinander spezifizieren. Dann würden die Programmiererinnen diese Entwurfsdokumente in Quellcode umwandeln. In einigen Unternehmen wurde dies als eine Arbeit betrachtet, die wenig Fähigkeiten erfordert - also lediglich als eine mechanische Übersetzungsübung.

In der Zwischenzeit würden Fachleute aus der Testabteilung anhand derselben Dokumente Ablaufpläne für den Test anfertigen, damit nach der Programmierung Heerscharen von Testern das Programm manuell überprüfen und Abweichungen als Fehler dokumentieren können. Nach jeder Phase dieses Ablaufplans würden die einzelnen Schritte aufmerksam dokumentiert, überprüft und unterschrieben werden.

Ein solches auf Phasen basierendes Vorgehensmodell wurde »Wasserfallmodell« oder auch »Stage-Gate-Modell« genannt.3 Wenn das für Sie wie ein vorgeschobenes Argument klingt, nun ja, schätzen Sie sich glücklich. Nicht jedes Unternehmen benutzte in der 90er-Jahren solch einen auf Dokumenten und Phasen basierenden Prozess. Auf diese Art zu arbeiten, wurde jedoch als logisch und vernünftig angesehen. Natürlich sollten wir Anforderungen definieren, entwerfen, implementieren und testen. Natürlich sollten wir jede Phase dokumentieren. So funktionierte Entwicklung und wie sollten wir auch sonst erfolgreich sein?

1.2Aus der Krise geboren

Große Unternehmen haben ihre Prozesse bis ins kleinste Detail definiert. Rollen, Verantwortlichkeiten, Dokumentenvorlagen, Modellierungssprachen, Change Control Boards, die über Anpassungen von Anforderungen berieten, . jeder Aspekt im Ablauf der Entwicklung wurde streng definiert und überprüft. Wenn ein Projekt nicht erfolgreich war - und nach dem CHAOS Report war dies bei weniger als einem Sechstel der Fall -, lag es daran, dass die Prozessbeschreibung mehr Details brauchte, mehr Dokumente, mehr Freigaben. Daraus resultierte ein riesiger Berg an Dokumentation. Martin Fowler nannte es »Der große Donnerschlag« (»The Almighty Thud«) [Fowler 1997].

Dies war keine schöne Art zu arbeiten: bürokratisch und nicht den Menschen gerecht. Es schien, als hätten Fähigkeiten weniger Bedeutung als die Einhaltung von Prozessen. Und in der Programmierung zu arbeiten, fühlte sich an, als seien wir ein austauschbares Zahnrad in einer anonymen Maschine. Und es funktionierte nicht einmal besonders gut.

Also entwickelten verschiedene Personen Methoden für die Softwareentwicklung, die einfacher und schlanker waren und weniger Vorgaben machten. Diese wurden im Gegensatz zu dem schwergewichtigen Vorgehensmodell großer Unternehmen als »leichtgewichtige Methoden« bezeichnet. Diese neuen Methoden hatten Namen wie »Adaptive Software Development«, »Crystal«, »Feature-Driven Development«, »Dynamic Systems Development Method«, »Extreme Programming« und »Scrum«.

In den späten 90er-Jahren erregten diese Methoden starke Aufmerksamkeit. Insbesondere Extreme Programming führte zu einem explosionsartigen Anstieg des Interesses unter Programmierern. Im Jahr 2001 trafen sich 17 Befürworter dieser leichtgewichtigen Methoden in einem Skigebiet in Utah, um zu diskutieren, wie sie ihre Bemühungen vereinheitlichen könnten.

1.3Das Manifest für Agile Softwareentwicklung

Alistair Cockburn sagte später: »Ich persönlich habe nicht erwartet, dass diese Gruppe [von Menschen] sich jemals auf etwas Wesentliches einigen würde.«

Und tatsächlich erreichten sie nach zwei Tagen nur zwei Dinge: den Namen »Agilität« und eine Angabe von vier Werten (siehe Abb. 1-1). In den darauffolgenden zwölf Monaten erarbeiteten sie per Mail zwölf begleitende Prinzipien (siehe Abb. 1-2) [Beck 2001].

Das war das Agile Manifest. Es hat die Welt verändert. Oder mit Bezug auf die Aussage von Alistair Cockburn oben: Sie haben sich nach zwei Tagen auf wesentliche Dinge einigen können.4

Manifest für Agile Softwareentwicklung

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

Kent Beck

Mike Beedle

Arie van Bennekum

Alistair Cockburn

Ward Cunningham

Martin Fowler

James Grenning

Jim Highsmith

Andrew Hunt

Ron Jeffries Jon

Kern

Brian Marick

Robert C. Martin

Steve Mellor Ken

Schwaber Jeff

Sutherland Dave

Thomas

Abb. 1-1Agile Werte5

Aber es gab nicht die eine agile Methode. Es gab sie nie und es wird sie nie geben. Agilität besteht aus drei Dingen: dem Namen, den Werten und den Prinzipien. Mehr gibt es nicht. Es ist nicht etwas, was Sie tun können, sondern eine Philosophie. Eine Art, über Softwareentwicklung zu denken. Wir können Agilität nicht »benutzen« oder »machen« . wir können nur agil sein oder eben nicht. Wenn das Team die Philosophie von Agilität verkörpert, ist es agil. Wenn es das nicht tut, dann ist es nicht agil.

Wenn das Team die Philosophie von Agilität verkörpert, ist es agil. Wenn es das nicht tut, dann ist es nicht agil.

1.4Die Essenz von Agilität

Martin Fowler hat Karriere gemacht, indem er für komplizierte Themen der Softwareentwicklung gut durchdachte und ausgewogene Erklärungen gibt. Seine Erklärung für »Die Essenz von agiler Softwareentwicklung« ist eine der besten:

Agile Entwicklung ist eher adaptiv als vorausschauend; orientiert sich eher an Menschen als an Prozessen6.

- Martin Fowler

Prinzipien hinter dem Agilen Manifest

Wir folgen diesen Prinzipien:

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen...