Agile Softwareentwicklung

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Agile Softwareentwicklung bezeichnet Ansätze im Softwareentwicklungsprozess, die die Transparenz und Veränderungsgeschwindigkeit erhöhen und zu einem schnelleren Einsatz des entwickelten Systems führen sollen, um so Risiken und Fehlentwicklungen im Entwicklungsprozess zu minimieren.[1] Dazu wird versucht, die Entwurfsphase auf ein Mindestmaß zu reduzieren und im Entwicklungsprozess so früh wie möglich zu ausführbarer Software zu gelangen. Diese wird in regelmäßigen, kurzen Abständen mit dem Kunden abgestimmt. So soll es möglich sein, flexibel auf Kundenwünsche einzugehen, um so die Kundenzufriedenheit insgesamt zu erhöhen. Agile Softwareentwicklung zeichnet sich durch selbstorganisierende Teams sowie eine iterative und inkrementelle[2] Vorgehensweise aus.

Agile Ansätze können sich auf Teile der Softwareentwicklung beziehen (z. B. bei Agile Modeling) oder auf den gesamten Softwareentwicklungsprozess (z. B. bei Extreme Programming oder Scrum). Das Ziel dabei ist, den Entwicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen, plangetriebenen Vorgehensmodellen der Fall ist.

Klassische Ansätze gelten oft als schwergewichtig und bürokratisch (z. B. Rational Unified Process oder V-Modell). Ein Vorwurf ihnen gegenüber lautet: Je mehr nach Plan gearbeitet wird, desto mehr bekommt man das, was geplant wurde, aber nicht das, was gebraucht wird.

Geschichtliche Entwicklung[Bearbeiten | Quelltext bearbeiten]

Das inkrementelle Vorgehensmodell in der Softwareentwicklung kann zurückverfolgt werden bis ins Jahr 1957.[3] Das evolutionäre Projektmanagement[4][5] und die adaptive Software-Entwicklung[6] entstanden in den frühen 1970er Jahren.[7]

Erste Ansätze zu agiler Softwareentwicklung sind Anfang der 1990er Jahre zu finden. Popularität erreichte die agile Softwareentwicklung erstmals 1999, als Kent Beck das erste Buch zu Extreme Programming veröffentlichte. Dies ebnete den Weg für andere agile Prozesse und Methoden. Zu Beginn war Extreme Programming die gängigste agile Methode,[8] spätestens seit der ersten jährlichen Umfrage von VersionOne (2006) ist mit weitem Abstand Scrum die gängigste agile Methode.[9]

Die Bezeichnung agil wurde im Februar 2001 bei einem Treffen in Utah auf Vorschlag von Mike Beedle 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.

2005 wurde von Forrester Research untersucht, dass 14 % der Unternehmungen in Nordamerika und Europa ihre Software mit agilen Prozessen entwickeln; weitere 19 % dachten über die Nutzung nach. VersionOne stellte 2013 fest, dass bereits 84 % aller Unternehmen agile Prozesse einsetzen,[10] 2016 waren es 95 %.

Bestandteile agiler Softwareentwicklung[Bearbeiten | Quelltext bearbeiten]

„Agile Softwareentwicklung ist ein Sammelbegriff für eine Reihe von Methoden und Praktiken, die auf Werten und Prinzipien des Manifests Agiler Softwareentwicklung basieren.“

Agile Alliance, 2018[11]

Agile Leitsätze[Bearbeiten | Quelltext bearbeiten]

Vier Leitsätze wurden im Februar 2001 als Agiles Manifest (englisch Manifesto for Agile Software Development oder kurz Agile Manifesto) formuliert:

„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 und Dave Thomas[12]

Unter den 17 Erstunterzeichnern befinden sich die Begründer des Extreme Programming (Kent Beck, Ward Cunningham, Ron Jeffries), die Begründer von Scrum (Ken Schwaber, Jeff Sutherland), Vertreter von DSDM (Arie van Bennekum) und FDD (Jon Kern) sowie die Begründer von ASD (Jim Highsmith), Crystal (Alistair Cockburn) und pragmatic programming (Dave Thomas, Andrew Hunt).

Agile Prinzipien[Bearbeiten | Quelltext bearbeiten]

Agile Prinzipien dienen als Leitsätze für agile Arbeit. Manchmal werden agile Prinzipien auch als Methode bezeichnet. Bei schwergewichtigen Prozessen werden Prinzipien von umfangreichen Methodenbeschreibungen überlagert und lassen Prinzipien in den Hintergrund treten; zudem wurden Prozesse früher hauptsächlich über Methoden, nicht über Prinzipien definiert. Die Benennung der Prinzipien soll ihnen gegenüber formalen Methoden wieder mehr Gewicht verleihen.

Im Agilen Manifest sind zwölf Prinzipien aufgelistet.[13]

  • 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)
  • Die besten Architekturen, Anforderungen und Entwürfe entstehen in selbstorganisierten Teams
  • Selbstreflexion der Teams über das eigene Verhalten zur Anpassung im Hinblick auf Steigerung der Effektivität

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

Agile Methoden[Bearbeiten | Quelltext bearbeiten]

Agile Methoden sollen dazu dienen, dass die Aufwandskurve möglichst flach bleibt; d. h., Änderungen oder neue Anforderungen sollen mit wenig Aufwand berücksichtigt werden können.

Beispiele für agile Methoden sind:

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

Agile Prozesse[Bearbeiten | Quelltext bearbeiten]

Zu den bekannten agilen Prozessen zählen:

Agile Bewertung[Bearbeiten | Quelltext bearbeiten]

