Schneller zu Ergebnissen unser erstes Agile Project

Save this PDF as:

WORD PNG TXT JPG

Größe: px

Ab Seite anzeigen:

Download "Schneller zu Ergebnissen unser erstes Agile Project"

Melanie Hauer
vor 2 Jahren
Abrufe

Transkript

1 Schneller zu Ergebnissen unser erstes Agile Project Thomas Schmidt Juni 2014

2 Agenda Das Project Projektstruktur und der Projektplan Theorie vs Realität Releases und Sprints Executable Code Angst vor dem Ende Fazit 2

3 Das Project Factory direct ship

4 Factory Direct Ship Ziel Kundenbestellungen für Drucker direkt aus der Fabrik zu erfüllen In ein bestehendes IT System zu integrieren (SAP R3) das bisher von der Druckersparte nicht genutzt wurde Existierende Prozesse andere Geschäftsbereiche (PC Sparte) auf diesen System nicht zu gefährden Direct Ship in bestehende Prozesse/ IT Systeme (andres R/3 und APO) zu integrieren Meine Rolle Experte im Planungsumfeld für Drucker Schnittstelle zwischen IT und Fachabteilung Zum ersten mal Product Owner 4

5 Projektstruktur und Projektplan

6 Projektplan und - struktur Projektdauer Schätzung mit traditionellen Projektplan Wasserfall : 1,5 Jahre Zu lange; wir brauchen früher Ergebnisse erste Direkte Lieferungen innerhalb von 3-6 Monaten => dann machen wir Agile 6

7 Asien III Asien II Asien I EU Prod. Business Dev IT Dev Projektplan Alle 3 Monate eine Release Q2 13 Q1 13 Q3 13 Q4 13 Shipment start Q1 14 Release #1 Release #2 Release #3 Release #4 Release #5 Business read. Business Deployment Venray Read. Venray Deployment Venray Deployment SCH Readiness SCH Deployment SCH Deployment IPS Readiness IPS Deployment IPS Deployment Toner Readiness Toner Deployment Toner Supplies 7 Source: JdJ adapted from workshop output

8 Projektplan und -struktur Projektstruktur 3 IT Entwicklungsteams: Release Teams Kundenaufträge (Order Management Team); Logistik Planung Entwicklung der Features Abarbeiten des Backlogs 8

Projektplan und -struktur E2E planning cycle Customer Demand planning Gross Forecast Supply Planning IT Team Planung Net Forecast to Suppliers and Mpa Procurement Supply Positioning (DC vs FDS)

9 Projektplan und -struktur E2E planning cycle Customer Demand planning Gross Forecast Supply Planning IT Team Planung Net Forecast to Suppliers and Mpa Procurement Supply Positioning (DC vs FDS) E2E order cycle Supply picture Customer Order Entry Demand Supply Matching Factory Logistic Customer Ordering Order Clean Drop to factory Shipment Delivery IT Team Kundenaufträge IT Team Logisitk 9

10 Projektplan und -struktur Projektstruktur Deployment Teams: Fachabteilung Reihenfolge der erforderlichen Funktionen/Features Einsatz in der Produktivumgebung Bussiness Development Team Definintion / Anpassung der Geschäftsprozessen Definition von Verantwortlichkeiten (RACI) 10

11 Projektplan und -struktur Projektstruktur WW Program Management 11 Stakeholders Business impact MOC EMEA Steering Up- Directions dates Scope Releasescope Product backlog EMEA IT Release Development teams Program manager System capabilities MPa connections MPa EMEA Business deployment inputs EMEA Mpa Scope Program mngt Deployment Deployment team Updates Program mngt Team Updates Team Team EMEA Business HP Deployment Internal: program Execution Scope Processes manager Enabled MPa Up- feedback dates Training Business EMEA Business Scale Development Program RACI Operation Team Business model manager Customer impact

12 Projektplan und - struktur Projektstruktur WW Program Management Business impact EMEA Steering Up- Directions dates Scope Releasescope Product backlog Release teams System capabilities MPa connections Stakeholders MOC inputs Updates Business Development Team EMEA EMEA Program mngt Program mngt Team Scope Updates RACI Business model Customer impact Execution feedback Scope Updates Operation Business Deployment Team HP Internal: User Setup Processes Training Scale Mpa Deployment Team Enabled MPa 12

13 Theorie und Realität Releases und Sprints

14 Asien III Asien II Asien I EU Prod. Business Dev IT Dev Releases und Sprints Release Plan Q2 13 Q1 13 Q3 13 Q4 13 Shipment start Q1 14 Release #1 Release #2 Release #3 Release #4 Release #5 Business read. Business Deployment Venray Read. Venray Deployment Venray Deployment SCH Readiness SCH Deployment SCH Deployment IPS Readiness IPS Deployment IPS Deployment Toner Readiness Toner Deployment Toner Supplies 14 Source: JdJ adapted from workshop output

