WikiDer > Agile Softwareentwicklung

Agile-softwareontwikkeling

Agile Software Entwicklung ist ein Weg Software-Entwicklung. Das englische Wort agil bedeutet: wendig, wendig.

Geschichte

Obwohl die Praktiken, die als agil Stürze sind seither üblich Software entwickelt ist, die Geburt von agil als Begriff und Konzept auf das Agile Manifest zurückzuführen.[1]

Agiles Manifest

Das agile Manifest[1] (Manifesto for Agile Software Development) wurde während eines informellen Treffens von 17 Softwareentwicklern erstellt. Dieses Treffen fand vom 11. bis 13. Februar 2001 im "The Lodge" in . statt Schneevogel (Utah).

Die Charta und die Prinzipien waren eine Ausarbeitung von Ideen, die Mitte der 1990er Jahre als Reaktion auf Methoden entstanden, die traditionell als Wasserfall-Entwicklungsmodelle. Diese Modelle wurden als bürokratisch, langsam und eng empfunden und würden perceived Kreativität und behindern die Entwicklereffektivität. Die siebzehn Personen, die gemeinsam das Agile Manifest verfassten, repräsentierten die verschiedenen agilen Bewegungen. Nach der Veröffentlichung der Charta gründeten einige Unterzeichner die „Agile Alliance“, um die Prinzipien weiter in Methoden zu übersetzen.

Agile Methoden

Einige agile Entwicklungsmethoden und Frameworks sind:

Es kann argumentiert werden, dass agile und iterative Entwicklungsmethoden in der frühen Geschichte der Softwareentwicklung in die Entwicklungspraxis zurückkehren.[3]Ursprünglich wurden agile Methoden "Leichtbaumethoden" genannt, weil sie so wenige Regeln hatten.

Agile Methoden haben viel mit den schnelle Anwendungsentwicklung- oder RAD-Techniken aus den Achtzigern nach James Martin et al. Danach wurden die folgenden Methoden entwickelt, die später als Agile bezeichnet wurden

Mit extremes Programmieren (abgekürzt als „XP“) sind agile Methoden populär geworden, obwohl es vielleicht nicht die erste agile Methode ist. Extreme Programmierung war 1996 die Antwort von Kent Beck auf die Kämpfe des Chrysler Comprehensive Compensation (C3)-Projekts. Die Methode wurde von Ron Jeffries durch öffentliche Diskussion in Portland-Muster-Repository von Gemeinde Cunningham und weitere Arbeiten von Beck, darunter ein Buch im Jahr 1999. Es scheint Elemente extremer Programmierung basierend auf Scrum und "Episodes Pattern Language" von . zu geben Gemeinde Cunningham.

Eigenschaften

Iterationen

Die meisten agilen Methoden versuchen, das Risiko zu reduzieren, indem sie Software in kurzen überschaubaren Zeiträumen entwickeln (Zeitboxen), Das 'Iterationenheißen '. Jede Iteration ist wie ein Miniaturprojekt für sich, das alle notwendigen Aufgaben umfasst: Planung, Analyse, Design, Test und Dokumentation. Das Ziel ist es, nach jeder Iteration etwas Nützliches zu liefern. Am Ende der Iteration wird das Produkt gezeigt, getestet und das Produkt und der Prozess bewertet. Das begrenzt das Risiko und lässt Sie leicht erkennen, ob Sie auf dem richtigen Weg sind. Durch das Sehen des Produkts wird alles konkreter und neue Ideen entstehen. Anschließend werden die Projektprioritäten betrachtet und festgelegt, was in der nächsten Iteration (Release) gemacht wird.

Kommunikation

Agile Methoden betonen die direkte Kommunikation, vorzugsweise als persönlichen Kontakt, und nicht die schriftliche Berichterstattung. In agilen Projekten wird im Vergleich zu anderen Methoden nur sehr wenig schriftliche Dokumentation erstellt. Die meisten agilen Teams sind an einem Ort untergebracht, der als „Bullpen“ bezeichnet wird. In einem solchen Team sind nach Möglichkeit alle für das Projekt benötigten Personen untergebracht. Aber das sind zumindest die Entwickler und die, die das Produkt definieren. Das kann Produktmanager sein, Business-Analysten oder sogar Kunden. In Scrum hat das Team auch keine Projektmanager, sondern Scrum Master, die dem Team nicht hierarchisch übergeordnet sind, es aber unterstützen. Dies fördert eine offene Kommunikation zwischen gleichberechtigten Teammitgliedern. Bei XP ist auch von . die Rede Paar-Programmierung, wo zwei Entwickler direkt zusammenarbeiten. Dies ist eine sehr direkte Art der Kommunikation.

