Scrum Scrum

Document Sample
Scrum Scrum Powered By Docstoc
					Scrum




                                 Scrum

                              Martin Müller

                          Universität Duisburg-Essen


                              9. März 2010




 Martin Müller (UniDUE)             Scrum              9. März 2010   1 / 30
                             Einführung

Überblick
1   Einführung
2   Der Prozess
      Die Rollen
      Vision
      Product Backlog
      Schätzklausur
      Sprint Planning Meetings
      Sprint
      Daily Scrum
      Sprint Review
      Sprint Retrospektive
3   Planen in Scrum
4   Berichterstattung in Scrum
5   Skalieren von Teams
6   Fazit
    Martin Müller (UniDUE)            Scrum   9. März 2010   2 / 30
                            Einführung

Wofür braucht man Scrum?




    60% aller Softwareprojekte scheitern
    klassische Softwareintwicklungsprozesse sind durch vollständig
    definierte Prozesse unflexibel
    Fehler werden in den klassischen Entwicklungsprozessen erst
    sehr spät sichtbar
Scrum möchte damit Schluss machen!




   Martin Müller (UniDUE)            Scrum              9. März 2010   3 / 30
                           Einführung

Entwicklung von Scrum




   1994 Fertigstellung des ersten dokumentierten Projekts mit Scrum
   1996 erster Vortrag von Ken Schwab über Scrum
   stetige Weiterentwicklung




  Martin Müller (UniDUE)            Scrum              9. März 2010   4 / 30
                                 Einführung

Überblick




                           Abbildung: Der Scrum Prozess
  Martin Müller (UniDUE)                  Scrum           9. März 2010   5 / 30
                            Einführung

Wobei hilft Scrum uns nicht?




    Designerstellung
    Codeerstellung
    Testverfahren
Das Team ist in seiner Arbeitsweise durch nichts eingeschränkt.




   Martin Müller (UniDUE)            Scrum               9. März 2010   6 / 30
                           Der Prozess   Die Rollen

Product Owner




   meistens Product Manager oder Marketingmitarbeiter
   repräsentiert die Sicht des Kunden
   Anforderungsbeschreibung
   priorisiert das Product Backlog
   hat komplette Entscheidungsfreiheit bezüglich des Projekts




  Martin Müller (UniDUE)             Scrum              9. März 2010   7 / 30
                           Der Prozess   Die Rollen

Scrum Master




   achtet darauf, dass Scrum richtig angewandt wird
   macht veraltete Arbeitsweisen sichtbar
   hilft dem Team selbstorganisiert zu arbeiten
   Abschirmung des Teams von der Außenwelt




  Martin Müller (UniDUE)             Scrum            9. März 2010   8 / 30
                           Der Prozess   Die Rollen

Team




  besteht aus 5-12 Personen
  ist interdisziplinär besetzt
  fühlt sich für den Projekterfolg verantwortlich
  arbeitet selbstorganisiert
  muss seine Verpflichtungen einhalten




 Martin Müller (UniDUE)              Scrum            9. März 2010   9 / 30
                           Der Prozess   Die Rollen

Stakeholder




   Kunden
   Anwender
   eigenes Management




  Martin Müller (UniDUE)             Scrum            9. März 2010   10 / 30
                           Der Prozess   Vision

Vision




   wird vom Product Owner erstellt
   zeigt dem Team warum und woran es arbeitet
   hilft die eingeschlagene Richtung abzugleichen




  Martin Müller (UniDUE)             Scrum          9. März 2010   11 / 30
                            Der Prozess   Product Backlog

