Agile Softwareentwicklung

Agile software development poster

Agile Softwareentwicklung ist der Oberbegriff für den Einsatz von Agilität (lat. agilis: flink; beweglich) in der Softwareentwicklung. Je nach Kontext bezieht sich der Begriff auf Teilbereiche der Softwareentwicklung – wie im Fall von Agile Modeling – oder auf den gesamten Softwareentwicklungsprozess – exemplarisch sei Extreme Programming angeführt. Agile Softwareentwicklung versucht mit geringem bürokratischen Aufwand und wenigen Regeln auszukommen.

Zielsetzung

Das Ziel Agiler Softwareentwicklung ist es, den Softwareentwicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen Vorgehensmodellen der Fall ist. Man möchte sich mehr auf die zu erreichenden Ziele fokussieren und auf technische und soziale Probleme bei der Softwareentwicklung eingehen. Die Agile Softwareentwicklung ist eine Gegenbewegung zu den oft als schwergewichtig und bürokratisch angesehenen traditionellen Softwareentwicklungsprozessen wie dem Rational Unified Process oder dem V-Modell.

Geschichtliche Entwicklung

Erste Ansätze zu Agiler Softwareentwicklung sind bereits Anfang der 1990er Jahre zu finden. Popularität erreichte die Agile Softwareentwicklung erstmals 1999, als Kent Beck und andere das erste Buch zu Extreme Programming veröffentlichten. Das Interesse an Extreme Programming ebnete den Weg auch für andere Agile Prozesse und Methoden. Die Bezeichnung agil für diese Art der Softwareentwicklung wurde im Februar 2001 bei einem Treffen in Utah ausgewählt, als Ersatz für das bis dahin gebräuchliche leichtgewichtig (engl. lightweight). Bei diesem Treffen wurde auch das Agile Manifest (siehe unten) formuliert.

Ende 2005 wurde von Forrester Research eine Untersuchung herausgebracht, die besagt, dass 14 % der Unternehmungen in Nordamerika und Europa ihre Software unter Zuhilfenahme von agilen Prozessen entwickeln. Weitere 19 % denken über die Nutzung nach.

Bestandteile Agiler Softwareentwicklung

Agile Werte bilden das Fundament. Agile Prinzipien basieren auf den Agilen Werten und bilden Handlungsgrundsätze. Agile Methoden sind konkrete Verfahren während der Softwareentwicklung, die sich auf die Werte und Prinzipien stützen. Der Agile Prozess ist die Zusammenfassung aller angewandten Methoden und dient der Agilen Softwareentwicklung.

Werte

Die Werte agiler Softwareentwicklung bilden das Fundament und wurden im Februar 2001 als Agiles Manifest (englisch Manifesto for Agile Software Development oder kurz Agile Manifesto) formuliert^[1]:

1. Individuen und Interaktionen mehr als Prozesse und Werkzeuge. - Zwar sind wohldefinierte Entwicklungsprozesse und Entwicklungswerkzeuge wichtig, wesentlicher sind jedoch die Qualifikation der Mitarbeitenden und eine effiziente Kommunikation zwischen ihnen.
2. Funktionierende Software mehr als umfassende Dokumentation. - Gut geschriebene und ausführliche Dokumentation kann zwar hilfreich sein, das eigentliche Ziel der Entwicklung ist jedoch die fertige Software.
3. Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung. - Statt sich an ursprünglich formulierten und mittlerweile veralteten Leistungsbeschreibungen in Verträgen festzuhalten, steht vielmehr die fortwährende konstruktive und vertrauensvolle Abstimmung mit dem Kunden im Mittelpunkt.
4. Reagieren auf Veränderung mehr als das Befolgen eines Plans. - Im Verlauf eines Entwicklungsprojektes ändern sich viele Anforderungen und Randbedingungen ebenso wie das Verständnis des Problemfeldes. Das Team muss darauf schnell reagieren können.

Das Manifest weist 17 Autoren und Erstunterzeichner aus, die auf unterschiedlichen Gebieten der agilen Softwareentwicklung tätig sind: 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 und Dave Thomas. Die Liste der Unterzeichner umfasst tausende Personen und wächst nach wie vor ^[2].

Agiles Prinzip

