imported>LingoMaeleon: HINZUGEFÜGT: Wiki-Link.

2026-02-09T05:37:02Z

HINZUGEFÜGT: Wiki-Link.

Neue Seite

'''Agile Softwareentwicklung''' (von [[latein]]isch ''agilis'' „flink, beweglich“) bezeichnet Ansätze im [[Vorgehensmodell zur Softwareentwicklung|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.<ref>[http://wirtschaftslexikon.gabler.de/Definition/agile-softwareentwicklung.html ''Agile Softwareentwicklung''.] In: ''[[Gabler Wirtschaftslexikon]]''; abgerufen am 15. Juli 2020</ref> 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<ref>{{Internetquelle |url=http://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/ |titel=Fidelity – The Lost Dimension of the Iron TriangleAvailAgility |werk=AvailAgility |datum=2009-12-22 |abruf=2017-03-03|sprache=en}}</ref> 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 ==
Die agile Softwareentwicklung als Methode der kontinuierlichen Anpassung hat ihren Ursprung im [[Inkrementelles Vorgehensmodell|inkrementellen Vorgehensmodell in der Softwareentwicklung]]. Dessen Entstehung kann bis ins Jahr 1957 zurückverfolgt werden.<ref name="craig2003">[[Gerald M. Weinberg]], as quoted in {{cite journal|last1 = Larman| first1 = Craig| last2 = Basili| first2 = Victor R.| year = 2003| month = June| title = Iterative and Incremental Development: A Brief History
| journal = IEEE Computer| volume = 36| issue = 3| pages = 47–56| doi = 10.1109/MC.2003.1204375| url = https://dl.acm.org/doi/10.1109/MC.2003.1204375| quote = Although many view iterative and incremental development as a modern practice, its application dates as far back as the mid-1950s.|language = en}} "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.'"</ref> Das [[Evolutionäres Management|evolutionäre Projektmanagement]]<ref name="EvolutionaryProjectManagement">{{cite web
|url=https://www.gilb.com/Project-Management|accessdate=2017-04-30|url-status=dead|archiveurl=https://web.archive.org/web/20160327214807/http://www.gilb.com/Project-Management|title=Evolutionary Project Management (Original page, external archive)|archivedate=2016-03-27|publisher=Gilb|language=en}}</ref><ref>{{cite web|url=http://concepts.gilb.com/tiki-page.php?pageName=Evolutionary-Project-Management|title=Evolutionary Project Management (New page)|accessdate=2017-04-30|publisher=Gilb|archiveurl=https://web.archive.org/web/20180207005508/http://concepts.gilb.com/tiki-page.php?pageName=Evolutionary-Project-Management|archivedate=2018-02-07|offline=0|language=en}}</ref> und die [[Adaptive Software Development|adaptive Software-Entwicklung]]<ref name="edmonds1974">{{Cite journal|last=Edmonds|first=E. A.|year=1974|title=A Process for the Development of Software for Nontechnical Users as an Adaptive System|journal=General Systems|volume=19|pages=215–18|language=en}}</ref> entstanden in den frühen 1970er Jahren und können als Vorläufer der agilen Softwareentwicklung verstanden werden.<ref>{{Cite journal|last=Gilb|first=Tom|date=1981-04-01|title=Evolutionary development|journal=ACM SIGSOFT Software Engineering Notes|language=en|volume=6|issue=2|pages=17|doi=10.1145/1010865.1010868}}</ref> Die adaptive Softwareentwicklung entwickelte sich parallel zum [[Design Thinking]] als iterative und evolutionäre Herangehensweise zur Behandlung [[Komplexes Problem|komplexer Probleme]].<ref>{{Literatur |Autor=Julio Cesar Pereira, Rosaria de F.S.M. Russo |Titel=Design Thinking Integrated in Agile Software Development: A Systematic Literature Review |Sammelwerk=Procedia Computer Science |Band=138 |Datum=2018 |DOI=10.1016/j.procs.2018.10.101 |Seiten=775–782 |Online=https://linkinghub.elsevier.com/retrieve/pii/S1877050918317484 |Abruf=2022-07-22|Sprache=en}}</ref>

Die ersten konkreten Ansätze zu agiler Softwareentwicklung sind Anfang der 1990er Jahre zu finden und erreichten 1999 erstmals Popularität, 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 das ''Extreme Programming'' die gängigste agile Methode,<ref>{{Webarchiv|url=https://www.nku.edu/~sakaguch/msis655/lindstrom2004.pdf |wayback=20210124164521 |text=nku.edu }} (PDF; 170 kB). Abgerufen am 7. April 2024.</ref> spätestens seit der ersten jährlichen Umfrage von VersionOne (2006) ist mit weitem Abstand [[Scrum]] die gängigste agile Methode.<ref>{{Internetquelle |url=https://digital.ai/resource-center/analyst-reports/state-of-agile-report |titel=15th Annual State Of Agile Report {{!}} Digital.ai |sprache=en |abruf=2022-05-27}}</ref>

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,<ref>{{Internetquelle |url=https://www.stateofagile.com/ |titel=State of Agile Survey {{!}} State of Agile |datum=2020-04-24 |abruf=2022-01-04 |archiv-url=https://web.archive.org/web/20200424220232/https://www.stateofagile.com/ |archiv-datum=2020-04-24 |offline= |sprache=en}}</ref> 2016 waren es 95 %.

== Bestandteile agiler Softwareentwicklung ==
{{Zitat
|Text=Agile Softwareentwicklung ist ein Sammelbegriff für eine Reihe von Methoden und Praktiken, die auf [[Wertvorstellung|Werten]] und [[Prinzip]]ien des Manifests Agiler Softwareentwicklung basieren.
|Quelle=Agile Alliance, 2018
|ref=<ref>{{Internetquelle |url=https://www.agilealliance.org/agile101/ |titel=The Agile Alliance: What is Agile Software Development? |abruf=2018-03-25 |sprache=en}}</ref>}}

=== {{Anker|Werte}} Agile Leitsätze ===
Vier Leitsätze wurden im Februar 2001 als ''Agiles Manifest'' (englisch ''Manifesto for Agile Software Development'' oder kurz ''Agile Manifesto'') formuliert:

{{Zitat
|Text=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'' sind wichtiger als Prozesse und Werkzeuge
* ''Funktionierende Software'' ist wichtiger als umfassende Dokumentationen
* ''Zusammenarbeit mit dem Kunden'' ist wichtiger als Vertragsverhandlungen
* ''Reagieren auf Veränderung'' ist wichtiger 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.
|Autor=[[Kent Beck]], [[Mike Beedle]], Arie van Bennekum, [[Alistair Cockburn]], [[Ward Cunningham]], [[Martin Fowler]], James Grenning, [[Jim Highsmith]], [[Andy Hunt (Autor)|Andrew Hunt]], [[Ron Jeffries]], Jon Kern, Brian Marick, [[Robert C. Martin]], Steve Mellor, [[Ken Schwaber]], [[Jeff Sutherland (Softwareentwickler)|Jeff Sutherland]] und [[Dave Thomas (Programmierer)|Dave Thomas]]
|ref=<ref>{{Internetquelle |url=https://agilemanifesto.org/iso/de/manifesto.html |titel=Manifesto for Agile Software Development |abruf=2020-07-15|sprache=en}}</ref>}}

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 (Softwareentwickler)|Jeff Sutherland]]), Vertreter von [[DSDM]] (Arie van Bennekum) und [[Feature Driven Development|FDD]] (Jon Kern) sowie die Begründer von [[Adaptive Software Development|ASD]] ([[Jim Highsmith]]), [[Crystal Family|Crystal]] ([[Alistair Cockburn]]) und pragmatic programming ([[Dave Thomas (Programmierer)|Dave Thomas]], [[Andy Hunt (Autor)|Andrew Hunt]]).

=== Agile Prinzipien ===
''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.<ref>{{Internetquelle |url=https://agilemanifesto.org/iso/de/principles.html |titel=Prinzipien hinter dem Agilen Manifest |abruf=2022-05-27|sprache=en}}</ref>

* 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 Veränderungen zum Wettbewerbsvorteil des Kunden.
* Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
* Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
* Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
* Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
* Funktionierende Software ist das wichtigste Fortschrittsmaß.
* Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
* Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
* Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell.
* Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
* In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

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

== Agile Methoden ==

=== Agile Frameworks ===
Zu den bekannten agilen Frameworks zählen:
* [[Scrum]]
* [[Extreme Programming]] (XP)
* [[Kanban (Entwicklung)|Kanban]]
* [[Scrumban]]
* [[DSDM]]
* [[Feature Driven Development]] (FDD)
* [[Adaptive Software Development]] (ASD)
* [[Crystal Family|Crystal]]
* [[Lean Startup]]

=== Agile Praktiken ===

Agile Praktiken 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 Praktiken sind:

* [[Kontinuierliche Integration]]
* ständige [[Refaktorierung]]en
* [[Continuous Delivery]]
* [[Continuous Delivery#Continuous Deployment|Continuous Deployment]]
* [[Paarprogrammierung]]
* [[Testgetriebene Entwicklung]]
* [[Behavior Driven Development]]
* [[Story-Card]]s
* schnelle [[Codereview]]s
* [[Agiles Testen]]
* [[Rapid Application Development]]

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

Mit dem ''Agility Index Measurements''<ref>{{cite web|url=http://jroller.com/page/bokmann?entry=improving_your_processes_aim_high|title=David Bock’s Weblog|date=|accessdate=2020-07-15|last=|first=|publisher=Jroller.com|archiveurl=https://web.archive.org/web/20060111041831/http://jroller.com/page/bokmann?entry=improving_your_processes_aim_high|archivedate=2006-01-11|offline=yes|language=en}}</ref> gibt es den Vorschlag, Softwareprojekte genauso wie bei [[Capability Maturity Model Integration|CMMI]] anhand fester Faktoren zu bewerten. Der ähnlich benannte ''Agility Measurement Index''<ref>{{Literatur |Autor=Subhajit Datta |Titel=Agility Measurement Index: A Metric for the Crossroads of Software Development Methodologies |Verlag=ACM |Ort=New York NY |Datum=2006 |ISBN=1-59593-315-8 |Seiten=271–273 |DOI=10.1145/1185448.1185509|Sprache=en}}</ref> 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,<ref>{{Internetquelle |autor=Joe Little |url=http://agileconsortium.blogspot.com/2007/12/nokia-test.html |titel=Agile & Business: The Nokia Test |werk=Agile & Business |datum=2007-12-02 |abruf=2022-01-04|sprache=en}}</ref> 42-Points-Test<ref>{{Internetquelle |autor=Kelly Waters |url=http://www.allaboutagile.com/how-agile-are-you-take-this-42-point-test/ |titel=How Agile Are You? (Take This 42 Point Test) |werk= |hrsg= |datum=2008-01-28 |sprache=en |archiv-url=https://web.archive.org/web/20140505223335/http://www.allaboutagile.com/how-agile-are-you-take-this-42-point-test/ |archiv-datum=2014-05-05 |offline=1 |abruf=2020-07-15}}</ref>, Karlskrona Test<ref>{{Internetquelle |autor=Mayberg |url=https://mayberg.se/karlskrona-test |titel=Karlskrona test |sprache=en |abruf=2022-01-04}}</ref>).

== Kritische Betrachtung ==
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.<ref>[http://www.fh-wedel.de/archiv/iw/Lehrveranstaltungen/WS2006/SWE/PaperAndrenaObjects.pdf ''XP und RUP – Passt das zusammen?''] (PDF; 139 kB)</ref> Weder das V-Modell noch RUP verbieten den Einsatz von agilen Elementen, wie [[Prototyping (Softwareentwicklung)|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.<ref>{{Internetquelle |url=https://www.hs-koblenz.de/bpm-labor/status-quo-scaled-agile-2020 |titel=Status Quo (Scaled) Agile 2020 |werk= |hrsg=Hochschule Koblenz |datum= |abruf=2020-07-20|sprache=en}}</ref>

== Siehe auch ==
* [[Agiles Lernen]]
* [[Liquibase]]

== Literatur ==
* [[Kent Beck]]: ''Extreme Programming. Die revolutionäre Methode für Softwareentwicklung in kleinen Teams.'' München u. a. 2000, ISBN 3-8273-1709-6.
* [[Ken Schwaber]]: ''Agiles Projektmanagement mit Scrum.'' Unterschleißheim 2007, ISBN 978-3-86645-631-0.
* Ingrid und Peter Gerstbach: ''Design Thinking in IT Projekten - Agile Problemlösungskompetenz in einer digitalen Welt.'' München 2020, ISBN 978-3-446-45959-5.

== Weblinks ==
{{Wiktionary|agil}}
* [http://agilemanifesto.org/iso/de/manifesto.html Manifest für Agile Softwareentwicklung]
* [http://www.martinfowler.com/articles/newMethodology.html The New Methodology], ein Artikel von [[Martin Fowler]], in welchem u. a. Agile Methoden verglichen werden
* [http://www.agilealliance.org/ Agile Alliance] (englisch)

== Einzelnachweise ==
<references />

{{Normdaten|TYP=s|GND=4806620-5|LCCN=sh/2007/6411}}

[[Kategorie:Agile Softwareentwicklung| ]]
[[Kategorie:Vorgehensmodell (Software)]]
[[Kategorie:Projektmanagement]]

Agile Softwareentwicklung - Versionsgeschichte

imported>LingoMaeleon: HINZUGEFÜGT: Wiki-Link.