Fortschritt

Bei agilen Methoden wird der Fortschritt an funktionierenden Produkten, Features oder Prototypen. Am Ende jeder Iteration oder jedes Sprints werden sowohl das gelieferte Produkt als auch der Entwicklungsprozess bewertet. Der Zweck ist, zu lernen und immer besser zu werden. Dieser Aspekt, die kontinuierliche Verbesserung, (Kaizen) stammt aus dem lehnen- Produktionsmethoden.

Arbeitssoftware

Auf funktionierende Software wird Wert gelegt. In jeder Iteration sollte etwas Funktionierendes geliefert werden. Etwas, das auch direkt in die bestehende Software integriert ist und so deutlich macht, ob das alles gut läuft.

Benutzen

Agile Methoden werden schnell populär und auch in großen Projekten immer häufiger eingesetzt.[Quelle?] Bekannte Projekte und Firmen, bei denen es angewendet wurde, sind:

Vergleich mit anderen Methoden

Adaptiv vs. Verschreiben

Agile Methoden werden manchmal irreführend als das genaue Gegenteil von „geplanten“ und „disziplinierten“ Methoden bezeichnet. Eine genauere Beschreibung kann durch die Unterscheidung zwischen „adaptiven“ und „verschreibenden“ Methoden erfolgen.[6] Agile Methoden befinden sich dann am adaptiven Ende dieses Spektrums.

„Adaptive“ (agile) Methoden zielen darauf ab, sich schnell an die sich ändernde Realität anzupassen. Ein „adaptierendes“ Team passt sich daher schnell an, hat aber Schwierigkeiten, genau zu beschreiben, was in der Zukunft passieren wird und was es damit anstellen wird.

Im Gegensatz dazu gibt es „vorschreibende“ Methoden. Diese zielen darauf ab, die Zukunft im Detail zu planen. Ein Team, das mit einer solchen Methode arbeitet, kann genau angeben, welche Ergebnisse und Aufgaben für die gesamte Dauer der Entwicklung geplant sind, tut sich aber schwer mit Veränderungen.

Gegenteil von "iterativer Entwicklung"

Die meisten agilen Methoden teilen den Schwerpunkt der „iterativen Entwicklung“, der Schaffung von releasefähigen Produkten in kurzen Zeiträumen. Davon unterscheiden sich agile Methoden durch einen noch kürzeren Zeitrahmen (Wochen statt Monate) und durch die Betonung einer intensiven Zusammenarbeit. Zudem nehmen agile Methoden ihre „Timebox“ wörtlich; es gibt keine überstunden und am ende der timebox wird nur geliefert, was wirklich fertig (erledigt) ist.

Gegenüber der Wasserfallmethode

Das Wasserfallmethode ist immer noch weit verbreitet.[7]Es ist das präskriptivste aller Modelle mit detaillierten Prozessschrittanforderungen in einer streng geplanten Reihenfolge. Der Fortschritt wird anhand von Dokumenten aller Art gemessen, auf deren Grundlage das Management Fortschrittsentscheidungen trifft.

Die Starrheit des Wasserfallmodells mit der Aufteilung von Projekten in einzelne Phasen und vorzeitigen Verpflichtungen macht es schwierig, auf Veränderungen zu reagieren. Es ist daher praktisch nutzlos, wenn Projektziele und Produktanforderungen nicht im Voraus detailliert werden oder sich während des Projekts ändern können.[8]

Auf der anderen Seite liefern agile Methoden alle paar Wochen ausgereifte und getestete Teile, obwohl dies immer kleine Teile des Ganzen sind. Der Fokus liegt darauf, möglichst kleine Funktionsteile so schnell wie möglich zu liefern, kontinuierlich zu verbessern und zu erweitern Einige agile Teams wenden den Wasserfall-Ansatz in jeder Iteration im kleinen Maßstab an. Andere Teams, insbesondere XP-Teams, lassen den Wasserfall komplett los und arbeiten gleichzeitig an verschiedenen Aufgaben.

