Benutzerspezifische Werkzeuge

Agile Vorgehensmodelle

Agile Vorgehensweisen geraten zunehmend in den Fokus des allgemeinen Interesses. Sie versprechen schnelle flexible Projekte, die mit hoher Qualität besser den Bedürfnissen der Kunden entsprechen, als klassische Vorgehensmodelle. Dieser Artikel gibt einen allgemeinen Überblick über die "Agilität". Im Weiteren werden zwei bekannte Vertreter der Agilen Vorgehensmodelle, XP und Scrum, genauer vorgestellt.

Agilität

Agile Methoden bündeln Entwicklungsmaßnahmen, die mit leichtgewichtigen Vorgehensweisen eine höhere Flexibilität versprechen. Zentrale Ideen sind ein frühes Einsteigen in die Codierung, starke Einbeziehung der Nutzer, beständiges Testen und die Weiterentwicklung der Architektur. Diese Werte wurden im "Agilen Manifest" (Manifesto for Agile Software Development) niedergeschrieben. Sie beschreiben die grundlegende Philosophie der agilen Entwicklung, und zwar:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Ergänzt werden diese Werte durch sogenannte Prinzipien, wie Zweckmäßigkeit, Kundennähe oder dass der im Projekt erstellte Code allen Teammitgliedern "gehört" (im Sinne einer offen zugänglichen Codebasis für das Team).

Agile Vorgehensweisen beschreiben Techniken und Methoden, die als Baukasten in Projekten kombiniert werden können. Prominente Vertreter sind das Pair Programming, Test-driven Development, Continuous Integration oder das Unit Testing. Solche Elemente agilen Vorgehens kann man in auch in großen Projekten und insbesondere in den als schwergewichtig bezeichneten Vorgehensmodellen mit einbringen. So ist beispielsweise der Unit Test [Beck 2002] eine breit akzeptierte Technik, die z.B. auch im Rational Unified Process oder im V-Modell XT Anwendung finden kann. 

Rein agile Vorgehensweisen eigen sich aber nur für Projekte überschaubaren Umfangs. Weiterhin sind agile Projekte darauf angewiesen, dass sich alle am Projekt beteiligten Parteien auf das Vorgehen verständigen und sich daran halten. Insbesondere im Bereich der Vertragsgestaltung sind agile Vorgehensweisen kritisch, da z.B. die Offenheit gegenüber Änderungen im Zweifelsfall einer Vertragsänderung entspricht und auch Festpreisprojekte sehr schnell kritisch werden können, wenn z.B. durch "ausuferndes" Prototyping viel Aufwand für wenig Produktivcode verbraucht wird. Auch muss berücksichtigt werden, dass agile Vorgehen in "vagen" Szenarien ihre Vorteile klar ausspielen können, diese jedoch in "stabilen" Projekten mit klaren Anforderungen nicht zur Geltung kommen. Die Entscheidung für oder gegen ein agiles Vorgehen ist somit stark an den Projektcharakter gekoppelt.

In den letzten Jahren haben sich viele agile Vorgehensweisen entwickelt. Die bekanntesten sind das Extreme Programming (XP, [Beck, Andres 2004]) und Scrum [Schwaber 2004].

Extreme Programming

Das XP ist ein inkrementell, iteratives Vorgehen, in dem sich das Entwicklungsprojekt unter starker Einbindung des Kunden schrittweise dem Projektziel nähert. XP geht davon aus, dass der Kunde zum Projektstart die Anforderungen noch nicht vollständig erfasst hat, sodass bereits von Anfang an Änderungen und Verschiebungen der Prioritäten erwartet werden.

Um sich dem Projektziel schrittweise anzunähern, wird kontinuierlich programmiert und es werden lauffähige Prototypen erstellt. Auf Basis einer Feedbackschleife mit dem Kunden werden die realisierten Funktionen evaluiert und entweder abgenommen oder die Anforderungen bzw. die Implementierung angepasst (Refactoring siehe [Fowler, Beck, Brant, Opdyke 1999]) – bis zur nächsten Iteration. Da der Kunde kontinuierlich über den aktuellen Entwicklungsstand informiert ist und diesen begutachten muss, werden Fehlentwicklungen schnell sichtbar.

XP ist besonders durch seine Praktiken bekannt geworden, die in ähnlicher Form auch von anderen Vorgehensweisen adaptiert wurden. Die bekanntesten sind:

  • Kommunikation
  • Continuous Integration
  • Test-driven Development
  • Refactoring

Scrum

In Scrum organisieren sich Teams weitgehend selbstständig anhand gewisser Rituale (Daily Scrum etc.). Die Grundannahme von Scrum ist es, dass Projekte komplex und somit nicht von Anfang an detailliert planbar sind. Daher wird für das Projekt ein grober Rahmen vereinbart, in dem sich das Team selbstorganisierend bewegen kann.

