Agile
Softwareentwicklung
am Beispiel SCRUM
It´s all about value
ZELJKO KVESIC | MISSION-ONE GMBH |05.10.2017
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
Agenda
1. Vorgehensmodelle Überblick
2. Klassische Vorgehensmodelle
3. Was bedeutet Agilität in der
Softwareentwicklung
4. Überblick agile Vorgehensmodelle
5. Scrum in a nutshell
Ü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
BEISPIEL
WASSERFALL
Quelle: blog.five1.de
V-Modell
NACHTEILE
KLASSISCHE
MODELLE
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
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
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.
SCRUM AUF
EINEM
BIERDECKEL
Quelle: scrum-master.de
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.
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)
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
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
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
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
Self organised teams
Scrum Meetings
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
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.
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
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?
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
RETROSPEKTIVE
Regelmäßig nach hinten schauen – um sich stetig zu verbessern
SCRUM AUF
EINEM
BIERDECKEL
Quelle: scrum-master.de
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
DANKEFÜRDIE AUFMERKSAMKEIT
ZELJKO KVESIC | MISSION-ONE GMBH |05.10.2017

Agile softwareentwicklung am Beispiel von Scrum

  • 1.
    Agile Softwareentwicklung am Beispiel SCRUM It´sall 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 vonkomplexen 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.
  • 6.
  • 7.
  • 8.
    AGILE MANIFESTO Wir erschließen bessereWege, 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ähnung1993  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.
  • 12.
    PRODUCT BACKLOG  Priorisierte Listevon 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 vonPBI´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ürdie 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  Pflegedes 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ägtdie 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  Entwickeltdas 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.
  • 19.
  • 20.
    BACKLOG REFINEMENT  Pflege vomBacklog 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  ProcutOwner 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  inder 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  findettä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  Vorstellungder 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 hintenschauen – um sich stetig zu verbessern
  • 26.
  • 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

Hinweis der Redaktion

  • #9 Lesbarkeit, Übersichtlichkeit, Verständlichkeit, Erweiterbarkeit, Vermeidung von Redundanz, Testbarkeit