Scrum
Janne Berngruber, Ralf Ohlenbostel, Stephan Wirries
                         1
Agenda
• Probleme beim Software-Development
• Paradigmenwechsel hin zur Agilität
• SCRUM
 • Geschichte
 • Rollen
 • Prozes...
Probleme
bei der Software Entwicklung




             3
Traditionelles Engineering

• Phasenweise Entwicklung
• Erwartete Ziele
• Im Voraus stark geplant




                    ...
Traditionelles Engineering


   frühes festlegen der Anforderungen          Unflexibilität bei Änderungen




technische Hü...
Engineering

• definierte Prozesse
• intensive Dokumentation
• Konformität




                      6
Software Engineering

      Peter Naur 1968 NATO
      Konferenz:
      „The phrase software engineering was chosen...
   ...
Paradigmenwechsel


                         Organisation durch
     Befehls-und                              informations...
C3 Projekt

Chrysler Comprehensive Compensation




                 9
C3 Projekt
Martin Fowler                                Kent Beck
berät Chrysler                              rebootet das...
Standish Group

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



...
Untersuchte Projekte


           erfolgreich
              29%


                                starke Projektänderungen...
Standish Group - Umfrage
16



12



 8           16
                            14              13
                      ...
Kostenüberschreitung IT-Projekte

                                     21-50%
                  16%
                      ...
Zeitüberschreitung IT-Projekte

                  20%
                                          101-200%
                 ...
Zusammengefasst

• nur 35 % der Projekte sind erfolgreich
• starke Kosten und Zeitüberschreitungen
• Erfolgsfaktoren essen...
Agiles Manifest
              2001




Fowler   Cockburn   Beck   Schwaber Sutherland

                    17
Agiles Manifest

       Individuen &
                                     Prozesse und Werkzeuge
        Interaktion




 ...
Agile Prinzipien


       iteratives entwickeln




       19
Agile Prinzipien

Klasse XY erstellen
                       Listen abarbeiten
Feature Z bauen

                          ...
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 offizielles     OOPSLA 95
 setzt „Scrum“      Scrumprojekt
erstmals bei GPA ...
Wo man Scrum einsetzen kann


     Neue & Festgefahrene Projekte




                  30
Ziele
Komplexität, Unverhergesehenes
    beherrschbar machen

Flexible Änderungen durch stetige
            Reflektion
   W...
Scrum Grundwerte

   Commitment
      Focus
    Openness
     Respect
    Courage



        32
Scrum Rollen



     33
ScrumTeam
Product Owner
                                       Scrum Master




                Organisation (Kunde)
     ...
Wir haben tolle Ideen!
                 und mehr nicht...




                    Wir wollen Software die
                ...
Wir wollen in 3 Monate
    ein Redesign!




                          Product Owner
Wir haben tolle Ideen!
              ...
VISION




Product Owner        ScrumTeam




                37
Product Owner

         Vision entwickeln
Festlegen der Produkteigenschaften
          Team motivieren
  Priorisierung der...
Das Team

           Lieferant des Produkts
Bereichsübergreifend (Entwickler, Designer..)
             Definiert Aufgaben
 ...
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 Lauf...
Product Backlog




                  44

                       picture by juhansonin
Product Backlog

 priority   item #               description                estimated   by

very high

              1   ...
Product Backlog

 priority   item #                 description                    estimated   by

very high

            ...
User Stories
(Als <user> möchte ich <Funktionalität>,
  so dass <Nutzen>)


Als Mitglied möchte ich mein Profil einstellen,...
Time-Boxing
     Kleine Entwicklungszyklen
       Zeitlich gleich bleibend
 Nur die wichtigsten Informationen
Keine Anpass...
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...
Sprint Planning Meeting 2
Teamsitzung
Detailierte Planbesprechung
Sprint Backlog
Abstimmungsbedarf?




                  ...
Sprint Backlog




      53
Sprint Backlog
Requirement            Task           Who Status                          Work left

                      ...
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 Hi...
Task Board




    57
Sprint Burn Down
                     Chart für Sprint 1

                     Points Expected          Points Left

20


...
Sprint Review

Sprint Goal erreicht?
Feedback
Kommunikation




                        59
Sprint Review

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




    ...
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
                    ...
Release Planung
                             Planung von Features in Sprints und Releases

                            Rel...
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: Pr...
Sprints

•Durch den Product Owner angetrieben
•Kleine rückführbare Schritte
•Change Kultur
•Funktionsübergreifende Teams
•...
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 Überflüssigem

