Change For Free - Best Practices und Bad Practices für Agile Festpreisprojekte (German)

HINTERGRUND
ZIEL
PROBLEM
LÖSUNG
CHANGE FOR FREE
Ein Lieferant setzt ein Kundenprojekt mit einem (zu Beginn) ﬁxen Projektumfang zu einem
Festpreis um. Der Kunde ist an einer agilen Vorgehensweise interessiert - insbesondere an der
Möglichkeit, Anforderungen noch während der Umsetzung ändern oder detaillieren zu können.
Der Kunde kann oder will nicht nach einer agilen Methodik verfahren und aktiv eine Rolle in einem
agilen Prozess (z.B. Product Owner in Scrum) wahrnehmen.
Der Lieferant bietet dem Kunden eine “Change for Free”-Option an.
Während der Umsetzung des Projekts können Anforderungen ohne Mehrkosten gegen ursprünglich nicht
vereinbarte Anforderungen ausgetauscht werden sofern folgende Voraussetzungen erfüllt sind:
1 ) Die zu entfernenden Anforderungen beﬁnden sich noch nicht in der Umsetzung.
2 ) Der Umsetzungsaufwand der zu entfernenden Anforderungen ist identisch mit dem der hinzuzufügenden Anforderungen.
Concept of “Change for Free” taken from Jeff Sutherland, Money For Nothing and Your Change For Free: Agile Contracts, 2008, Scrum Inc.
User Stories examples inspired by Mike Cohn, User Stories Applied: For Agile Software Development, 2004, Addison-Wesley
REFERENCES
CHANGE FOR FREE Best Practices und Bad Practices für Agile Festpreisprojekte
© 2015 YMC AG www.ymc.ch

S
C
in Umsetzung befindliche Anforderungen
nicht zwangsläufig unter Anwendung von Iterationen (Sprints in Scrum)
UMSETZUNG
Aufwand für die Umsetzung einer einzelnen Anforderung (auf hoher oder niedriger Abstraktionsebene)
entweder relativ zueinander in frei wählbaren Einheiten (i.d.R. Storypoints) geschätzt oder absolut in einer Zeiteinheit (z.B. Personentage)
der Aufwand einer Anforderung auf hoher Abstraktionsebene sollte der Summe der Aufwände aller darin enthaltenen Anforderungen auf
niedriger Abstraktionsebene entsprechen
AUFWAND
KUNDE
LIEFERANT
festgelegt durch Anforderungen auf hoher Abstraktionsebene und ggf. weiteren vertraglichen Vereinbarungen
PROJEKTUMFANG (SCOPE)
(noch) nicht detailliert genug für eine unmittelbare Umsetzung
oft in Form einer ausgedehnten User Story (auch Epic genannt)
Beispiel: “Als registrierter Benutzer möchte ich meine Kontoinformationen ändern.”
wird (im Laufe des Projekts) durch Aufteilung in mehrere Anforderungen auf niedriger Abstraktionsebene detailliert















ANFORDERUNG AUF HOHER ABSTRAKTIONSEBENE
beschreibt einen in sich abgeschlossenen funktionalen Bestandteil einer Anforderung auf hoher Abstraktionsebene
oft in Form einer detaillierten User Story
Beispiel 1: “Als registrierter Benutzer möchte die in meinem Konto hinterlegten Liefer- und Rechnungsadressen ändern.”
Beispiel 2: “Als Benutzer möchte ich die in meinem Konto hinterlegten Kreditkartendaten ändern.”
oft mittels Akzeptanzkriterien spezifiziert
Beispiel: Der Benutzer wird gewarnt wenn die Kreditkartennummer auf eine ungültige Nummer geändert wird.
ANFORDERUNG AUF NIEDRIGER ABSTRAKTIONSEBENE
LEGENDE
A

C
Der einfachste Fall von Change for Free: Der Kunde möchte eine neue Anforderung
(auf hoher Abstraktionsebene) zum Projektumfang hinzufügen. Zusammen mit dem
Lieferanten entscheidet er, welche bestehende Anforderung dafür aus dem
Projektumfang entfernt wird.
#1Practice
EFFORT
C+S
++
+
-
--
Best Practice
Bad Practice
Bad Practice
Best Practice

#2Practice
C
C
C+S
EFFORT
++
+
-
--
Best Practice
Bad Practice
Bad Practice
Best Practice
Eine einzelne Anforderung kann auch mit mehreren Anforderungen ausgetauscht
werden - solange der (summierte) Aufwand übereinstimmt.

