Scrum Lego-City Hands-on Training - fbi.h-da.de · Dennis Bork • Duales Studium der Informatik an...

Scrum Lego-City Hands-on Training

© msg systems ag, 2014Dennis Bork / Marc Lohmann1

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



• Motivation für agiles Vorgehen und Vergleich zu klassischem Vorgehen

Agiles Vorgehen


• 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


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


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


• Eine kurze Einführung in Scrum

Scrum Basics


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


• 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


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


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?


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


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.


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


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


• 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/


Vision


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


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


Lets play „Planning Poker“

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.


Planning Poker?


Backlog Re-Priorisierung & Release Planung


Erklärung und Durchführung eines Planning Meeting


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


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)


Sprint Backlog – Taskboard

CompletedTasksBurndown

ChartTasks to o

ProductBacklog


Sprint Durchführung - Lets build our „Lego City“

Bild: http://ourlegocity.wordpress.com/


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


Sprint Review & Retrospektive


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


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


Burn Down Charts

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


Literatur


Offene Fragen


Geschafft!

Vielen Dank für Ihre Aufmerksamkeit


Dennis Bork

msg systems ag

Telefon: +49 173 3861302 [email protected]

www.msg-systems.com


Anhang


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.


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


• 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

Scrum Lego-City Hands-on Training - fbi.h-da.de · Dennis Bork • Duales Studium der Informatik an...

Documents

Transcript of Scrum Lego-City Hands-on Training - fbi.h-da.de · Dennis Bork • Duales Studium der Informatik an...