6. 1984
•Managing the
New Product
Development
Process
1986
•Erster Artikel über
ein neues
holtistische
Vorfahren.
•Moving the Scrum
Downfield„
1990
•Scrum
Downfield„Wicked
Problems,Righteous
Solutions
1995
•SCRUM
1999
•A Pattern
Language for
Hyperproductive
Software
Developement“
Scrum by coPROcess
7
7. Scrum ist keine Methode. Scrum bietet
keineAntworten auf, wie man qualitativ
hochwertige Software schneller baut.
Scrum ist ein Rahmen, in dem das Spiel
der Produktentwicklung abgespielt wird.
IhrTeam spielt und, Gutes oder
Schlechtes wird sehr sichtbar.
IhrTeam befindet sich in einem Prozess
der kontinuierlichenVerbesserung.
Scrum by coPROcess 8
9. Scrum ist ein flexibles Framework für komplexe Projekte.
Ursprünglich ist Scrum für Software-Entwicklung
formalisiert worden. Aber es funktioniert auch gut für
komplexe und innovative Projekte.
Der Scrum Rahmen ist trügerisch einfach.
10Scrum by coPROcess
10. Scrum Rahmen
Der Product Owner legt eine Liste
der Features namens Product
Backlog
Während des Sprint Planning, “zieht”
dasTeam ein Stück vom Haupt dieser
Liste: der Sprint Backlog; und
entscheidet, wie man dieses umsetzt.
DasTeam hat eine Zeitspanne um
dieses Ziel zu erreichen: der Sprint
❶
11Scrum by coPROcess
11. Scrum Rahmen
JedenTag messt dasTeam seine
Entwicklung während 15’: der Daily
Scrum
Während des gesamten Projekts,
sorgt der ScrumMaster dafür, dass
dasTeam auf seineAufgabe
konzentriert bleibt.
Am Ende des Sprints, muss dieArbeit
potenziell lieferbar sein. Diese
Arbeit gilt als fertig.
❷
12Scrum by coPROcess
12. Scrum Rahmen
Der Sprint beendet sich mit der
Sprint Review und die
Retrospective.
Wenn der nächste Sprint startet,
wählt dasTeam einen neuen Stück im
Product Backlog und wiederholt den
Prozess.
Der Prozess wird beendet, wenn
genug Features ausgestellt sind, oder
das Budget verbraucht ist, oder die
Frist erreicht ist.
❸
13Scrum by coPROcess
17. 5 bis 7 Leute
Bestehend
aus
Generalisten-
Experten
Self-
Managed-
Team
18Scrum by coPROcess
18. Self-Managed-Team
Traditionelle Organisation
Kundenorientiert Management getrieben
Multi-kompetente Arbeitskraft Belegschaft von isolierten Spezialisten
Wenig Stellenbeschreibungen Viele Stellenbeschreibungen
Weithin geteilte Information Begrenzte Information
Nur wenige Management-Ebene Viele Managements Ebenen
Whole Business Oriented Funktion / Abteilung konzentriert
Geteilte Ziele GetrennteZiele
Scheinbar chaotisch Scheinbar organisiert
Ziel orientert Problemlösung orientiert
Hohe Arbeitnehmer Engagement Hohes Management Engagement
KontinuierlicheVerbesserungen InkrementelleVerbesserungen
Selbst-gesteuert Management gesteuert
Werte / Prinzipien basiert Politik /Verfahren basiert
Source: "Leading self-directed work teams" by Kimball Fisher. Frei Überstetzung Pierre NEIS.
19Scrum by coPROcess
19. Gewährleistet
Hilft
Coacht
Schützt
Beseitigt
Verantwortlich
Arbeitet mit
20Scrum by coPROcess
20. Verantwortlich für
den Product
Backlog
Sichert dieWert
Anschaffung
Akzeptiert
Verwirft
Unterhält
Arbeitet mit
21Scrum by coPROcess
25. Moderator:
Product Owner
Teilnehmer:Team
(aktiv),
ScrumMaster
(passiv)
Dauer: 8 Stunden
für einen 4
wochiger Sprint
2TEILE:
Sprint Planning 1: das WAS?
Sprint Planning 2: das WIE?
PRODUCT OWNER:
Stellt den vom Kunden/Users prioritierten
Product Backlog vor
Stellt den Release Plan vor.
Erklärt die Vision
TEAM:
Schätzt den Product Backlog im Hinnblickt
zur Machbarkeit (funktionale Schätzung)
Schneidet den Product Backlog in Sprint
Backlogs mit dem Product Owner
Schneidet den Sprint Backlog in Tasks
TEAM UND PRODUCT OWNER:
Definiert das Sprint Objectiv
Definiert die “Definition of Done” für den
Sprint.
26Scrum by coPROcess
27. Moderator:
Team
Teilnehmer :
Team,
ScrumMaster,
Product Owner
Dauer: 2-4
Wochen
Entwicklung der
Applikationen vom Sprint
Backlog an dem dasTeam
engagiert ist.
Wartung des Level of Done:
Developement
Unit test
Acceptance
Integrations test
System tests
Performance
ZusammenVerwaltung der
Hindernisse mit den
ScrumMaster
ZusammenWartung des Sprint
Backlog mit den Product Owner
28Scrum by coPROcess
29. Moderator:
Team
Teilnehmer :
Team (aktiv),
ScrumMaster
(passiv), Product
Owner (passiv)
Dauer: 15 min
Es ist das Inspect-
and-Adapt vom
Team:
Synchronisierung
und Engagement
Die 3 Fragen:
1. Was hast du
Gestern gemacht?
2. Welche
Hindernisse?
3. ¨Was hast du
heute vor?
30Scrum by coPROcess
31. Moderator: Product
Owner
Teilnehmer:Team
(aktiv), ScrumMaster
(passiv),
Management (aktiv),
Kunde (aktiv), Users
(aktiv)
Dauer: 4 Stunden für
einen 4 wochiger
Sprint
Ist das Inspect-und-Adapt
vom Kunde, Users und
Management
DasTeam stellt die Ergebnisse
des Sprint vor.
Users/Kunde/ Management
bringen ihre Kommentare und
finden einen Kompromiss mit
demTeam
Der Product Owner bestätigt
oder verwirft die Sprint
Backlog Items gemäß der
Definition of Done
Der Product Owner hat hier
immer das letzteWort.
32Scrum by coPROcess
33. Moderator:
ScrumMaster
Teilnehmer:Team
(aktiv), ScrumMaster
(aktiv), Product
Owner (aktiv als
ScrumTeam
Mietglied)
Dauer: 3 Stunden für
einen 4Wochen
Sprint
Scrum Prozess
Analyze:
Wie war es während
den Sprint?
Wie kann man uns
verbessern?
Überprüfungs
Schwerpunkte :
Kommunication im
Team
Die Beziehungen
zwischen den
Teammitgliedern
Prozesse undTools
Schulungsbedarf
34Scrum by coPROcess
40. Fürs
TEAM Code entspricht die Norm
Code ist
sauber
Re-factored
Unit tested
checked in
built
Hat eine Reihe von angewendete Unit-tests.
Um dies zu erreichen, besteht die Entwicklungsumgebung
von:
Eine Source-Code Library
Codes Standards
Automatisches Build
Eine Unit-tests Umgebung
41Scrum by coPROcess
41. Pour
SCRUM
Eine Story/Item ist “done” wenn das
Team sein Level-of-Done erreicht hat
Sprint/Iteration ist “done” wenn
Alle items“done” sind
Wenn der Sprint sein Ziel erreicht hat
Und wenn Acceptance Kriterien erreicht
sind.
Release ist “done”
“done” für Integration
“done” für Produktion
42Scrum by coPROcess
Die Regeln:
Kein Handy
Die 2 Füsse Regel: Sie langweilen sich, es nimmt nicht die von Ihnen erwartete Richtung, ... Fühlt euch frei zu gehen.
Aufkommende Fragen:Fragen stellen sich wenn sie aufkommen. Wichtig ist die Interaktion.
Der Parkplatz : einige Frage bekommen deren Antwort in den kommende Folien oder die Frage liegt etwas außerhalb des Geltungsbereichs. In diesem Fall sind sie auf einem Parkplatz positioniert und ich werde die Antwort am Ende der Präsentation bringen.
Gewährleistet dass das Team den Werten, Prinzipien und Praktiken von Scrum folgt.
Hilft dem Team und Organisation bei der Annahme von Scrum.
Coacht und unterstützt das Team zur Verbesserung der Produktivität und der Qualität.
Schützt das Team.
Beseitigt Hindernisse.
Verantwortlich für das reibungslose Funktionieren des Projekts.
Es gibt nur ein ScrumMaster pro Team.
Der ScrumMaster arbeitet mit dem Team (idealweise im selben Raum)
Ist allein verantwortlich für die Verwaltung des Product Backlog.
Sorgt für das Team erstellte Wert: akzeptiert oder verwirft die Items gemäss der “Definition of Done”.
Unterhält das Product Backlog und gewerleistet dass von alle sichtbar ist.
Es gibt nur einen Product Owner pro Team
Der Product Owner arbeitet mit dem Team (idealweise im selben Raum)
Push vs Pull
Pull:
Le cahier des charges est prédéfini par la MOA.
La MOA définit la feuille de route.
Elle pousse (“push”) le cahier des charges vers l’équipe projet.
Objectif: exécution du cahier des charges conformément à un cadre fixe et figé.
Pull:
Le cahier des charges est estimé par la MOA.
La MOA définit la feuille de route prévisionnelle.
Elle présente le cahier des charges vers l’équipe projet.
L’équipe projet tire (“pull”) les éléments du cahier des charges qu’elle peut développer.
Objectif: co-production en fonction de la capacité réélle de production. Co-production orinetée résultat.
Dieses Exempel is als Basis an zu nehmen.
Es gibt mehrere Varianten.
zB.
Vor Sprint Planning 1 kann man ein Estimation Meeting machen mit Team, Product Owner, Users und Kunde wo man den Product Backlog schätzt.
-Danach Sprint Planning 1: wo das “WAS” definiert wird und die Sprint Backlog abgestimmt werden.
- Sprint Planning 2: wir vom Team durchgeführt + design
Daily Scrum ist idealweiser ein Stand-up meeting vor dem Scrum Board.
Product Backlog Building: answer these questions:
What? When? For Who?
Product Backlog Management
Clean the Backlog bottom from unused features (they can be added later if necessary)
Ever keep in mind: is that really necessary?
For Backlog Meeting: transcribe it on cards and stick up