Iterative Vorgehensweise und agile Entwicklungsmodelle

Agile Entwicklung und iterative Vorgehensmodelle 1

Im ersten Teil unserer Blogserie zum Thema “Agile Entwicklung und iterative Vorgehensmodelle” schauen wir uns die sequenzielle Entwicklung anhand des beliebten Wasserfallmodelles an und verschaffen uns einen ersten Einblick in iterative Vorgehensmodelle.

Für den erfolgreichen Verlauf eines Software-Projektes im Hinblick auf maximalen Kundennutzen und größtmöglichen Output ist die Wahl des richtigen Vorgehensmodells von zentraler Bedeutung. Um die Prinzipien eines iterativen Vorgehensmodells zu erläutern, lohnt es sich vorab einen Blick auf sequenzielle Vorgehensmodelle zu werfen.

Sequenzielle Entwicklung anhand des Wasserfallmodells

Das wohl bekannteste und sehr häufig in der Softwareentwicklung eingesetzte sequenzielle Vorgehensmodell ist das Wasserfallmodell. Bei diesem Modell wird das Projekt in Phasen aufgeteilt, wobei jede der einzelnen Projektphasen erst vollständig abgeschlossen (und oftmals auch abgenommen) sein muss bevor mit der nächsten Phase begonnen werden kann. Die dabei erzeugten Ergebnisse einer Phase werden als Basis für die weiteren Phasen herangezogen. Üblicherweise werden dabei folgende Phasen vorgesehen:

 

Abb: Vereinfachte Darstellung eines Wasserfallmodells (vg. Royce 1970: 1f.)

Das Modell sieht vor, dass sämtliche Anforderungen und notwendigen Maßnahmen zur Umsetzung zu Projektbeginn geplant und anschließend im Rahmen der abgeschlossenen Projektphasen umgesetzt werden. Dabei wird davon ausgegangen, dass durch sorgfältige Planung  verlässliche Voraussetzungen geschaffen werden können, die eine rasche und kostengünstige Durchführung ermöglichen.

Sich ändernde Bedingungen und bewegliche Ziele

Während das Wasserfallmodell bei planbaren Projekten, deren Anforderungen sich detailliert bestimmen lassen und deren Ziele genau definiert werden können, seine Stärken in vollen Zügen ausspielen kann, stößt es bei Änderungen während des Projektverlaufes an seine Grenzen und führt zu hohen Folgekosten bei sich ändernden Bedingungen.

Wie in der Vergangenheit immer wieder festgestellt werden musste und durch zahlreiche Studien belegt wurde, ist bei Softwareprojekten die endgültige und genaue Definition von Anforderungen vor dem Projektstart meist nur ein frommes Wunschdenken. Softwareentwicklung kann als hochdynamischer Prozess bezeichnet werden, wobei oft erst während des Verlaufs Erkenntnisse gewonnen und Ziele genauer definiert werden können.

Eine zusätzliche Schwierigkeit stellt die Abstimmung bzw. Kommunikation mit dem Kunden dar. Durch die schriftliche Aufarbeitung in Form von Lasten- und Pflichtenheften bzw. Konzepten entsteht eine zusätzliche Abstraktions-Schicht. Denn die in Worte gefasste Beschreibung von Softwarekomponenten und Systemen lässt immer einen gewissen Interpretationsspielraum, der zu Missverständnissen und ungleichen Erwartungen führen kann.

Iterative Vorgehensmodelle

Bei sogenannten iterativen Entwicklungsmodellen, welche bereits seit den frühen 1950er Jahren existieren, ist die Aufteilung des Projektes in Iterationen (dt. Wiederholungen) bzw. Kleinst-Projekte vorgesehen. Jede Iteration enhält dabei von der Analyse bis zur Auslieferung alle Disziplinen, welche innerhalb der Iterationsphase sequenziell oder sogar parallel ablaufen können. Nach jeder Iteration soll eine Veröffentlichung (meist zu Demonstrationszwecken) eines stabilen, integrierten und getestenten Teil-Systems erfolgen können, welches ein Bestandteil des Gesamtprojektes darstellt. Damit soll möglichst viel Feedback eingeholt werden, welches in die Definition von Anforderungen und Ziele der nächsten Iteration einfließen kann.

 

Ablauf einer iterativen Entwicklung über drei Iterationen

Abb: Ablauf einer iterativen Entwicklung über drei Iterationen: Das System wächst schrittweise mit jeder Veröffentlichung, da das Feedback einer Iteration zur Detailierung und Anpassung der Anforderungen der nächsten Iteration führt.

Der Kunde bzw. Enduser soll so früh wie möglich mit dem “echten” System in Berührung kommen. Das im Aufbau befindliche System wird damit (be)greifbar und erlebbar und kann so auf seine Alltagstauglichkeit geprüft werden. Erlangtes Feedback fließt unmittelbar in den weiteren Planungsprozess ein.

“Nachjustieren” beim iterativen Vorgehensmodell

Beim Projektmanagement existieren normalerweise vier “Justierhebel“, mit welchen der Projektverlauf gesteuert werden kann: Zeit, Umfang, Ressourcen und Qualität. Beim sogenannten “Time Boxing“, welches Bestandteil aller iterativen Vorgehensmodelle ist, wird der Zeit-Hebel fixiert, d.h. jede Iteration wird mit einem fixen Zeitrahmen geplant. Dadurch bleiben drei Möglichkeiten zur Projektsteuerung übrig. Bei auftretenden Problemen wird bevorzugt der Umfang justiert, indem einzelne Aufgaben anhand ihrer Priorität auf die nächste Iteration verschoben werden.

Ausblick: Fortsetzung folgt …

In unserem kommenden Blogpost werden wir diese Serie weiterführen und agile Entwicklungsmodelle etwas genauer unter die Lupe nehmen. Im Weiteren bieten wir dann einen Einblick aus welchen Methoden sich die Vorgehensweise zusammensetzt, die wir für Entwicklungs- und Intergrationsprojekte insbesondere im Hinblick auf die Erstellung von Unternehmensportalen für uns adaptiert haben.

 

Weitere Informationen zu den behandelten Themen finden Sie unter folgenden Links:

http://de.wikipedia.org/wiki/Wasserfallmodell
http://de.wikipedia.org/wiki/Timeboxing

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>