Your SlideShare is downloading. ×
ESEconf2011 - Lorenz Oliver: "'Agil heisst nicht beliebit' - Scrum als wirksames Mittel zur Beherrschung von Projektrisiken"
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

ESEconf2011 - Lorenz Oliver: "'Agil heisst nicht beliebit' - Scrum als wirksames Mittel zur Beherrschung von Projektrisiken"

2,242

Published on

Published in: Technology, Health & Medicine
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,242
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Bildnachweis: iStockphoto®, © Mike Dabell, Kick Off, #: 10053162In welchem Bereich verwendet die SNB Scrum?Wieso verwendet die SNB in diesen Projekten Scrum?Welche Erfahrungen haben wir mit Scrum gemacht?
  • Bildnachweis:, “View to Rangitoto Island from the top Rugby field at Rangitoto College”, © Glen H. (creativecommons.org)
  • Bildnachweis:, “View to Rangitoto Island from the top Rugby field at Rangitoto College”, © Glen H. (creativecommons.org)2005 zeichnete sich Erneuerungsbedarfder zentralen Softwaresysteme dieser Umgebung abDas „Saisonziel“ war deshalb: Ablösung zentraler, 30 und 10 Jahre alter, in die Abläufe der SNB stark integrierter Systeme Längerfristig (20+ Jahre) effiziente und effektive Lösung Wesentlicher Innovationssprung (fachlich und technisch)
  • Die drei zwischen 2008 und 2011 entwickelten Systeme decken den gesamten Daten-Lifecycle von der Datenerfassung bis zur Erstellung von Publikationen ab
  • Durchgängiger Technologie-Stack für drei neu zu entwickelnde Systeme (O’Reilly-Level)Stammdaten gemäss Domänenmodell (Springer-Level)Ontologie (Konzepte, Individuen, Eigenschaften, Assoziationen, Konsistenzbedingungen und –prüfung)Taxonomie (Bilanzstruktur, hierarchische Bestände)Prozessorientierte Repositories (Springer +)Bi-temporal (sowohl Stamm- als Bewegungsdaten)Voll revisioniert (jeder frühere Systemzustand rekonstruierbar)Staging (aufeinanderfolgende Datenkopien zunehmender Qualität)Autonomie und Effizienz der FachabteilungenSkriptingWorkflow mit Extension Points für die Hinterlegung von Konsistenz- und Auffälligkeitsprüfungen, Reports, Analysen etc.
  • Das gesamt-Projekt war im Antrag von 2007 von Beginn Entwicklung bis Einführung auf ca. 36 Monate angelegtMacro-Ebene „RUP“: Definition der Tätigkeiten und Ziele in den Phasen I,E,C,T. Eintritts- und Austrittsbedingungen: Taktung MonateMicro Ebene Scrum: Taktung Tag
  • Methode aus dem „Katalog“ von Alan Koch (vgl. Literaturangaben)3 Wochen1 Tag planen1 Tag reviewFunktion-getriebenRisiko-getrieben
  • Die Folie im SteeringCommitteeDer Rahmen ist wichtig!! -> Magisches DreieckPlanen am Anfang (wenn wir am wenigsten wissen) ???der Funktionsumfang muss mindestens die Kernfunktionen erreichen. Der Kunde erwartet aber mehr.Erst im Verlauf des Projekts sinken die Unsicherheit und die Risiken (Information wächst)
  • Wir zeigen bessere Methoden auf, Software zu entwickeln,indem wir es vorleben und andere dabei unterstützen. Mit unserer Erfahrung schätzen wirIndividuen und Interaktionen mehr als Prozesse und Werkzeuge,Funktionsfähige Produkte mehr als umfassende Dokumentationen,die gemeinsame Arbeit mit dem Kunden mehr als Vertragsverhandlungen,das Eingehen auf Änderungen mehr als das Einhalten von Plänen.Das heisst, obwohl die Punkte auf der rechten Seiten berechtigt sind, sehen wir einen höheren Wert in den Punkten auf der linken Seite.Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave ThomasSehr anspruchsvoll für den Leser, der neu zu diesem Thema kommt:Rechte Seite im Management-Gefühltraditionelle „Lösungen“Prozesse und Werkzeugeumfassende Dokumentationverbindliche Anforderungskataloge und VerträgePlan verfolgenMan weiss wo man steht, man kann alles belegen, muss sich nichts vorwerfen lassen, hat die „Form“ eingehaltenIndividuen und Interaktion: personenorientierte Abläufe vs. standardisierte ProzesseFunktionstüchtige SW: tönt gut aber vor dem „Meilenstein Release 1“ taugt der Umfang noch nichtgemeinsame Arbeit mit Kunden: Bäume wachsen in den HimmelEingehen auf Änderungen: Wie ist Planbarkeit gegeben?vertraute Projektparameter werden eliminiert
  • Bildnachweis: „Scotland vs Ireland scrum at Edinburgh during the 2007 Six Nations Championship”, © ConorLawless. (creativecommons.org)Vor der Partie sagt der Trainer, welche Gegenwehr und Hindernisse er in der Partie erwartet
  • Bildnachweis: „Scotland vs Ireland scrum at Edinburgh during the 2007 Six Nations Championship”, © ConorLawless. (creativecommons.org)Der Trainer sagt, welche Stärke des Teams er in’s Spiel bringen wird.
  • Bildnachweis: „Scotland vs Ireland scrum at Edinburgh during the 2007 Six Nations Championship”, © ConorLawless. (creativecommons.org)Der Trainer sagt, wie er die Saison- und Match-Spiele erreichen wird
  • Alle Projekte synchron:Integration der Projekt-ReleasesTeilnahme an der Planung und Review des Partner-Teams (als Chicken)Alle Teams in derselben Stress-StimmungZuerst 6 Wochen Iterationen dann 3Am Anfang eher grosser Integrationsbedarf zwischen den ProjektenPlanung und Review am Anfang eher hoch, noch grosse Themen für WorkshopsSeptember 2009: Nach Untersuchung von Massnahmen zur Effizienzerhöhung
  • täglichesProjektkontrollingIndikator: ZeitPflicht des Scrummasters Abweichungen vom Zeitplan zu analysieren und wenn nötig zu handeln (die am ehesten verzichtbaren Tasks opfern und am Review dafür gerade zu stehen)Der Mechaniker kann nicht mehr weiterarbeiten, wenn die Schrauben ausgegangen sindDer Plättlileger kann nicht mehr weiterarbeiten, wenn die Plättli ausgegangen sindDie Wolle geht aus ich muss schneller liesmen!Materialkosten ~ Arbeitsaufwand (offensichtliches Kostenmass)Dem Programmierer gehen die Code-Zeilen niemals ausDer Workshop dauert halt solange wie es braucht und das Protokoll ….Opportunitätskosten sind kein offensichtliches Kostenmass
  • Velocity schon nach wenigen Iterationen bekannt
  • Bildnachweis: iStockphoto®, © han3617, Rugby line-out, #3120972Wachsende und sich ändernde Anforderungen Anpassen des Projetkrahmens Kunde übernimmt Verantwortung
  • Am Anfang wussten wir offensichtlich zu wenigKnownunknownsUnknownunknownsEnde 2009 kannten wirDen Umfang des KernsystemsDie Velocity des Teams und des ProductOwnerDie „Hebel“ und deren Potential: Prozess-Effizienz, Priorisierung Ein Jahr vor geplanter Fertigstellung: Backlog Grooming C5-C7: starke Priorisierung durch Product Owner auf jenen Umfang der mit der nun bekannten Velocity realisierbar ist. Der Projektrahmen wurde leicht erweitert (+1 Quartal mit entsprechenden Mehrkosten)-> Punktlandung im Mai 2010
  • Bildnachweis: iStockphoto®, © am29, ball rugby, #3076051
  • Bildnachweis: iStockphoto®, © am29, ball rugby, #3076051
  • Bildnachweis: iStockphoto®, © Lovattpics, Yellowcard, #13516015Kontrollverlust (wer tun was?)der Auftraggeber hat kein „Auftragsblatt“ auf das er sich bei Meinungsverschiedenheiten beziehen kann die Einhaltung des Prozesses und die Verpflichtung der Rollen auf ihre Aufgaben braucht sehr grosse Disziplin und muss konstant überwacht werden(Selbst-)VertrauenEntwickler: tun wir das was der Kunde will?Kunde: sind wir sicher, dass wir wissen was wir wollen? Kunde->Entwickler: hat die Arbeit die geforderter Qualität (Usability)? Entwickler->Kunde: stimmt das Fachkonzept? Zusammenarbeit, den Lernprozess des Gegenüber akzeptieren, sich gegenseitig fordernUnbekanntes Endziel, unbekannter ProjektumfangSicht nur auf kurze Frist (aktueller und nächster Sprint)Teppichwalze: wir schieben einen immer grösseren Berg von Stories/Funktionen vor uns herwir verlieren das Gefühl, wann das Projekt abgeschlossen sein wird und welche Funktion zur Verfügung stehen wirdNeben der Sprint-Planung gibt es eine Langzeitplanung. Jeder Sprint-Review umfasst einen Forecast bis Projektende und eine Überprüfung der Langzeitplanung.Der Projektrahmen (Ressourcen/Zeit) wird realistisch geschätzt (Resultat der Elaboration, falls möglich Beizug von Referenzprojekten) und ist durch Priorisierung einzuhalten. Eine Ausdehnung des Projektrahmens ist möglich, muss aber nach Spielregeln verlaufen.
  • Bildnachweis: „Referee with Ball“, © Chris Brown (creativecommons.org)Mit geeigneten Projekten startenneuer Lösungsansatz oder unklare AnforderungenBereitschaft im Management sich auf eine ungewohnte Methode einzulassenCommittment des Product Owner vor ProjektstartDer Product Owner muss von Anfang an beteiligt sein (Zielformulierung, Definition und Besetzung der begleitenden Gremien, Projektablauf)Die „rechte Seite“ des Manifests nicht vernachlässigen:Absolute Disziplin bei der Einhaltung des Scrum-ProzessesSpezielle Rolle „Process Owner“ definieren (unabhängig aber mit „Entscheidungs- und Gestaltungsmacht“)Workshops, Protokolle und System-Dokumentation sind Deliverableswerden in der Planung explizit bestellt und vom Team als Tasks geplant Klare Spielregeln zwischen Kunden und Projektteam, den Kunden hartnäckig fordern (z.B. Backlog-Grooming)Möglichst früh eine gemeinsame Vision und einen akzeptablen Projektrahmen entwickeln (Inception/Elaboration)
  • Wo funktionierts und bringt’s was?Quadrant (Risiken, Controlling)Productowner ausserhalb des TeamsAufgabe lässt sich in Sprints einteilenAufgabe hat adäquate Grösse (rechtfertigt Aufwand)Wo nicht?Kontinuierliche Arbeitsleistung (-> Kanban)Product Owner nötig aber nicht verfügbar (ansprechbar)
  • Transcript

    • 1. Verringerung von Projektrisiken durch Scrum
      Oliver Lorenz, SNB, ESE 2011
      Agil heisst nicht beliebig
    • 2. Kick Off
      iStockphoto®, © Mike Dabell, Kick Off
    • 3. Spielfeld
      © Glen H. (CC)
    • 4. Spielfeld
      externe Quellen und
      Empfänger
      PRIMA
      (Primär Statistik)
      EASY-R
      (zentrales Zeitreihen-system)
      Aggregate
      interne Datenquellen
      Gallery (Visuali-sierung)
      interne Publikationen
      Intranet
      externePublikationen
      www.snb.ch
      © Glen H. (CC)
    • 5. Life-Cycle Coverage
    • 6. Innovationskomponenten
      neu
      Forschung
      Springer
      O’Reilly
    • 7. Weshalb agil mit Scrum?
      © John Martinez Pavliga(CC)
    • 8. Time Line
      Vorgängersystem (Oase)
      Inception &
      Elaboration
      T
      PRIMA R1 Construction
      Production
      PRIMA Migration
      (Daten)
      PRIMA R2
      Construction
      T
      I&E
      Production
      November 2010
      Vorgängersystem (Easy)
      Production
      Inception &
      Elaboration
      EASY-R R1
      Construction
      T
      EASY-R Migration
      (Prozesse)
      Production
      EASY-R R2
      Construction
      T
      I&E
    • 9. Scrum Prozess
      Story
      Tageszyklus
      Backlog
      Produkt
    • 10. Dealing with Reality
      magic triangle
      time
      speculate
      learn
      function
      ressources
      function
      expected functions
      core functions
      uncertainty
      risks
      start
      end
    • 11. Meine Meinung:
      Keine Methode entfernt auch nur ein Projektrisiko
      aber sie bietet vielleicht adäquate Lösungen, um mit Risiken umzugehen
      Keine Methode fügt mehr Projektrisiken ein
      aber sie bietet vielleicht keine adäquaten Lösungen, um mit Risiken umzugehen
      Welche Risiken werden durch Scrum vermieden?
    • 12. We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:
      Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
      That is, while there is value in the items onthe right, we value the items on the left more.
      Manifesto for Agile Software Development
    • 13. Wer sind die Gegner ?
      Ressourcen
      Akzeptanz
      Anforderungen
      Lieferanten
      Termine
      Stabilität
      Performance
      © ConorLawless(CC)
    • 14. Wieso ist unser Team stark?
      engagierte, qualifizierte Entwicklerteams
      regelmässige Erfolge und Feedback
      continuousimprovement
      time boxing
      involvierte Kunden
      Rituale
      Lernbereitschaft
      © ConorLawless(CC)
    • 15. Was ist die Strategie?
      Klare Spielregeln und Spielerrollen
      viele Sprints
      regelmässige Scrums
      klare Ziele und vager Spielplan für das gesamte Spiel
      klare Ziele und Strategie für den aktuellen Sprint
      © ConorLawless(CC)
    • 16. Scrum bei der SNB
      © John Martinez Pavliga(CC)
    • 17. Sprintplanung 2008-2010
    • 18. HerkömlicheProjektmethodik
      speculate
      learn
      function
      expected functions
      core functions
      uncertainty
      risks
      start
      end
    • 19. Agil-iterative Projektmethodik
      speculate
      learn
      function
      expected functions
      core functions
      uncertainty
      risks
      start
      end
      • ca 30 Sprints:
      • 20. 30 x planen
      • 21. 30 x reviewen
      • 22. 120 x lernen in Workshops
    • Zielkategorien in jedem Sprint
    • 23. Review: Dokument
    • 24. Review: Iterationsfortschritt
      Burndown und Velocity
      Projektparameter
      Zielerreichung
      grösste Verzögerungen
      Risiken und Gegenmassnahmen
    • 25. Review: Burn Down Graph
    • 26. Review: Velocity
    • 27. Retrospektive
    • 28. Herausforderungen
      iStockphoto®, © han3617, Rugby line-out
    • 29. Wunsch und Realität
      speculate
      learn
      function
      expected functions
      core functions
      uncertainty
      risks
      start
      end
      speculate
      learn
      function
      Priorisierung durch Product Owner
      expected functions
      core functions
      uncertainty
      risks
      start
      end
    • 30. Projekt-Controlling
      ursprünglicherRahmenfürRelease 1
      Juni 2008
      Feb-Mai 2009
      Mai 2010
      Anfang 2010
    • 31. Abbau des Backlog in der Phase Transition
    • 32. Atthe End ofthe Game
      iStockphoto®, © kolbz, Rugby Winner
    • 33. Erfolgsfaktoren
      iStockphoto®, © am29, ball rugby
    • 34. Erfolgsfaktoren
      iStockphoto®, © am29, ball rugby
    • 35. Risiken beim Einsatz von Scrum
      iStockphoto®, © Lovattpics, Yellowcard
    • 36. Risiken
      iStockphoto®, © Lovattpics, Yellowcard
    • 37. Empfehlungen
      © Chris Brown(CC)
    • 38. Empfehlungen
      © Chris Brown(CC)
    • 39. Geeignete Einsatzbereiche
      instabil,
      in Bewegung
      dynamisch
      komplex
      agiles
      PM
      Anforderungen
      einfach
      innovativ
      stabil,
      keine Dynamik
      vertraut,
      bekannt
      neu,
      unbekannt
      Lösungsansatz
    • 40. Risikomanagment für IT- und Softwareprojekte, Ein Leitfaden für die Umsetzung in der Praxis [2004]: Ernest Wallmüller, Hanser, ISBN 3-446-22430-0
      Agile Software Development, EvaluatingtheMethodsforYourOrganization[2005]: Koch, Alan S., Artech House Inc., ISBN 1-58053-842-8
      Agile Project Management with Scrum [2003]: Ken Schwaber, Microsoft Press, ISBN 0-7356-1993-X
      Agile Retrospectives, Making Good Teams Great [2006]: E. Derby & D. Larsen, Pragmatic Bookshelf, ISBN 0-9776166-4-9
      Literatur
    • 41. Danke für Ihre Aufmerksamkeit
      Ende

    ×