15 Releases und Sprints Product Backlog Produkt Backlog deferieren Was ist der richtige Detaillevel? Sehr stark Abhängig von der Erfahrung der Entwickler ist ohne IT nicht herauszufinden Und ist ohne IT auch nicht zu lösen (z.b. Welche Felder in SAP) IT konnte erst zu Beginn der Sprints den Product Backlog untersuchen Der Product Backlog für den nächsten Release sollte schon während des aktuellen Release definiert werden war aber in der Realität nicht zu machen da der aktuelle Release sämtliche Ressourcen brauchte 15

16 Releases und Sprints Überlappen von Phasen 16

17 Releases und Sprints Product Backlog Produkt Backlog priorisieren Was ist wichtiger Stammdaten oder Bestellung; Absatzplanung oder Produktionsplanung Um einen neuenprozess zu implementieren sollten eigentlich alle Komponenten vorhanden sein Um sich in einen bestehenden Prozess (z.b. Bedarfsplanung) zu integrieren müssen alle Komponenten vorhanden sein Unser Ansatz: mehr manueller Aufwand und Ungenauigkeiten am Anfang, die dann Release für Release abgearbeitet wurden 17

18 Releases und Sprints Überlappen von Phasen Testen und Training Das Development Team testet und übergibt funktionierenden Code an die Fachabteilung Fachabteilung testet die Entwicklung End-to-End und gibt dann den Sign-Off Trainingsaufwand um die Fachabteilung auf die neue IT Lösung zu schulen stark unterschätzt Fachabteilung macht E2E Tests im alten Modell waren dafür mehrwöchige Testphasen eingeplant, in unseren Agile approach eigentlich nicht wurde dann als eigener Sprint eingeführt 18

19 Theorie und Realität Executable Code

20 Executable Code Jeder Sprint / Release liefert Executable Code Ziel: möglichst schnell die ersten Direct Ship Transaktionen Nach 3 Monaten haben wir die ersten Transaktionen durchgeführt In kleinen Schritten implementiert Code weggeschmissen und Schleifen gedreht häufige Codeänderungen ein sich stetig ändernder Prozess über mehrere Releases hoher Schulungsaufwand Kleine Schritte für IT - - aber ständige Unruhe für die Fachabteilungen 20

21 Executable Code Executable Code der nicht sofort gebraucht wurde Ziel: erzeuge mit jeden Sprint executable Code der Code wurde getestet auf das Produktivsystem transportiert um sicher vor anderen Projekten zu sein um die Objekte nicht zu loggen Der Code hatte dann doch Seiteneffekte auf bestehende Prozesse in Produktion die beim Testen nicht entdeckt wurden Code hatte dann doch noch Fehler oder fehlende Details die erst beim Benutzen auftraten dann war es schwer den Zusammenhang herzustellen denn für IT war das ja alter Code 21

22 Theorie und Realität Die Angst vor dem Ende

23 Die Angst vor dem Ende Der letzte Release War für eine weitere Sparte vorgesehen War mit den Requirements dieser Sparte schon voll Musste dann noch die Verbesserungen und Korrekturen aus den vorherigen Releases aufnehmen Wurde etwas gestreckt Längere Warrenty / Garantiephase 23

24 Fazit

25 Fazit Knackpunkte was wir unterschätzt haben Ständigen Änderungen mit jeden Release sind für die Fachabteilung kaum zu stemmen Schulungen und Trainings wurden durch den folgenden Release überholt Keine wirkliche Stabilisierung zwischen den Releases IT Develoment Team agierte als 1st level Support Der Aufwand die neuen Features zu Schulen, zu Testen und zu Übergeben war wesentlich größer als gedacht Übergabe vom IT Developmet Team zum Deployment Team zur Fachabteilung innerhalb eines Release stellte sich als nicht praktikabel heraus Die Theorie vom priorisierten Product Backlog hat nur zum Teil funktioniert Für einen erfolgreichen Prozess sind alle User Stories wichtig Unterschätzt die neuen/geänderten Backlog Items aus den vorherigen Releases 25

26 Fazit Knackpunkte was wir unterschätzt haben Testen IT Unit Tests genügen nicht NOT DONE E2E testen mit diversen Szenarien sind nötig Lösung: testing Sprints Projektstruktur Sehr komplex mit 3 IT Teams und 2 BIZ Teams Zu viele Meetings und Schnittstellen IT Teams in verschieden Zeitzonen 26

27 Fazit Mit kritischen Blick Im Endeffekt nicht schneller oder effektiver als im Traditionellen Modell Der Umfang wurde reduziert ( schon am Anfang bei der Releaseplanung) da auch die ursprünglich Aufwandsschätzung zu optimistisch war Viele Verbesserungen sind in der verlängerten Garantiephase implementiert worden 27

28 Fazit Die positiven Seiten Die ersten Erfolge waren relativ schnell sichtbar Nach 3 Monaten die ersten Transaktionen Nach knapp 2 Jahren läuft Direct Ship: nicht perfekt aber es läuft Ohne Agile hätten wir nie angefangen 28

29 The End

Ähnliche Dokumente

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management