Ein Agiles Prinzip ist ein Leitsatz für die agile Arbeit.

Manchmal werden Agile Prinzipien auch als Methode bezeichnet. Die eigentlich falsche Verwendung des Begriffs Methode für Prinzipien wird von den Vertretern agiler Methoden teilweise bewusst eingesetzt. Bei schwergewichtigen Prozessen werden Prinzipien von umfangreichen Methodenbeschreibungen überlagert und lassen die Prinzipien häufig in Vergessenheit geraten. Zudem wurden Prozesse früher hauptsächlich über Methoden, nicht über Prinzipien definiert. Die Auflistung von Prinzipien als Methoden soll den Prinzipien gegenüber formalen Methoden wieder mehr Gewicht verleihen. Im Agilen Manifest sind zwölf Prinzipien aufgelistet^[3].

Beispiele für Agile Prinzipien:

• Vorhandene Ressourcen mehrfach verwenden
• einfach (KISS-Prinzip)
• zweckmäßig
• kundennah
• Gemeinsamer Code-Besitz (Collective Code Ownership)

Der Übergang zwischen Prinzipien und Methoden ist fließend.

Agile Methode

Streng genommen bezeichnet Agile Methode eine an Agilität ausgerichtete Methode zur Softwareentwicklung.

Ein Kennzeichen agiler Methoden ist, dass sie in einem Prozess dazu dienen können, die Aufwandskurve möglichst gering zu halten. Als Leitsatz gilt: Je mehr Du nach Plan arbeitest, um so mehr bekommst Du das, was Du geplant hast, aber nicht das, was Du brauchst. Daraus resultieren einige Prinzipien des Agile Modelling und des Extreme Programmings.

Agile Methoden lassen sich in zwei Gruppen unterteilen: die tatsächlichen Methoden und die den Methoden zu Grunde liegenden Prinzipien.

Beispiele für Agile Methoden:

• Paarprogrammierung
• Testgetriebene Entwicklung
• ständige Refaktorisierungen
• Story-Cards
• schnelle Codereviews

Agiler Prozess

Ziel der Vorgehensweise ist es, den Softwareentwicklungsprozess durch Abbau der Bürokratisierung und durch die stärkere Berücksichtigung der menschlichen Aspekte effektiver zu gestalten.

Den meisten Agilen Prozessen liegt zu Grunde, dass sie versuchen, die reine Entwurfsphase auf ein Mindestmaß zu reduzieren und im Entwicklungsprozess so früh wie möglich zu ausführbarer Software zu gelangen, die dann in regelmäßigen, kurzen Abständen dem Kunden zur gemeinsamen Abstimmung vorgelegt werden kann. Auf diese Weise soll es jederzeit möglich sein, flexibel auf Kundenwünsche einzugehen, um so die Kundenzufriedenheit insgesamt zu erhöhen. Sie stellen damit einen Gegensatz zu den klassischen Vorgehensmodellen wie dem V-Modell oder dem Rational Unified Process (RUP) dar.

Allen agilen Prozessen ist gemeinsam, dass sie sich zahlreicher Methoden bedienen, die Aufwandskurve möglichst flach zu halten. Inzwischen gibt es eine Vielzahl von agilen Prozessen. Zu den bekanntesten zählen unter anderem:

• Adaptive Software Development (ASD)
• Crystal
• Dynamic System Development Method (DSDM)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Pragmatic Programming
• Scrum
• Software-Expedition
• Universal Application
• Usability Driven Development (UDD)

Der Rational Unified Process (RUP) wird von vielen Vertretern Agiler Methoden (viele von ihnen haben das Agile Manifesto unterzeichnet) als nicht-agiler, schwergewichtiger Prozess aufgefasst. Das ist allerdings umstritten^[4] beziehungsweise wurde versucht mit dem Agile Unified Process eine agile Variante von RUP zu entwickeln.^[5]

Agile Bewertung

Auf die Frage, inwieweit Agile Werte in Prozesse und Methoden umgesetzt wurden, kann eine Agile Bewertung Auskunft geben.

