Scrum in der Praxis (eine mögliche Umsetzung)

ALM Talk, 26. Oktober 2011

Stefan Stettler

Ausgangslage

• Viele Projektbeteiligte

Verkauf, Entwickler, PM, Designer, Ergonomen

Unterschiedliche Sichten und Vorstellungen, wie Anforderungen umgesetzt

werden können

• Unpriorisierte Anforderungen

Liste mit vielen Anforderungen, welche sich nicht innerhalb 2 Monaten

realisieren lassen

Hohe Anforderungen an Bedienoberfläche bezüglich Design und Ergonomie

• Zeitdruck

Innerhalb von 2 Monaten muss eine Lösung für Messe vorhanden sein

Nach 6 Monaten soll der 1. Release freigegeben werden können

Erkenntnisse

• Priorisierung der Anforderungen

Die erste Lösung soll die Kernfunktionalität beinhalten (Must-Haves) und

einige Hingucker für die Messe

• Schneller Output

Wir müssen schnell liefern, damit am konkreten Objekt die Umsetzung der

Anforderungen überprüft werden kann

• Gute Kommunikation

Viele Projektbeteiligten erfordert klaren, regelmässigen

Informationsaustausch

• Offen für Veränderung

Die Anforderungen ändern regelmässig, vor allem bei einem ‚0 auf 100-

Projekt‘

Konsequenz Scrum

• Scrum liefert Output in Intervallen

Kurze Sprints ergeben schnelles Feedback

• Scrum zwingt zu priorisieren

Anforderungen in eine Reihenfolge bringen

Wichtigsten Features zuerst umsetzen

• Scrum fördert Kommunikation

Daily Scrums, Sprint Reviews geben allen Beteiligten, die Möglichkeit

regelmässig Informationen auszutauschen

Designer und Ergonomen nehmen am Sprint Review teil

• Scrum ist offen für Veränderung (nur nicht während des Sprints)

lässt neue Richtungsvorgabe zwischen den Sprints zu

Der Scrum-Entwicklungsprozess

Quelle: DasScrumTeam.de © Peter Beck

Scrum - Projektstart

Quelle: DasScrumTeam.de © Peter Beck

Scrum - Projektstart

Wenn ich wenig Zeit habe, nehme ich mir viel davon am Anfang! (Ruth C. Cohn)

• Agil bedeutet nicht: ‚Einfach drauf los entwickeln…‘

• Projektziele festlegen

• Anforderungen erfassen und priorisieren

• Konzepte erarbeiten (Architektur- und Technologieentscheidungen)

• Zusammenarbeit und Prozess definieren und Infrastruktur einrichten

Sp

rin

t 0

P Ziel

Scrum – Anforderungen, Product Backlog

Scrum – Anforderungen, Product Backlog

Scrum – Sprint Planning I

Quelle: DasScrumTeam.de © Peter Beck

Scrum – Sprint Planning I (Was?)

Sprintziel(e), Umfang, Umsetzung und Prioritäten zu definieren

• Meeting-Qualität hängt davon ab, wie gut die User Stories vorbereitet

sind.

Bei unklaren User Stories Unterstützung des PO durch

Konzepterarbeitung

• Commitment über Umfang eines Sprints auch bei kurzen Sprints

schwierig

Sprintziele priorisiert

Optionale Sprintziele formuliert

Scrum – Anforderungen, Product Backlog

Scrum – Anforderungen, Product Backlog

Scrum – Anforderungen, Product Backlog

Scrum – Sprint Planning II

Quelle: DasScrumTeam.de © Peter Beck

Scrum – Sprint Planning II (Wie ?)

Umsetzungsarbeiten definieren, schätzen und planen

Commitment zu bestätigen

• Commitment über Umfang eines Sprints kann nur über

Kapazitätsplanung erfolgen

• Kapazitätsplanung notwendig, da Ressourcenverfügbarkeit sich ändert

