Post on 16-Jul-2018
Dennis Bork
• Duales Studium der Informatik an der Hochschule Darmstadt
− In Zusammenarbeit mit der Deutschen Telekom
• 2009 – 2013: Student Deutsche Telekom Netztechnik
− Schwerpunkt mobile Telekomunikation
• seit 2013 bei der der msg systems ag
− Requierments Engineering (u.a. für Vodafone)
− Bereich „Telecommunications & Media“
• Aktuell bei Miles & More als Testmanager für den Webauftritt und zur Dienstleistersteuerung der App tätig
Privates
Hobbys: Sport, Sport und … Nach dem Studium… 2 Monate USA
© msg systems ag, 2014Dennis Bork / Marc Lohmann2
© msg systems ag, 2014Dennis Bork / Marc Lohmann3
• Motivation für agiles Vorgehen und Vergleich zu klassischem Vorgehen
Agiles Vorgehen
© msg systems ag, 2014Dennis Bork / Marc Lohmann4
• Beschleunigte Markteinführung
• Verbesserte Möglichkeiten zum Umgang mit Änderungen, Prioritäten, Umfang und Anforderungen
• Stärkere Einbindung der Kunden
• Frühe Risikominimierung (in Technik, Funktion und Fachlichkeit)
• Verbesserte Sichtbarkeit des Projekts
• Kunden haben eine agile Unternehmenskultur
Allgemeine Motivation für agiles Projektvorgehen
Bild: (CC BY-ND 2.0)http://www.flickr.com/photos/jerseygal2009/3910066458
© msg systems ag, 2014Dennis Bork / Marc Lohmann5
Entwicklungsvorgehen mit Bezug zum Grad ihrer Stabi lität
Entscheidungen für ein Modell - Gewünschte Stabilität
Stabilität
Agilität
Agi
l
Itera
tiv
Kla
ssis
ch
Agi
l
Itera
tiv
Kla
ssis
ch
© msg systems ag, 2014Dennis Bork / Marc Lohmann6
Kernelemente – Klassisch, Iterativ, Agil
• Transparenz und Kommunikation
• Iterativ –Inkrementell (Sprints)
• Priorisierung und Entwicklung von Anforderungen
• Anpassungsfähige Planung
• Aktive Kunden
• Selbstständiges Team
• Leichtgewichtiger Prozess
• Team durch Projektleiter geführt
• Lange Entwicklungszyklen
• Wasserfallähnliche Konkretisierung über alle Bereiche
• Gesteuert durch einen Plan
• Formaler CR Prozess und Nachvollziehbarkeit
• Dokumentations- und Qualitätskontrollen von Zwischenergebnissen
• Schwergewichtiger Prozess
• Team durch Projektleiter geführt
• Iterativ inkrementelles Vorgehen
• Priorisierung und Entwicklung von Anforderungen
• Gesteuert durch einen Plan
• Häufiges Kunden-Feedback
• Dokumentations- und Qualitätskontrollen von Zwischenergebnissen
• Schwergewichtiger Prozess
© msg systems ag, 2014Dennis Bork / Marc Lohmann8
Characteristika
• Leichtgewichtiger Management-Rahmen
• Einfach zu verstehen (!), aber extrem schwer zu meistern
• Guter Startpunkt für agiles Vorgehen
• Selbstorganisierende Teams
• Kurze Entwicklungszyklen
• Anforderungen sind sequenziell priorisiert.
• Keine spezifische Entwicklungsmethode vorgeschrieben, stattdessen generative Regeln, um ein agiles Umfeld für die Auslieferung von Produkten zu schaffen.
Scrum
Gefahren
• Einführung ohne Erfahrung mit Scrum
• Die Beteiligten sind nicht reif für Scrum
• Passt nicht in die Organisation
• Scrum & Festpreisprojekte
© msg systems ag, 2014Dennis Bork / Marc Lohmann9
• Scrum basiert auf der Theorie der empirischen Prozesssteuerung.
• Diese basiert auf der Grundannahme, − dass Wissen aus Erfahrung gewonnen wird und − dass Entscheidungen auf Grundlage bekannter Fakten getroffen werden.
• In Scrum wird zur Verbesserung der Vorhersagbarkeit und Risikokontrolle ein iterativer und inkrementeller Ansatz verfolgt.1)
Jede Anwendung empirischer Prozesssteuerung (und dam it auch Scrum) stützt sich auf folgende drei Säulen:
Die drei Säulen von Scrum
1) Quelle: scrum.org, Scrum Guide, 1991-2011 Ken Schwaber and Jeff Sutherland
Transparenz
Anpassung
Überprüfung
© msg systems ag, 2014Dennis Bork / Marc Lohmann10
Agile Methoden basieren auf einem gemeinsamen Werte system. Diese Werte sind notwendig für das Funktionieren vo n agilen Methoden.
Agiles Wertesystem
• Welcome changing requirements , even late in development.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development: The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• … Quelle: http://agilemanifesto.org/principles.html
Agile Manifesto
Agile Prinzipien
• Individuen und Interaktionen wichtiger als Prozesse und Tools
• Funktionierende Software wichter als umfangreiche Dokumentation
• Kooperation mit Projektbetroffenen wichtiger alsVertragsverhandlungen
• Reaktion auf Änderungen wichtiger als Verfolgung einesfestgelegten Plans. Quelle: http://agilemanifesto.org
© msg systems ag, 2014Dennis Bork / Marc Lohmann11
Scrum auf einen Blick
Hilfsmittel:• User Stories• Impediment List
• Burndown Charts• Definition of Done
Daily SrcumTäglich
Sprints
Sprint Backlog
Produkt-Inkrement
ProductBacklog
Detail-planung
Sprint Review
Sprint RetrospektiveSprint Planning Meeting
ScrumMaster(SM)
TeamProductOwner(PO)
Sprint RetrospektiveDie Sprint Retrospektive wird am Ende jedes Sprints durchgeführt und dient der kontinuierlichen Prozessverbesserung.
SprintsSprints sind immer gleich lang, z. B. vier Wochen. Während eines Sprints entwickelt das Team ohne Störung von außen die Features aus dem Sprint-Backlog.
Daily SrcumDas Daily Srcum dauert 15 Minuten. Jedes Teammitglied beantwortet kurz drei Fragen:1. Was habe ich seit dem letzten
Daily-Scrum getan?2. Was hat mich dabei behindert?3. Was werde ich bis zum nächsten
Daily-Scrum tun?
© msg systems ag, 2014Dennis Bork / Marc Lohmann12
Scrum auf einen Blick
Sprint BacklogDer Sprint Backlogenthält die Features, welche im nächsten Sprint um gesetzt werden.
Product BacklogDer Product Backlogenthällt alle dem PO bekannten und priorisierten Features.
Produkt-InkrementDas Ergebnis eines Sprints ist ein potentiell auslieferbares Produkt-Inkrement.
Sprint ReviewDas Sprint Review Meeting wird am Ende jedes Sprints durchgeführt und dient der Abnahme des Produktinkrements.
Täglich
Sprint Backlog
Produkt-Inkrement
ProductBacklog
Detail-planung
ScrumMaster(SM)
TeamProductOwner(PO)
Sprint Planning MeetingIm Sprint Planning Meeting selektiert das Team die Features mit der höchsten Priorität aus und führt die Detailplanung für den nächsten Sprint durch.
Scrum Master
• ist verantwortlich für die Einhaltung der Scrum-Werte und -Techniken
• ist ein Coach für die eingesetzten Techniken
• hilft beim Beseitigen von Hindernissen
• schützt das Team vor äußeren Störungen
• versucht Lernprozess und Selbstorganisation des Teams anzustoßen
aber …
• darf nicht inhaltlich arbeiten
• ist nicht Teil des (Umsetzungs-)Teams
• hat keine Weisungsbefugnis gegenüber dem Team
© msg systems ag, 2014Dennis Bork / Marc Lohmann13
Das Scrum Team
Entwicklungs-Team
• selbstorganisierend
• Typischerweise 5-9 Personen
• Funktionsübergreifend: QS, Programmierer, UI-Designer, etc.
• Mitglieder sollten Vollzeitmitglieder sein
• Mitgliedschaft kann sich nur zwischen Sprints verändern
Product Owner
• erfasst Bedürfnisse der Kunden und Stakeholder
• bestimmt Auslieferungsdatum und Inhalt
• ist verantwortlich für Produkt und Projekterfolg (u.a. ROI)
• definiert und priorisiert Features abhängig von deren Geschäftswert
• akzeptiert oder weist Arbeitsergebnisse zurück
Das Team-Modell in Scrum wurde konzipiert, um Flexibi lität, Kreativität und Produktivität zu optimieren.
© msg systems ag, 2014Dennis Bork / Marc Lohmann14
Scrum Meetings
Sprint Planning
• Vor jedem Sprint
• Team wählt zusammen mit dem Product Ownerdie Features mit der höchsten Priorität für den nächsten Sprint aus
• Team bricht die Features auf Tasks herunter und führt Detailschätzung des Aufwands durch
• Team gibt Comittment für den Umfang des nächsten Sprint ab
Sprint Review
• Nach jedem Sprint
• Das Team präsentiert, was es während eines Sprints erreicht hat
• Keine Folien, sondern echte Artefakte bzw. Live Demo
• Das ganze Team nimmt teil
• Laden Sie die ganze Welt ein!
• Product Owner und andere geben Feedback
Daily Scrum Meeting
• Täglich während des Sprints
• Immer am selben Ort und zur gleichen Zeit
• <15 Minuten im Stehen
• Jeder beantwortet 3 Fragen− Was hast du seit dem letztem Mal geschafft?− Was wirst du bis zum nächsten Mal tun?− Was behindert dich beim Vorwärtskommen?
• Keine Inhaltlichen Diskussionen
Sprint Retrospektiven
• Nach jedem Sprint
• Alle Teammitglieder
• Product Owner optional
• Prozess Review und Lessons Learned
� kontinuierliche Verbesserung
Burndown-Charts
• Visualisierung bereits geleisteter und noch verbleibender Arbeit
• Für jeden Sprint und ggf. Release
© msg systems ag, 2014Dennis Bork / Marc Lohmann15
Scrum Artefakte
Impediment List
• Liste aller Hindernisse
• wird vom Team verwaltet
• wird genutzt, um team-interne Hindernisse selbst zu beheben und team-externe Hindernisse zu kommunizieren
Product Backlog
• enthält die zukünftigen Features (meist in Form von User stories)
• wird vom Product Ownerverwaltet
• Features sind vom ProductOwner nach Geschäftsnutzen priorisiert (Serialisierung)
• Granularität nimmt nach unten hin ab
Definition of done
• Implementiert
• JUnit Tests erstellt und erfogreich getestet
• Integrationstests erfolgt
• Dokumentation im IT-Konzept / Benutzerhandbuch
• Release Notes
Sprint Backlog
• wird vom Team verwaltet
• enthält die User Stories, welche vom Team im aktuellen Sprint für die Umsetzung geplant sind
• Diese werden vom Team in Tasks auf gesplittet
• Tasks sind mit ihrem Aufwand enthalten
© msg systems ag, 2014Dennis Bork / Marc Lohmann16
• SCRUM erleben anhand des Projektes „Lego®-City“
Lego®-City
„Es soll eine Lego Stadt aus Häusern, Autos, Flugzeugen, Straßen und weiteren Objekten gebaut werden.“
Setting:
• Die Teilnehmer sind Mitarbeiter eines großen Unternehmens und erstellen in einem oder mehreren Teams die gewünschte Stadt. (je nach Zahl der Teilnehmer)
• Pro Team ist ein Scrum Master zu bestimmen (kann auch wechseln).
• Der Coach spielt neben seiner eigentlichen Rolle den ProductOwner.
• Geplant für das Spiel sind 3 Sprints.
Bild: http://ourlegocity.wordpress.com/
© msg systems ag, 2014Dennis Bork / Marc Lohmann17
Vision
© msg systems ag, 2014Dennis Bork / Marc Lohmann18
Product Backlog
• enthält die einzelnen User Stories.
• Jede User Story wird mit dem Datum versehen, zu dem diese in Product Backloggekommen ist.
• Es gibt eine klare Sequenz, d. h. User Stories haben bezüglich ihrer Priorität eine eindeutig fortlaufende Nummer.
• Je „weiter weg“ die Umsetzung der User Stories ist, desto „gröber“ ist ihre Beschreibung.
• enthält sogenannte Storypoints, die durch das Scrum-Team individuell genormten Komplexitätspunkte.
User Story
• beschreibt eine Anforderung an ein (Software-)System.
• Die Anforderung besitzt einen konkreten und sichtbaren Mehrwert für den Kunden.
• Beispiel: „Als Kunde möchte ich mich im System registrieren und mir ein Kundenkonto anlegen können.“
Product Backlog & User Stories
© msg systems ag, 2014Dennis Bork / Marc Lohmann19
Setting:
• Teilnehmer stellen sich an einer gedachten Linie hinsichtlich der gefühlten Scrum-Erfahrung der Reihe nach auf.
• Eventuell werden Gruppen gebildet (je nach Teilnehmerzahl).
Teams bilden
Was ist Planning Poker?
• Expertenschätzung mit dediziertem Schätzmeeting
• Nutzung von identischen Schätzkarten (mit Fibonacci Zahlen) pro Schätzer
• Schätzung Story Points
Wie funktioniert Planning Poker?
• Schätzmeeting mit Scrum Master als Moderator
• Schätzer sind in der Regel das Team.
• Für jedes zu schätzende Feature werden folgende Schritte durchgeführt:− Product Owner stellt das Feature vor.− Team diskutiert das Feature mit dem Product Owner.− Moderator fordert die Schätzer auf, eine Karte auszuwählen und verdeckt auf den Tisch zu legen.− Alle Karten werden simultan umgedreht.− Ausreißer nach oben und unten werden diskutiert.− Schätzer einigen sich auf eine gemeinsame Schätzung.− Am Ende des Meetings sind alle Features geschätzt.
© msg systems ag, 2014Dennis Bork / Marc Lohmann21
Planning Poker?
© msg systems ag, 2014Dennis Bork / Marc Lohmann23
Erklärung und Durchführung eines Planning Meeting
© msg systems ag, 2014Dennis Bork / Marc Lohmann24
Sprint Planning Meeting
Tag 1 Tag 2 Tag 3 … Tag 14 (21, 28)
Retrospektive
Das „Sprint Planning Meeting“ findet zu Beginn jedes Sprints statt.
Teil 1
• Product Owner und Scrum-Team einigen sich auf das Sprint-Ziel.
Teil 2
• Dieses Treffen organisiert das Scrum-Team eigenverantwortlich.
• Arbeit (User Stories) wird in Aufgaben (Tasks) zerlegt (optimalerweise je Aufgabe < 1BT).
• Aus den Aufgaben entsteht das „Sprint Backlog“.
Planning Review
Sprint
© msg systems ag, 2014Dennis Bork / Marc Lohmann25
Vom Product Backlog zum Sprint Backlog
As a vacation planner, I wantto see photos of the hotels.
Code the middle tier (8 hrs)Code the user interface (4)Write test fixtures (4)Code the foo class (6)Update performance tests (4)
© msg systems ag, 2014Dennis Bork / Marc Lohmann26
Sprint Backlog – Taskboard
CompletedTasksBurndown
ChartTasks to o
ProductBacklog
© msg systems ag, 2014Dennis Bork / Marc Lohmann27
Sprint Durchführung - Lets build our „Lego City“
Bild: http://ourlegocity.wordpress.com/
© msg systems ag, 2014Dennis Bork / Marc Lohmann28
Inside eines Sprints
Daily Scrum• Pünktlicher Start
• Alle dürfen teilnehmen
• Zeitlich begrenzt auf 15 min
• Gleicher Ort und Zeit jeden Tag (z. B. 12 Uhr, Projektbüro)
Jedes Teammitglied beantwortet folgende Fragen:
• Was habe ich gestern gemacht?
• Was plane ich heute zu machen?
• Gibt es Probleme, welche verhindern, dass ich mein Ziel erreiche?
Daily Build• Nicht vorgeschrieben in Scrum
• Dennoch sehr sinnvoll und hilfreich
• Abschluss einer Aufgabe auf Tagesebene
• Abarbeitung des Sprint Backlogs (priorisiert!)
• Aktualisierung des Scrum Taskboard (kontinuierlich)
Tag 1 Tag 2 Tag 3 … Tag 14 (21, 28)
Retrospektive
Planning Review
Aufgabenfokussiertes Arbeiten
© msg systems ag, 2014Dennis Bork / Marc Lohmann30
Sprint Review Meeting
Tag 1 Tag 2 Tag 3 … Tag 14 (21, 28)
Retrospektive
Das Sprint Ergebnis wird einem informellen Review durch das Te am und den ProductOwner unterzogen.
• Das Ergebnis wird vorgeführt (=laufende Software, keine Folien).
• Product Owner prüft, ob das Ergebnis seinen Anforderungen entspricht.
• Eventuelle Änderungen können in Form von Erweiterungen, Umpriorisierungen oder durch das Entfernen von Elementen des Product Backlogs dokumentiert werden.
Planning Review
© msg systems ag, 2014Dennis Bork / Marc Lohmann31
Sprint Retrospektive
Tag 1 Tag 2 Tag 3 … Tag 14 (21, 28)
Retrospektive
In der Retrospektive wird die zurückliegende Sprint-Phase betrachtet.
• Folgende Fragen werden von allen beantwortet:− „Was war gut?“ (Best practice)
− „Was könnte verbessert werden?“ (Verbesserungspotential)
• Jedes Verbesserungspotential wird protokolliert und aktiv verfolgt.
• Scrum Master treibt die Umsetzung der Verbesserungs-potentiale aktiv voran (direkt & indirekt).
Planning Review
Succeeding with Agile: Software Development Using Scrum; Mike Cohn
http://www.mountaingoatsoftware.com/books/7-succeeding-with-agile-software-development-using-scrum
Agile Estimating and Planning; Mike Cohn
Brief Summary:
http://www.mountaingoatsoftware.com/books/1-agile-estimating-and-planning
http://www.niwotridge.com/BookReviews/AgileEstimatingandPlanning.pdf
The Software Project Manager's Bridge to Agility (Agile Software Development), Michele Sliger, Stacia Broderick
http://www.sligerconsulting.com/resources/books/
Management 3.0: Leading Agile Developers, Developing Agile Leaders, Jurgen Appelo
Scrum Guide https://www.scrum.org/Scrum-Guide
© msg systems ag, 2014Dennis Bork / Marc Lohmann33
Literatur
Vielen Dank für Ihre Aufmerksamkeit
© msg systems ag, 2014Dennis Bork / Marc Lohmann36
Dennis Bork
msg systems ag
Telefon: +49 173 3861302 dennis.bork@msg-systems.com
www.msg-systems.com
© msg systems ag, 2014Dennis Bork / Marc Lohmann38
Die PL-Rolle ist aufgeteilt auf Product Owner und Tea m.
Aufteilung der PL-Rolle auf die Scrum Rollen
Aspekt Scrum Master Product Owner Team
Risikomanagement � (Prozess) � (Projekt/Release) �(Technisch)
Zeit � � (Projekt/Release) �(Sprint)
Umfang � � (Projekt/Release) � (Sprint)
Kosten � � (Projekt/Release) � (Sprint)
Qualität � (Prozess) � (Umfang) � (Testing)
Kommunikation � (Prozess) � (Projekt/Release) �(Sprint)
Sourcing* � (Anforderung) (Anforderung) �
* Das Sourcing/Staffing erfolgt in enger Abstimmung mit dem Linemanagement.
© msg systems ag, 2014Dennis Bork / Marc Lohmann39
Unser Scrum-Vorgehen in Großvorhaben
Scrum of Scrums MeetingsTeamübergreifende ZusammenarbeitZiel: Problemlösung Einheitliches Vorgehen.
Communities of Practice Teamübergreifende Zusammenarbeit Ziel: Einheitliches Vorgehen
CPO
POFS
POFS
PO
PO
PO
PO
PO
Product OwnerHierarchie Einheitliche und hierarchisch aufgeteilte Sicht auf Fachlichkeit
Release
QG QG QG QG QG
Initialer Sprint Aufsetzen des Releases
Sprints zum Implementieren der Fachlichkeit
Finaler QS-Sprint Abschließen des Releases
Quality Gates : Synchronisation und Release-begleitende Integration und Qualitätssicherung
Kurze Sprintsverkürzen die Reaktions-geschwindigkeit bei Anfragen fachlicher Teams.
Fach-Teams
Querschnitts-Teams
© msg systems ag, 2014Dennis Bork / Marc Lohmann40
• Findet statt, wenn Projekt mit mehreren Scrum Teams durchgeführt wird.
• Empfohlen: alle 2 Tage ca. 30 min.
• Aus jedem Team nehmen 1-2 Personen teil.
• Jeder beantwortet folgende Fragen:− Was hat dein Team seit dem letzten Treffen gemacht?− Was wird dein Team bis zum nächsten Treffen machen?− Gibt es Dinge, welche dein Team behindern?− Ist dein Team dabei irgend etwas zu machen, was andere Teams behindern könnte?
Scrum of Scrum Meeting