scrum - von traditionellen ansaetzen zu agilen methoden wie scrum

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