Scrum und Co.

Schlank planen, agil entwickeln, Kosten einhalten

Prof. Dr. Volker Gruhn gründete 1997 die adesso AG mit und ist heute Vorsitzender des Aufsichtsrats. Er ist Inhaber des Lehrstuhls für Software Engineering an der Universität Duisburg-Essen. Sein Forschungsschwerpunkt in diesem Bereich bezieht sich auf mobile Anwendungen. Gruhn ist Autor und Co-Autor von rund 200 nationalen und internationalen Veröffentlichungen und Konferenzbeiträgen.

Die Flexibilität des Starren: Agile Festpreise - oder etwas Ähnliches

Agile Festpreise in Reinkultur kann es nicht geben. Wenn das Modell es zulässt, dass regelmäßig neu priorisiert wird, können die Projektbeteiligten nicht zusagen, welcher Funktionsumfang bis wann geliefert wird. Und auch nicht, wie teuer er wird. Kurze Phasen - der nächste Sprint, vielleicht auch noch der übernächste - sind überschaubar. Für solche Phasen sind feste Preise möglich (siehe unten: "Agile Festpreise im ganz Kleinen").

Foto: liubomirt - Fotolia.com

Für lange Zeiträume wird es schwieriger; Agilität verbessert die Prognosefähigkeit nicht gerade. Und trotzdem gibt es Modelle, die das Einhalten von Preiskorridoren gewährleisten (siehe unten: "Agile Festpreise im Mittelgroßen"). Diese Modelle werden unter dem Namen "Shared Pain / Shared Gain" zusammengefasst. Auftraggeber gewinnen gemeinsam (bei "schlanker Software") und verlieren gemeinsam (bei "fetter Software"). Ein Beispiel für Shared-Pain-/Shared-Gain-Modelle ist adVANTAGE (siehe adVANTAGE: A Fair Pricing Model for Agile Software Development Contracting).

Agile Festpreise im ganz Kleinen (ein Sprint)

Für kurze Zeiträume können die Beteiligten Anforderungsstabilität annehmen und Anforderungsänderungen ausklammern. Selbst ohne vollständige Spezifikation können sie die Funktionalitäten, die sie in den nächsten vier Wochen realisieren sollen, abschätzen und kalkulieren (Die neben den zu entwickelnden Funktionen anfallenden Grundausgaben für Product Owner, Scrum Master, Elaboration, Integrationstest und Release-Erstellung werden im Preismodell durch eine Grundpauschale abgedeckt, die in geeigneter Weise auf die einzelnen Features umgelegt wird).

Das ist nichts anderes als ein fester Preis für ein kurzes Entwicklungsprojekt. Für einen kurzen Zeitraum schließt das Team späte Anforderungen aus und verschiebt sie in den nächsten Sprint. Am Ende steht kein agiler Festpreis für ein gesamtes Projekt, sondern viele Festpreise für viele aufeinander folgende Sprints. Allerdings ohne dass klar ist, wie viele Sprints folgen, wie lange das Projekt dauert und welche Funktionalitäten am Ende zur Verfügung stehen werden. Im Grunde also ein agiles Vorgehen mit festpreissicheren Einzelschritten.

Agile Festpreise im Mittelgroßen - ein paar Sprints

Eine Preisdiskussion für jeden Sprint kann schnell ermüdend sein. Oft können die Projektbeteiligten zusammenhängende, aufeinander folgende Sprints und die in ihnen zu entwickelnden Funktionalitäten zusammenfassen. Festpreisfähigkeit im engeren Sinn ist hier nicht mehr gegeben. Das Team kann den Aufwand nur grob abschätzen, entsprechend besteht das Risiko, dass die Schätzung überschritten wird. Jetzt greifen Modelle, in denen dieses Risiko zwischen Auftraggeber und Dienstleister geteilt wird.

Projektbeispiel

Vereinbart ist ein Tagessatz von 1.000 Euro, für die Entwicklung einer Funktion schätzt das Team fünf Tage. Tatsächlich arbeiten sie sieben Tage an der Funktion. Die zwei zusätzlichen Tage werden nur mit einem geringeren Tagessatz – beispielsweise 600 Euro – vergütet.

Beträgt die Entwicklungszeit aber nur vier statt der ursprünglich geschätzten fünf Tage, werden die tatsächlich eingesetzten plus der Hälfte der eingesparten Tage berechnet, also viereinhalb Tage.

Wird ein geplantes Feature innerhalb eines Sprints nicht fertig, wird es nicht bezahlt. Die Vervollständigung wird für den nächsten Sprint eingeplant. An dem Preis des Features ändert sich nichts. Mit einem möglichen Overspent für dieses Feature im folgenden Sprint wird umgegangen wie oben beschrieben.

So können Auftragnehmer und Auftraggeber gemeinsam verfolgen, welche durchschnittlichen Tagessätze pro Sprint zum Tragen kommen (siehe Abbildung unten). Auf dieser Grundlage lässt sich auch erkennen, ob bestimmte Arten von Features falsch geschätzt wurden oder ob bestimmte Features besonders teuer waren.

Auswertung durchschnittliche Tagessätze pro Sprint.
Auswertung durchschnittliche Tagessätze pro Sprint.
Foto: adesso

Einen Zeithorizont, der länger als ein paar Sprints ist, werden Kunde und Dienstleister so kaum überblicken können. Die Illusion der langlaufenden Festpreisprojekte ist aber aufgelöst; die Beteiligten erkennen die Kosten frühzeitig, die sich aus neuen Wünschen ergeben. Nämlich indem sich diese Wünsche in unmittelbar anstehende Sprints niederschlagen.