Scrum 2009 10_23

Prof. J. Anton Illik1

SCRUMEine agile, iterative Vorgehensweise für die

Software-Entwicklung


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


Rollen


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


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


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


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.


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


Artefakte


Product Backlogs

Abb.1

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

-Produkt-Anforderungen mit Prioritäten

-Pflichtenheft für das Team


Release Backlog

Product Backlogs

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

Release Backlogs

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________


Sprints

Release Backlogs

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

Sprint 1

Sprint 2

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________

__________________


Sprints & Sprint Backlogs (time boxed)

Sprint 1__________________

__________________

__________________

__________________

__________________

Sprint 2__________________

__________________

__________________

__________________

__________________

Sprint 3__________________

__________________

__________________

__________________

__________________

Sprint 4__________________

__________________

__________________

__________________

__________________

__________________


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


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


Zeremonien


Sprint Planning Meeting

Developer

Developer

Developer

(Scrum Master)

Developer

Developer

Product Owner

Timebox: 4 hourOwner: POParticipants: • PO• Team• Scrum Master


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)


Sprint Retrospective

Developer

Developer

Developer

(Scrum Master)

Developer

Developer(Stakeholder)

Timebox: 2 hourOwner: Scrum MasterParticipants: • PO• Team• Scrum Master• Stakeholders


Sprint Review Meeting

Developer

Developer

Developer

(Scrum Master)

Developer

Developer

Product Owner

Timebox: 2 hourOwner: TeamParticipants: Product OwnerTeamScrum Master


Sprints

3 days 30 days


Prozess


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


Das Gerüst von Scrum

Inspektion im

24-Stunden-Rythmus

Product Backlog

Inkrement an Funktionalität

Daily Scrum

SprintIteration


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

http://de.wikipedia.org/wiki/Testgetriebene_Entwicklung


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


Sprint-Planung für mehrere TeamsSprint-Planung für unterschiedlich funktionale Teams

Fakturierung

Zeitplanung

Einweisung

Sprint

Sprint

Sprint


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


Ü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


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


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


ScrumLiteratur zu

Scrum

und

Methodik

der Software-

Entwicklung

Documents

Scrum 2009 10_23