Vortrag auf der SeaCon 2015:
Agile Festpreisprojekte sind kein Widerspruch - das Agile Manifest lässt sich auch in einem eher klassischen Umfeld anwenden. Auf die Zusammenarbeit kommt es an.
4. Festpreis
– Wenn alles klar ist, kann alles geplant werden
– Risikoverlagerung zum Auftragnehmer
– Änderungen vermeiden
Agil
– Starten, wenn noch nicht alles klar ist
– Risikoteilung
– Änderungen unterstützen
Realität
– 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?
08.05.2015Agile Festpreisprojekte?
6. Ziel
– Ablösung einer dezentralen Altanwendung durch Neuentwicklung
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
08.05.2015Ein Projekt mir Problemen
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“
Was sollte da schief gehen?
7
Das Projekt
08.05.2015Ein Projekt mir Problemen
8. Planung: Der Ansatz „alles“ haben zu wollen, führte zu
übermäßiger Parallelentwicklung
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
Eskalation und Klärung
8
Status Sommer 2011: Projekt in Schieflage
08.05.2015Ein Projekt mir Problemen
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 in der Software-Release-Planung
– Intensive Zusammenarbeit in Workshops und TelCos
– Abschirmung des Teams und realistischer Workload
Kein „agiles Vorgehen“ mehr – „Klassischer Wasserfall“ war
gefordert
– Der Begriff Agilität war „verbrannt“
10
Meine ersten Schritte
08.05.2015Der Neuanfang
12. 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
– Beschreibung und Bewertung der Anforderungen
12
Der Weg zu mehr Agilität
08.05.2015Agile meets Classic
13. 13
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
08.05.2015Agile meets Classic
15. 15
Eine Anforderung wird formuliert
08.05.2015
Zielstellung in Form von SPIN-Selling
Entwurf von Lösungen (Szenarien)
Klassifikation mit Kano-Modell
Auswahl von Muss, Soll, Kann
Abnahmekriterien aus Sicht des Testers und Entwicklers
Annahmen, Abgrenzungen, Abhängigkeiten
Schätzung
Entscheidung zur Umsetzung
Agile meets Classic
16. Der Projektplan
„parallelisiere den Wasserfall“
Priorisiere mit Lean Management
16
Analyse/Design Implementierung Abnahme
Feature 1
Feature 2
Feature 3
Muss
Soll
Kann
08.05.2015
– time2market
– design2cost
Agile meets Classic
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
Zahlungen
– Pro Release nach nach tatsächlichem Aufwand
20
Das Vertragliche
08.05.2015Das Vertragliche
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
22
Die Zeit 2012-2014
08.05.2015Erkenntnisse
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)
23
Die Probleme
08.05.2015Erkenntnisse
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
24
Was schaffte Vertrauen?
08.05.2015Erkenntnisse