Gegenteil von "Cowboy-Codierung"

Beim "Cowboy-Coding" gibt es keine explizite Methode. Teammitglieder tun, was sie für richtig halten. Agile Teams erwecken manchmal den Eindruck, Cowboy-Codierung zu betreiben. Die regelmäßige Überprüfung der Pläne und die Betonung des persönlichen Kontakts anstelle der dokumentierten Kommunikation können unstrukturiert erscheinen. Aber agile Teams koordinieren ihre Aktivitäten ständig und folgen klar definierten und disziplinierten Prozessen.

Wie bei allen Methoden hängt ihr Erfolg von den Fähigkeiten des Anwenders ab. Praktiker können leichter anhand fester und systematischer Anforderungen beurteilt werden. Das Wegfallen solcher Anforderungen kann zu Aktivitäten führen, die als Cowboy-Codierung bezeichnet werden könnten.

Eignung für agile Methoden

Ob agile Methoden grundsätzlich geeignet sind, hängt von der gewählten Sichtweise ab. Agile Methoden eignen sich besser, wenn die Anforderungen noch vage und veränderlich sind. Aus organisatorischer Sicht lässt sich die Eignung anhand von drei Dimensionen messen: Kultur, Menschen und Kommunikation. Diesbezüglich wurden eine Reihe von Erfolgsfaktoren angegeben (Cohen et al., 2004):[9]

  • Die Kultur der Organisation sollte offen für Diskussionen und Verhandlungen sein.
  • Organisationen müssen Personen (Vollzeit) freistellen, um Entscheidungen darüber zu treffen, was die Organisation will, und zu testen, ob das gelieferte Produkt auch diesen Anforderungen entspricht.
  • Menschen muss man vertrauen.
  • Organisationen müssen die Entscheidungen ihrer Vertreter / Product Owner / Product Manager akzeptieren.
  • Organisationen müssen über eine Umgebung verfügen, die eine schnelle Kommunikation zwischen den Teammitgliedern ermöglicht.
  • Menschen müssen zusammenarbeiten können.

Das DSDMMethode ist mit einem „Fitnessfilter“ ausgestattet. Auch der Kristallfamilie der Methoden gibt Kriterien an, nach denen eine Methode für ein bestimmtes Projekt ausgewählt werden kann. Die Auswahl erfolgt nach Projektgröße, Wichtigkeit und Priorität. Andere agile Methoden bieten jedoch keine solchen expliziten Werkzeuge, um ihre Eignung zu bestimmen.

Von einigen Methoden, wie DSDM und Funktionsorientierte Entwicklung (FDD), sollen für jedes Entwicklungsprojekt geeignet sein, unabhängig von Umweltfaktoren (Abrahamsonn et al., 2003),[10] zumindest was die Software angeht.

Große Projekte

Große Projekte sind wegen des hohen Kommunikationsaufwands immer schwierig, aber genau das ist eine Stärke der agilen Methoden. Agile Entwicklung ist umfassend dokumentiert, um in kleinen (weniger als zehn Entwicklern) gemeinsam ansässigen Teams gut zu funktionieren.

Es wurden Vorschläge für groß angelegte Entwicklungen (mehr als zwanzig Entwickler) gemacht.[11]Agil wird auch verwendet in nicht am selben Ort Teams, die auf der ganzen Welt verteilt werden können. Vorschläge wurden gemacht in Die Distanz überbrücken[12] und in Verwenden eines agilen Softwareprozesses mit Offshore-Entwicklung[13]

Daseinsberechtigung

Agile Daseinsberechtigung:

  • Wenn noch unklar ist, was Sie genau wollen.
  • Wenn erste Ergebnisse schnell erwünscht sind.
  • Wenn sich die Anforderungen ständig ändern
  • Kontinuierliche Verfügbarkeit von Kunden / Benutzern erforderlich, um ihre Wünsche zu ermitteln und die Ergebnisse zu testen.
  • Kann mit Veränderungen gut umgehen, auch spät im Projekt.
  • Es wird behauptet, dass Agile 2 bis 10 mal so schnell / gut ist wie ein traditioneller Prozess.

