Einführung in Scrum auf ein paar Folien.

1. Agile
Softwareentwicklung
am Beispiel SCRUM
It´s all about value
ZELJKO KVESIC | MISSION-ONE GMBH |05.10.2017

2. Vorstellung
Zeljko Kvesic
Leiter Entwicklung & Systeme
mission-one GmbH
www.mission-one.de
Mostar, Bosnien und Herzegowina
zeljko@kvesic.de
Twitter: @nadrealista
Web: www.kvesic.de

3. Agenda
1. Vorgehensmodelle Überblick
2. Klassische Vorgehensmodelle
3. Was bedeutet Agilität in der
Softwareentwicklung
4. Überblick agile Vorgehensmodelle
5. Scrum in a nutshell

4. Überblick
Vorgehensmodelle
 Entwicklung von komplexen Softwareprojekten ist
schwierig umzusetzen und zu warten
 Schwer bis unmöglich zu planen
 Vorgehensmodelle unterteilen den
Entwicklungsprozess in zeitlich und inhaltlich
abgegrenzte Phasen
 Klassische vs. Agile Vorgehensmodelle

5. BEISPIEL
WASSERFALL
Quelle: blog.five1.de

6. V-Modell

7. NACHTEILE
KLASSISCHE
MODELLE

8. AGILE
MANIFESTO
Wir erschließen bessere Wege, Software zu
entwickeln, indem wir es selbst tun und anderen
dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu
schätzen gelernt:
 Individuen und Interaktionen mehr als Prozesse
und Werkzeuge
 Funktionierende Software mehr als umfassende
Dokumentation
 Zusammenarbeit mit dem Kunden mehr als
Vertragsverhandlung
 Reagieren auf Veränderung mehr als das Befolgen
eines Plans
Quelle: http://agilemanifesto.org/iso/de/manifesto.html

9. SCRUM
ALLGEMEIN
 Erste Erwähnung 1993
 Als Erfinder von Scrum gelten heute Jeff
Sutherland und Ken Schwaber
 Scrum – aus dem Rugby / Gedränge
 Scrum ist ein Framework – vieles ist nicht definiert
und muss von dem Team ausgearbeitet werden
 Einfach zu verstehen aber schwer zu meistern

10. SCRUM WERTE
 Commitment – einen bestimmten Ergebnis
auszuliefern
 Fokus – im Sprint sich auf die gegenwertige
Aufgaben konzentrieren und fokusieren
 Offenheit – gegenüber neue Praktiken, neue
Denkweisen, Offenheit und Transparenz
 Respekt – respektvoller Umgang, andere
Meinungen zulassen eigene und die Schwächen
anderer honorieren.

11. SCRUM AUF
EINEM
BIERDECKEL
Quelle: scrum-master.de

12. PRODUCT
BACKLOG
 Priorisierte Liste von Anforderungen mit
Schätzwerten (Estimates)
 Die Anforderungen werden als PBI (Product
backlog items) bezeichnet
 Schätzung in Effort Points  gefühlte Größe, gibt
auch das Verhältnis zu anderen Items im Backlog
 Wird durch den Product Owner verwaltet.
 Je höher ein PBI einsortiert desto detaillierter ist es
beschrieben.

13. SPRINT
BACKLOG
 Liste von PBI´s und Tasks die den Arbeitsumfang
vom aktuellen Sprint festlegt.
 Wird täglich von allen Mitgliedern vom Scrum
Team gepflegt.
 Gibt Einblick in den Fortschritt der Arbeit im
aktuellen Sprint (Burndown Chart)

14. SPRINT
 Timebox für die Implementierung von einem
Inkrement von einem potentiell auslieferbarem
Produkt
 Länge vom Sprint 2 – 4 Wochen
 Beginnt mit dem Sprint Planing
 Endet mit der Sprint Review

