• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
ESEconf2011 - Lorenz Oliver: "'Agil heisst nicht beliebit' - Scrum als wirksames Mittel zur Beherrschung von Projektrisiken"
 

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

on

  • 879 views

 

Statistics

Views

Total Views
879
Views on SlideShare
879
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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)

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

  • Verringerung von Projektrisiken durch Scrum
    Oliver Lorenz, SNB, ESE 2011
    Agil heisst nicht beliebig
  • Kick Off
    iStockphoto®, © Mike Dabell, Kick Off
  • Spielfeld
    © Glen H. (CC)
  • 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)
  • Life-Cycle Coverage
  • Innovationskomponenten
    neu
    Forschung
    Springer
    O’Reilly
  • Weshalb agil mit Scrum?
    © John Martinez Pavliga(CC)
  • 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
  • Scrum Prozess
    Story
    Tageszyklus
    Backlog
    Produkt
  • Dealing with Reality
    magic triangle
    time
    speculate
    learn
    function
    ressources
    function
    expected functions
    core functions
    uncertainty
    risks
    start
    end
  • 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?
  • 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
  • Wer sind die Gegner ?
    Ressourcen
    Akzeptanz
    Anforderungen
    Lieferanten
    Termine
    Stabilität
    Performance
    © ConorLawless(CC)
  • Wieso ist unser Team stark?
    engagierte, qualifizierte Entwicklerteams
    regelmässige Erfolge und Feedback
    continuousimprovement
    time boxing
    involvierte Kunden
    Rituale
    Lernbereitschaft
    © ConorLawless(CC)
  • 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)
  • Scrum bei der SNB
    © John Martinez Pavliga(CC)
  • Sprintplanung 2008-2010
  • HerkömlicheProjektmethodik
    speculate
    learn
    function
    expected functions
    core functions
    uncertainty
    risks
    start
    end
  • Agil-iterative Projektmethodik
    speculate
    learn
    function
    expected functions
    core functions
    uncertainty
    risks
    start
    end
    • ca 30 Sprints:
    • 30 x planen
    • 30 x reviewen
    • 120 x lernen in Workshops
  • Zielkategorien in jedem Sprint
  • Review: Dokument
  • Review: Iterationsfortschritt
    Burndown und Velocity
    Projektparameter
    Zielerreichung
    grösste Verzögerungen
    Risiken und Gegenmassnahmen
  • Review: Burn Down Graph
  • Review: Velocity
  • Retrospektive
  • Herausforderungen
    iStockphoto®, © han3617, Rugby line-out
  • 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
  • Projekt-Controlling
    ursprünglicherRahmenfürRelease 1
    Juni 2008
    Feb-Mai 2009
    Mai 2010
    Anfang 2010
  • Abbau des Backlog in der Phase Transition
  • Atthe End ofthe Game
    iStockphoto®, © kolbz, Rugby Winner
  • Erfolgsfaktoren
    iStockphoto®, © am29, ball rugby
  • Erfolgsfaktoren
    iStockphoto®, © am29, ball rugby
  • Risiken beim Einsatz von Scrum
    iStockphoto®, © Lovattpics, Yellowcard
  • Risiken
    iStockphoto®, © Lovattpics, Yellowcard
  • Empfehlungen
    © Chris Brown(CC)
  • Empfehlungen
    © Chris Brown(CC)
  • Geeignete Einsatzbereiche
    instabil,
    in Bewegung
    dynamisch
    komplex
    agiles
    PM
    Anforderungen
    einfach
    innovativ
    stabil,
    keine Dynamik
    vertraut,
    bekannt
    neu,
    unbekannt
    Lösungsansatz
  • 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
  • Danke für Ihre Aufmerksamkeit
    Ende