Begründung traditioneller Verschreibungsmethoden:

  • Wenn man Entwickler nicht wechseln/umschulen will.
  • Wenn Sie hauptsächlich Junior-Entwickler haben
  • Feste Projektanforderungen / scharfe Spezifikationen (wenn im Voraus klar ist, was Sie wollen).
  • Wenn sich das Umfeld nur langsam ändert / wie die (Halb-)Regierung (Steuerbehörden, UWV, Krankenhäuser, GBA, usw.)
  • Kultur, die Ordnung erfordert, keine Änderung der Anforderungen zwischen Abschluss der Analysephase und Umsetzung.

Agile Methoden und Anpassungsmethode

Für die Methodenadaption werden verschiedene Begriffe verwendet, wie beispielsweise Method Tailoring, Method Fragment Adaption und Situational Method Engineering. Die Schneidermethode („Methodenschneiderei“) ist definiert als:

ein Prozess oder eine Fähigkeit, durch die menschliche Faktoren den Ansatz zur Entwicklung eines Systems für eine bestimmte Projektsituation durch koordinierte Veränderungen und dynamische Interaktionen zwischen Kontexten, Absichten und Methodenfragmenten bestimmen.[14]

Fast alle agilen Methoden sind potenziell anpassbar. Auch die DSDM-Methode wird zu diesem Zweck verwendet und wurde erfolgreich in a KMGKontext.[10]Die situative Anpassung gilt als Unterscheidungsmerkmal zwischen agilen Methoden und traditionellen Entwicklungsmethoden, wobei letztere unflexibel und präskriptiv sind. In der Praxis ermöglichen die agilen Methoden Projektteams, Praktiken an individuelle Projektbedürfnisse anzupassen. Praktiken sind konkrete Aktivitäten und Produkte, die Teil eines methodischen Rahmens sind. Auf einer extremeren Ebene kann die Philosophie hinter der Methode, die aus einer Reihe von „Prinzipien“ besteht, modifiziert werden (Aydin, 2004).[15]

XP

Im Fall von XP wurde die Notwendigkeit einer Methodenanpassung explizit gemacht. Eine der Grundannahmen von XP ist, dass es keinen Prozess gibt, der für jedes Projekt gilt, sondern dass Praktiken an die individuellen Projektanforderungen angepasst werden müssen. Es gibt auch keine Erfahrungsberichte, die XP-Praktiken beinhalten. Andererseits gab es mehrere Berichte über die teilweise Anwendung von XP-Praktiken.[16]

Es kann unterschieden werden zwischen statisch und dynamisch Methodenanpassung.[17]Die Grundannahme der statischen Methodenanpassung ist, dass der Projektkontext zu Beginn gegeben ist und während des gesamten Projekts gleich bleibt. Das Ergebnis ist eine statische Definition des Projektkontextes. Bei einer solchen Definition kann aus Fragmenten strukturierter Methoden gewählt werden, bei der dynamischen Methodenadaption wird hingegen davon ausgegangen, dass sich der Projektkontext auch in der Entwicklung befindet. Das bedeutet, dass das Projekt sehr unvorhersehbar ist und sich ändern kann. Es ist daher nicht vorhersehbar, welche Methodenfragmente anwendbar sein werden. Projektleiter werden daher während der Projektdurchführung Methodenfragmente an ihre Bedürfnisse anpassen oder sogar neue erfinden müssen. (Aydin et al., 2005).[17]

Agile Methoden und Projektmanagement

Agile Methoden unterscheiden sich stark in der Überschneidung mit dem Projektmanagement. Einige Methoden werden durch Richtlinien zum Projektmanagement ergänzt.[18]

Agilität messen

Obwohl Agilität als Mittel zum Zweck angesehen wird, wurden mehrere Vorschläge gemacht, sie zu quantifizieren. Agility Index Measurements (AIM) misst Projekte anhand einer Reihe von Agilitätsfaktoren. Der Agility Measurement Index, der fast Namensvetter ist, zeichnet Entwicklungen gegen fünf Dimensionen eines Projekts (Dauer, Risiko, Neuheit, Aufwand, Interaktion) auf. Andere Techniken basieren auf messbaren Zielen. In einer Studie mit Fuzzy Math[19] Es wird empfohlen, die Projektgeschwindigkeit als Maß für die Agilität zu verwenden.

