4. Festpreis
– Alles geklärt -> Alles geplant -> Alles angehen
– Risikoverlagerung zum Auftragnehmer
– Änderungen vermeiden
– Ein Release am Ende
Agil
– Gemeinsames Starten, wenn noch nicht alles klar ist
– Risikoteilung durch Zusammenarbeit
– Änderungen ermöglichen
– Viele Releases bis zum Ende
Realität
– Es gibt feste Jahres-Budgets und Frozen Zones
– Festpreisprojekte benötigen einen Prozess zur Kostenschätzung
– In IT-Projekten ändert sich oft die Aufgabenstellung
– Vollständige Anforderungsanalyse ist teuer und kostet Zeit
4
Agile Festpreisprojekte?
Agile Festpreisprojekte? 06.10.2015
6. Ziel
– Ablösung einer dezentralen Altanwendung durch Neuentwicklung einer
zentralen Serverversion
– Alle alten und viele neue Funktionalitäten
Kunde
– Maschinenbau
– Keine Erfahrung mit verteilten Systemen
– Keine Erfahrung mit agilen Methoden
akquinet
– Dienstleister
– Expertise in Individual-Softwareentwickung
– Erfahrung mit agilem Vorgehen (RE, (A)TDD, CI, Prototyping, …)
6
Das Projekt
Ein Projekt mir Problemen 06.10.2015
7. Kenngrößen
– Laufzeit von November 2009 bis Dezember 2014
– Örtliche Trennung von AG und AN
– Teamgröße variabel: 4-12
– Aufwand insgesamt 3500 PT (über mehrere Verträge)
Vorgehen im Festpreis mit „agilen Ansätzen“ (Feature-Tausch)
Was sollte da schief gehen?
7
Das Projekt
Ein Projekt mir Problemen 06.10.2015
8. Planung: Der Ansatz „alles“ haben zu wollen, führte zu
übermäßiger Parallelentwicklung und „Feature-Enlargement“
Vorgehen: Unterschiedliches Verständnis von agilem Vorgehen
bei AG und AN
Kommunikation: Änderungen auf Zuruf
Kosten: Mehraufwände und Verzug im Projekt
Vertrauen: Erschüttert
Ausweg: Eskalation und Klärung
8
Status Sommer 2011: Projekt in Schieflage
Ein Projekt mir Problemen 06.10.2015
10. Aufbau von Vertrauen und Zuverlässigkeit
– Fokus auf Produktivsetzung im November 2011
– Qualität, Termine, Kosten
Motivation von Team und Kunde
– Einbringen eigener Expertise aus der Software-Release-Planung
– Intensive Zusammenarbeit in Workshops und TelCos
– Abschirmung des Teams für realistischen Workload
Kein „agiles Vorgehen“ mehr – „Klassischer Wasserfall“ war
gefordert
– Der Begriff Agilität war „verbrannt“
10
Meine ersten Schritte
Der Neuanfang 06.10.2015
12. Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
12
Das Agile Manifest
agilemanifesto.org
06.10.2015Agile meets Classic
13. Definition von Agilität und Festpreis
– Agilität bedeutet Flexibilität
– Festpreis ist der Rahmen
– Änderungen bedeuten Mehrkosten
– Variabler Leistungsumfang mit Fokus auf optimiertem Mehrwert
Vorgehen mit gemeinsamer Collaboration-Plattform
– Confluence, JIRA
Unterstützung des Kunden beim Produktmanagement
– Gemeinsame Beschreibung und Bewertung der Anforderungen
13
Der Weg zu planbarer Agilität im Projekt
Agile meets Classic 06.10.2015
14. 14
Anforderungsanalyse – Wie viel RE?
Angemessenes RE als
grundlegende Absicherung
Minimales RE
RE als Versicherung für
den Fall der Fälle
Detailliertes RE unbedingt
notwendig
Zusammenarbeit
Domäne
wissendunwissend
neu / nicht
kooperativ
kooperativ
Abbildung nach
Johannes Bergsmann
Agile meets Classic 06.10.2015
15. 16
Eine Anforderung wird formuliert
Zielstellung in Form von
SPIN-Selling
Entwurf von Lösungen (Szenarien)
Klassifikation mit Kano-Modell
– Auswahl von Muss, Soll, Kann
Annahmen, Abgrenzungen,
Abhängigkeiten
Abnahmekriterien aus Sicht
des Testers und Entwicklers
Schätzung
Entscheidung zur Umsetzung
Agile meets Classic
„Kano Modell allgemein“at de.wikipedia.org
06.10.2015
16. Der „agile“ Projektplan
„parallelisiere den Wasserfall“
Priorisiere mit Lean Management
17
Analyse/Design Implementierung Abnahme
Feature 1
Feature 2
Feature 3
Muss
Soll
Kann
– time2market
– design2cost
Agile meets Classic 06.10.2015
20. Eine Pilotbeauftragung
– Zum Kennenlernen des Vorgehens „Agiler Festpreis“
Szenarien / Features aus Sicht des Vertriebs
– Wireframes, Fachlichkeit, Lösungen als Abnahmekriterium
Partnerschaftliche Risikoteilung
– Planänderungsbudget 10%
– Risikobudget von 10%
– Bei Kostenunterschreitung oder –überschreitung können 50% in Rechnung
gestellt werden
– Laufzeit von maximal einem Jahr
– Implementierung im Festpreis mit „Cap“
Zahlungen
– Pro Release nach tatsächlichem Aufwand
22
Das Vertragliche
Das Vertragliche 06.10.2015
22. Nach der Pilotphase (ca. 3 Monate) hat der Kunde das Vorgehen
beibehalten
Das Vorgehensmodell führte zu vielen Änderungen im
Projektverlauf
Viele Anforderungen aus dem alten Lastenheft waren obsolet
Neue Anforderungen konnten aufgenommen werden
Terminänderungen passten zu den Wünschen des Kunden
Budget wurde eingehalten, Mehrwert wurde erzeugt
24
Die „agile“ Zeit 2012-2014
Erkenntnisse 06.10.2015
23. Aufwände bei der Zusammenarbeit
– Planänderungsboard - Anfänglich vom Kunden unterschätzt
Die Abnahme und das Gefühl des Kunden dabei
– „weiche“ Abnahmekriterien in Form von Wireframes, User Stories
– Änderungen am Projektkontext während der Laufzeit
Was half?
– Vertrag förderte das Partnerschaftliche
– Konzentration auf die Fachlichkeit
– Konsequente Kosten/Nutzen-Betrachtungen bei Entscheidungen
(auch bei Fehlerbehebungen)
25
Die Probleme
Erkenntnisse 06.10.2015
24. Volle Transparenz der Kosten durch Änderungen
Domänenverständnis und Beratung über mehrere
Lösungsszenarien
Nutzung von Synergien
Priorisierung anhand von Kosten/Nutzen-Betrachtungen
Termin- und Budgettreue im Projekt – trotz Änderungen
Schneller Mehrwert, ohne alles vorher durchdacht zu haben
26
Was schaffte Vertrauen?
Erkenntnisse 06.10.2015