Kosten, Zeit, Qualität und Umfang im Sinne des Auftraggebers zu optimieren, ist die Herausforderung für Softwareentwicklung in Projekten. Wie Krisen dabei durch Agile Methoden zu bewältigen oder zu verhindern sind, skizziert IT-Freiberufler Christian Noack (zuerst veröffentlicht im IT-Freelancer-Magazin im Oktober 2004).
Von den vier Variablen: Kosten, Zeit, Qualität und Umfang können drei zu Projektbeginn durch den Kunden vorgegeben werden, die vierte ergibt sich daraus. So kann beispielsweise aus Vorgaben zur Projektlaufzeit, den Gesamtkosten und der Qualität der unter diesen Voraussetzungen zu bewältigende Umfang ermittelt werden. Eine Krise tritt jedoch ein, wenn während der Projektlaufzeit die Vorgaben und Prognosen nicht eingehalten werden können.
Traditionelle Phasenmodelle
Bei den Anfang der 200er noch weit verbreiteten dokumentenzentrierten Phasenmodellen (wie Wasserfall oder V-Modell) wird versucht, Krisen bereits in der Anfangsphase eines Projekts zu vermeiden. Durch sehr umfangreiche Analysen und Spezifikationen zu Beginn sollen Kosten, Zeit und Umfang zuverlassig vorherbestimmt werden. Die Qualität der Software wiederum soll in einer abschließen den Testphase validiert werden. Wenn der Zeitliche Rahmen nicht eingehalten werden kann, werden die Entwicklerteams meist vergrößert. Dadurch entstehen Kostensteigerungen.
Qualitätsprobleme fallen allgemein erst am Ende der Entwicklung auf; erforderliche Nachbesserungen wirken sich auf die Zeit und die Kosten aus. Viele Softwareentwicklungsprozesse wie RUP oder Rational Unified Process versuchen, auf diese Probleme mit immer detaillierteren Vorgehensmodellen zu reagieren.
Zu viel Prozess ist jedoch ähnlich problematisch wie zu wenig Prozess - die Entwickler erfüllen nur
noch die formal vorgeschriebenen Teile des Vorgehensmodells. Unter stabilen Voraussetzungen können diese klassischen Prozesse durchaus erfolgreich sein. Es gibt jedoch nur selten stabile Voraussetzungen: Je langer ein Projekt läuft, desto häufiger gibt es Änderungen. Diesem Problem sind die statischen Phasenmodelle nicht gewachsen. Sie werden daher ergänzt um ein change request management.
Neue leichtgewichtige Prozesse seit Ende der 90er Jahre
Seit Ende der 90er Jahre werden die dokumentengestützten insbesondere wegen ihrer Schwäche im Umgang mit Anforderungsänderungen abgelöst durch sogenannte leichtgewichtige Prozesse, auch Agile Methoden genannt wie Crystal, Extreme Programming oder SCRUM. Diese fokussieren, was wirklich wichtig ist: die laufende Software. Voraussetzung dafür:
Akzeptieren, dass SE ein kreativer Prozess ist und nicht das stumpfe Umsetzen von Spezifikationen. Leichtgewichtig bedeutet aber nicht Verzicht auf Dokumentation, sondern deren Reduktion auf ein notwendiges MaB. Einfachheit, Konzentration auf das Wesentliche, Reduktion auf das Benötigte, eine im Sinne des Kunden funktionierende Software ist wichtiger als umfangreiche Dokumentation.
Kommunikation ist wichtiger als Prozess und Werkzeuge. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen. Anpassungsfahigkeit an veränderte Anforderungen (siehe Abbildung) ist wichtiger als sture Planverfolgung.
Agile Methoden stehen also in erster Linie fur einen ,,Wertekanon”. Sobald man erkannt hat, dass diese Werte für das eigene Projekt eine geeignete Grundlage bilden, kann man aus der Vielzahl der Techniken und Praktiken im Umfeld Agiler Methoden die für die jeweiligen Umstände geeigneten auswählen. Die verfgbaren Techniken verbinden normalerweise bereits bewährte. Die neue agile Sichtweise auf vorhandene Techniken ermöglicht aber eine kreative, effiziente Kombination, wie man beispielsweise bei eXtreme Programming (XP) deutlich sehen kann.
Iteratives Vorgehen erlaubt laufende Kostenkontrolle
Das bei Agilen Methoden praktizierte iterative Vorgehen erlaubt eine regelmaBige Kostenkontrolle jeweils am Ende einer Iteration. Zu Beginn jeder Iteration (bei XP von drei bis vier Wochen Dauer, bei SCRUM heißen sie Sprints und dauern 14-30 Tage) wird der Umfang gemeinsam festgelegt und durch den Kunden priorisiert. Sowohl die aktive Beteiligung der Entwickler an der Planung und deren uneingeschrankte Verantwortung — für die Umsetzung der Anforderungen als auch kontinuierliche unit tests und die regelmaBige Ausführung von Akzeptanztests am Ende jeder Iteration sichern zuverlassig die Qualität der Software. Je später Änderungen vorgenommen werden desto teurer sind sie, so die grundlegende Annahme aber auch die Folge von Phasenmodellen. Bei iterativen Prozessen sind Anforderungsmodifikationen Bestandteil des Vorgehensmodells. Spät auftretende Änderungen erzeugen daher kaum höhere Kosten und führen zu keiner Krise.
Agile Methoden auch bei großen Projekten
Bisher standen Agile Methoden im Ruf, für gröBere Projekte ungeeignet zu sein, da diese Verfahren ursprünglich für kleine Teams ausgelegt wurden. Jutta Eckstein weist in ihrer Arbeit aber eindrucksvoll nach, dass Agile Methoden durchaus in großen und verteilten Teams mödglich sind (Jutta Eckstein: Agile Softwareentwicklung im GroBen. Ein Eintauchen in die Untiefen erfolgreicher Projekte. Heidelberg 2004).
Welche Agile Methode konkret eingesetzt wird, hängt vom gesamten Umfeld des Projekts ab. Ob die Wahl beispielsweise auf eXtreme Programming mit einem vergleichsweise streng reglementierten Vorgehensmodell oder SCRUM mit deutlich flexibleren Anpassungsmoglichkeiten fällt, ist zweitrangig. Alle Agile Methoden bieten umfassende Möglichkeiten, Krisen in einem Softwareentwicklungsprojekt zu bewältigen oder sie gar von vornherein zu verhindern.