Sie sind auf Seite 1von 19

Agile Softwareentwicklung

mit Scrum

http://bambo.it 1
Agenda
• Über Scrum

• Der Prozess

• Die Rollen

• Die Prinzipien

2
Über Scrum
• Ein Framework für das Management
komplexer Projekte
– Technische
Unwägbarkeiten/Machbarkeit
– Sich ändernde Anforderungen

• Ein einfaches Framework für
iterative und inkrementelle
Softwareentwicklung

• Nicht iterativ vs. iterativ 3


Wasserfallmodell




• Es wird zu weit in die Zukunft geplant
• Verlauf 1: Software entspricht nicht den
Anforderungen
• Verlauf 2: Anforderungen ändern sich zu
undefinierten Zeitpunkten
4
Scrum






• Es werden nur 2 – 4 Wochen konkret
geplant.
• Definierter Zeitpunkt für
Anforderungsänderungen 5
Der Prozess

6
Das Product Backlog
• Eine Liste von priorisierten und
geschätzten User Stories
(Anforderungsworkshops)
• Eine User Story beschreibt eine
konkrete Funktionalität aus Sicht
des Anwenders
• Eine User Story ist in der Sprache des
Kunden beschrieben und liefert
einen konkreten Mehrwert
• Template: Als <Benutzerrolle> will
ich <das Ziel>[, so dass <Grund 7
Das Selected Backlog
• Eine Liste der höchstpriorisierten
User Stories aus dem Product
Backlog (Sprint Planning I)
• Festlegung des Sprint Zieles
• Vorstellung, Analyse und
Commitment

8
Das Sprint Backlog
• Ausgewählte User Stories werden in
ihre Einzeltasks zerlegt. (Sprint
Planning II)
• Eine Liste von priorisierten
Einzeltasks.
• Die Umsetzung eines Task sollte nicht
länger als einen Arbeitstag dauern.
• Tasks sind meist
Programmieraufgaben können aber
auch Infrastrukturarbeiten oder 9
Der Sprint
• Eine Entwicklungsphase fester
Länge, an deren Ende das Team
funktionierende Software ausliefert.
• Während des Sprints darf niemand
dem Team nicht geplante Arbeiten
aufdrücken
• Das Team organisiert sich während
des Sprints vollständig selbst und
synchronisiert sich im Daily Scrum.
• 10
Das Daily Scrum
• Das Team trifft sich jeden Tag zu
einer festen Zeit zu einem Stand-up
Meeting. (15min)
• Teammitglieder äußern sich der
Reihe nach zu folgenden drei
Punkten:
1.Was habe ich gestern erreicht?
2.Was plane ich heute?
3.Welche Hindernisse oder Probleme
haben sich mit in den Weg gestellt.
11
Sprint Review/Demo
• Ziel: Feedback von der Außenwelt
• Der Scrum Master erklärt welche
User Stories erreicht bzw. nicht
erreicht wurden
• Das Team stellt jede User Story am
laufenden System vor
• Änderungen oder neue User Stories
werden ins Product Backlog
eingetragen
• 12
Sprint Retrospektive
• Ziel: ständige Verbesserung (Kaizen)
• Daten Sammeln (Positiv/Negativ)
• Einsichten generieren (Warum-
Fragen)
• Entscheiden, was zu tun ist (Dot-
Voting)
• Ziele formulieren und Aktionen
planen

13
Die Rollen

14
Das Team
• Das Team entwickelt die Software
und ist für den Erfolg des Sprints
verantwortlich.
• Innerhalb des Teams gibt es keine
Hierarchien oder Führungsrollen.
• Niemand sagt dem Team wie es zu
arbeiten hat.
• Selbstorganisiert: Keiner weist
jemanden Tasks zu. Kanban-Pull-
System. 15
Der Scrum Master
• Er ist verantwortlich für das Einhalten
von Scrum-Werten und -Techniken.
• Er schützt das Team vor negativen
Einflüssen von außen und beseitigt
Hindernisse.
• Er hat keine Weisungsberechtigung
und ist kein Projekt- oder
Teamleiter.
• Er nimmt keine Verantwortung ab,
sondern sorgt dafür, dass andere
Rollen ihre Verantwortung 16
Der Product Owner
• Er repräsentiert den Kunden.
• Er ist verantwortlich für das Product
Backlog und hat als einziger
schreibrechte darauf.
• Er füllt das Backlog mit User Stories,
priorisiert diese und schätzt sie mit
Hilfe des Teams.
• Er ist während des Sprints immer für
das Team verfügbar um Story
Details zu klären. 17
Scrum Prinzipien I
• Transparenz: Schlechte Dinge
sichtbar machen
• Beobachten & Anpassen: Tests,
Prioritäten,
Entwicklungsgeschwindigkeit
(Velocity)
• Timeboxing: Daily, Sprint Planning,
Sprint
• Dinge Abschließen: User Story,
„Definition of Done“, „Technical 18
Scrum Prinzipien II
• Maximierung von Geschäftswerten:
Priorisierung, Mehrwert, Risiko
• Teams scheitern nicht: keine
Schuldzuweisung, daraus lernen,
Velocity anpassen
• Ergebnisorientiert: nicht die Dauer
sondern das Ergebnis zählt,
„Definition of Done“

19