Mit dem sogenannten "Agility Index Measurements"^[6] gibt es den Vorschlag, Softwareprojekte genauso wie bei CMMI anhand fester Faktoren zu bewerten. Der ähnlich benannte "Agility Measurement Index"^[7] bewertet die Entwicklung von Softwareprojekten in 5 unterschiedlichen Dimensionen (Dauer, Risiko, Erfindungsreichheit, Aufwand und Interaktion). Weiterhin gibt es agile Selbstbewertungen, um zu bestimmen, ob ein Team auf Agile Weise arbeitet (Nokia Test^[8], Karlskrona Test^[9]).

Kritische Betrachtung

Es ist umstritten, ob der Entstehungsprozess von Software so gut verstanden wird, dass eine planmäßige Herstellung möglich ist: Kritiker argumentieren, dass Software nichts anderes sei als „ausführbares Wissen“. Wissen jedoch lässt sich nicht ingenieursmäßig herstellen, wie sich etwa eine Brücke oder ein Hochhaus herstellen lässt, sondern wird in einem kreativen Prozess gefunden.

Nach alten Modellen gedacht, wären also agile Projekte zum Scheitern verurteilt. Solche Statistiken stützen sich allerdings noch auf Zahlen aus traditioneller Software-Herstellung. Es ist jedoch zu bedenken, dass generell weniger als zwanzig Prozent von Software-Projekten ohne Budget- und Zeitüberschreitung zu Ende geführt werden. Der Rest überschreitet das Budget oder scheitert. Experten sehen darin mangelnden Einsatz von bewährten Herstellungsprozessen als Ursache. Diese funktionieren nach dem Prinzip des Brückenbaus.

In der Fachpresse findet häufig eine Vermischung zwischen abstrakten und konkreten Begriffen der Agilität statt. So wird häufig ein Agiler Prozess in Ermangelung eines eigenen Namens einfach als der Agile Prozess bezeichnet, obwohl er nur ein möglicher agiler Prozess unter vielen ist. Gleiches gilt für Begriffe wie Agile Methode, Agiles Prinzip, Agile Modellierung usw. Ein Leser von Artikeln über Agile Softwareentwicklung ist also stets gut beraten, zwischen allgemeinen, abstrakten Bestandteilen von Agilität und speziellen konkreten Bestandteilen einer Umsetzung von Agilität zu unterscheiden.

Allerdings verbieten weder das V-Modell noch RUP den Einsatz von Rapid Prototyping; weder vor noch während der Phasen Anforderungsdefinition oder Design. Generell ist in Projekten ein agiles Vorgehen notwendig, allein schon um die Änderungen, die ein Projekt zwangsläufig mit sich bringt, zu berücksichtigen und zu integrieren. Vorgehensmodelle helfen dabei, diese Änderungen geregelt ins Projekt aufzunehmen.

Agiles Vorgehen stößt dann an Grenzen, wenn einer der beiden Vertragspartner (Auftraggeber oder Auftragnehmer) sich nicht an diese Prinzipien hält oder man nicht die rechtlichen Aspekte von (Vertrags-)Änderungen im Projekt berücksichtigt. Zu beachten sind auch neue Anforderungen, die das Verfahren an die Kommunikationsfähigkeit von Entwicklern stellt. Kritisch wird es, wenn Entwickler, die sich gut behaupten können, die Arena im Unternehmen für sich übernehmen, während stillere Gemüter entlassen werden oder freiwillig gehen. Die Fähigkeit, sich in agilen Projekten behaupten zu können, ist nicht mit Produktivität gleichzusetzen. Befürworter der agilen Prinzipien werden dem entgegensetzen, dass dies die Anzeichen falscher Implementierung von agilen Prozessen sind. Unternehmen wiederum können am Nutzen von Entwicklern, die für diesen Prozess ungeeignet sind, direkt zweifeln. Weitere Grenzen bestehen darin, wenn ein Unternehmen mit als Plattform ungeeigneten Mitteln agile Entwicklung forcieren will. Dies geschieht meist, wenn die eingesetzte Software nicht verstanden wird und agiles Vorgehen fälschlicherweise als Allheilmittel angesehen wird.

Insbesondere wird dann der Einsatz agiler Verfahren problematisch, wenn ein Projekt klar definierte Anforderungen erfüllen muss und engen Budgetvorgaben unterliegt. Hier bieten die klassischen, ingenieursmäßigen Vorgehensmodelle mit klar definierten Phasen große Vorteile. Agile Verfahren eignen sich hingegen gut bei weichen und wenig ausformulierten Anforderungen.

