Agile Festpreisprojekte
Agile Softwareentwicklung und Festpreisprojekte – Wer kurz darüber siniert kommt ganz schnell zu dem Ergebnis, dass dies nicht funktionieren kann. Nun sind wir bei WOGRA verfechter der agilen Philosophie, aber geben unseren Kunden immer die Möglichkeit ein Festpreisprojekt mit uns durchzuführen.
Wie kann das erfolgreich funktionieren?
Der erste Schritt ist schon mal, die richtige agile Vorgehensweise zu wählen. Viele IT’ler und Kunden denken bei agiler Vorgehensweise an SCRUM. SCRUM ist toll und SCRUM Entwicklung im Team kann richtig Spaß machen, aber für Festpreisprojekte nur schwer realisierbar. Jetzt werden natürlich einige sagen, dass man den Weg sowohl gehen kann und dabei Sprints (Iterationen von 2 – 4 Wochen in einem SCRUM Projekt) zu einem Festpreis anbieten und definieren muss, was innerhalb einer Iteration geleistet werden soll. Das ist aber nicht die Idee von SCRUM, sondern erhöht wieder den Druck auf das Team und nimmt dem Team die Möglichkeit Stories von einer Iteration auf die nächste zu verschieben.
Das ist aber nicht unsere Idee. Wir gehen den Weg von Feature Driven Development. Die Idee von Feature Driven Development enthält viele gute Errungenschaften der agilen Methoden, aber sorgt zugleich dafür, dass Kunden, die herkömmliche Vorgehensweisen wie den Wasserfall gewohnt sind, sehr gut damit abgeholt werden können.
Feature Driven Development in der Praxis
In Workshops legen wir fest, wie das Gesamtresultat am Ende des ersten Entwicklungsprojektes aussehen soll. Hierbei wird priorisiert und die wichtigsten Features aufgenommen. Dabei wird der Projektzeitraum relativ klein gewählt und dauert im Durchschnitt 3 – 4 Monate. Ein Projekt sollte maximal ein halbes Jahr laufen. Die für dieses Projekt priorisierten Features werden ausformuliert und von uns geschätzt. So sind wir in der Lage eine fundierte Aufwandsschätzung durchzuführen. Bei Feature Driven Development schätzen wir auch nicht in StoryPoints sondern in Personentagen (PT). Aber wir halten uns auch an die agilen Schätzregeln. Wir zerteilen Features in Tasks. Ein geschätztes Feature, das größer als 10 PT ist, wird aufgeteilt. Es wird im Team geschätzt und auch bei uns wird „gepokert“. Das heißt, jeder schreibt seine geschätzten PT auf eine Karte und verdeckt sie zunächst. Dann decken alle gleichzeitig auf und die Kollegen mit der höchsten sowie der niedrigsten Schätzung müssen erklären, weshalb sie so geschätzt haben. Das machen wir, weil dies die Schätzqualität deutlich erhöht.
Ein weiterer Vorteil von agilen Methoden sind kurze Entwicklungszyklen. Auch das können wir mit Feature Driven Development leisten. Es ist jedoch so, dass der erste Zyklus ein Architektur Zyklus ist, um für das zu entwickelnde System eine stabile Basis zu erarbeiten. Danach können wir je nach Kundenwunsch in 2 bis 4 Wochen funktionsfähige Software zur Verfügung stellen. Das Feedback, dass wir hier erhalten, können wir auch direkt in die Software integrieren. Das ist für uns günstiger, als wenn wir Änderungen am Ende des Entwicklungszeitraum integrieren und größere Anpassungen vornehmen müssen. In einem Festpreisprojekt sind Risikopuffer eingeplant, die genau für diese Zwecke gedacht sind.
Spontane Feature Requests – jederzeit integrierbar
Ein weiterer Punkt des agilen Manifest lautet: „Wir begrüßen Veränderungen“. Ist das noch machbar? Selbstverständlich! Wenn der Kunde nach einer Iteration zu uns kommt und eine neue Anforderung mitbringt, die wichtig für das System ist, analysieren wir den Aufwand und schieben es in die nächste Iteration. Dafür muss ein weniger wichtiges Feature, das noch nicht umgesetzt wurde und ähnlichen Aufwand hat, aus dem Projekt entnommen werden. Dieses Feature könnte dann in einer folgenden Projektphasen umgesetzt werden.
Eine gute Frage ist natürlich, was passiert, wenn ein größeres Feature aus dem Projekt herausgenommen wird und die neuen Feature nicht den gleichen Wert entsprechen? In der Regel bieten wir unseren Kunden an, das Rest-Budget als Gutschrift in die nächste Projektphase zu übertragen. Dann haben sie den Vorteil, dass sich das Projektbudget für das Folgeprojekt reduziert und es evtl. weniger Aufwand bedeutet, die nächste Entwicklungsphase genehmigen zu lassen.
Die Frage kann aber auch umgekehrt gestellt werden: Was passiert, wenn das neue Feature so groß ist, dass ich nicht genügend andere weniger wichtige Features herausnehmen kann? Auch dann muss es nicht zwangsläufig zu Mehrkosten kommen. Dies hängt jedoch von der Projektsituation ab. Haben wir noch ausreichend Puffer, wird dieser verwendet um das Feature umzusetzen, wenn dadurch kein größeres Risiko für das Projekt entsteht. Ist dem nicht so, so müssen wir den Mehraufwand in Rechnung stellen.
Transparenz als entscheidender Faktor
Auch hier ist es natürlich so, dass je früher ein neues großes Feature erkannt wird, umso mehr Spielraum hat man mit dem Projektbudget. Wenn es um Budgets geht, ist Transparenz der entscheidende Faktor. Wenn der Kunde unsere Aufwände nachvollziehen kann, entwickelt er ein viel besseres Verständnis und egal welches Modell – sei es Festpreis, nach Aufwand o.ä. – wird besser funktionieren. Wenn dieses Vertrauen entstanden ist, dann spielt es keine Rolle mehr, wie die Abrechnung erfolgt.