Ferner erleichtert eine einzige Anforderung auf hoher
Abstraktionsebene den Austausch, da so nur eine
Aufwandsschätzung angepasst werden muss.
#3Practice
A
B
C
D
A
BC
C+S
C
A
D
Wie in Practice #1, nur handelt es sich bei den miteinander ausgetauschten Anforderungen
um Anforderungen auf niedriger Abstraktionsebene mit einer gemeinsamen
Anforderung auf hoher Abstraktionsebene.
Diese Practice ist besonders zu empfehlen, da der Aufwand von Anforderungen auf niedriger
Abstraktionsebene mit weniger Ungewissheit als der Aufwand von Anforderungen auf hoher
Abstraktionsebene schätzbar ist und der Austausch aus diesem Grund mit vermindertem
Risiko einhergeht.
C
EFFORT
++
+
-
--
Best Practice
Bad Practice
Bad Practice
Best Practice

++
+
-
--
Best Practice
Best Practice
Bad Practice
Bad Practice
#4Practice
A
B
C
D
A
BC C
C
A
D
C
? S
EFFORT
Bei der entfernten Anforderung könnte eine
technische Abhängigkeit zu einer anderen
Anforderung bestehen, die nur der Lieferant erkennen
kann. Und bei der Übernahme eines feststehenden
Werts für den Aufwand müsste man ggf. die
Anforderung ändern (z.B. vereinfachen), was
wiederum nur dem Kunden zusteht.
Dem Kunde sollte prinzipiell die Freiheit zustehen, auch eine ungeschätzte
Anforderung in den Projektumfang hinzufügen zu können, die erst im Zuge des
Austauschs geschätzt wird.
Hierbei sollte aber vermieden werden, dass die zu entfernende Anforderung alleinig
vom Kunden bestimmt wird und/oder dass hinzugefügte Anforderung alleinig vom
Lieferanten im Nachhinein “geschätzt” wird indem der Lieferant einfach die
Aufwandsschätzung der entfernten Anforderung unverändert übernimmt.

#5Practice
A
B
C
D AC
C+SB
C
++
+
-
--
Best Practice
Best Practice
Bad Practice
Bad Practice
EFFORT
Eine Anforderung, die sich bereits in Umsetzung beﬁndet, sollte niemals ausgetauscht
werden - unabhängig davon wie weit die Umsetzung bereits fortgeschritten ist.
Wie in allen Practices ab einschliesslich Practice #3 zu erkennen ist, sind die Anforderungen auf
niedriger Abstraktionsebene einer sich in Umsetzung beﬁndlichen Anforderung auf hoher
Abstraktionsebene potentiell weiterhin austauschbar, da sie in sich abgeschlossen sind.

#6Practice
A
B
C
D
A
BC
C+S
C
EFFORT
++
+
-
--
Best Practice
Best Practice
Bad Practice
Bad Practice
Auch der Fall andersrum ist problematisch: Ist der
Aufwand der hinzuzufügenden Anforderung niedriger
als der Aufwand der zu entfernenden Anforderung, so
müsste dem Kunden ein Preisnachlass gewährt
werden, welcher bei Fixpreisprojekten jedoch i.d.R.
nicht vorgesehen ist.
Anforderungen mit jeweils unterschiedlichem Aufwand sollten niemals miteinander
ausgetauscht werden.
Ist der Aufwand der hinzuzufügenden Anforderung höher als der Aufwand der zu
entfernenden Anforderung, kann nicht mehr ohne weitere Massnahmen sichergestellt
werden, dass das Projekt fristgerecht umgesetzt werden kann. Zudem dürften wohl
unvermeidlich das Budget überschritten werden (zu Lasten des Lieferanten).

A
B
C
D D
A
B
A
C
C
C+S
C C+S
#7Practice
EFFORT
++
+
-
--
Best Practice
Bad Practice
Bad Practice
Best Practice
Practice #6 kommt in abgewandelter Variante dennoch in Frage: Kunde und Lieferant
ändern gemeinsam (siehe Practice #4) und zusätzlich zum Austausch der
Anforderungen eine andere Anforderung, so dass die summierten Aufwände effektiv
gleich bleiben.

A
B
C
D D
A
B
A
C
C+S
C
#8Practice
C
C+S
EFFORT
++
+
-
--
Best Practice
Best Practice
Bad Practice
Bad Practice
Practice #7 sollte vermieden werden wenn die geänderte Anforderung keinen
inhaltlichen Bezug zu den miteinander ausgetauschten Anforderungen hat, da der
Vorgang des Austauschs zusammen mit der Änderung einer anderen Anforderung
mit einer höheren Komplexität und damit mit einem höheren Risiko einhergeht.
(siehe auch Practice #3)

Change For Free - Best Practices und Bad Practices für Agile Festpreisprojekte (German)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Empfohlen

Empfohlen (20)

Change For Free - Best Practices und Bad Practices für Agile Festpreisprojekte (German)