Agiler Festpreis - Project Partners

Agiler Festpreis – oder Change Management par excellence?
Wie dieser Widerspruch Ihnen bei der agilen Transition hilft.
Agile Vorgehensweisen setzen sich in der Softwareentwicklung immer stärker durch. Flexibilität und frühzeitige Releases bei
vagen Anforderungen sind vielleicht die prägnantesten Vorteile. Aber beim Geld hört die Freundschaft auf. Das Risiko, nicht
zu wissen, wie viel Budget benötigt wird, möchte kein Management eingehen. Hier setzt der agile Festpreis an und kämpft
mit dem Vorurteil des Widerspruchs.
Der Begriff Agilität bedeutet „Beweglichkeit“ und enthält somit die Eigenschaft der Änderung. Demgegenüber steht das
Wort Festpreis, unter dem eher das Gegenteil verstanden wird. Was passiert also, wenn diese beiden Begriffe zusammengebracht werden?
Der Festpreis gibt den Rahmen vor, in dem sich agil bewegt wird. Denn auch wenn Termin, Budget und Leistung am Ende
eingehalten wurden, ist das Projekt gescheitert, wenn keiner das Ergebnis braucht oder haben will. Somit wird ein Rahmen
geschaffen, der zwar Flexibilität in Bezug auf den Termin und die Leistung gewährleistet, aber gleichzeitig auch Sicherheit
beim Budget. Die Grundidee liegt darin, von Story-Points1 über Personentage auf einen Festpreis zu gelangen und ein Kontingent an Story-Points festzulegen. Beim Austausch von Anforderungen ändert sich nichts am Festpreis, solange der Wert
eines Story-Points gleich bleibt.
Der Faktor Zeit ist allerdings häufig ebenfalls ein kritisches Thema. Wird ein Werkvertrag abgeschlossen, ist dieser zumeist
mit einem Liefertermin verbunden. Der Rahmen des agilen Festpreises gestaltet sich dann ebenfalls über die zeitliche Komponente.
VORGEHENSWEISE
1. Anforderungen sammeln: Zusammentragen aller bekannten
Anforderungen nach gleichem
Schema (User Stories) zum Aufbau eines Backlogs. Dieses Backlog verhält sich (später) wie ein
unvollständiges und flexibles
Pflichtenheft. Unvollständig deshalb, da sich im Laufe der Zeit
neue Anforderungen ergeben
können. Flexibel, da bestehende
aber noch nicht umgesetzte Anforderungen im Laufe der Zeit
obsolet werden oder sogar nachträglich noch angepasst werden
können.
2. Story-Points (SP) ermitteln: Jede
User Story erhält gemäß ihres
Funktionsumfangs SP. Dies geschieht mittels agiler Schätzungsmethoden, wie z.B. Planning Poker2 o.ä.. Im Vordergrund
steht dabei die Komplexität oder
auch die Menge an Funktionen,
die mit dieser User Story verbunden sind. Eine gemeinsame
Schätzung
und
gegenseitige
Rechtfertigung erhöht die Qualität und die Einigkeit. Die Story
Points sind dabei nicht gleichzusetzen mit einer Aufwandsberechnung in Personentagen, sondern spiegelt nur das Verhältnis
1
2
3.
4.
5.
der Komplexität verschiedener
User Stories zueinander wider.
User Stories mit weniger SP benötigen also gemäß der Expertenschätzung voraussichtlich auch
geringere Aufwände für eine Umsetzung als vergleichbare.
Definition of Done: An diesem
Punkt wird zusammen mit dem
Kunden festgelegt, wann eine User Story als abgeschlossen oder
geliefert gilt. Dazu gehören auch
Akzeptanz- und Qualitätskriterien.
Umrechnung SP in PT: Beim
kritischsten Punkt werden einige
User Stories ausgewählt und weiter in kleinere Aufgaben zerlegt.
Mit Hilfe der „Definition of Done“ wird eine Expertenschätzung
für diese Aufgaben eingeholt,
welche dann wiederum einen
Aufwand in Personentagen für die
geschätzte User Story als Ergebnis hat. Ist dies für mehrere User
Stories erfolgt, kann ein Umrechnungsfaktor von Story-Points auf
Personentage ermittelt werden.
Gesamtaufwand und Festpreis:
Mittels des Umrechnungsfaktors
lässt sich der Aufwand für das gesamte Backlog errechnen. Dieser
kann dann mit einem durchschnittlichen Tagessatz (des de-
http://www.ksimons.de/2011/06/story-points-verstandlich-erklart/
http://www.planningpoker.de/
Abb. 1: Festpreis eines Backlogs
signierten
Entwicklungsteams)
multipliziert werden und ergibt
den Festpreis.
Wichtig dabei ist, dass der so berechnete Festpreis sich auf die Story-Points
des Backlogs und nicht auf dessen
Inhalt bezieht (siehe Abb. 1). Änderungen von Anforderungen sind jetzt
jederzeit möglich, ohne den Preis in
die Höhe zu treiben. Hat die neue User
Story tatsächlich mehr SP als diejenige, die ersetzt wird, greift am besten
ein definierter Change Management
Prozess.
Die Schätzung von neuen Anforderungen hat zwar im Einvernehmen mit
dem Auftragnehmer oder nach objektivierbaren Kalkulations- und Bemessungsverfahren zu erfolgen, aber dabei
helfen wir Ihnen auch gerne.
EIN KURZES BEISPIEL
Die Praxis bestätigt, dass hierbei Festpreis (Teil-)Gewerke über Laufzeiten
von mehr als sechs Monaten und einer
externen agilen Projektorganisation
von ca. 30 FTE keine Hürden darstellen. Im Rahmen eines OmnichannelProjektes und der damit verbundenen
Project Partners Management GmbH | Nördliche Münchner Str. 16 | D-82031 Grünwald b. München
T: 089/ 447 18 004 | www.project-partners.de
Abb. 2: Planungsvariationen
Einführung der E-Commerce Plattform
„Hybris“ wurden mit Hilfe der
Schätzmethode „Planning Poker“
Story-Points für Storys im Backlog
ermittelt. Eine Story war dann abgeschlossen, wenn sie genau vier Punkte
erfüllt hat:
1. Die festgelegten Akzeptanzkriterien sind erfüllt,
2. die Code-Implementierung ist
abgeschlossen,
3. die Dokumentation ist eingearbeitet und
4. Entwicklungs-, sowie Funktionstests seitens des externen Partners
sind erfolgt.
Danach wurden die Ergebnisse im
gemeinsamen Review präsentiert und
abgenommen.
Im beschriebenen Beispiel wurden
Teilgewerke definiert und über die
Velocity (Teamgröße) dann der Umfang bestimmt. Für das gesamte Projekt reichten 1,7 Mio Euro aus.
Die entscheidendste Erkenntnis war,
dass vor allem durch das Austauschen
von Anforderungen im Scope-Rahmen
und die notwendige Spezifikation der
Stories zur angemessenen Zeit während der Umsetzungsphase die not-
wendige Flexibilität in großen Projekten gibt. Die Konzentration auf das
Aktuelle unterstützt eine effiziente und
schlagkräftige Ablauforganisation. So
ist es ohne Probleme möglich kurzfristig zu agieren, ganz im Sinne des
Stakeholder Managements.
OPTIONAL: TERMIN FIXIEREN
Wie schon erwähnt ist oft auch ein
Liefertermin notwendig, um z. B.
Abhängigkeiten gerecht zu werden
oder den Wünschen von Kunden nachzukommen.
Eine Möglichkeit ist es dabei zwei
oder drei Sprints durchzuführen und zu
messen, wie viele Story-Points im
Durchschnitt pro Sprint abgearbeitet
werden können. Daraus wird eine
Gesamtdauer für alle restlichen StoryPoints errechnet. Eine mögliche Steigerung der Velocity darf dabei berücksichtigt werden.
FAZIT
In neuen agilen Partnerschaften im
internen und externen Verhältnis
empfehlen wir zum Start die Gewerke
überschaubar zu halten. Zusätzlich
können weitere Qualitätssicherungsmaßnahmen, die über den Anforde-
rungen eines klassischen Werkvertrags
im Wasserfallmodell liegen, vereinbart
werden. Dabei lernen beide Partner
voneinander, das schafft Vertrauen, da
die Ergebnisse sofort messbar sind.
Der agile Festpreis ist ein Kompromiss
zwischen Flexibilität und BudgetDeckelung, wenn gewünscht sogar
Liefertermin. Dabei schlägt er eine
Brücke zwischen agilem und klassischem Projektmanagement. Ob Sie
von Sprint zu Sprint die absolute
Flexibilität genießen, ein Budget vorgeben oder sogar nur Freiheiten beim
Funktionsumfang genehmigen (siehe
Abb. 2), egal, wie Sie sich entscheiden: Vom Set-Up über Schätzmethoden und „Definition of Done“, bis hin
zum Product Owner unterstützt Sie
Project Partners mit Erfahrung und
Expertise.
Clemens Bedbur
GREENPAPERS sind Expertenpapiere von Project Partners in denen wir
unsere Erfahrung speziell für IT Entscheider zusammenfassen.
Gerne stehen wir auch Ihnen bei ITProjekten mit Rat und Tat zur Seite.
www.project-partners.de
Project Partners Management GmbH | Nördliche Münchner Str. 16 | D-82031 Grünwald b. München
T: 089/ 447 18 004 | www.project-partners.de

Download Report