Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Gotthold Nartker Geändert vor über 10 Jahren
2
Scrum in der Praxis aus Entwicklersicht
Oliver Schulz Senior Software Engineer & Project Manager Noser Engineering AG
3
Noser Engineering Noser Engineering AG > 140 Mitarbeiter
NOSER Group > 450 Mitarbeiter Microsoft Gold Partner 28 Jahre Erfahrung in der Softwareentwicklung Die Noser Engineering AG erhielt den Microsoft ALM Partner Award 2012 «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.»
4
Ausgangslage Viele Projektbeteiligte Unpriorisierte Anforderungen
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
5
Erkenntnisse Priorisierung der Anforderungen Schneller Output
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‘
6
Konsequenz Scrum Scrum zwingt zu priorisieren
Scrum 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
7
Der Scrum-Entwicklungsprozess
Quelle: DasScrumTeam.de © Peter Beck
8
Scrum - Projektstart Quelle: DasScrumTeam.de © Peter Beck
9
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 Sprint 0 P Ziel
13
Scrum – Sprint Planning I
Quelle: DasScrumTeam.de © Peter Beck
14
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
19
Scrum – Sprint Planning II
Quelle: DasScrumTeam.de © Peter Beck
20
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
24
Scrum – Entwicklungsphase
Quelle: DasScrumTeam.de © Peter Beck
25
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)
26
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)
31
Scrum – Sprint Review Quelle: DasScrumTeam.de © Peter Beck
32
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
42
Scrum – Sprint Retrospective
Quelle: DasScrumTeam.de © Peter Beck
43
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
45
… einmal rum und das Ganze wieder von vorne…
Quelle: DasScrumTeam.de © Peter Beck
46
Fazit Scrum 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
47
Besten Dank für Ihre Aufmerksamkeit
Für allfällige Fragen stehen wir Ihnen jederzeit gerne zur Verfügung: Oliver Schulz Noser Engineering AG Rudolf-Diesel-Strasse 3 8404 Winterthur
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.