Agile Entwicklungsmodelle zur Abwicklung komplexer Projekte

In ihrem Artikel „Achieving success in large, complex software projects“ schreiben McKinsey über die Besonderheiten komplexer Entwicklungsprojekte.

In einem der Schaubilder kann man sehr gut erkennen, welchen eigentlichen Vorteil die agile Entwicklungsmethode bietet.

Der Entwurfszyklus im Überblick

In dem bereits erwähnten Artikel (siehe „weiterführende Informationen“ weiter unten) benennt der Autor eine interessante Größenordnung. Demnach läuft ein sehr großer Prozentsatz der komplexen Projekte schlecht bis sehr schlecht:

 „A joint study by McKinsey and Oxford Uni­versity found that large software projects on average run 66 percent over budget and 33 percent over schedule; as many as 17 percent of projects go so badly that they can threaten the very existence of the company.“

Die Autoren gehen im Rahmen der Lösungssuche auf zwei Entwicklungsmodelle ein. Das erstgenannte Modell beschreibt eine Organisation, die nach der Wasserfallmethode arbeitet. Das zweite Modell behandelt eine Organisationsform, die man auch in agilen Organisationen so findet.

Die Bewertung ist, wie ich sie erwarten würde.

Wasserfall

Die erstgenannte Methode fördert demnach die Bildung von Silos, und (interessant für das Produktmanagement) sie erfordert, daß Requirements definiert sind, bevor die Entwicklung überhaupt startet:

„We have found that for many large, complex application-development projects, functionally organized team structures are counter-productive. Each function takes ownership only of its part of the software-development life cycle instead of delivering working functionality to the end user.“

Agiles Modell

Im agilen Modell verwendet cross funktionale Teams, d.h hier sind Entwickler, Tester oder Produktexperten Teil desselben Teams.  Dies bietet sehr viele Vorteile, wie die Autoren schreiben:

„When applied well, cross-functional units can have multiple benefits, including increased indi­vi­dual and collective accountability, better communication and coordination, and shorter iterations.“

Erfahrungen

Ich habe in beiden Modellen gearbeitet, und kann die Ergebnisse der Studie genau so unterschreiben. Allerdings denke ich, daß man die agile Methode auch bei Projekten verwenden kann, die nicht sehr strukturiert sind, man muss sie nur „hierarchisch“ (im Sinne der Inhalte) verwenden.

Ein visueller Grund für den Nutzen der agilen Methode springt den Leser des erwähnten Artikels förmlich an.

Nutzen Visuell

Schauen Sie sich dort einmal die Pfeile an, mit denen gezeigt wird, wie der Business User eingebunden wird.

  • In der Wasserfallmethode wirkt dieser User an den Anforderungen mit, und wird später noch einmal aktiv bei der Klärung von Fragen, die sich aus Entwicklung und Test ergeben haben. Dieser Prozess ist stark desintegriert, und es bleibt zu vermuten, daß die Rückkopplung oft ausbleibt.
  • In der agilen Methode mit cross-funktionalen Teams gibt es eine direkte Rückkopplungsschleife zwischen der Anforderung, der Umsetzung, dem Test, und der Anforderung (bzw dem User). Die formal eingesetzte Methode ist das „User-acceptance Testing“, das hier durch Business User erfolgt, und bei der ersten Methode durch Tester.

Ergänzungen

Zwei Ergänzungen sind in der Praxis wichtig:

  • User Acceptance Tests müssen nicht unmittelbar immer mit Endkunden stattfinden. Vielmehr kann man schon viel erreichen, indem man die Anforderungen bereits so erhebt und dokumentiert, daß man sie später auch als Grundlage für den Test verwenden kann („Specification by Example„).
  • Laut Schaubild finden mehrere Testzyklen auf Modulebene statt. In der Realität wird man versuchen, die drei gezeigten Module zusätzlich in einer Konsolidierungslandschaft zusammenzubringen, um sie dort mittels Integrations- und Szenariotests zu überprüfen. Hierbei entsteht ein Modell, das man mit den Schalen der Zwiebel vergleichen kann: Auf Modulebene werden begrenzte Modultests durchgeführt, die sich auf die Anforderungen zum Modul konzentrieren. Die in der Ebene darüber stattfindenden Integrationstests konzentrieren sich auf größere Szenarien.

Alles in allem sind die Vorteile der agilen Methodik aber sehr gut auf den Punkt gebracht.

Weiterführende Informationen

Das Original dieses Artikels ist auf Der Produktmanager erschienen (©Andreas Rudolph). Folgeartikel zum Thema gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen.

In der Online Version des Artikels finden Sie hier die versprochenen weiterführenden Links:

0saves
If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.

Comments are closed.