Upload
gotthold-nartker
View
103
Download
0
Embed Size (px)
Citation preview
28. Januar, Zürich-Oerlikon
Scrum in der Praxis aus Entwicklersicht
Oliver SchulzSenior Software Engineer & Project ManagerNoser Engineering AG
Noser Engineering Noser Engineering AG > 140 Mitarbeiter NOSER Group > 450 Mitarbeiter Microsoft Gold Partner 28 Jahre Erfahrung in der
Softwareentwicklung
«Noser Engineering AG ist einer unserer führenden ALM-Partner. Das Unternehmen praktiziert selbst konsequent, was es seinen Kunden rät – die Steigerung von Innovativität und Qualität dank ALM“, so Christof Zogg, Director Developer & Platform Group bei Microsoft Schweiz.»
Die Noser Engineering AG erhielt den Microsoft ALM Partner Award 2012
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 von 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
ErkenntnissePriorisierung 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 Projektbeteiligte erfordern klaren, regelmässigen Informationsaustausch
Offen für Veränderung Die Anforderungen ändern sich regelmässig, vor allem bei einem ‚0 auf 100-
Projekt‘
Konsequenz ScrumScrum liefert Output in Intervallen Kurze Sprints ergeben schnelles Feedback
Scrum zwingt zu priorisieren Anforderungen in eine Reihenfolge bringen Wichtigste 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
Projektziele festlegen
Anforderungen erfassen und priorisieren
Konzepte erarbeiten (Architektur- und
Technologieentscheidungen)
Zusammenarbeit und Prozess definieren und Infrastruktur
einrichten
Wenn ich wenig Zeit habe, nehme ich mir viel davon am Anfang! (Ruth C. Cohn)
Sp
rin
t 0
Agil bedeutet nicht: ‚Einfach drauf los entwickeln…‘
P Ziel
Quelle: DasScrumTeam.de © Peter Beck
Scrum – Sprint Planning I
Scrum – Sprint Planning I (Was?)
Sprintziel(e), Umfang, Umsetzung und Prioritäten 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 – 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
Quelle: DasScrumTeam.de © Peter Beck
Scrum – Entwicklungsphase
Scrum – Entwicklungsphase
Nächstes Software-Inkrement 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 Tasks 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)
Quelle: DasScrumTeam.de © Peter Beck
Scrum – Sprint Review
Scrum – Sprint Review
Ergebnisse präsentieren und Feedback der Stakeholder einholen
Zielüberprüfung am konkreten Objekt lohnt sich Korrigiert die Erwartungshaltung an Umsetzungsgeschwindigkeit 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 Stakeholder
Quelle: DasScrumTeam.de © Peter Beck
Scrum – Sprint Retrospective
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
… einmal rum und das Ganze wieder von vorne…
Quelle: DasScrumTeam.de © Peter Beck
FazitScrum zwingt Entwicklungsteams fokussiert auf ein gemeinsames Zeil hinzuarbeiten Tendenz zu pragmatischeren Lösungen
Scrum-Lösungen werden gemeinsam erarbeitet Verantwortung wird gemeinsam getragen
Scrum fördert Know-How-Verteilung Problemlose(re) Intergrationsphasen Ermöglicht auch Anpassung der Teamgrösse in bestimmten Phasen
Scrum gibt Transparenz Kunde sieht zu jeder Zeit die Zielsetzung und den aktuellen Stand
Besten Dank für Ihre AufmerksamkeitFür allfällige Fragen stehen wir Ihnen jederzeit gerne zur Verfügung:Oliver SchulzNoser Engineering AGRudolf-Diesel-Strasse 38404 Winterthur
+41 52 234 56 11
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a
commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.