Konferenzen

Agile Entwicklung ist Thema mehrerer Konferenzen. Einige von ihnen haben einen wissenschaftlichen Hintergrund mit Peer-Review Artikel und Fallstudien. Fallstudien teilen Erfahrungen aus der Praxis mit agiler Entwicklung.

Einige Konferenzen, bei denen Erfahrungen veröffentlicht wurden

  • XP (2000, 2001, 2002, 2003, 2004, 2005, 2006)
  • XP-Universum (2001)
  • XP/Agiles Universum (2002, 2003, 2004)
  • XP Days Benelux (2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012)[20]

Ausbildung und Zertifizierung

Mit der zunehmenden Nutzung ist auch ein Markt für die Bereitstellung von Agile/Scrum-Trainings entstanden, die auch mit einer Zertifizierung abgeschlossen werden können. Dies kann bei verschiedenen Behörden erfolgen.[21],[22]

Kritik

Agile Entwicklung wird manchmal als „Cowboy-Coding“ kritisiert. XP sorgte zunächst mit seinen umstrittenen Lehren wie "Pair Programming" und "Continuous Design" für Aufsehen und zog Kritik wie die von McBreen auf sich[23] und Boehm und Turner und in Extreme Programming Refactored von Matt Stephens.[24] Ein Großteil der Kritik wurde von agilen Praktikern als Missverständnis abgetan.[25]

Kritik beinhaltet:

  • Mangel an Struktur, Disziplin und Dokumentation;
  • beinhaltet unzureichendes Softwaredesign;
  • funktioniert nur mit erfahrenen Entwicklern;
  • erfordert zu viel Kulturwandel;
  • man weiß nicht vorher, was man will und bekommt. Dies kann daher zu erschwerten Vertragsverhandlungen mit FestpreisProjekte. Diese sind daher fast unmöglich, man kann sich eigentlich nur auf einen festen Stundensatz einigen.

Literatur

  • Abrahamsson, P., Warsta, J., Siponen, M. T., & Ronkainen, J. (2003). Neue Wege zu agilen Methoden: Eine vergleichende Analyse. Verfahren von ICSE'03, 244-254.
  • Aydin, M. N., Harmsen, F., Slooten van K. & Stegwee, R. A. (2005). Zur Anpassung einer agilen Informationssystementwicklungsmethode. Journal of Database Management Sonderausgabe zu Agile Analyse, Design und Implementierung, 16(4), 20-24
  • Cohen, D., Lindvall, M. & Costa, P. (2004). Eine Einführung in agile Methoden. Im Fortschritte bei Computern (S. 1-66). New York: Elsevier Science.
  • Fowler, Martin. Ist Design tot?. Erschien in Extreme Programmierung erklärt, G. Succi und M. Marchesi, Hrsg., Addison-Wesley, Boston. 2001.
  • Hochschmied, J. Agile Softwareentwicklungs-Ökosysteme. Addison-Wesley-Profi, 2002 (ISBN 0-201-76043-6 )
  • de Jonge, M. (März 2009). Agile (Web-)Entwicklung – nehmen Sie den Wandel an. VORWÄRTS, Artikel #155.
  • Karlstrom, D., & Runeson P. (2005). Kombination agiler Methoden mit Stage-Gate-Projektmanagement. IEEE-Software, 22(3), 43-49
  • Larman, Craig & Basili, Victor R. Iterative und inkrementelle Entwicklung: Eine kurze Geschichte IEEE-Computer, Juni 2003
  • Molendijk, K., Oud, S. (Juni 2008). Auswahl der Softwareentwicklungsmethode: Der Kampf um die Aufmerksamkeit des Projektleiters. Informationen, Nr. 50(5), S. 2 48-52.
  • Riehle, Dirk. Ein Vergleich der Wertesysteme von adaptiver Softwareentwicklung und Extreme Programming: Wie Methoden voneinander lernen können. Erschien in Extreme Programmierung erklärt, G. Succi und M. Marchesi, Hrsg., Addison-Wesley, Boston. 2001.