Als PDF, PPTX herunterladen
Hochgeladen vonRalf Ohlenbostel
Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum
Das Dokument behandelt die Herausforderungen im Software-Engineering und den Paradigmenwechsel hin zu agilen Methoden, insbesondere Scrum. Es werden verschiedene Probleme traditioneller Ansätze, die hohe Fehlerraten und Zeit- sowie Kostenüberschreitungen aufweisen, sowie die Prinzipien und Rollen von Scrum erläutert. Es wird betont, dass nur 35% der Projekte erfolgreich sind und dass eine flexible, teamorientierte Herangehensweise zu besseren Ergebnissen führt.
Weitere ähnliche Inhalte
Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum
- 1. Scrum Janne Berngruber, RalfOhlenbostel, Stephan Wirries 1
- 2. Agenda • Probleme beimSoftware-Development • Paradigmenwechsel hin zur Agilität • SCRUM • Geschichte • Rollen • Prozesse 2
- 3. Probleme bei der SoftwareEntwicklung 3
- 4. Traditionelles Engineering • PhasenweiseEntwicklung • Erwartete Ziele • Im Voraus stark geplant 4
- 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. Engineering • definierte Prozesse •intensive Dokumentation • Konformität 6
- 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. Paradigmenwechsel Organisation durch Befehls-und informationsbasierende Abteilungen und Kontrollorganisationen Organisationen Geschäftsbereiche Zeit 8
- 9. C3 Projekt Chrysler ComprehensiveCompensation 9
- 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. Standish Group „Das ChaosManifesto ist die Summe von 15 Jahren Arbeit über Projektfehlschläge auf 48 Seiten“ 11
- 12. Untersuchte Projekte erfolgreich 29% starke Projektänderungen 53% Fehlschläge 18% Standish Report 2004 starke Projektänderungen Fehlschläge erfolgreich 12
- 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. 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. 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. Zusammengefasst • nur 35% der Projekte sind erfolgreich • starke Kosten und Zeitüberschreitungen • Erfolgsfaktoren essentiell: •realistische Ziele •klare Anforderungen •Einbeziehen der User 16
- 17. Agiles Manifest 2001 Fowler Cockburn Beck Schwaber Sutherland 17
- 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. Agile Prinzipien iteratives entwickeln 19
- 20. Agile Prinzipien Klasse XYerstellen Listen abarbeiten Feature Z bauen stetig liefern Methode AZ erstellen 20
- 21. Agile Prinzipien Nur ein Feature zur Zeit entwickeln 21
- 22. Agile Prinzipien Den Kunden befriedigen 22
- 23. Agile Prinzipien Abteilungsübergreifende selbstorganisierende Teams 23
- 24. Agile Prinzipien Face-to-Face Kommunikation 24
- 25. Agile Prinzipien Menschen motivieren 25
- 26. Agile Prinzipien Laufende Software als Primäreinheit für den Erfolg 26
- 27.
- 28. Scrum Herkunft: Rugby Neustart nacheinem Foul Bedeutung: Gedränge 28
- 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. Wo man Scrumeinsetzen kann Neue & Festgefahrene Projekte 30
- 31. Ziele Komplexität, Unverhergesehenes beherrschbar machen Flexible Änderungen durch stetige Reflektion Wettbewerbsvorteil durch Flexibilität 31
- 32. Scrum Grundwerte Commitment Focus Openness Respect Courage 32
- 33. Scrum Rollen 33
- 34. ScrumTeam Product Owner Scrum Master Organisation (Kunde) 34
- 35. Wir haben tolleIdeen! und mehr nicht... Wir wollen Software die funktioniert! Organisation (Kunde) Wir wollen in 3 Monate ein Redesign! 35
- 36. Wir wollen in3 Monate ein Redesign! Product Owner Wir haben tolle Ideen! VISION und mehr nicht... Wir wollen Software die funktioniert! 36
- 37. VISION Product Owner ScrumTeam 37
- 38. Product Owner Vision entwickeln Festlegen der Produkteigenschaften Team motivieren Priorisierung der Backlogitems Releaseplan bestimmen ROI sichern Verantwortung für das Projekt 38
- 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. Scrum Master Unterstützende Führung BehebtProbleme 40
- 41.
- 42. Product Backlog 42 picture by juhansonin
- 43. Product Backlog Product Owner priorisiert Keine Anforderungen Nicht vollständig, nicht perfekt Im Laufe des Prozesses weiterentwickelt 43
- 44. Product Backlog 44 picture by juhansonin
- 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. 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. 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. Time-Boxing Kleine Entwicklungszyklen Zeitlich gleich bleibend Nur die wichtigsten Informationen Keine Anpassung der Zyklen (zeitlich) 48
- 49. Sprints Timeboxed – FestgelegteFeatures Variabler Umfang – Liefert Ergebnis 49
- 50. Sprint Planning Welche BacklogItems? Team entscheidet Sprint Goal = fertiger Teil der Software 50
- 51. Sprint Planning Meeting1 Product Owner stellt Vision vor Sprint Goal Sprint Backlog Items bestimmen Ergebnis präsentieren 51
- 52. Sprint Planning Meeting2 Teamsitzung Detailierte Planbesprechung Sprint Backlog Abstimmungsbedarf? 52
- 53.
- 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.
- 56. Daily Scrum Was habeich 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. Task Board 57
- 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. Sprint Review Sprint Goalerreicht? Feedback Kommunikation 59
- 60. Sprint Review Neue Funktionalitäten Nichtgeschaffte Backlog Items neu einordnen Veränderung der Priorisierung 60
- 61. Sprint Retrospective Was liefgut? Was lief schlecht? Was soll übernommen werden? 61
- 62.
- 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. Release Planung Planung von Features in Sprints und Releases Releases hängen von den akzeptierten Sprints ab picture by Sviluppo Agile 64
- 65. Release Sprints • Usabilitytesting • Dokumentation • Hilfe Dateien • Packaging 65
- 66. Sprint Termination • Nurin 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. Sprints •Durch den ProductOwner 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. Results effects of applyingscrum 68
- 69. Risiken managen Rolling wavePlanung Simple mini Projekte senken Risiken 69
- 70. Flexible Aufgabenstellung Erlaubt Änderungenin fixen Intervallen Releases ermöglichen lernen 70
- 71. Schnellere Lieferung kürzere “timeto market” Der Wert wird inkrementell geliefert 71
- 72. Höhere Qualität Kontinuierliches Testen EingebauteProzessverbesserung 72
- 73. Entfernen von Überflüssigem Eswird nichts designed das nicht gebaut wird Es wird nichts gebaut das nicht genutzt wird 73
- 74. Erhöhte Sichtbarkeit Alle Problemesind sichtbar Fortschritt ist die laufende, getestete Software 74
- 75. Mehr Spaß, GlücklicheTeams 75
- 76.
- 77. Vorbedingungen Empowerment Disziplin Courage Ausdauer Passion Coaching Stabile Teams Funktionsübergreifend Verfügbare Kunden 77
- 78. Bücher 78
- 79.