scrum 2009 10_23
DESCRIPTION
SCRUM im ÜberblickTRANSCRIPT
Prof. J. Anton Illik1
SCRUMEine agile, iterative Vorgehensweise für die
Software-Entwicklung
Prof. J. Anton Illik22
Artefa
kte
Zeremonien
Rollen
Sprint Backlog
Release Backlog
Product Backlog
Before Sprint: Sprint Planning Meeting
During Sprint: Daily Scrum
After Sprint: Review Meeting
Scrum Master
Product Owner
Development Team
Burn-down-chart
Pair-Programming
Scrum Überblick
Prof. J. Anton Illik33
Rollen
Prof. J. Anton Illik44
Product Owner (PO)
• Verantwortlich für: Product Backlog und Priorisierung
• Legt Prioritätslisten der anfallenden Aufgaben an (Product Backlog)
• Verantwortlich für die Rendite, den Return on Investment (ROI)
• Validiert Ergebnisse und prüft, ob die Qualität aus Sicht der Endnutzer akzeptabel ist
• Entscheidet über die Wichtigkeit einzelner Funktionen
• Er muss dem Team eine Vorstellung über das fertige Produkt vermitteln (Produktvision)
• Muss auf Rückfragen schnell reagieren
• Erfüllt in einem Projekt die Rolle des Kommunikators
• Koordiniert die finanzielle Seite der Produktentwicklung
Prof. J. Anton Illik55
Development Team
• Verantwortlich für Software (Owner)
• Sind selbst organisiert• Learning by doing• Muss alles tun um das
gesteckte Sprint-Ziel zu erreichen (“commitment”)
Software Developer
Software Developer
Software Developer
Software Developer
Software Developer
Prof. J. Anton Illik66
Scrum Master
• “Agile Leader” nimmt sich zurück und tritt hinter das Team (Scrum Master ist nicht Mitglied des Teams; er ist Owner of Scrum Process)
• Sorgt dafür das, dass Team die Methoden von Scrum beachtet und umsetzt
• Mischt sich nicht in die entscheidungsspezifischen Entscheidungen des Teams ein
• Berät das Team und steht ihm zur Seite
• Greift nur ein wenn das Team oder ein anderer an Projekt Beteiligter die Scrum-Regeln verletzt
• Muss Schwierigkeiten verhindern, die das Team bei der Arbeit behindern oder stören können
Prof. J. Anton Illik77
Teambildung in vier Phasen
Forming
• Die Gruppe kommt zusammen, lernt sichkennen und Beziehungenbilden sich heraus.
• Jeder sucht seinen Platz im Team
Storming
• Die Teammitglieder identifizieren Unstimmigkeiten bezüglich des Vorgehens und derMethoden, die jeder für sich als wichtig bewertet.
• Das führt zu Konfliktendie offene Diskussionenhervorrufen und vonjedem erfordern, deneigenen Standpunkt klar zu vertreten.
• Es gilt außerdem, eigeneGrenzen zu erkennen
Norming
• In dieser Phase arbeitetdas Team daran, allenötigen Best Practices für das gemeinsamevorgehen zu definierenund zu implementieren, um alles, was die täglicheArbeit stören könnte, zu beseitigen.
• In dieser Phase identifiziert die Gruppe die Fähigkeiten, Expertise und Talent, die die einzelnen Mitglieder einbringen können.
Performing
• In der letzten Phase hat das Team Unabhängigkeit und Selbstbewusstsein erlangt und kann die meisten Schwierigkeiten, die sich während der Produktentwicklung ergeben, selbst ausräumen.
• Die Reife und Effizienz der angewandten Best Practices wird kontinuierlich verbessert und optimiert, und das Team erreicht die ihm eigene Geschwindigkeit und Produktivität.
Prof. J. Anton Illik88
Fünf Aspekte, die sich gegenseitig beeinflussen, können die Teamarbeit behindern
kein Gesamt-bild vor Augen
keine Rechenschaft abzulegen
fehlendes Commitment
Ängste vor Konflikten
fehlendes Vertrauen
Prof. J. Anton Illik9
Artefakte
Prof. J. Anton Illik1010
Product Backlogs
Abb.1
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
-Produkt-Anforderungen mit Prioritäten
-Pflichtenheft für das Team
Prof. J. Anton Illik1111
Release Backlog
Product Backlogs
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
Release Backlogs
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
Prof. J. Anton Illik1212
Sprints
Release Backlogs
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
Sprint 1
Sprint 2
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
__________________
Prof. J. Anton Illik1313
Sprints & Sprint Backlogs (time boxed)
Sprint 1__________________
__________________
__________________
__________________
__________________
Sprint 2__________________
__________________
__________________
__________________
__________________
Sprint 3__________________
__________________
__________________
__________________
__________________
Sprint 4__________________
__________________
__________________
__________________
__________________
__________________
Prof. J. Anton Illik1414
Burndown-Diagramm
Release-1
Verbleibender Arbeitsaufwand in
Tagen
0
10
20
30
40
50
60
70
80
90
1 2 3 4 5 6 7 8 9
Release-2
Release-3
Release-4
Prof. J. Anton Illik1515
Prinzip des Product Backlogs
Anforderungen in Textform (jede
Anforderung eine Zeile)
Product Backlog:
In diesem Sprint: klar definierte Arbeit, kann <30 Tagen erledigt werden; ausführbares Programm erzeugen.
Wahrscheinlicher nächster Sprint: nächste Backlog-Priorität, von Ergebnissen des vorigen Sprints abhängig.
Während eines Sprints ist das dazugehörige Product Backlog fixiert und kann nur als Ergebnis der in diesem Sprint durchgeführte Arbeit verändert werden. Außerhalb des aktuellenSprints wird das Produkt Backlog immer geändert, weiterentwickelt und neu mit Priorität versehen.
Geplantes
Release
Prof. J. Anton Illik1616
Zeremonien
Prof. J. Anton Illik1717
Sprint Planning Meeting
Developer
Developer
Developer
(Scrum Master)
Developer
Developer
Product Owner
Timebox: 4 hourOwner: POParticipants: • PO• Team• Scrum Master
Prof. J. Anton Illik1818
Daily Scrum Meeting Timebox:15 minutes
Three Questions:
• What have I done since last meeting?
• What will I do until next meeting?
• What problems do I have?
Developer
Developer
Developer
(Scrum Master)
Developer
Developer(Stakeholder)
Prof. J. Anton Illik1919
Sprint Retrospective
Developer
Developer
Developer
(Scrum Master)
Developer
Developer(Stakeholder)
Timebox: 2 hourOwner: Scrum MasterParticipants: • PO• Team• Scrum Master• Stakeholders
Prof. J. Anton Illik2020
Sprint Review Meeting
Developer
Developer
Developer
(Scrum Master)
Developer
Developer
Product Owner
Timebox: 2 hourOwner: TeamParticipants: Product OwnerTeamScrum Master
Prof. J. Anton Illik2121
Sprints
3 days 30 days
Prof. J. Anton Illik2222
Prozess
Prof. J. Anton Illik2323
From Release Planning to the Daily Scrum
24 hours
time
Product Backlog
Sprint
Backlogs
Daily Scrum
Potentially Shippable Product
Increment
Release
Backlogs
Sprint2 – 4
weeks
Prof. J. Anton Illik2424
Das Gerüst von Scrum
Inspektion im
24-Stunden-Rythmus
Product Backlog
Inkrement an Funktionalität
Daily Scrum
SprintIteration
Prof. J. Anton Illik2525
Scrum ProcessMore on Test Driven Development
(Re) Write a test
Write production code
Clean up code
Check if the Test fails
Run all tests
Test succeeds
Test fails
Test fails
All tests succeed
Repeat
Test succeeds
Siehe auch: http://de.wikipedia.org/wiki/Testgetriebene_Entwicklung
Prof. J. Anton Illik26
Prinzip des Sprints bei skalierten Projekten
Start-Product Backlog- funktionale Anforderungen- nicht funktionale Anforderungen- Staging der nicht funktionalen Anforderungen- die übrigen funktionalen und nicht funktionalen Anforderungen
Product Backlog- Funktionale Anforderungen- nicht funktionale Anforderungen
Viele Teams
Einzelnes Team
Prof. J. Anton Illik27
Sprint-Planung für mehrere TeamsSprint-Planung für unterschiedlich funktionale Teams
Fakturierung
Zeitplanung
Einweisung
Sprint
Sprint
Sprint
Prof. J. Anton Illik28
Burn down Charts• Work that is complete is track against remaining days of
the sprint
• The target line indicates the velocity the team should track to during a sprint
• Points above the line indicate work trending shower, points below the line indicates work trending faster
• As you complete your work you should trend downward to 0 hours of work on the last day on the sprint
Prof. J. Anton Illik29
Überblick über den Scrum Prozess
Alle 24
Stunden
Sprint Backlog
Demonstration der neuen Funktionalität zum Sprint-Ende
Ausgewähltes Product Backlog
Product Backlog: sich abzeichnende Anforderungen höchster Priorität
Vision: erwarteter ROI, Releases,
Meilensteine
Sprint
Prof. J. Anton Illik30
Scrum Process
ReleaseScrum ProcessScrum ProcessUpdate Product Backlog
Sprint retrospective
Sprint review
Daily CycleSprint planning meeting
Product increment
• Business case & funding• Contractual agreement• Vision• Initial product backlog• Initial release plan• Stakeholder buy-in• Assemble Team
Preparation
Prof. J. Anton Illik31
Scrum Process
ReleaseScrum ProcessScrum Process
Update Product Backlog
Sprint retrospective
Sprint review
Daily CycleSprint planning meeting
Product increment
• Business case & funding• Contractual agreement• Vision• Initial product backlog• Initial release plan• Stakeholder buy-in• Assemble Team
Preparation
Scrum Artifacts
ListProduct Backlog
Product Backlog
Burn down
Sprint Backlog
Backlog Delta
____________
____________
____________
Scrum Rolls
Product Owner
Scrum Master
Prof. J. Anton Illik3232
ScrumLiteratur zu
Scrum
und
Methodik
der Software-
Entwicklung