Scrum – Entwicklungsphase

Quelle: DasScrumTeam.de © Peter Beck

Scrum – Entwicklungsphase

Nächste Software-Inkrement zu erstellen

• Architektur-/Design-Workshops im Team

Schnittstellen und Zusammenspiel der Komponente detailliert definiert

Ganzheitlichere Lösungen erhalten

Know-How-Verteilung erreicht

• Effektives Arbeiten dank klarer Ziele schneller Fortschritt

• Controlling ermöglicht frühzeitig Massnahmen einzuleiten

(z.B. Taskumverteilung)

Scrum – Entwicklungsphase

• MA arbeitet seine Tasks ab und bucht auf entsprechendes Work Item

• Daily Scrums:

Jeder erklärt welche Tasks abgeschlossen sind, an welchen Taks gearbeitet

wird, welche Probleme anstehen

• PL behält verbleibende Kapazität zu verbleibender Arbeit im Auge

falls möglich Taskumverteilung, sonst Rücksprache mit PO)

Scrum – Entwicklungsphase

• MA arbeitet seine Tasks ab und bucht auf entsprechendes Work Item

• Daily Scrums:

Jeder erklärt welche Tasks abgeschlossen sind, an welchen Taks gearbeitet

wird, welche Probleme anstehen

• PL behält verbleibende Kapazität zu verbleibender Arbeit im Auge

falls möglich Taskumverteilung, sonst Rücksprache mit PO)

Scrum – Sprint Review

Quelle: DasScrumTeam.de © Peter Beck

Scrum – Sprint Review

Ergebnisse präsentieren und Feedback der Stakeholders einholen

• Zielüberprüfung am konkreten Objekt lohnt sich

Korrigiert die Erwartungshaltung an Umsetzunggeschwindigkeit

Neue Ideen entstehen

• Diskussion über verschiedene Umsetzungsmöglichkeiten können

langwierig sein Moderator muss klaren Entscheid anstreben

• Meeting ist ein Indikator für aktuelle Wichtigkeit des Projekts

Vakanzen der Stakeholders

Scrum – Sprint Review

Scrum – Sprint Review

Scrum – Sprint Review

Scrum – Sprint Review

Scrum – Sprint Review

Scrum – Sprint Review

Scrum – Sprint Review

Scrum – Sprint Review

Scrum – Sprint Review

Scrum – Sprint Retrospective

Quelle: DasScrumTeam.de © Peter Beck

Scrum – Sprint Retrospective

Kontinuierliche Verbesserungen im Entwicklungsprozess

• Infrastruktur/Organisation

Build-Server, Definition von Dokumentenstruktur auf Portal

Design-Tag am Anfangs des Sprints eingeführt

• Nach Bedarf

Am Anfang regelmässiger als akutell

Scrum – Sprint Retrospective

• Team besprechen Verbesserungsmöglichkeiten Infrastruktur, Dokumentation, Infrastruktur

• Punkte werden auf Portal festgehalten

• In jeden Sprint werden 1-2 Punkte eingeplant

… einmal rum und das Ganze wieder von vorne…

Quelle: DasScrumTeam.de © Peter Beck

Fazit

• Scrum zwingt Entwicklungsteam fokussiert auf ein gemeinsames Ziel

hinzuarbeiten

Tendenz zu pragmatischeren Lösungen

• Scrum-Lösungen werden gemeinsam erarbeitet

Verantwortung gemeinsam getragen

• Scrum fördert Know How-Verteilung im Team

Problemlose Integrationsphasen

ermöglicht auch Anpassung der Teamgrösse in bestimmten Phasen

• Scrum gibt Transparenz

Kunde sieht die Zielsetzung und den aktuellen Stand

NOSER ENGINEERING AG

Talackerstrasse 99

8404 Winterthur

+41 52 234 56 33 direct

+41 52 234 56 11 phone

stefan.stettler@noser.com

www.noser.com