Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum

4,298 views
4,046 views

Published on

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

Published in: Technology

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

×