RE-Metriken in SCRUM. Michael Mainik

Größe: px

Ab Seite anzeigen:

Download "RE-Metriken in SCRUM. Michael Mainik"

Martina Schmidt
vor 8 Jahren
Abrufe

1 RE-Metriken in SCRUM Michael Mainik

2 Inhalt Agile Methoden Was ist SCRUM? Eine kurze Wiederholung Metriken Burn Down Graph Richtig schätzen Running Tested Features WBS/ Earned Business Value Business Value Added Zusammenfassung RE-Metriken in SCRUM Michael Mainik

3 Agile Methoden Nicht alle Projekte lassen sich wie ein industrieller Prozess planen Kundenzufriedenheit Schnell laufende Software liefern Änderungen sind gut, denn sie steigern die Zufriedenheit Kommunikation zwischen Managern, Kunden und Entwicklern Information schnell und effektiv austauschen Regelmäßige Kontrolle des Status von Software Krisen früh erkennen RE-Metriken in SCRUM Michael Mainik

4 SCRUM Was war es nochmal? Aus Japan 1990 Priorisierte Liste der Anforderungen vom Product Owner Implementieren der wichtigsten Anforderungen in einem 30-Tage-Sprint Keine neuen Anforderungen während des Sprints Danach aber gerne gesehen Selbstorganisation während des Sprints SCRUM-Master als Leiter, Beobachter, Helfer und Puffer Tägliche Besprechungen (15 min) 3 Fragen an Entwickler Lauffähiges Increment RE-Metriken in SCRUM Michael Mainik

5 SCRUM Überblick RE-Metriken in SCRUM Michael Mainik

6 Praktisch keine Dokumentation Product Backlog Priorisierte Liste mit Anforderungen Sprint Backlog Ausgewählte Anforderungen für Sprint Sprint-Ergebnis Temporäre Dokumente Schätzungen Auswertungen Im Sprint entstandenen Dokumente RE-Metriken in SCRUM Michael Mainik

7 Metriken Burndown-Graph (Work Remaining) Running Tested Features (RTF) Earned Business Value / Work Breakdown Structure Business Value Added RE-Metriken in SCRUM Michael Mainik

8 Daily Burndown-Graph Verbleibender Aufwand Ideal: Jeden Tag den Aufwand von einem Tag bewältigen Tägliche Übersicht über Fortschritt Woher weiß man wie viel Aufwand wirklich nötig ist? RE-Metriken in SCRUM Michael Mainik

9 Schätzen Geschätzte h / (h pro Tag * Anzahl der Entwickler) Schätzungen bleiben Schätzungen Oft entsteht kein perfekter Graph wegen Verschätzungen Nicht vorhersehbare Probleme tauchen auf Fehlende Motivation Ungeklärte Hindernisse Unproduktive Meetings Schlechter SCRUM-Master RE-Metriken in SCRUM Michael Mainik

10 Release Burn Down RE-Metriken in SCRUM Michael Mainik

11 Burndown (1) RE-Metriken in SCRUM Michael Mainik

12 Burndown (2) RE-Metriken in SCRUM Michael Mainik

13 Burndown (3) RE-Metriken in SCRUM Michael Mainik

14 Doch wie schätzt man richtig? Aufwand läßt sich nicht vollständig berechnen Ungeachtet des Aufwandes für die Schätzung: es bleibt eine Schätzung Die ersten 10% liefern bereits mehr als 50% Genauigkeit Richtig schätzen will gelernt sein Gibt es Techniken für das Schätzen? RE-Metriken in SCRUM Michael Mainik

15 Story Points Abstrakte Einheit für geschätzten Aufwand Vergebene Story Points sind stets relativ zum kleinsten und mittleren geschätzten Aufwand Dauer aus Story Points herleitbar Vorteil: Bei Verschätzungen bleiben Relationen erhalten Mit jeder Iteration werden Schätzungen besser RE-Metriken in SCRUM Michael Mainik

16 Ideal Days Keine gewöhnlichen, sondern reine Arbeitstage Nachteile bei der Messung der Leistung von unerfahrenen Entwicklern Velocity = Ideal Days Umgesetzt 1 Feature / 5 Ideal Days 1 Feature / 1 Ideal Day Velocity = 5, obwohl mehr geleistet Velocity bei Story Points hat höhere Aussagekraft RE-Metriken in SCRUM Michael Mainik

17 Running Tested Features (RTF) Gewünschte Software in Features zerlegen Echte End-Benutzer-Features, keine Entwicklungszwischenschritte Für jedes Feature werden Tests definiert Erst wenn Test bestanden, gilt ein Feature als implementiert Zeigt jederzeit auf wieviele Features die Tests bestanden haben RE-Metriken in SCRUM Michael Mainik

18 Die perfekte Kurve Wachstum gleich von Anfang an Stetiges Wachstum über die ganze Zeit des Projekts Kein starkes Wachstum anfangs und später Abflachen Kein flacher Verlauf am Anfang und später Wachstum RE-Metriken in SCRUM Michael Mainik

19 Was sagt die RFT-Kurve aus? Wieso plötzlicher Einbruch? Die Anforderungen haben sich geändert; Tests haben sich geändert Wieso die Abflachung am Ende? Kein Refactoring; Nicht genug Anforderungen Keine Programmierer, keine neuen Tests RE-Metriken in SCRUM Michael Mainik

20 Work Breakdown Structure [1] ATM [3] Product [0] Team [1] Business [1] Function [0] Structure [1] Management [2] Sites Support [3] Team Training [1] Marketing Spt [0] Domain Model [1] Conversions [5] Environments [1] User Training [15] Login [1] Rewrites [2] Dev Process [2] User Docs [10] Withdraw Cash [2] Refactoring [5] App Framework [1] Business [7] Deposit Check [2] Tools [1] Adept Process [10] Transfer Funds [1] Maintenance [1] Buy Stamps RE-Metriken in SCRUM Michael Mainik

21 Earned Business Value Login Use Case: 1 * ¾ * 1 * 15/43 = 45/172 => $ Fertige Features / Geschätzter Aufwand % Sagt nichts darüber aus ob es immer noch das richtige Produkt ist RE-Metriken in SCRUM Michael Mainik

22 Business Value Added Wie sicherstellen, dass fertige Features Wertsteigerung bedeuten? Anzahl der wertvollen Features hinzugefügt abhängig von Zeit Neues Maß : Product Backlog Element * Priorität Wert des Elementes: wirtsch. Wert oder Aufwand Priorität: relative Priorität Zeigt nicht nur Fortschritt, sondern Fortschritt der auch zur Zufriedenheit des Kunden führt Business Value Added as a Scrum Metric, Victor Szalvay, 2004 RE-Metriken in SCRUM Michael Mainik

23 Zusammenfassung Wiederholung: SCRUM Burn Down Graph Wie schätze ich richtig? Running Tested Features WBS/ Earned Business Value Erweiternde Metriken Mögliche Kombination mit EBV? Danke für die Aufmerksamkeit Agile Software Development with Scrum, Ken Schwaber, Mike Beedle, 2002 Agile Estimating and Planning, Mike Cohn, 2007 RE-Metriken in SCRUM Michael Mainik

Ähnliche Dokumente

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

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum 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