Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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
www.noser.com