Die vier grundlegenden Annahmen, auf denen Scrum aufbaut, entsprechen den Prinzipien der agilen Entwicklung (siehe oben). Scrum besitzt kein detailliert ausgeprägtes Rollenmodell, wie z.B. der Rational Unified Process oder das V-Modell XT, sondern verteilt die Aufgaben im Projekt auf drei Rollen. Die Verantwortung für das Ergebnis übernimmt ein sog. Product Owner, der im Wesentlichen mit dem Projektmanager zu vergleichen ist. Er wählt die umzusetzenden Anforderungen aus einem Product Backlog aus, priorisiert diese und sorgt für die Erreichung der gesetzten Ziele. Die Implementierung wird durch das Team durchgeführt, das selbstorganisierend innerhalb Sprints bestimmt, welche Elemente des Backlogs umgesetzt werden. Das Team hat dabei das Recht, eine Auswahl zu treffen, verpflichtet (commitment) sich dafür aber auch, das durch die Auswahl gesetzte Ziel zu erreichen. Der Scrum Master ist abschließend dafür zuständig, dass der Scrum-Prozess im Projekt umgesetzt wird. Er muss dafür sorgen, dass das Team produktiv arbeiten kann. Der Scrum Master ist kein Mitglied des Projektteams. Er hat keine Weisungsbefugnisse bezüglich des Projektgegenstands und mischt sich nicht in die Kommunikation zwischen Projektteam und Product Owner ein. Allerdings hat er die Pflicht, darauf zu achten, dass das Projektteam sich ohne Einflussnahme des Product Owners selbst organisieren kann. Somit ist der Scrum Master eine Art Mentor und Kontrollinstanz für das Projekt in Prozessfragen.

Genau wie beim Rollenmodell ist Scrum auch in Bezug auf die Artefakte und das Prozessmodell sehr schmal. Im Wesentlichen fokussiert Scrum das gesamte Projekt auf das Product Backlog und das Sprint Backlog. Ersteres enthält alle Anforderungen an die zu realisierende Software (Features). Das Product Backlog muss nicht vollständig sein und kann mit dem Wissenszuwachs im Projekt wachsen, also um neue Anforderungen ergänzt werden. Diese werden regelmäßig priorisiert und bewertet. Hoch priorisierte Features werden in das Sprint Backlog übernommen. Das Sprint Backlog enthält alle Aufgaben, die das Team im anstehenden Sprint bearbeitet. Der Erfüllungsgrad der Aufgaben wird täglich in einem sog. Burndown-Chart dargestellt. 

Der Sprint selbst ist das zentrale Element des Prozessmodells. Er kennzeichnet eine Iteration in Form einer Time Box. Jeden Tag soll ein sog. Daily Scrum durchgeführt werden. Dieses Ritual dient dazu, dass jeder im Projektteam berichtet, was sein aktueller Arbeitsstatus ist, was er bis zum nächsten Daily Scrum bearbeiten will und wo er möglicherweise Probleme im Projekt hat, die der Scrum Master lösen muss. Ziel ist es, dass möglichst jeder im Projekt über den aktuellen Status informiert ist. Nach jedem Sprint soll eine lauffähige Version der Software vorliegen, die durch den Kunden durch ein Review geprüft wird. Änderungsforderungen, die der Kunde im Rahmen des Reviews aufstellt, werden wieder in das Product Backlog eingepflegt. Ebenfalls am Ende eines Sprints ist das Projektteam dazu aufgerufen, in eine Retrospektive zu gehen und den zurückliegenden Projektabschnitt zu bewerten. Die Erfahrungen werden im nächsten Sprint berücksichtigt, bzw. an den Scrum Master zurückgemeldet, wenn Probleme zu beseitigen sind.

Scrum ist eine agile Methode, die hohe Anforderungen sowohl an die Organisation als auch an die Projektteams und die einzelnen Mitarbeiter stellt. Die Organisation muss einen hohen Reifegrad besitzen und insbesondere Techniken wie automatische Testverfahren und Refaktorierung beherrschen. Die Mitarbeiter müssen in modernen Programmiertechniken ausgebildet sein, um in den kurzen Iterationen des Projekts auch Ergebnisse produzieren zu können. Weiterhin ist Scrum von einem sozial ausgewogenen Team abhängig. Dominante Einzelcharaktere stören das selbstorganisierende Team und wirken negativ auf die Produktivität.

Literatur

Beck, Kent;Andres, Cynthia: Extreme Programming Explained: Embrace Change. Addison-Wesley Longman, Amsterdam, 2004

Schwaber, Ken: Agile Project Management with Scrum. Microsoft Press, 2004.

Beck, Kent: Test Driven Development. By Example. Addison-Wesley Longman, Amsterdam, 2002.

Fowler, Martin; Beck, Kent; Brant, John; Opdyke, William: Refactoring: Improving the Design of Existing Code. Addison-Wesley Longman, Amsterdam, 1999.

 

Autor


 

Dr. Marco Kuhrmann, Technische Universität München, Institut für Informatik, Boltzmannstr. 3, 85748 Garching

Autoreninfo


Zuletzt bearbeitet: 21.02.2013 16:46
Letzter Abruf: 18.12.2017 08:07
Artikelaktionen