ESEconf2011 - Lorenz Oliver: "'Agil heisst nicht beliebit' - Scrum als wirksames Mittel zur Beherrschung von Projektrisiken"
•
0 j'aime•3,117 vues
Recommandé
Recommandé
Contenu connexe
Similaire à ESEconf2011 - Lorenz Oliver: "'Agil heisst nicht beliebit' - Scrum als wirksames Mittel zur Beherrschung von Projektrisiken"
Similaire à ESEconf2011 - Lorenz Oliver: "'Agil heisst nicht beliebit' - Scrum als wirksames Mittel zur Beherrschung von Projektrisiken" (20)
Plus de Aberla
Plus de Aberla (20)
ESEconf2011 - Lorenz Oliver: "'Agil heisst nicht beliebit' - Scrum als wirksames Mittel zur Beherrschung von Projektrisiken"
- 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)
- 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)
- 18. HerkömlicheProjektmethodik speculate learn function expected functions core functions uncertainty risks start end
- 20. 30 x planen
- 21. 30 x reviewen
- 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
Notes de l'éditeur
- 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)