Das Dokument bietet eine umfassende Einführung in agile Softwareentwicklung mit Scrum, einschließlich der Prinzipien, Rollen, Artefakte und Zeremonien des Scrum-Prozesses. Es diskutiert die Vorteile der agilen Methodik im Vergleich zu traditionellen Modellen, betont die Bedeutung von Teaminteraktionen sowie kontinuierlicher Verbesserung und zeigt die Struktur und Organisation von Scrum-Teams auf. Abschließend werden Herausforderungen und Erkenntnisse aus einer dreijährigen praktischen Anwendung von Scrum bei Regis24 vorgestellt.

1. Agile Softwareenwticklung mit SCRUM

2. AGENDA

3. 1 2 3

4. Über Rollen, Artefakte und Zeremonien – Eine Einführung in die Begriffswelt von SCRUM 1 2 3

5. SCRUM ist mehr als Projektmanagement und Softwareentwicklung - Agile Prinzipien, Werte und der Faktor Mensch. 1 2 3

6. SCRUM im Feldversuch – 3 Jahre SCRUMologie bei Regis24. 1 2 3

7. Einführung in die Begriffswelt von Agile und SCRUM 1

8. Das Ziel agiler Softwareentwicklung ist es, schneller und effektiver Software zu entwickeln als in den klassischen, schwergewichtigen Entwicklungsmodellen. = 1 2 3

9. Im schwergewichtigen Wasserfallmodell wird die Gesamtprojektzeit in feste Phasen eingeteilt. Projektfortschritt Zeit 1 Monat 3 Monat 12 Monate 16 Monate Initialplanung Anforderungs- analyse Systemdesign Implementierung Release Nutzung 1 2 3

10. Agile Prozesse nähern sich dem Projektziel in kurzen, absehbaren und planbaren Iterationen und schaffen dadurch kontinuierlich Nutzen. ITERATION 1-5 Wochen Initialplanung Anforderungs- analyse Systemdesign Implementierung Test Planung aktualisieren Release Nutzung 1 2 3

11. SCRUM gibt eine Antwort auf viele typische Probleme der Softwareentwicklung. Zu lange Releasephasen Zu wenig Stabilität Änderungen nur schwer umsetzbar Unzureichende Qualität Demoralisierung durch Projektstopp Kurze Releasephasen Stabilität durch TDD und Refactoring Änderungen dankbar annehmen Hohe Qualität der Software Spaß und Freude bei der Arbeit 1 2 3

12. SCRUM ist ein agiler Prozess, der durch verschiedene agile Methoden gestützt werden sollte. Pair- Programming Test Driven Development (TDD) Ständiges Refactoring Code- und Architecture-Reviews Nightly Builds / Continous Integration Implementierungsaufgaben werden in Paaren gelöst

13. Eine Person schreibt Code, die Andere prüft, modelliert, hinterfragt

14. Vorteile: bessere Qualität, weniger Ablenkung, Wissenstransfer, Spaß

15. Nachteile: mehr direkter Zeitaufwand, ggf. negative Teamwirkung, Nicht nur Unit- und Integrationstests, auch Anforderungen, Usability etc.

16. 100% Abdeckung erforderlich

17. Tests als elementarer Bestandteil der Entwicklung

18. Absicherung von Code gegen Änderung, Klare Zielrichtung Code-Smells regelmäßig aufspüren und beseitigen

19. Alles wird in besserem Zustand verlassen als es vorgefunden wurde

20. Dringende Grundbedingung: 100% TDD, Collective Code Ownership

21. Vermeidung und Reduktion von Technical Dept als oberstes Ziel Regelmäßige geplante und ständige spontane Code Reviews

22. Unstimmigkeiten werden sofort beseitigt

23. Alle Ansätze werden untereinander gechallenged

24. Wissenstransfer und Förderung des kollektiven Geistes Jedes Teammitglied integriert seinen neuen Code täglich

25. Mit jeder Integration werden an einem Testserver sämtliche Unit-Tests sowie ein automatischer Build durchgeführt

26. Code Fragmente laufen so nicht auseinander, jederzeit Release möglich 1 2 3

27. SCRUM bringt ein sehr übersichtliches Set an Grundsätzen mit. Product Owner Scrum Master TEAM Sprint Planning Sprint Sprint Review Retrospektive Daily Scrum Product Backlog Sprint Backlog Sprint Burndown Chart Product Increment Impediment List Estimation Meeting Product Burndown Definition of Done Rollen Zeremonien Artefakte 1 2 3

28. SCRUM beschreibt 3 relevante Rollen im Entwicklungsprozess. Product Owner Team Scrum Master 1 2 3 definiert Produkt-Features

29. bestimmt Auslieferungsdatum und Inhalt

30. ist verantwortlich für den Gewinn des Projekts (ROI)

31. priorisiert Features abhängig vom Marktwert

32. passt Features und Prioritäten nach Bedarf für jede Iteration an

33. akzeptiert oder weist Arbeitsergebnisse zurück Typischerweise fünf bis zehn Leute

34. Mitglieder sollten Vollzeitmitglieder sein

35. Interdisziplinär

36. Teams organisieren sich selbst

37. Mitgliedschaft kann sich nur zwischen Sprints verändern Verantwortlich für die Einhaltung von Scrum-Werten und -Techniken

38. Entfernt Hindernisse

39. Stellt sicher, dass das Team vollständig funktional und produktiv ist

40. Unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen

41. Schützt das Team vor äußeren Störungen

42. Vermittelt der Organisation die Welt der agilen Werte

43. SCRUM lebt vor allem durch die Interaktionen zwischen den einzelnen Akteuren. Das Team Nebenrollen Scrum Master Product Owner Anwender Vertrieb Kunde Marketing Geschäftsleitung Rechtsabteilung Gesetz Entwickler Tester DBA's / SysAdmins Designer Beschützt, befähigt und hilft unterstützt Klärt Anforderungs- details Erteilt Aufträge als User Stories Sammelt Anforderungen und Wünsche klärt Anforderungsdetails 1 2 3

44. Vor dem ersten Sprint – und immer dann, wenn neue Produkte entwickelt werden – sollte eine Vorplanungs- phase stattfinden (Vom Konzept zum Produktbacklog) Das Produkt ist immer mehr als die Software – und sollte aus diesem Grund auch eine andere Behandlung erfahren. Alles was sich nicht oder nur sehr schwer ändern lässt (z.B. Basisarchitektur), sollte ausserhalb von Scrum in einer Vorphase aufgesetzt werden. Agilität ist nicht der komplette Verzicht auf Vorabplanung. Vision Product Planning Product Envisioning Major Features Product Design Product Architecture Risks / Benifits Budgetierung 1 2 3

45. Iterationen bestehen aus den gleichen, immer wieder kehrenden Stufen, die den Rhythmus der Entwicklung vorgeben. Planning Estimation Sprint Retrospektive Review Daily Scrum 1 2 3

46. Iterationen bestehen aus den gleichen, immer wieder kehrenden Stufen, die den Rhythmus der Entwicklung vorgeben. Planning Estimation Sprint Retrospektive Review Daily Scrum Aktuelle, priorisierte User Stories werden kurz vom Product Owner vorgestellt

47. Team schätzt den Aufwand (die Größe) der User Stories in Story Points