Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Größe: px

Ab Seite anzeigen:

Download "Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum"

Wilhelmine Maurer
vor 8 Jahren
Abrufe

1 Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management Domain Expert EMEA Copyright 2008 Serena Software, Inc.

edit Master subtitle style Christian Christophoridis

2 Wasserfall Lange Planungszeit Lange Release-Zyklen Lange Iterationen Keine kontinuierlichen Tests Aufwändige Abstimmung über Requirements (intern und extern) Erschwerte Kommunikation zu Kunden Was war 2 Copyright 2008 Serena Software, Inc.

Abstimmung über Requirements (intern und extern) Erschwerte

9 Scrum Organisation Scrum Team 4-7 Entwickler selbstorganisierend jeder hat jede Rolle ScrumMaster verantwortlich für Scrum-Kultur Beseitigung von Hindernissen Rudergänger Product Owner Produkt Manager priorisiert den Product Backlog 9 Copyright 2008 Serena Software, Inc.

Beseitigung von Hindernissen Rudergänger Product Owner Produkt

10 Scrum Grundlagen Product Backlog definiert Projektumfang Sprint Backlog definiert Aufgaben für aktuellen Sprint Sprint als 30-Tage-Iteration Ergebnis jedes Sprints: vollständig getestet potentiell auslieferfähig mit Vorteil für den Kunden während eines Sprints darf nur das Team den Sprint Backlog erweitern 10 Copyright 2008 Serena Software, Inc.

vollständig getestet potentiell auslieferfähig mit Vorteil für den Kunden während

11 Scrum Meetings Sprint Planning Team wählt die Aufgaben für den Sprint aus Sprint Review keine Slideware nicht länger als 2 Stunden Daily Scrum (Stand-Up-Meeting) Gestern? Heute? Hindernisse? Jeder darf teilnehmen, nur Aktive sprechen. 11 Copyright 2008 Serena Software, Inc.

Daily Scrum (Stand-Up-Meeting) Gestern? Heute? Hindernisse?

12 Aufwandsschätzung Story Points Story Point = NUT (Nebulous Units of Time) stellen geplanten Aufwand zur Umsetzung der User Story dar Schätzung im Team Kunde kann teilnehmen, darf aber nicht schätzen nur klären Abgleichen: 4 Punkte ist doppelt so viel Aufwand wie 2 3 benötigt mehr als 2 und weniger als 4 Velocity (Story Points pro Iteration) Abschätzung, wie viele Story Points in einem Sprint bearbeitet werden können Review nach jeder Iteration und Anpassung der Projektgesamtplanung 12 Copyright 2008 Serena Software, Inc.

wie 2 3 benötigt mehr als 2 und weniger als 4 Velocity (Story Points pro Iteration) Abschätzung, wie viele Story Points in einem

13 Release-Planung Priorisierung MoSCoW (Must have, Should have, Could have, Won t have) Release Plan Story Points / Velocity = Anzahl der Iterationen User Stories werden nach Priorität den einzelnen Releases zugeordnet 13 Copyright 2008 Serena Software, Inc.

Anzahl der Iterationen User Stories werden nach Priorität den

14 Herausforderungen bei der Umstellung (1/2) User Stories kein fertiges Anforderungsdokument keine festen Regeln für Detailgrad Ziel und Benefit für den Kunden steht immer im Vordergrund nicht nummerieren Tests müssen vor der Programmierung geschrieben sein es wird sowohl die Korrektheit des Codes als auch der Wert für den Kunden geprüft 14 Copyright 2008 Serena Software, Inc.

nicht nummerieren Tests müssen vor der Programmierung geschrieben sein es wird sowohl die

15 Herausforderungen bei der Umstellung (2/2) Änderung der Verantwortlichkeit (Entwickler zu Kunde) Rolle des Kunden wird während des gesamten Projekts aufgewertet Vertretung des Kunden durch interne Stakeholder Kunde hat indirekt Einfluss auf Priorisierung Kulturänderung Rolle jedes Einzelnen und des Teams als Einheit wird gestärkt höhere Transparenz 15 Copyright 2008 Serena Software, Inc.

interne Stakeholder Kunde hat indirekt Einfluss auf Priorisierung Kulturänderung Rolle jedes

16 Man kann ein System nur schwerlich am Anfang vollständig beschreiben Use Cases oder Szenarien helfen, müssen aber meistens aufgeteilt werden Entwickler nehmen die Kulturänderung positiv auf - Verantwortliche haben es meistens schwerer Transparenz statt Chaos schnell Ergebnisse bessere Team-Kultur bessere Produktqualität höhere Akzeptanz bei Kunden Erfahrungen 16 Copyright 2008 Serena Software, Inc.

Verantwortliche haben es meistens schwerer Transparenz statt Chaos schnell Ergebnisse bessere

Ähnliche Dokumente

Sollten folgende drei Fragen durch das Team positiv beantwortet werden, sind wichtige SCRUM-Elemente in Ihrem Team erfolgreich installiert.

Sollten folgende drei Fragen durch das Team positiv beantwortet werden, sind wichtige SCRUM-Elemente in Ihrem Team erfolgreich installiert. SCRUM-CHECKLISTE Teilen Sie diese Liste an alle Teammitglieder aus. Jeder soll einen Haken an der Stelle setzen, die er für Ihr SCRUM Team als erfüllt ansieht. Anschließend diskutieren Sie über fehlende