Product Backlog

   enthält Anforderungen
   häufig in User Stories ausgedrückt
   jede Anforderung muss einen Mehrwert für den Kunden
   ausdrücken
   es können jederzeit neue Anforderungen hinzugefügt werden
   die Anforderungen müssen priorisiert werden
          Anforderungen mit hohem Wert und hohem Risiko bekommen
          Vorzug
          Anforderungen mit hohem Wert und geringem Risiko werden später
          umgesetzt
          Anforderungen mit geringem Wert und geringem Risiko werden
          zum Schluss umgesetzt
          Anforderungen mit geringem Wert und hohem Risiko werden
          vermieden


  Martin Müller (UniDUE)              Scrum                 9. März 2010   12 / 30
                             Der Prozess   Schätzklausur

Die Schätzklausur




   Treffen von Scrum Master, Product Owner und Team
   findet einmal zu Beginn und in jedem Sprint statt
   nicht die Personentage, sondern die Größe der Anforderungen
   wird geschätzt
   1,3,5,8,13,20,40,100 ist eine geeignete Punktesequenz
          ermöglicht die Unsicherheit bei großen Stories zu berücksichtigen




  Martin Müller (UniDUE)               Scrum                  9. März 2010   13 / 30
                           Der Prozess   Sprint Planning Meetings

Sprint Planning Meeting 1




   Ziel: welche Anforderungen werden im kommenden Sprint
   umgesetzt?
   das Team entscheidet, wie viel umgesetzt werden soll
   findet in einem 4 stündigen Zeitfenster statt
   der Product Owner verfasst ein Sprint Ziel
   Velocity gibt eine Richtgröße für die Menge der Backlog Items vor




  Martin Müller (UniDUE)             Scrum                          9. März 2010   14 / 30
                           Der Prozess   Sprint Planning Meetings

Sprint Planning Meeting 2



   Ziel: wie werden die Anforderungen umgesetzt?
   das Team entscheidet wie es die ausgewählten Anforderungen
   implementieren möchte
   findet in einem 4 stündigen Zeitfenster statt
   die grobe Architektur für den Sprint wird geplant
   Systemarchitektur wird inkrementell erstellt
   Anforderungen werden in kleine konkrete Tasks zerteilt
   als Ergebnis erhalten wir das Sprint Backlog




  Martin Müller (UniDUE)             Scrum                          9. März 2010   15 / 30
                             Der Prozess   Sprint

Sprint

   das Team implementiert die Anforderungen
   nur 100% fertiger, getesteter und dokumentierter Code wird
   akzeptiert
   Endzeit vorher festgelegt
   nicht verschiebbar, festes Zeitfenster
   das Team arbeitet selbstorganisiert und darf durch nichts gestört
   werden
   Team hat zu viele Anforderungen ausgewählt
          Mitteilung an den Product Owner
          wenn Sprint Ziel in Gefahr, dann wird Sprint abgebrochen
   Team hat zu wenig Anforderungen ausgewählt
          Review-Arbeiten durchführen
          neue Anforderungen vom Product Owner holen


  Martin Müller (UniDUE)               Scrum                 9. März 2010   16 / 30
                           Der Prozess   Daily Scrum

Daily Scrum



   Was wurde am letzten Tag gemacht?
   Was wird heute gemacht?
   Welche Probleme sind aufgetreten?
   Zeitfenster von 15 Minuten
   wird im Stehen durgeführt
   das Team und der Scrum Master müssen anwesend sein, Product
   Owner und Stakeholder sind erwünscht
   weitere Kommunikation im Anschluss erforderlich




  Martin Müller (UniDUE)             Scrum             9. März 2010   17 / 30
                           Der Prozess   Sprint Review

Sprint Review




   das Produkt wird vom Product Owner abgenommen
   Stakeholder dürfen ihre Meinung äußern
   durch ein Zeitfenster beschränkt
   nur 100% fertiger Code darf abgenommen werden




  Martin Müller (UniDUE)             Scrum               9. März 2010   18 / 30
                            Der Prozess   Sprint Retrospektive

Sprint Retrospektive



   durch ein Zeitfenster beschränkt
   Sprint wird reflektiert
   positive Dinge werden hervorgehoben
   negative Dinge werden der Wichtigkeit nach angegangen
   Scrum Master moderiert das Meeting
   komplettes Team ist anwesend
   wichtiger Bestandteil von Scrum




  Martin Müller (UniDUE)              Scrum                      9. März 2010   19 / 30
                           Planen in Scrum

