Erfahrungen mit agiler Softwareentwicklung in einem Großprojekt bei den Berliner Wasserbetrieben. Thomas Kujawski, BWB,

Transkript

1 Erfahrungen mit agiler Softwareentwicklung in einem Großprojekt bei den Berliner Wasserbetrieben Thomas Kujawski, BWB,

2 AGENDA Projektüberblick Explorationsphase Festpreisgedanke Change Management Releasezyklus Erfahrungen Fazit 2

3 Projektüberblick Projektname: UBI IT-Unterstützung für Betriebsführungs- und Instandhaltungsprozesse Phase I: Machbarkeitsstudie von März 2002 bis März 2003 Phase II: Realisierung von Dezember 2003 bis heute Auftraggeber: 4 Technische Geschäftsbereiche der BWB Anwendergruppen: Bauleiter, Arbeitsvorbereiter, Disponenten, Kolonnenführer, Verbrauchsableser, (ca. 450 User, die meisten mit wenig IT-Vorkentnissen) Ziel: Optimierung der Betriebsführung und der Instandhaltungsprozesse in den technischen Bereichen und im Zählermanagement Wirtschaftlichkeitsparameter: Reduktion von 47 PJ und SAP-Lizenzen, IT- Konsolidierung und Ausbau der J2EE-Plattform (Geringe Folgekosten) Aufwand/Dauer: Programmierung ca. 4 Mio. / ca. 5 Jahre Aktueller Stand: Fertigstellungsgrad ca. 90%, produktiv ca. 80% 3

4 Explorationsphase Kernideen/Ziele für die Geschäftsbereiche unterschiedlich klar Häufige Prototypen wecken Begehrlichkeiten (Aufwandstreiber) Teilweise sehr große Erwartungshaltungen bei Anwendern (auch durch zu frühe vollmundige Versprechen) Prototypische Durchstiche (GIS, SAP) zeigen technische Machbarkeit zur Risikominimierung Aufwandsschätzungen teilweise nicht nachvollziehbar Wo bleiben die Synergien, bei gleicher Fachlichkeit? (Betrachtung auf Metaebene) Aufschreiben der Anforderungen fällt schwer (Formalismus) Vertragsrelevanter OUTPUT: verbindliches Anforderungsdokument mit verbindlicher Aufwandsschätzung 4

5 Festpreisgedanke Basis für Werkvertrag Festpreis für Werkvertrag Anforderungsliste Dskfjksdjskdjdsfdsfdsfsdf Sdsadlajd sdkfjksdf sdfk Dskfjksdjskdjdsfdsfdsfsdff sdj ssdfjjsdf sd aaaaaaaa dsf Dskfjksdjskdjdsfdsfdsf sdj ssdfjjsdf sdkjfsddsf dsfsdf Dskfjksdj skdj dsf bbbb dffks sdj ssdfjjsdf sdkjfsddsf dsfsdf Dskfjksdjskdjdsfdsfdsfsdf sdj ccccccc ffffffffff sfsdf sdf Dskfjksdjskdjdsfdsfdsfsdffk sdj ddddddddddd sf dsfsdf sdf Dskfjksdjskdjdsfdsf sdj eee eeeeesddsf dsfsdf Dskfjksdjskdjdsfdsfdsfsdff sdj ssdfjjsdf shhhhhhh dsfsdf Dskfjksdjskdjdsfdsfdsfsd Verbindliche Schätzung = 5

6 Change Management unter Festpreisbedingungen Anforderungsliste Sdsadlajd sdkfjksdf sdfk sdj ssdfjjsdf sd aaaaaaaa dsfsdf sdf sdj ssdfjjsdf sdkjfsddsf dsfsdf sdf Dskfjksdj skdj dsf bbbb dffksdf sdj ssdfjjsdf sdkjfsddsf dsfsdf sdf sdj ccccccc ffffffffff sfsdf sdf sdj ddddddddddd sf dsfsdf sdf fj Release 1 Release 2 Neue Anforderungen sdj ccccccc ffffffffff sfsdf sdf sdj ddddddddddd sf dsfsdf sdf fj Release n Release n Release n 6

7 Ein typischer Releasezyklus (im Werkvertragskontext) Auftraggeber Konkretisierung der groben Anforderungen (Vom Lastenheft zum Pflichtenheft) Anforderungen zu Release zusammenfassen SW-Erstellung anhand abgestimmter Anforderungsdokumente (Abnahmerelevant) Während der Entwicklung eines Releases (3-12 Wochen lang) kein Change- Management möglich. Tests und Abnahmen (Explizite Testumgebung) Reviews Entscheidung über GO-Live-Inhalte (Produktivumgebung) Mitbestimmung Konkretisierung Fachliches Release Realisierung Teil 1 Realisierung Teil 2 Test Anwendertest Teilzahlung Restzahlung Mitbestimmung Schulung Produktivschaltung 7

8 Erfahrungen Teilprojektleiter müssen sich als Product-Manager verstehen (Generalisten) Auftraggeber muss mit klaren Visionen antreten und sich nicht so oft in Details verlieren. (Zielgerichtetes Arbeiten) Große Projekte in Machbarkeits- und Realisierungsphasen aufteilen Projekte mit unklaren Anforderungen mittels Oberflächen-Prototyping sukzessive konkretisieren. (das hilft den Vertragspartnern bei der Risikominimierung) Ressourcenbeistellung ist bei hoher zeitlicher Mitwirkungspflicht kritisch Mut zur Lücke besitzen und Release trotz Widerstand der Personalräte und Anwender einführen. D.h. frühzeitiges Ausrollen als Chance verstehen, um Feedback zu erlangen Agiles Vorgehen ermöglicht eine hohe Flexibilität unter Werkvertragsbedingungen Hohe Software-Qualität ist wichtiger als eine feste Terminzusage Permanentes Feedback und Projektreviews führten zur kontinuierlichen Verbesserung Eine vertrauensvolle Zusammenarbeit ist eine elementare Voraussetzung 8

9 FAZIT Agil befördert das Projektklima positiv Agil fordert und fördert den Auftraggeber (hoher zeitlicher Mitwirkungsanteil notwendig, aber mit hohe Lernkurven) Agil setzt ein gegenseitiges Vertrauensverhältnis voraus Agil ermöglicht eine enorme Flexibilität bei unpräzisen Lastenheften (anders wäre es mit dieser diffusen Menge an Anforderungen auch nicht möglich gewesen) Agil hilft durch Prototyping den Anwendern, die keine IT-Affinität besitzen Agil identifiziert rechtzeitig Risiken Agil setzt auf Qualität vor maximaler Termintreue Agil half, das Budget im Rahmen zu halten (Abweichung + 5%) Agil klappt gut, aber: Ohne klares Geschäftsziel und klare Vorgaben hilft auch kein agiler Ansatz 9

10 Herzlichen Dank!! Gerne stellen wir Ihnen unsere innovative Gesamtlösung persönlich vor. Kontaktdaten: Berliner Wasserbetriebe Tel.: Mobil: