Das Rückgrat der Zeitplanung in Projekten ist die Aufwandschätzung. Dafür verwendete Verfahren, wie z.B. Function Point Analysis oder Predictive Object Points greifen allerdings nur, wenn weit reichende Spezifikationen des angestrebten Projektergebnisses zur Verfügung stehen. Diese zu erzeugen, ist Ziel in konventionellen Vorgehensmodellen. Projekte in der Software-Entwicklung laufen jedoch typischerweise in einem Zustand weitgehender Unwissenheit bzw. Unsicherheit ab, mit einem permanenten Lernprozess im Projektverlauf.

Benutzt man die genannten Schätzmodelle unter solchen unsicheren Bedingungen und in Zeiten beschleunigten Wandels, wie das z.B. in der serviceorientierten Architektur (SOA) und Web 2.0 der Fall ist, wird der Aufwand regelmäßig unterschätzt. Das führt zu Qualitätsverlust und Fehlentwicklungen, die am Bedarf des Kunden vorbeigehen und deshalb nicht akzeptiert werden - und letztendlich zum Scheitern des Projekts.

Alternativ lassen sich für eine relativ große Klasse von Software-Projekten agile Vorgehensmodelle verwenden. Diese werden jedoch noch kaum akzeptiert, da sie oft anstelle klarer Regeln und Prozesse nur den Begriff der "kollaborativen Werte" setzen (The Agile Manifesto, 2001).

Dieser Beitrag soll Ihnen aufzeigen, wie man mit einer agilen Vorgehensweise - auch bei räumlich verteilten Teams unter Outsourcing-Bedingungen - zuverlässige Aufwandschätzungen und Projektpläne erhalten kann. Einzige Voraussetzung ist eine verbindliche und verantwortungsvolle Projektkultur.

Entwickeln in Zeiten von SOA und Web 2.0

Software-Entwicklungsprojekte beinhalten - unabhängig von den konkreten Zielen - immer den Übergang von einer vagen Idee zu einem konkreten Produkt. Dabei ist eine zutreffende und realistische Aufwandschätzung notwendig, um die Projektarbeiten zielorientiert und risikobewusst steuern zu können. Da der Markt von den Unternehmen immer mehr Flexibilität erwartet, müssen auch die IT-Lösungen, insbesondere Softwarelösungen diesen Anforderungen entsprechen. Besonders gut lässt sich diese Entwicklung in dem derzeit vorherrschenden Architekturparadigma der serviceorientierten Architektur (SOA) nachvollziehen. Die IT-Lösungen von heute sind eine permanente Baustelle, in der Altes und Neues entwickelt, verbunden, auseinander gerissen und wieder zusammengesetzt wird, ganz nach den Geschäftsanforderungen.

Außerdem sind die Grenzen der Organisationen ständig in Bewegung. Kooperative Strukturen bilden sich heraus, Partnerschaften werden eingegangen und wieder gelöst, Unternehmen werden gegründet, fusionieren oder lösen sich auf.

Dieses pulsierende Geschehen hat auch zu dem Phänomen "Web 2.0" geführt. Dabei handelt es sich um eine Sichtweise, die immer stärker die Art und Weise diktiert, wie im Internet Anwendungen bereitgestellt werden. Aussagen wie "gemeinschaftliche Nutzung kollektiver Intelligenz" oder "Schaffung von Mehrwert für alle Teilnehmer" (Högg, Meckel, 2006) klingen zunächst vielleicht übertrieben, dennoch gibt es immer mehr erfolgreiche Geschäftsmodelle mit diesem Ansatz. Web 2.0 hat den Gedanken der Heterogenität von Systemen salonfähig gemacht. Die Plattformen für Web 2.0 erlauben es, eine Vielzahl unterschiedlicher Endgeräte und Programme zu kombinieren, indem sie diese als Dienste integrieren. Dazu passen keine langen Release-Zyklen und lokal installierte Applikationen mehr. Alles wird flüchtiger und ist ständig in Bewegung.

Viele Software-Projekte sind direkt oder indirekt von diesen Entwicklungen betroffen. Zum einen sind immer häufiger serviceorientierte Architekturen zu bedienen, zum anderen wirken die Ideen und der Takt von Web 2.0 als Paradigmenwechsel auch in den Köpfen der beteiligten Menschen - und zwar bei Anwendern und Entwicklern gleichermaßen. Verkürzte Anwendungs-Lebenszyklen, die von mehreren Jahren auf wenige Monate zurückgegangen sind, erhöhen die Unsicherheit in Bezug auf den Umfang und die Qualität der benötigten Funktionalität.

Bisher erfolgreiche Prozessmodelle mit starker Betonung der Phasenübergänge können diesen Herausforderungen nur schwer begegnen. So geht beispielsweise das Wasserfallmodell davon aus, dass sich Anforderungen bereits in der Planungsphase präzise beschreiben lassen. Dabei wird außer Acht gelassen, dass sich die Anforderung während des Projektverlaufs ändern können und sich die Domänenkenntnisse mit zunehmendem Detaillierungsgrad erhöhen. Das Wasserfallmodell wurde bereits in den 70er Jahren kritisiert, spielt jedoch vor allem in der Lehre, aber auch in der allgemeinen Vorstellung von Auftraggebern immer noch eine dominante Rolle.

Verfeinerte phasenbetonte Ansätze finden sich vor allem in Vorgehensmodellen, die sich schwerpunktmäßig auf die Bereitstellung eines Ordnungs- und Dokumentationsrahmens für die Projektdurchführung konzentrieren. In der Regel stellen diese Modelle umfangreiche Methodensammlungen zur Verfügung, die durch Maßschneidern (Tailoring) auf den benötigten Umfang zurechtgestutzt werden sollen. Beispiele dafür sind das V-Modell mit seinen Modifikationen oder sog. schlanke Vorgehensmodelle wie der Rational Unified Process. Diese theoretisch sehr ansprechenden Ansätze begegnen der wachsenden Dynamik der anfordernden Märkte durch eine massive Verstärkung der Kontroll- und Steuerungsmechanismen bei der Projektdurchführung. Vor dem Hintergrund der aktuellen Entwicklungen werden viele Projekte zu klein sein, um den damit gestiegenen Verwaltungsaufwand zu erwirtschaften.