Eine agile Bewertung kann Auskunft geben, inwieweit agile Werte in Prozesse und Methoden umgesetzt wurden.

Mit dem Agility Index Measurements[14] gibt es den Vorschlag, Softwareprojekte genauso wie bei CMMI anhand fester Faktoren zu bewerten. Der ähnlich benannte Agility Measurement Index[15] bewertet die Entwicklung von Softwareprojekten in fünf 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,[16] 42-Points-Test[17], Karlskrona Test[18]).

Kritische Betrachtung[Bearbeiten | Quelltext bearbeiten]

Wesentliche Gründe für agile Herangehensweisen sind, dass sich die Ziele und das Umfeld (beteiligte Personen, Marktanforderungen, technisches Umfeld/Schnittstellen) im Laufe des Projektes ändern. Die agilen Methoden eignen sich daher besonders gut, um auf geänderte Anforderungen zu reagieren, da die Entwicklungszyklen in der Regel kurz angelegt sind. Die Anforderungen werden häufig nur knapp beschrieben und erst kurz vor Beginn von Umsetzung und Test ausformuliert. Durch die kurzen Zeiträume sind (nachträgliche) Änderungen der Anforderungen relativ leicht möglich.

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.[19] Es wurde mit dem Agile Unified Process eine agile Variante von RUP entwickelt.[20] Weder das V-Modell noch RUP verbieten den Einsatz von agilen Elementen, wie Rapid Prototyping; weder vor noch während der Phasen Anforderungsdefinition oder Design.

Auch plangetriebene Vorgehensmodelle regeln, wie Änderungen im Projekt berücksichtigt werden können; wenngleich der Aufwand und die geforderte Dokumentation vergleichsweise höher sind.

Klare inhaltliche Vorgaben (Pflichtenheft) sind bei einem agilen Vorgehen schwierig, da die Anforderungen per Definition erst zur Projektlaufzeit entwickelt werden.

Agile Methoden werden manchmal fälschlicherweise als Allheilmittel bei Projektproblemen angesehen. Hinderungsgründe für ein erfolgreiches Projekt (z. B. Interessens- oder Zielkonflikte, mangelnde Unterstützung durch Auftraggeber oder Sponsor) können für agile genauso wie für traditionelle Verfahren gelten.

Die Studie Status Quo (Scaled) Agile 2020 der Hochschule Koblenz zeigte eine in fast allen Dimensionen und in der Gesamtbewertung verbesserte Leistungsfähigkeit agiler Methoden gegenüber klassischem Projektmanagement. Dabei wurde Scrum als besonders erfolgreich bewertet.[21]

Literatur[Bearbeiten | Quelltext bearbeiten]

Weblinks[Bearbeiten | Quelltext bearbeiten]

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

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. Agile Softwareentwicklung. In: Gabler Wirtschaftslexikon; abgerufen am 15. Juli 2020
  2. Fidelity – The Lost Dimension of the Iron TriangleAvailAgility. In: AvailAgility. 22. Dezember 2009, abgerufen am 3. März 2017.
  3. Gerald M. Weinberg, as quoted in Craig Larman, Victor R. Basili: Iterative and Incremental Development: A Brief History. In: IEEE Computer. 36, Nr. 3, Juni 2003, S. 47–56. doi:10.1109/MC.2003.1204375. „Although many view iterative and incremental development as a modern practice, its application dates as far back as the mid-1950s.“ "We were doing incremental development as early as 1957 in Los Angeles, under the direction of Bernie Dimsdale at IBM's Service Bureau Corporation. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell ... All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for 'software development.'"
  4. Evolutionary Project Management (Original page, external archive). Gilb. Archiviert vom Original am 27 March 2016. Abgerufen am 30. April 2017.
  5. Evolutionary Project Management (New page). Gilb. Abgerufen am 30. April 2017.
  6. E. A. Edmonds: A Process for the Development of Software for Nontechnical Users as an Adaptive System. In: General Systems. 19, 1974, S. 215–18.
  7. Tom Gilb: Evolutionary development. In: ACM SIGSOFT Software Engineering Notes. 6, Nr. 2, 1. April 1981, S. 17. doi:10.1145/1010865.1010868.
  8. nku.edu (PDF)
  9. 1st Annual State of Agile™ Report bis 13th Annual State of Agile™ Report
  10. 7th Annual State of Agile Development Survey.
  11. The Agile Alliance: What is Agile Software Development? Abgerufen am 25. März 2018.
  12. Manifesto for Agile Software Development. Abgerufen am 15. Juli 2020.
  13. Prinzipien hinter dem Agilen Manifest
  14. David Bock’s Weblog. Jroller.com. Archiviert vom Original am 11. Januar 2006. Abgerufen am 15. Juli 2020.
  15. Subhajit Datta: Agility Measurement Index: A Metric for the Crossroads of Software Development Methodologies. ACM, New York NY 2006, ISBN 1-59593-315-8, S. 271–273, doi:10.1145/1185448.1185509.
  16. Nokia test, Scrum specific
  17. Kelly Waters: How Agile Are You? (Take This 42 Point Test). (Nicht mehr online verfügbar.) 28. Januar 2008, archiviert vom Original am 5. Mai 2014; abgerufen am 15. Juli 2020 (englisch).
  18. Karlskrona test, generic agile adoption
  19. XP und RUP – Passt das zusammen? (PDF; 139 kB)
  20. The Agile Unified Process
  21. Status Quo (Scaled) Agile 2020. Hochschule Koblenz, abgerufen am 20. Juli 2020.