scrum - von traditionellen ansaetzen zu agilen methoden wie scrum
DESCRIPTION
a presentation about scrum. We start looking at the roots of software-engineering and discuss the problems with traditional models like the waterfall-model and show the development of agile methods like scrumTRANSCRIPT
ScrumJanne Berngruber, Ralf Ohlenbostel, Stephan Wirries
1
Agenda
• Probleme beim Software-Development
• Paradigmenwechsel hin zur Agilität
• SCRUM
• Geschichte
• Rollen
• Prozesse
2
Probleme bei der Software Entwicklung
3
Traditionelles Engineering
• Phasenweise Entwicklung
• Erwartete Ziele
• Im Voraus stark geplant
4
frühes festlegen der Anforderungen Unflexibilität bei Änderungen
technische Hürden werden zu spät erkannt hoher Zeit / Kostenfaktor
„Big Bang Test“ geringer Einfluß des Kunden
Traditionelles Engineering
5
Engineering
• definierte Prozesse• intensive Dokumentation• Konformität
6
Software Engineering
Peter Naur 1968 NATO Konferenz:
„The phrase software engineering was chosen...implying the need for software manufacture to be based of foundations, that are traditional in the established branches of engineering„
7
Paradigmenwechsel
8
Befehls-und Kontrollorganisationen
Organisation durch Abteilungen und
Geschäftsbereiche
informationsbasierende Organisationen
Zeit
C3 Projekt
Chrysler Comprehensive Compensation
9
C3 Projekt
1993 1995
Entwicklung des C3 Projektes beginnt
1996
C3 Live
1997
Martin Fowler berät Chrysler
Kent Beck rebootet das
Projekt mit XP
10
„Das Chaos Manifesto ist die Summe von 15 Jahren Arbeit über Projektfehlschläge auf 48 Seiten“
Standish Group
11
Untersuchte Projekte
erfolgreich29%
Fehlschläge18%
starke Projektänderungen53%
starke Projektänderungen Fehlschläge erfolgreich
Standish Report 2004
12
0
4
8
12
16
Erfolgsfaktoren bei IT-Projekten
810
131416
Standish Group - Umfrage
13
Einbeziehen der User Unterstützung durch das Management Klare AnforderungenRichtige Planung Realistische Erwartungen
4%
9%
10%30%
21-50%32%16%
Kostenüberschreitung IT-Projekte
14
Unter 20% 21-50% 51-100% 101-200%201-400% über 400%
1%11%
101-200%36%
20%
18%
14%
Zeitüberschreitung IT-Projekte
Unter 20% 21-50% 51-100% 101-200%201-400% über 400%
15
Zusammengefasst
• nur 35 % der Projekte sind erfolgreich• starke Kosten und Zeitüberschreitungen • Erfolgsfaktoren essentiell: •realistische Ziele•klare Anforderungen•Einbeziehen der User
16
Agiles Manifest2001
17
Fowler Cockburn Beck Schwaber Sutherland
Individuen &Interaktion
funktionierende Software
Zusammenarbeit mit Kunden
Reagieren auf Änderungen
Prozesse und Werkzeuge
ausführliche Dokumentation
Verhandlungen von Verträgen
Plan befolgen
Agiles Manifest
18
Agile Prinzipien
iteratives entwickeln
19
Agile Prinzipien
Listen abarbeiten
stetig liefern
Klasse XY erstellen
Feature Z bauen
Methode AZ erstellen
20
Agile Prinzipien
Nur ein Feature zur Zeit entwickeln
21
Agile Prinzipien
Den Kunden befriedigen
22
Agile Prinzipien
Abteilungsübergreifendeselbstorganisierende Teams
23
Agile Prinzipien
Face-to-Face Kommunikation
24
Agile Prinzipien
Menschen motivieren
25
Agile Prinzipien
Laufende Software als Primäreinheit für den Erfolg
26
SCRUM
27
Scrum
Herkunft: Rugby
Neustart nach einem Foul
Bedeutung: Gedränge
28
Geschichte von Scrum
1990-93 1995
Agile Manifest
Gründung „Agile Alliance“
Scrum Buch
2001
Jeff Sutherland setzt „Scrum“
erstmals bei GPA ein
„Scrum akzeptiert, dass der Entwicklungsprozess unvorhersehbar ist...“
OOPSLA 95
Konferenzbeitrag über Scrum von Ken Schwaber
29
Erstes offizielles Scrumprojekt
Easel Corp.
1993-94
Wo man Scrum einsetzen kann
Neue & Festgefahrene Projekte
30
Ziele
Komplexität, Unverhergesehenes beherrschbar machen
Flexible Änderungen durch stetige Reflektion
31
Wettbewerbsvorteil durch Flexibilität
Scrum Grundwerte
32
CommitmentFocus
OpennessRespectCourage
Scrum Rollen
33
Product OwnerScrumTeam
Scrum Master
Organisation (Kunde)34
Organisation(Kunde)
Wir haben tolle Ideen!und mehr nicht...
Wir wollen Software die funktioniert!
Wir wollen in 3 Monate ein Redesign!
35
Wir haben tolle Ideen!und mehr nicht...
Wir wollen Software die funktioniert!
Wir wollen in 3 Monate ein Redesign!
VISION
Product Owner
36
VISION
Product Owner
37
ScrumTeam
Vision entwickelnFestlegen der Produkteigenschaften
Team motivierenPriorisierung der Backlogitems
Releaseplan bestimmenROI sichern
Verantwortung für das Projekt
Product Owner
38
Das Team
Lieferant des ProduktsBereichsübergreifend (Entwickler, Designer..)
Definiert AufgabenManaged sich selbst
Steuert die ArbeitsmengeIst verantwortlich für die Qualität
39
Scrum Master
Unterstützende FührungBehebt Probleme
40
Der Scrum Prozess
41
Product Backlog
picture by juhansonin
42
Product Backlog
43
Product Owner priorisiert
Keine Anforderungen
Nicht vollständig, nicht perfekt
Im Laufe des Prozesses weiterentwickelt
Product Backlog
picture by juhansonin
44
priority item # description estimated by
very highvery highvery highvery highvery high
1 Datenbankverbindung erstellen 2 SW
2 Wildcards bei der Suche unterstützen 4 RO
3 Jquery einbauen 1 JB
4 Html5 Geolocator einbauen 3 SW
highhighhighhighhigh
5 Grafiken optimieren 1 RO
6 User Registrationssystem erstellen 4 JB
Product Backlog
45
priority item # description estimated by
very high
1 Datenbankverbindung erstellen 2 SW
2 Wildcards bei der Suche unterstützen 4 RO
3 Jquery einbauen 1 JB
4 Html5 Geolocator einbauen 3 SW
high
5 Grafiken optimieren 1 RO
6 User Registrationssystem erstellen 4 JB
Product Backlog
Priorisierung nach Wertigkeit und Risiko
Schätzwerte
Öffentlich einsehbar
Userstories
46
User Stories
47
(Als <user> möchte ich <Funktionalität>, so dass <Nutzen>)
Als Mitglied möchte ich mein Profil einstellen, so dass andere Mitglieder mich finden können.
Time-BoxingKleine Entwicklungszyklen
Zeitlich gleich bleibend
Nur die wichtigsten Informationen
Keine Anpassung der Zyklen (zeitlich)
48
Sprints
Timeboxed – Festgelegte FeaturesVariabler Umfang – Liefert Ergebnis 49
Sprint Planning
50
Welche Backlog Items?Team entscheidetSprint Goal = fertiger Teil der Software
51
Sprint Planning Meeting 1
Product Owner stellt Vision vorSprint Goal
Sprint Backlog Items bestimmenErgebnis präsentieren
52
Sprint Planning Meeting 2
TeamsitzungDetailierte Planbesprechung
Sprint BacklogAbstimmungsbedarf?
Sprint Backlog
53
Requirement Task Who Status Work leftWork leftWork leftWork left
Day 1 Day 2 Day 3 Day 4
Member Sign In
Database Coding JB Done 1 0 0
Member Sign In
Unit Testing JB Done 2 0 0
Member Sign In Business Logic JB Done 2 2 0Member Sign In
Front End Screens RO Done 2 2 0
Member Sign In
Ui Testscripts SW Done 2 2 1
Reset Password
Unit Testing SW Done 1 1 0
Reset PasswordBusiness Logic RO Done 2 0 0
Reset PasswordUi Testscripts RO Done 2 2 1
Reset Password
Front End Screens JB Pending 1 1 1
Work remainingWork remainingWork remainingWork remaining 15 10 3
Sprint Backlog
54
55
Daily Scrum
Täglich
Selber Ort
Gleiche Zeit
56
Daily ScrumWas habe ich seit dem letzten Daily Scrum gemacht?
Was will ich bis zum nächsten daily Scrum machen?
Welche Hindernisse sind mir dabei im Weg?
Task Board
57
Sprint Burn Down
0
5
10
15
20
1.10.09 2.10.09 3.10.09 4.10.09 5.10.09 6.10.09 07.10.09 08.10.09
Points Expected Points Left
Chart für Sprint 1
58
59
Sprint Review
Sprint Goal erreicht?
FeedbackKommunikation
60
Sprint Review
Neue Funktionalitäten
Nicht geschaffte Backlog Items neu einordnen
Veränderung der Priorisierung
61
Sprint Retrospective
Was lief gut?Was lief schlecht?Was soll übernommen werden?
62
Sprint Retrospective
-50
-25
0
25
50
75
100
1.10.09 8.10.09 16.10.09 24.10.09 30.10.09 5.11.09 11.11.09 19.11.09
Features remaining Scope Target
Burn Down Chart
Aufgabenbereichs-wechsel
63
Release PlanungPlanung von Features in Sprints und Releases
Releases hängen von den akzeptierten Sprints ab
picture by Sviluppo Agile 64
Release Sprints
• Usability testing
• Dokumentation
• Hilfe Dateien
• Packaging
65
Sprint Termination
• Nur in Ausnahmefällen
• Team Abbruch: Kann Sprint Ziele nicht erreichen
• Product Owner Abbruch: Prioritätenwandel
• Arbeit fällt zum Ende des vorherigen Sprints zurück
• Erhöht die Sichtbarkeit von Problemen
66
Sprints
•Durch den Product Owner angetrieben
•Kleine rückführbare Schritte
•Change Kultur
•Funktionsübergreifende Teams
•Beinhalten Design und Testing
•Beibehalten einer konstanten Geschwindigkeit
•Gemeinsame Hingabe
•Hohe Qualität
•Feedback bekommen
•Schnelles Scheitern
67
Resultseffects of applying scrum
68
Risiken managen
Rolling wave Planung
Simple mini Projekte senken Risiken
69
Flexible Aufgabenstellung
Erlaubt Änderungen in fixen Intervallen
Releases ermöglichen lernen
70
Schnellere Lieferung
kürzere “time to market”
Der Wert wird inkrementell geliefert
71
Höhere Qualität
Kontinuierliches Testen
Eingebaute Prozessverbesserung
72
Entfernen von Überflüssigem
Es wird nichts designed das nicht gebaut wird
Es wird nichts gebaut das nicht genutzt wird
73
Erhöhte Sichtbarkeit
Alle Probleme sind sichtbar
Fortschritt ist die laufende, getestete Software
74
Mehr Spaß, Glückliche Teams
75
Vorbedingungen
76
Vorbedingungen
Empowerment
Disziplin
Courage
Ausdauer
Passion
Coaching
Stabile Teams
Funktionsübergreifend
Verfügbare Kunden
77
Bücher
78
Webseiten
www.scrumalliance.org
www.controlchaos.com
www.mountaingoatsoftware.com
www.jeffsutherland.com
www.implementingscrum.com
www.agilesoftwaredevelopment.com
www.noop.nl
79