15. SCRUM ROLLEN
 Pflege des Product Backlogs
 Vertritt sämtliche Stakeholder im Projekt
 Priorisiert das Backlog – mit dem Ziel das Business
Value vom Produkt zu maximieren.
 Steht dem Developer Team immer zur Verfügung
bei Fragen oder Unklarheiten
 Sollte keine andere Rolle im Projekt einnehmen
 Verändert nicht den Sprint Backlog während des
Sprints
Product Owner

16. SCRUM ROLLEN
 trägt die Verantwortung für den Scrum-Prozess
 ist ein Vermittler und Unterstützer im Scrum Team
 beseitigt Hindernisse (sog. Impediments)
 moderiert Scrum Meetings
 schützt das Team vor unberechtigten Eingriffen
während des Sprints
 ist ein „servant leader“
Scrum Master

17. SCRUM ROLLEN
 Entwickelt das Produktinkrement im Sprint
 Interdisziplinäres Team
 Sollte alle Fertigkeiten besitzen die notwendig sind
um da Produktinkrement zu entwickeln
 5-9 Personen
 Das Team pflegt täglich während des Sprints das
Backlog
Developer Team

18. Self organised teams

19. Scrum Meetings

20. BACKLOG
REFINEMENT
 Pflege vom Backlog durch Product Owner und das
Developer Team
 Schätzung der PBI´s durch das Developer Team
 Schätzung in Effort Points (Fibonacci Reihe)
 4 Stunden im Sprint bei 2-wöchigen Sprints
 Verfeinern von PBI´s damit Klarheit bei hoch
priorisierten PBI´s herrscht

21. SPRINT
PLANING 1
 Procut Owner zusammen mit Developer Team
 Moderiert durch den Scrum Master
 Team legt den Umfang der Arbeit für den nächsten
Sprint und Verpflichtet sich dies im Sprint
auszuliefern (Commitment)
 Nur das Team macht die Aussage was in den Sprint
reingenommen wird. Product Owner äußert die
Wünsche und priorisiert.

22. SPRINT
PLANING 2
 in der zweiten Phase diskutiert das Developer
Team technische Details zur Realisierung von PBI´s
 Zerlegung der Anforderungen in Arbeitspakete
(Tasks)
 keine Zuordnung der Tasks zu Personen
 das Team entwickelt gemeinsam eine Strategie für
die Realisierung der Anforderungen

23. DAILY SCRUM
 findet täglich statt
 immer am gleichen Ort und zur gleichen Zeit
 15 Minuten Dauer
 folgende Fragen beantworten:
 Was habe ich gestern getan?
 Was tue ich heute?
 Welche Probleme habe ich?

24. SPRINT REVIEW
 Vorstellung der Ergebnisse aus dem Sprint
 Vorstellung an den Product Owner der die Arbeit
abnimmt und als Done definiert
 Anwesenheit anderer Stakeholder möglich
 Das Team selbst präsentiert
 Feedback vom Product Owner und Stakeholder
fließt in die weitere Arbeit ein

25. RETROSPEKTIVE
Regelmäßig nach hinten schauen – um sich stetig zu verbessern

26. SCRUM AUF
EINEM
BIERDECKEL
Quelle: scrum-master.de

27. LITERATUR
 Scrum Guide:
http://www.scrumguides.org/scrum-guide.html
 People´s Scrum
https://www.amazon.de/Peoples-Scrum-Agile-
Revolutionary-Transformation-
ebook/dp/B00CO8CRDY
 Rework
https://www.amazon.de/ReWork-Change-Way-
Work-Forever/dp/0091929784/
 Scrum in der Praxis
https://www.amazon.de/dp/3864902584
 Scrum Zertifizierungen
https://www.scrum.org/professional-scrum-
certifications/professional-scrum-developer-
assessment

28. DANKEFÜRDIE AUFMERKSAMKEIT
ZELJKO KVESIC | MISSION-ONE GMBH |05.10.2017