Es wird nichts designed das nicht gebaut wird

Es wird nichts gebaut das nicht genutzt wird


...
Erhöhte Sichtbarkeit

Alle Probleme sind sichtbar

Fortschritt ist die laufende, getestete Software




                  ...
Mehr Spaß, Glückliche Teams




            75
Vorbedingungen




      76
Vorbedingungen

    Empowerment
        Disziplin
        Courage
       Ausdauer
        Passion
       Coaching
     Sta...
Bücher




         78
Webseiten

www.scrumalliance.org
www.controlchaos.com
www.mountaingoatsoftware.com
www.jeffsutherland.com
www.implementing...
Nächste SlideShare
Wird geladen in …5
×

Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum

4.386 Aufrufe

Veröffentlicht am

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 scrum

Veröffentlicht in: Technologie
0 Kommentare
7 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
4.386
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
207
Aktionen
Geteilt
0
Downloads
166
Kommentare
0
Gefällt mir
7
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum

  1. 1. Scrum Janne Berngruber, Ralf Ohlenbostel, Stephan Wirries 1
  2. 2. Agenda • Probleme beim Software-Development • Paradigmenwechsel hin zur Agilität • SCRUM • Geschichte • Rollen • Prozesse 2
  3. 3. Probleme bei der Software Entwicklung 3
  4. 4. Traditionelles Engineering • Phasenweise Entwicklung • Erwartete Ziele • Im Voraus stark geplant 4
  5. 5. Traditionelles Engineering 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 5
  6. 6. Engineering • definierte Prozesse • intensive Dokumentation • Konformität 6
  7. 7. 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
  8. 8. Paradigmenwechsel Organisation durch Befehls-und informationsbasierende Abteilungen und Kontrollorganisationen Organisationen Geschäftsbereiche Zeit 8
  9. 9. C3 Projekt Chrysler Comprehensive Compensation 9
  10. 10. 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
  11. 11. Standish Group „Das Chaos Manifesto ist die Summe von 15 Jahren Arbeit über Projektfehlschläge auf 48 Seiten“ 11
  12. 12. Untersuchte Projekte erfolgreich 29% starke Projektänderungen 53% Fehlschläge 18% Standish Report 2004 starke Projektänderungen Fehlschläge erfolgreich 12
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. Zusammengefasst • nur 35 % der Projekte sind erfolgreich • starke Kosten und Zeitüberschreitungen • Erfolgsfaktoren essentiell: •realistische Ziele •klare Anforderungen •Einbeziehen der User 16
  17. 17. Agiles Manifest 2001 Fowler Cockburn Beck Schwaber Sutherland 17
  18. 18. 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
  19. 19. Agile Prinzipien iteratives entwickeln 19
  20. 20. Agile Prinzipien Klasse XY erstellen Listen abarbeiten Feature Z bauen stetig liefern Methode AZ erstellen 20
  21. 21. Agile Prinzipien Nur ein Feature zur Zeit entwickeln 21
  22. 22. Agile Prinzipien Den Kunden befriedigen 22
  23. 23. Agile Prinzipien Abteilungsübergreifende selbstorganisierende Teams 23
  24. 24. Agile Prinzipien Face-to-Face Kommunikation 24
  25. 25. Agile Prinzipien Menschen motivieren 25
  26. 26. Agile Prinzipien Laufende Software als Primäreinheit für den Erfolg 26
  27. 27. SCRUM 27
  28. 28. Scrum Herkunft: Rugby Neustart nach einem Foul Bedeutung: Gedränge 28
  29. 29. Geschichte von Scrum Jeff Sutherland Erstes offizielles 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
  30. 30. Wo man Scrum einsetzen kann Neue & Festgefahrene Projekte 30
  31. 31. Ziele Komplexität, Unverhergesehenes beherrschbar machen Flexible Änderungen durch stetige Reflektion Wettbewerbsvorteil durch Flexibilität 31
  32. 32. Scrum Grundwerte Commitment Focus Openness Respect Courage 32
  33. 33. Scrum Rollen 33
  34. 34. ScrumTeam Product Owner Scrum Master Organisation (Kunde) 34
  35. 35. Wir haben tolle Ideen! und mehr nicht... Wir wollen Software die funktioniert! Organisation (Kunde) Wir wollen in 3 Monate ein Redesign! 35
  36. 36. Wir wollen in 3 Monate ein Redesign! Product Owner Wir haben tolle Ideen! VISION und mehr nicht... Wir wollen Software die funktioniert! 36
  37. 37. VISION Product Owner ScrumTeam 37
  38. 38. Product Owner Vision entwickeln Festlegen der Produkteigenschaften Team motivieren Priorisierung der Backlogitems Releaseplan bestimmen ROI sichern Verantwortung für das Projekt 38
  39. 39. Das Team Lieferant des Produkts Bereichsübergreifend (Entwickler, Designer..) Definiert Aufgaben Managed sich selbst Steuert die Arbeitsmenge Ist verantwortlich für die Qualität 39
  40. 40. Scrum Master Unterstützende Führung Behebt Probleme 40
  41. 41. Der Scrum Prozess 41
  42. 42. Product Backlog 42 picture by juhansonin
  43. 43. Product Backlog Product Owner priorisiert Keine Anforderungen Nicht vollständig, nicht perfekt Im Laufe des Prozesses weiterentwickelt 43
  44. 44. Product Backlog 44 picture by juhansonin
  45. 45. 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 Grafiken optimieren 1 RO 6 User Registrationssystem erstellen 4 JB 45
  46. 46. 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 Grafiken optimieren 1 RO Öffentlich einsehbar 6 User Registrationssystem erstellen 4 JB 46
  47. 47. User Stories (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. 47
  48. 48. Time-Boxing Kleine Entwicklungszyklen Zeitlich gleich bleibend Nur die wichtigsten Informationen Keine Anpassung der Zyklen (zeitlich) 48
  49. 49. Sprints Timeboxed – Festgelegte Features Variabler Umfang – Liefert Ergebnis 49
  50. 50. Sprint Planning Welche Backlog Items? Team entscheidet Sprint Goal = fertiger Teil der Software 50
  51. 51. Sprint Planning Meeting 1 Product Owner stellt Vision vor Sprint Goal Sprint Backlog Items bestimmen Ergebnis präsentieren 51
  52. 52. Sprint Planning Meeting 2 Teamsitzung Detailierte Planbesprechung Sprint Backlog Abstimmungsbedarf? 52
  53. 53. Sprint Backlog 53
  54. 54. 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
  55. 55. Daily Scrum Täglich Selber Ort Gleiche Zeit 55
  56. 56. 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
  57. 57. Task Board 57
  58. 58. 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
  59. 59. Sprint Review Sprint Goal erreicht? Feedback Kommunikation 59
  60. 60. Sprint Review Neue Funktionalitäten Nicht geschaffte Backlog Items neu einordnen Veränderung der Priorisierung 60
  61. 61. Sprint Retrospective Was lief gut? Was lief schlecht? Was soll übernommen werden? 61
  62. 62. Sprint Retrospective 62
  63. 63. 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
  64. 64. Release Planung Planung von Features in Sprints und Releases Releases hängen von den akzeptierten Sprints ab picture by Sviluppo Agile 64
  65. 65. Release Sprints • Usability testing • Dokumentation • Hilfe Dateien • Packaging 65
  66. 66. 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
  67. 67. 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
  68. 68. Results effects of applying scrum 68
  69. 69. Risiken managen Rolling wave Planung Simple mini Projekte senken Risiken 69
  70. 70. Flexible Aufgabenstellung Erlaubt Änderungen in fixen Intervallen Releases ermöglichen lernen 70
  71. 71. Schnellere Lieferung kürzere “time to market” Der Wert wird inkrementell geliefert 71
  72. 72. Höhere Qualität Kontinuierliches Testen Eingebaute Prozessverbesserung 72
  73. 73. Entfernen von Überflüssigem Es wird nichts designed das nicht gebaut wird Es wird nichts gebaut das nicht genutzt wird 73
  74. 74. Erhöhte Sichtbarkeit Alle Probleme sind sichtbar Fortschritt ist die laufende, getestete Software 74
  75. 75. Mehr Spaß, Glückliche Teams 75
  76. 76. Vorbedingungen 76
  77. 77. Vorbedingungen Empowerment Disziplin Courage Ausdauer Passion Coaching Stabile Teams Funktionsübergreifend Verfügbare Kunden 77
  78. 78. Bücher 78
  79. 79. Webseiten www.scrumalliance.org www.controlchaos.com www.mountaingoatsoftware.com www.jeffsutherland.com www.implementingscrum.com www.agilesoftwaredevelopment.com www.noop.nl 79

×