Post on 09-Jun-2020
transcript
Einstieg in die agile EntwicklungGroßprojekterfahrung bei Otto
sven.guenther@ottogroup.com henning.wolf@it-agile.de
Agenda
• Wer ist Otto, was ist NOA?• Ausgangslage und Zielsetzung• Vorgehen / Timeline• Das Neue Liefermodell (Kurzvorstellung)• Aktueller Stand• Was wir heute anders machen würden• Lernerfahrungen in acht Episoden• Ausblick und Fazit
Die otto group ist weltweit zweitgrößter OnlineAnbieter im Endkundengeschäft
• 123 Einzelfirmen• 19 Länder• 53.000 Mitarbeiter• Segmente
• Multichannel‐Einzelhandel• Finanzdienstleistungen• Service
NOA ist eines der größten ITEinzelprojekte des Konzerns
Host‐Migration
0
50
100
150
200
NOA ist eines der größten ITEinzelprojekte des Konzerns
Kunde
Artikel
AuftragSendung
~70 Mio.
~5 Mio.
~1 Mio. pro Tag ~500.000 pro Tag
NOA Abteilungsstruktur
Abteilung Auftrag
Abteilung Kunde
Abteilung Artikel
Abteilung Lieferung
Zentrale Dienste
Analyse
Entwicklung
AnalyseEntwicklung
Analyse
Analyse
Entwicklung
Entwicklung
Situation Ende 2007
• Lange Releasezyklen statt geplant 2-3 pro Jahr nur 1-2
• Langer Zeitraum von Abgabe Fachbereichskonzept bis zum Rollout >1 Jahr
• Späte Änderungen durch Fachbereich werden teuer und führen zu Unzufriedenheit auf beiden Seiten
• Viele Abhängigkeiten zwischen Projekten vorhanden
• Integration der Software erst zum Ende der Entwicklungsphase
Ziele für ein neues Entwicklungsmodell
1. Häufigere und flexiblere Auslieferung2. Bessere Qualität liefern3. Tests effektiver durchführen4. Entwicklung kostengünstiger gestalten5. Schnellere Reaktion auf Änderungen ermöglichen6. Geplante Termine zuverlässig einhalten7. Personal gleichmäßiger auslasten
Timeline
ErstePilotprojektestarten
ExternerCoach kommt dazu
Erste agileMultiplikatoren-schulungen
GO! Vom Vorstand
WeitereAbteilungenfolgen
JAX
Timeline
Wie sind wir vorgegangen?
1 Entwicklung
2 Analyse
3 Reporting / Management
4 Kunde
5 Andere Systeme
optional
Anforderung
Themenporträt Vorläufiges Angebot
IT-Konzept
PriorisierteFeatureliste
Detaillierte Stories für Iteration 1
Iteration 2 Iteration 3Iteration 0 (Exploration) Iteration 1
Verbindliches Angebot
Detaillierte Stories für Iteration 3
Detaillierte Stories für Iteration 2
Grob- Architektur• Design• Entwicklung• Modultest• Fachlicher Test
• Design• Entwicklung• Modultest• Fachlicher Test
• Design• Entwicklung• Modultest• Fachlicher Test
Kurzüberblick Neues Liefermodell
Kurzüberblick Neues Liefermodell
Fachliche / technische Integration
Performance und Stabilität
User Acceptance Test
Projektentwicklung
Produkttest
Der Iterationsablauf (looks like Scrum)
Stand heute
• Management steht dahinter• Analyse nimmt die Aufteilung der Anforderungen in Features und
Storys an (und es erleichtert die Angebote)• Entwickler stehen größtenteils auch dahinter und wollen agil arbeiten• Aber auch schon erste Ergebnisse sichtbar• Zur konkreten Umsetzung herrscht oft Unsicherheit und Unklarheit• Nach wie vor viele Fronten:
– Builds, die oft zerbrechen– Mehr automatisierte Tests nötig– Wissensinseln behindern die Planung und die Teambildung– Integrationstests dauern sehr lange und sind instabil
Was hätten wir besser machen können / sollen?
Frühes Abholen der Basis über• Mehr Informationen• Probleme abfragen und berücksichtigen
Frühere Festlegungen und Vorgaben• Tool•Reporting•Qualitätsstandards•Templates
Lernerfahrungen in Episoden
Mitspielen erlaubt: Pilotprojekte bringen nichts?
• Pilotprojekte mit wenig Ressourcen• Wenig Sichtbarkeit im Bereich• Wenn es schlecht läuft: „Klappt nicht mal im Piloten“ • Wenn es gut läuft: „War ja nur ein Pilot“
• Trotzdem erste Lernerfahrungen möglich/wichtig:– Wie viel Unterstützung des Projekts nötig?– Was fällt den Entwicklern / Analysten schwer daran?– Welche Infos fehlen?– Welchen Rahmen muss man setzen?
• Wen informiert man wann über was?• Frühe Info prinzipiell hilfreich, verwirrt aber
manche• Zu späte Info verärgert und führt zu
Wildwuchs („das war ja nicht klar, da haben wir es irgendwie gemacht“)
• Schön, wenn man als Ansprechpartner da ist, aber nur wenige kommen von alleine
• Viel Fragen, um rauszubekommen, was man nicht weiß und was die anderen nicht wissen
Info, Info, Info oderIch weiß nicht, was Du nicht weißt
CodeWissensinseln contra Team
• Wenn sich für viele Themen jeweils nur einer auskennt, steht vermeintlich immer fest, wer es bei der Planung tun muss
• Da treffen die Ziele Planungssicherheit und Effizienz auf einander
Produkt CentralLogistic Services (CLS)
LV
P07 Run
P05 Run
P02 Run
P0...Run
P01 Run
Produkt CentralOrder Services (COS)
System NOA
Auftragsverwaltung
DAT7NOABP
D3NOA
P015 Run
Kundenverwaltung
PreisberechnungBestandszuteilung
Artikelbeilagen-verwaltung &
ZuteilungNINA-Kette
Kundenbuchhaltung Fakturierung
C-Brief Tool
Abrufbreitschaftprüfen
Lieferungs-optimierung
Kategorisierung&
Lieferungsbildung
Mengensteuerung(Dez. + HF)Packplatzbeilagen
EK-Rechner
Anwendungauf EKR
NOA Bestandsverwaltung
EXPORT
SAMMLER
Lager (KR2)
NDEKUBIS /Internet
IBA / OPOS
Rechnungsdatenbank
Teradata
Teradata-Exporte
Lager-kommunikation
Sendungsbeschleunigung
Richtungsermittlung
3GL-Verarbeitung
Effizienzzwang: Beim Planen hinderlich• Alle Meetings werden als Overhead empfunden• Deswegen will man möglichst schnell durch jedes Meeting
kommen• Also wird schnell geplant und nicht diskutiert• Dabei steckt in den Diskussionen viel wert!• Das Planen ist wichtiger als der Plan!
Hierarchie vs. Rolle: ScrumMaster übernehmen Sie
Bisherige Hierarchie schwer abzubauen
Abteilungsleiter
Entwicklungsleiter Projektleiter
Entwickler
Entwickler
Entwicklungsleiter Projektleiter
Entwickler
Scrum-Master achten darauf, dass die Teams den Prozess richtig leben
• Erste Retrospektiverfahrungen:– Retrospektiven sind nicht immer leicht– Gibt es was Neues oder
ist es nicht eigentlich wie immer?– Was wird wohl passieren,
wenn man mal was sagt? (ändert sich ja doch nichts)
– „Können wir jetzt wieder entwickeln?“
• Auch hier hilft Moderation und Scrum-Master mit der Aufgabe zur Verbesserung
• Festgelegte Maßnahmen müssen umgesetzt werden!
Hinterher ist man immer schlauer:Retrospektiven wichtig aber ungewohnt
Retro
Gebrochene Builds:Das wird schon wieder ...• Viele gebrochene Builds• Es wird keine Verantwortung übernommen• Kein schnelles Feedback• Lange Buildzeiten• An der Lösung wird noch gearbeitet
Störungen ...... damit können Sie rechnen!
• Viele Störungen in der Iteration durch– Wartung– Bugfixing in Teststufen– Analysenachfragen– Schätzungen für neue Projekte
• Alles einplanen, was geht• Beispielsweise durch leere Storys als Container• Gedeckelter Aufwand für Störungen
• Langer Atem ist nötig• Große Organisationen bedürfen früher Standardisierung
(zumindest muss ein grober Rahmen abgesteckt sein, sonst entstehen viele Varianten)
• Ausbildung und Information für alle wichtig• Scrum-Master-Rolle (Methodenbegleitung) hilfreich
• Ausblick: – Es geht weiter, wir haben Fahrt aufgenommen– Builds stabilisieren– Baustelle: Integrationstests– Harte Qualitätskriterien einführen– Vorgehen in den Teams standardisieren– Ausrollen in der gesamten Otto-IT
Fazit und Ausblick