Agiles Projektmanagement oder Wasserfallmodell: Zwei Arten der Projektumsetzung
Klassische Softwareprojekte bestehen im Kern aus drei Phasen: Konzeption, Umsetzung und Qualitätssicherung. Meist wird dabei das Gesamtvorhaben aus einem Lastenheft (Anforderungskatalog) in ein präzisiertes Pflichtenheft überführt. Dieses Dokument wird vom Auftragnehmer entwickelt und in mehreren Runden mit dem Auftraggeber abgestimmt. Sobald die Abstimmungsphase abgeschlossen ist, beginnt ein Team mit der Umsetzung des Vorhabens auf Basis der vereinbarten Dokumente. Am Ende erfolgt die Qualitätssicherung, bevor dann dem Auftraggeber das „fertige“ Produkt übergeben wird.
Meist kommt dann das große Erstaunen auf beiden Seiten, da der Auftraggeber zwar im Grunde das bekommt, was er bestellt – aber nicht unbedeingt das, was er sich vorgestellt hat. Wenn es für den Auftragnehmer gut lief, hat er sich bei seinem Festpreis nicht allzusehr verschätzt. Denn eigentlich ist es doch so: Man weiß immer erst zum Ende des Projekts, wie lange es gedauert hat, welche Schwierigkeiten auf dem Weg zu umschiffen waren und wo man „tricksen“ musste, damit man noch im versprochenen Zeitplan bleibt. Idealerweise ist der Kunde dann auch nur ein bisschen traurig über das Produkt.
Bei dieser Vorgehensweise spricht man vom Wasserfallmodell, was mit der üblichen grafischen Darstellung als Kaskade zusammenhängt (es geht stufenweise abwärts). Natürlich gibt es gelegentlich durchaus auch erfolgreiche Produktentwicklungen nach dem Wasserfall-Prinzip. Gelegentlich.
Agiles Projektmanagement
Aus solchen Erfahrungen kann man lernen und etwas Grundsätzliches ändern. Es geht dabei um die Verkürzung der drei Phasen (Konzeption, Umsetzung und Qualitätssicherung). Diese Phasen werden nicht mehr als in sich geschlossene, nacheinander ausgeführte Handlungen für das Gesamtprodukt betrachtet sondern während der gesamten Projektdauer zyklisch für einzelne Anforderungen durchgeführt. Dabei wird das Gesamtprojekt in regelmäßige, kurze Intervalle unterteilt, in denen sich die Phasen wiederholen. Diese Intervalle dauern üblicherweise wenige Wochen und werden so lange fortgeführt, bis alle Leistungsmerkmale des Gesamtprojektes abgearbeitet wurden.
Eine wichtiges Grundprinzip ist die unbedingte Transparenz. Transparenz sowohl innerhalb des Umsetzungsteams als auch gegenüber dem Auftraggeber. Da dieser die gewünschten Funktionalitäten am besten kennt, kann er auch am besten beurteilen, ob diese seinen Vorstellungen entsprechend umgesetzt wurden. Dabei ist es unerheblich, ob die Anforderungen natürlichsprachig formuliert sind („wenn ein Nutzer sich angemeldet hat, soll er die geschützten Dokumente herunterladen können“) oder eher technisch, z. B. in Form eines Flussdiagramms.
Das Team bespricht den optimalen Ansatz, eine Anforderung umzusetzen, führt nach der Umsetzung die Qualitätssicherung durch und stellt die Lösung zur Abnahme bereit. Richtig: bei dieser Methode ist der Auftraggeber stärker eingebunden, kann und soll sich Zwischenstände ansehen und überprüfen, ob seine Anforderungen richtig verstanden und umgesetzt wurden. Sollte dies nicht der Fall sein, können einzelne Bestandteile noch umgebaut werden, bevor andere darauf aufbauen.
Diese Transparenz fördert nicht nur das Verständnis zwischen Auftragnehmer und Auftraggeber, sondern sorgt auch für mehr Produktivität innerhalb der Umsetzungsteams. Regelmäßiger Austausch in gemeinsamen kurzen Besprechungen macht deutlich, welche Hürden den Fortschritt behindern oder wo es Ressourcenengpässe gibt, die durch das hohe Maß an Transparenz auch schnell beseitigt sind. Da auch der Auftraggeber an der Kommunikation beteiligt ist, kann er seine Anforderungen durchaus auch während der Umsetzung neu priorisieren – oder gar verwerfen. Wenn sich beispielsweise herausstellt, dass sich die Umsetzung einer Anforderung äußerst zeitaufwendig gestaltet, deren Nutzen als relativ gering eingeschätzt wird, kann gemeinsam beschlossen werden, dass diese Aufgabe zugunsten des Projektfortschritts verworfen wird.
Unwägbarkeiten gibt es in der Softwareentwicklung immer. Auch dann, wenn man bei der ersten Einschätzung vermuten darf, dass es sich um Routineaufgaben handeln mag. Jedes Projekt ist ein bisschen anders. Und weil auf diese Unwägbarkeiten agil reagiert werden kann, muss auf ein typisches (und gern gefordertes) Element der „Wasserfallmethode“ verzichtet werden: mit Datum versehene Meilensteine. Natürlich darf es einen Release-Termin geben („Zur Messe im November muss die Website veröffentlicht sein.“) Aber Abstriche müssen möglich sein. Der volle Funktionsumfang in einwandfreier Qualität und ein knapper Umsetzungszeitraum und ein eingehaltenes Budget gehen in den seltensten Fällen Hand in Hand. Verabschieden Sie sich von dieser Vorstellung, und Sie erleben keine bösen Überraschungen.
Agiles Projektmanagement unterstellt, dass jedes Teammitglied am Projektfortschritt und einer zügigen Fertigstellung interessiert ist. Die Tatsache, dass in immer mehr Softwareentwicklungsteams agile Methoden Einzug halten, bestätigt, dass diese Unterstellung der Annahme vorzuziehen ist, der Mensch sei im Grunde faul und müsse durch hohen Zeitdruck oder gar Sanktionen angetrieben werden. Eine Vorgehensweise, die ohnehin nur in wirtschaftlichen Abhängigkeitsverhältnissen anwendbar ist. Die auf Freiwilligkeit basierende Open-Source-Entwicklergemeinde beweist, dass Softwareentwicklung auch dann bestens funktioniert, wenn ausschließlich die Fertigstellung von Aufgaben im Mittelpunkt steht.
Vertiefung
Die Gegenüberstellung der verschiedenen Methoden agiler Softwareentwicklung würde an dieser Stelle den Rahmen sprengen. Suchen Sie für den Einstieg im Internet nach folgenden Methoden:
- Kanban
- Scrum
- Extreme Programming
- Prototyping
Es gibt auch eine wachsende Zahl regelmäßiger Meetups zum Stichwort „Agile“ – vielleicht auch in Ihrer Nähe. Eine Suche in den gängigen Sozialen Netzwerken dürfte sich auf jeden Fall lohnen.