Planen in Scrum



   Releaseplan, damit der Kunde Informationen über das Projekt
   erhält
   nur eine Vorhersage
   Zeit, Funktionalität oder Budget darf angepasst werden
   Qualität darf nicht angepasst werden
   Velocity und kumulierte Aufwände aus dem Product Backlog
   relevant
   Fehltage, Urlaub und Krankheitswellen müssen berücksichtigt
   werden




  Martin Müller (UniDUE)                 Scrum         9. März 2010   20 / 30
                           Berichterstattung in Scrum

Berichterstattung in Scrum




   nur 100% fertiger Code darf in das Berichtswesen einfließen
   Release-Burndown-Chart
   Sprint-Burndown-Chart
   Velocity Chart




  Martin Müller (UniDUE)                            Scrum   9. März 2010   21 / 30
                           Berichterstattung in Scrum

Release-Burndown-Chart




  Martin Müller (UniDUE)                            Scrum   9. März 2010   22 / 30
                           Berichterstattung in Scrum

Sprint-Burndown-Chart




  Martin Müller (UniDUE)                            Scrum   9. März 2010   23 / 30
                           Berichterstattung in Scrum

Velocity Chart




  Martin Müller (UniDUE)                            Scrum   9. März 2010   24 / 30
                           Skalieren von Teams

Skalieren von Teams



   Scrum ist auch bei mehreren und verteilten Teams anwendbar
   Komplexität steigt deutlich an
   Kommunikationspfade steigen exponentiell an
   neue Regeln notwendig
   Chief Product Owner muss allen Teams das Ziel motivieren
   im Scrum of Scrums berichten die Teams gegenseitig über die
   erfolgte und zu erledigende Arbeit
   viel Erfahrung und gute Planung erforderlich




  Martin Müller (UniDUE)                     Scrum   9. März 2010   25 / 30
                                    Fazit

Zusammenfassung




                          Abbildung: Der Scrum Prozess
 Martin Müller (UniDUE)                 Scrum            9. März 2010   26 / 30
                             Fazit

Vorteile von Scrum


   Probleme werden sehr früh sichtbar.
   Die Mitarbeiterzufriedenheit steigt, da keine Vorgaben gemacht
   werden. Das Team ist selbstorganisiert.
   Die Kundenzufriedenheit steigt. Der Kunde kann jederzeit
   Anforderungen hinzufügen, neu priorisieren oder entfernen. Der
   Kunde sieht schon früh, ob sich sein Produkt in die richtige
   Richtung entwickelt.
   Die Software kann schon früh mit einigen Grundfunktionalitäten
   eingesetzt werden. Dadurch kann auch schon früh Geld verdient
   werden.




  Martin Müller (UniDUE)         Scrum                 9. März 2010   27 / 30
                             Fazit

Nachteile von Scrum




   Scrum einzuführen ist harte Arbeit, da Probleme nicht mehr
   ausgeblendet werden können.
   Unternehmensstrukturen müssen geändert werden, damit das
   Team selbstorganisiert arbeiten kann und die notwendige
   Unterstützung erhält.




  Martin Müller (UniDUE)         Scrum                9. März 2010   28 / 30
                               Fazit

Fazit




   viele namenhafte Unternehmen setzen Scrum ein (Google,
   Toyota, . . . )
   Zahl der Nutzer steigt stetig
   gute Methode um mit unpräzisen und unvollständigen
   Anforderungskatalogen umzugehen




  Martin Müller (UniDUE)           Scrum            9. März 2010   29 / 30
                            Fazit

Ende




                          Fragen?
Vielen Dank für die Aufmerksamkeit!




 Martin Müller (UniDUE)         Scrum   9. März 2010   30 / 30

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:35
posted:3/18/2011
language:German
pages:30