Einstieg in die agile Entwicklung

Transkript

1 Einstieg in die agile Entwicklung Großprojekterfahrung bei Otto

2 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

3 Die otto group ist weltweit zweitgrößter Online Anbieter im Endkundengeschäft 123 Einzelfirmen 19 Länder Mitarbeiter Segmente Multichannel Einzelhandel Finanzdienstleistungen Service

4 NOA ist eines der größten IT Einzelprojekte des Konzerns Host Migration

5 NOA ist eines der größten IT Einzelprojekte des Konzerns ~70 Mio. Kunde Auftrag Sendung Artikel ~1 Mio. pro Tag ~ pro Tag ~5 Mio.

6 NOA Abteilungsstruktur Abteilung Auftrag Analyse Entwicklung Zentrale Dienste Abteilung Kunde Analyse Entwicklung Abteilung Artikel Analyse Entwicklung Abteilung Lieferung Analyse Entwicklung

7 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

8 Ziele für ein neues Entwicklungsmodell 1. Häufigere und flexiblere Auslieferung 2. Bessere Qualität liefern 3. Tests effektiver durchführen 4. Entwicklung kostengünstiger gestalten 5. Schnellere Reaktion auf Änderungen ermöglichen 6. Geplante Termine zuverlässig einhalten 7. Personal gleichmäßiger auslasten

9 Timeline Erste Pilotprojekte starten Erste agile Multiplikatorenschulungen GO! Vom Vorstand Externer Coach kommt dazu

10 Timeline Weitere Abteilungen folgen JAX

11 Wie sind wir vorgegangen? 1 Entwicklung 2 Analyse 3 Reporting / Management 4 Kunde 5 Andere Systeme

12 Kurzüberblick Neues Liefermodell Anforderung Themenporträt Vorläufiges Angebot optional IT-Konzept Verbindliches Angebot Priorisierte Featureliste Detaillierte Stories für Iteration 1 Detaillierte Stories für Iteration 2 Detaillierte Stories für Iteration 3 Grob- Architektur Design Entwicklung Modultest Fachlicher Test Design Entwicklung Modultest Fachlicher Test Design Entwicklung Modultest Fachlicher Test Iteration 0 (Exploration) Iteration 1 Iteration 2 Iteration 3

13 Kurzüberblick Neues Liefermodell Projektentwicklung Produkttest Fachliche / technische Integration Performance und Stabilität User Acceptance Test

14 Der Iterationsablauf (looks like Scrum)

15 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

16 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

17 Lernerfahrungen in Episoden

18 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?

19 Info, Info, Info oder Ich weiß nicht, was Du nicht weißt 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

20 Code Wissensinseln contra Team IBA / KUBIS / 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 Auftragsverwaltung Preisberechnung Kundenbuchhaltung Artikelbeilagenverwaltung & Zuteilung Produkt Central Order Services (COS) Kundenverwaltung Bestandszuteilung Fakturierung Rechnungsdatenbank NINA-Kette System NOA Abrufbreitschaft prüfen Richtungsermittlung Produkt Central Logistic Services (CLS) NOA Bestandsverwaltung Packplatzbeilagen Lagerkommunikation 3GL- Verarbeitung Kategorisierung & Lieferungsbildung Mengensteuerung (Dez. + HF) Sendungsbeschleunigung EXPORT SAMMLER Lieferungsoptimierung Teradata- Exporte LV D3NOA P01 Run P02 Run DAT7 NOABP P05 Run P07 Run P0...Run P015 Run OPOS NDE Internet Anwendung auf EKR C-Brief Tool EK-Rechner Lager (KR2) Teradata

21 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!

22 Hierarchie vs. Rolle: Scrum Master übernehmen Sie Abteilungsleiter Entwicklungsleiter Projektleiter Entwicklungsleiter Projektleiter Bisherige Hierarchie schwer abzubauen Entwickler Entwickler Entwickler Scrum-Master achten darauf, dass die Teams den Prozess richtig leben

23 Hinterher ist man immer schlauer: Retrospektiven wichtig aber ungewohnt 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! Retro

24 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

25 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

26 Fazit und Ausblick 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