Abgrenzung

Der Begriff Agilität ist darüber hinaus in der deutschen Fachliteratur – über die hier präsentierte, aus dem amerikanischen übersetzte Software-Engineering-Philosophie hinaus – nicht klar definiert.

Agile Softwareentwicklung ist beispielsweise nicht mit IT-Agilität zu verwechseln, welche die Anpassungsfähigkeit einer Unternehmens-IT bezeichnet.

Literatur

• 10 Jahre Agiles Manifest.^[10] = OBJEKTspektrum. Nr. 2 = Schwerpunktheft, 2011, ISSN 0945-0491.
• Kent Beck: Extreme Programming. Die revolutionäre Methode für Softwareentwicklung in kleinen Teams. Addison-Wesley, München u. a. 2000, ISBN 3-8273-1709-6.
• Carsten Dogs, Timo Klimmer: Agile Software-Entwicklung kompakt. mitp, Bonn 2005, ISBN 3-8266-1503-4.
• Jutta Eckstein: Agile Softwareentwicklung im Großen. Ein Eintauchen in die Untiefen erfolgreicher Projekte. Deutsche Bearbeitung von Nicolai Josuttis. dpunkt-Verlag, Heidelberg 2004, ISBN 3-89864-250-X.
• Peter Hruschka, Chris Rupp, Gernot Starke: Agility kompakt. Tipps für erfolgreiche Systementwicklung. Spektrum Akademischer Verlag, Heidelberg u. a. 2003, ISBN 3-8274-1483-0.
• Michael Hüttermann: Agile Java-Entwicklung in der Praxis. O'Reilly, Beijing u. a. 2007, ISBN 978-3-89721-482-8.
• Jiri Lundak: Agile Prozesse. Fallstricke erkennen und vermeiden. entwickler.press, Frankfurt am Main 2009, ISBN 978-3-939084-55-6.
• Robert Cecil Martin: Agile Software Development. Principles, Patterns, and Practices. Prentice Hall, Upper Sadle River NJ 2003, ISBN 0-13-597444-5.
• Roman Pichler: Scrum – agiles Projektmanagement erfolgreich einsetzen. dpunkt-Verlag, Heidelberg 2008, ISBN 978-3-89864-478-5.
• Ken Schwaber: Agiles Projektmanagement mit Scrum. Microsoft Press, Unterschleißheim 2007, ISBN 978-3-86645-631-0.
• Jim Shore, Shane Warden: The Art of Agile Development. O'Reilly, Beijing u. a. 2008, ISBN 978-0-596-52767-9.
• Henning Wolf, Wolf-Gideon Bleek: Agile Softwareentwicklung. Werte, Konzepte und Methoden. 2. aktualisierte und erweiterte Auflage. dpunkt-Verlag, Heidelberg 2010, ISBN 978-3-89864-701-4.

Siehe auch

• Die Kathedrale und der Basar
• Business Value Points / Business Value Game

Weblinks

 Wiktionary: agil – Bedeutungserklärungen, Wortherkunft, Synonyme, Übersetzungen

• The New Methodology, ein Artikel von Martin Fowler in welchem u. a. Agile Methoden verglichen werden
• Agile Alliance (englisch)
• Manifesto for Agile Software Development (englisch)
• Agile Software Development Resource Portal (englisch)

Einzelnachweise

1. ↑ agilemanifesto.org Manifest für Agile Softwareentwicklung. Abgerufen am 25. Juli 2011. 
2. ↑ Independent Signatories of The Manifesto for Agile Software Development
3. ↑ Prinzipien hinter dem Agilen Manifest
4. ↑ 'XP und RUP – Passt das zusammen?'
5. ↑ The Agile Unified Process
6. ↑ David Bock's Weblog : Weblog. Jroller.com. Abgerufen am 7. Oktober 2010.
7. ↑ Agility measurement index. Doi.acm.org. Abgerufen am 7. Oktober 2010.
8. ↑ Nokia test, Scrum specific
9. ↑ Karlskrona test, generic agile adoption
10. ↑ http://www.sigs-datacom.de/fachzeitschriften/objektspektrum/archiv/artikelansicht.html?show=2882