Agile Softwareentwicklung

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

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, wenigen Regeln und meist einem iterativen Vorgehen auszukommen.

Zielsetzung[Bearbeiten]

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 konzentrieren 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[Bearbeiten]

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.

VersionOne stellte in ihrer siebten jährlichen Umfrage zu agilen Methodiken 2013 fest, dass bereits 84% aller Unternehmen agile Prozesse einsetzen.[1]

Bestandteile Agiler Softwareentwicklung[Bearbeiten]

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[Bearbeiten]

Die Werte agiler Softwareentwicklung bilden das Fundament. Im Februar 2001 haben 17 Erstunterzeichner diese Werte als Agiles Manifest (englisch Manifesto for Agile Software Development oder kurz Agile Manifesto) formuliert:

„We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.“

„Wir zeigen bessere Wege auf, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen, es zu tun. Durch unsere Arbeit sind wir zu folgender Erkenntnis gekommen:

  1. Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
  2. Funktionierende Software ist wichtiger als umfassende Dokumentation.
  3. Zusammenarbeit mit dem Kunden ist wichtiger als die ursprünglich formulierten Leistungsbeschreibungen.
  4. Eingehen auf Veränderungen ist wichtiger als Festhalten an einem Plan.

Das heißt: obwohl die Punkte auf der rechten Seite durchaus wichtig sind, halten wir die Punkte links für wichtiger.“

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[2]

Das Manifest weist die Autoren und Erstunterzeichner aus, die auf unterschiedlichen Gebieten der agilen Softwareentwicklung tätig sind. Die Liste der Unterzeichner umfasst tausende Personen und wächst nach wie vor.[3]

Agiles Prinzip[Bearbeiten]

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[4].

  • Zufriedenstellung des Kunden durch frühe und kontinuierliche Auslieferung von wertvoller Software
  • Agile Prozesse nutzen Veränderungen (selbst spät in der Entwicklung) zum Wettbewerbsvorteil des Kunden.
  • Lieferung von funktionierender Software in regelmäßigen, bevorzugt kurzen Zeitspannen (wenige Wochen oder Monate)
  • Nahezu tägliche Zusammenarbeit von Fachexperten und Entwicklern während des Projektes (Bsp.: Gemeinsamer Code-Besitz (Collective Code Ownership))
  • Bereitstellung des Umfeldes und der Unterstützung, welche von motivierten Individuen für die Aufgabenerfüllung benötigt wird
  • Informationsübertragung nach Möglichkeit im Gespräch von Angesicht zu Angesicht
  • Als wichtigstes Fortschrittsmaß gilt die Funktionsfähigkeit der Software
  • Einhalten eines gleichmäßigen Arbeitstempos von Auftraggebern, Entwicklern und Benutzern für eine nachhaltige Entwicklung
  • Ständiges Augenmerk auf technische Exzellenz und gutes Design
  • Einfachheit ist essenziell (KISS-Prinzip)
  • Selbstorganisation der Teams bei Planung und Umsetzung
  • Selbstreflexion der Teams über das eigene Verhalten zur Anpassung im Hinblick auf Effizienzsteigerung

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

Agile Methode[Bearbeiten]

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 flach zu halten. Als Leitsatz gilt: Je mehr du nach Plan arbeitest, desto 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:

Agiler Prozess[Bearbeiten]

Ziel der Vorgehensweise ist es, den Softwareentwicklungsprozess durch Abbau der Bürokratisierung und durch die stärkere Berücksichtigung der menschlichen Aspekte effizienter 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:

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

Agile Bewertung[Bearbeiten]

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

Mit dem sogenannten Agility Index Measurements[7] gibt es den Vorschlag, Softwareprojekte genauso wie bei CMMI anhand fester Faktoren zu bewerten. Der ähnlich benannte Agility Measurement Index[8] 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[9], Karlskrona Test[10]).

Kritische Betrachtung[Bearbeiten]

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. Mit ein Grund dafür ist, dass sowohl die Ziele, als auch das Umfeld (beteiligte Personen, Marktanforderungen, technisches Umfeld/Schnittstellen) flexibel sind und sich im Laufe der Zeit ändern.

Die agilen Methoden eignen sich daher besonders gut, um auf geänderte Anforderungen zu reagieren, da die Entwicklungszyklen in der Regel von vorneherein nicht lange angelegt sind. Die Anforderungen werden in der Regel nur mit Kurzbeschreibungen festgehalten und erst kurz vor Beginn von Umsetzung und Testvorbereitung ausformuliert. Durch die kurzen Zeiträume sind die Anforderungen relativ frei von nachträglichen Änderungen.

Allerdings verbieten weder das V-Modell noch RUP den Einsatz von agilen Elementen, wie 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.

Beim Vertragsabschluss müssen die Eigenschaften der agilen Vorgehensweise ausreichend berücksichtigt sein. Klare inhaltliche Vorgaben (Pflichtenheft) sind schwerlich möglich, da die Anforderungen per Definition erst zur Projektlaufzeit entwickelt werden.

Durch den Hype um agile Methoden werden diese manchmal fälschlicherweise als Allheilmittel bei Projektproblemen angesehen[11]. Dies ist natürlich nicht so: Die Haupthinderungsgründe (siehe auch Projektindikatoren) gelten für agile Verfahren genauso wie für traditionelle Verfahren.

Insbesondere wird dann der Einsatz agiler Verfahren problematisch, wenn ein Projekt klar (vorher) definierte Anforderungen erfüllen muss und engen Zeit- oder 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, bzw. einem hohen Maß an externen Störfaktoren/Marktveränderungen.

Der Standish Chaos Report 2011 hat festgestellt dass Projekte, die mit agilen Methodiken erstellt werden eine deutlich höhere Wahrscheinlichkeit haben, erfolgreich abgeschlossen zu werden. Sind bei der Anwendung der Wasserfallmethodik nur 14 % erfolgreich, 57 % problematisch und scheitern 29 % der Projekte, so sind bei agilen Methodiken 42 % erfolgreich, 49 % problematisch und nur 9 % scheitern.[12]

Abgrenzung[Bearbeiten]

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[Bearbeiten]

  • 10 Jahre Agiles Manifest. 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 Saddle 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.

Weblinks[Bearbeiten]

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

Einzelnachweise[Bearbeiten]

  1. 7th Annual State of Agile Development Survey (PDF; 8,0 MB)
  2. agilemanifesto.org Manifesto for Agile Software Development. Abgerufen am 26. Juni 2012.
  3. Independent Signatories of The Manifesto for Agile Software Development
  4. Prinzipien hinter dem Agilen Manifest
  5. XP und RUP – Passt das zusammen? (PDF; 139 kB)
  6. The Agile Unified Process
  7. David Bock's Weblog : Weblog. Jroller.com. Abgerufen am 7. Oktober 2010.
  8. Agility measurement index. Doi.acm.org. Abgerufen am 7. Oktober 2010.
  9. Nokia test, Scrum specific
  10. Karlskrona test, generic agile adoption
  11. Dr. Herpers, Martine, Agile Methoden können nicht zaubern, Blogeintrag
  12.  The Standish Group (Hrsg.): Chaos Manifesto - The Laws of CHAOS and the CHAOS 100 Best PM Practices. S. 25.