Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum

Scrum Janne 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

Traditionelles Engineering frühes festlegen der Anforderungen Unﬂexibilität bei Änderungen technische Hürden werden zu spät erkannt hoher Zeit / Kostenfaktor „Big Bang Test“ geringer Einﬂuß des Kunden 5

Engineering • deﬁnierte 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 Organisation durch Befehls-und informationsbasierende Abteilungen und Kontrollorganisationen Organisationen Geschäftsbereiche Zeit 8

C3 Projekt Chrysler Comprehensive Compensation 9

C3 Projekt Martin Fowler Kent Beck berät Chrysler rebootet das Projekt mit XP Entwicklung des C3 Projektes beginnt C3 Live 1993 1995 1996 1997 10

Standish Group „Das Chaos Manifesto ist die Summe von 15 Jahren Arbeit über Projektfehlschläge auf 48 Seiten“ 11

Untersuchte Projekte erfolgreich 29% starke Projektänderungen 53% Fehlschläge 18% Standish Report 2004 starke Projektänderungen Fehlschläge erfolgreich 12

Standish Group - Umfrage 16 12 8 16 14 13 10 4 8 0 Erfolgsfaktoren bei IT-Projekten Einbeziehen der User Unterstützung durch das Management Klare Anforderungen Richtige Planung Realistische Erwartungen 13

Kostenüberschreitung IT-Projekte 21-50% 16% 32% 4% 9% 10% 30% Unter 20% 21-50% 51-100% 101-200% 201-400% über 400% 14

Zeitüberschreitung IT-Projekte 20% 101-200% 36% 18% 11% 14% 1% 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 Manifest 2001 Fowler Cockburn Beck Schwaber Sutherland 17

Agiles Manifest Individuen & Prozesse und Werkzeuge Interaktion funktionierende Software ausführliche Dokumentation Zusammenarbeit mit Kunden Verhandlungen von Verträgen Reagieren auf Änderungen Plan befolgen 18

Agile Prinzipien iteratives entwickeln 19

Agile Prinzipien Klasse XY erstellen Listen abarbeiten Feature Z bauen stetig liefern Methode AZ erstellen 20

Agile Prinzipien Nur ein Feature zur Zeit entwickeln 21

Agile Prinzipien Den Kunden befriedigen 22

Agile Prinzipien Abteilungsübergreifende selbstorganisierende 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 Jeff Sutherland Erstes ofﬁzielles OOPSLA 95 setzt „Scrum“ Scrumprojekt erstmals bei GPA Konferenzbeitrag ein Easel Corp. über Scrum von Ken Schwaber Agile Manifest Gründung „Agile Alliance“ Scrum Buch 1990-93 1993-94 1995 2001 „Scrum akzeptiert, dass der Entwicklungsprozess unvorhersehbar ist...“ 29

Wo man Scrum einsetzen kann Neue & Festgefahrene Projekte 30

Ziele Komplexität, Unverhergesehenes beherrschbar machen Flexible Änderungen durch stetige Reﬂektion Wettbewerbsvorteil durch Flexibilität 31

Scrum Grundwerte Commitment Focus Openness Respect Courage 32

Scrum Rollen 33

ScrumTeam Product Owner Scrum Master Organisation (Kunde) 34

Wir haben tolle Ideen! und mehr nicht... Wir wollen Software die funktioniert! Organisation (Kunde) Wir wollen in 3 Monate ein Redesign! 35

Wir wollen in 3 Monate ein Redesign! Product Owner Wir haben tolle Ideen! VISION und mehr nicht... Wir wollen Software die funktioniert! 36

VISION Product Owner ScrumTeam 37

Product Owner Vision entwickeln Festlegen der Produkteigenschaften Team motivieren Priorisierung der Backlogitems Releaseplan bestimmen ROI sichern Verantwortung für das Projekt 38

Das Team Lieferant des Produkts Bereichsübergreifend (Entwickler, Designer..) Deﬁniert Aufgaben Managed sich selbst Steuert die Arbeitsmenge Ist verantwortlich für die Qualität 39

Scrum Master Unterstützende Führung Behebt Probleme 40

Der Scrum Prozess 41

Product Backlog 42 picture by juhansonin

Product Backlog Product Owner priorisiert Keine Anforderungen Nicht vollständig, nicht perfekt Im Laufe des Prozesses weiterentwickelt 43

Product Backlog 44 picture by juhansonin

Product Backlog 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 Graﬁken optimieren 1 RO 6 User Registrationssystem erstellen 4 JB 45

Product Backlog priority item # description estimated by very high 1 Datenbankverbindung erstellen 2 SW Priorisierung nach Wertigkeit und Risiko 2 Schätzwerte Wildcards bei der Suche unterstützen 4 RO 3 Jquery einbauen 1 JB 4 Html5 Geolocator einbauen 3 SW Userstories high 5 Graﬁken optimieren 1 RO Öffentlich einsehbar 6 User Registrationssystem erstellen 4 JB 46

User Stories (Als <user> möchte ich <Funktionalität>, so dass <Nutzen>) Als Mitglied möchte ich mein Proﬁl einstellen, so dass andere Mitglieder mich ﬁnden können. 47

Time-Boxing Kleine Entwicklungszyklen Zeitlich gleich bleibend Nur die wichtigsten Informationen Keine Anpassung der Zyklen (zeitlich) 48

Sprints Timeboxed – Festgelegte Features Variabler Umfang – Liefert Ergebnis 49

Sprint Planning Welche Backlog Items? Team entscheidet Sprint Goal = fertiger Teil der Software 50

Sprint Planning Meeting 1 Product Owner stellt Vision vor Sprint Goal Sprint Backlog Items bestimmen Ergebnis präsentieren 51

Sprint Planning Meeting 2 Teamsitzung Detailierte Planbesprechung Sprint Backlog Abstimmungsbedarf? 52

Sprint Backlog 53

Sprint Backlog Requirement Task Who Status Work left Day 1 Day 2 Day 3 Day 4 Database Coding JB Done 1 0 0 Unit Testing JB Done 2 0 0 Member Sign In Business Logic JB Done 2 2 0 Front End Screens RO Done 2 2 0 Ui Testscripts SW Done 2 2 1 Unit Testing SW Done 1 1 0 Business Logic RO Done 2 0 0 Reset Password Ui Testscripts RO Done 2 2 1 Front End Screens JB Pending 1 1 1 Work remaining 15 10 3 54

Daily Scrum Täglich Selber Ort Gleiche Zeit 55

Daily Scrum Was 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? 56

Task Board 57

Sprint Burn Down Chart für Sprint 1 Points Expected Points Left 20 15 10 5 0 1.10.09 2.10.09 3.10.09 4.10.09 5.10.09 6.10.09 07.10.09 08.10.09 58

Sprint Review Sprint Goal erreicht? Feedback Kommunikation 59

Sprint Review Neue Funktionalitäten Nicht geschaffte Backlog Items neu einordnen Veränderung der Priorisierung 60

Sprint Retrospective Was lief gut? Was lief schlecht? Was soll übernommen werden? 61

Sprint Retrospective 62

Burn Down Chart Features remaining Scope Target 100 75 50 Aufgabenbereichs- 25 wechsel 0 -25 -50 1.10.09 8.10.09 16.10.09 24.10.09 30.10.09 5.11.09 11.11.09 19.11.09 63

Release Planung Planung 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

Results effects 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 Überﬂü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

http://www.ohlenbostel.net	122
http://www.dunkelfels.de	46
http://www.slideshare.net	6

Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum

by capsnord on Nov 24, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 174

Statistics

Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum — Presentation Transcript