"Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen

2,120 views

Published on

"Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen - Ergebnisse aus einem World Café im Rahmen der OOP-Konferenz 2014 in München.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,120
On SlideShare
0
From Embeds
0
Number of Embeds
29
Actions
Shares
0
Downloads
8
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

"Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen

  1. 1. Joachim Seibert     ScrumMaster und Agile Coach bei //SEIBERT/MEDIA Informatik-Background Scrum Master (CSM), Scrum Developer (CSD) und Scrum Professional (CSP) Twitter: @jseibert
  2. 2. Paul Herwarth von Bittenfeld    Seit 2003 als Projektleiter, später als Product Owner und aktuell als ScrumMaster bei //SEIBERT/MEDIA tätig. Scrum Product Owner (CSPO) und Scrum Professional (CSP) Twitter: @pherwarth
  3. 3. PROBLEMSTELLUNG STORY POINTS Aufwandsschätzung Kosten-Nutzen-Verhältnis Risikozuschläge Ideale Tage Backlog Fibbonacci Drei-Punkt-Schätzung Vertikales Schneiden SCHÄTZUNGSGENAUIGKEIT Entwicklertage Stundenschätzung Horizontales Schneiden Schichtenmodell Function Points Features Expertenschätzung KOSTENSCHÄTZUNG Optimistische vs. Pessimistische Schätzungen Planning Poker Komplexität #noEstimates Teamschätzung Magic Estimation
  4. 4. ERFAHRUNGSABFRAGE 1. Konfrontation mit Schätzgenauigkeit Wer hat schon mal auf den Deckel bekommen, weil eine Schätzung nicht gepasst hat? → Antwort: Ja 75% 2. Wie viel Zeit für's Schätzen nehmen? → Antwort: Schnelle Schätzung: 50%, ausführliche Schätzung: 50% 3. Wer schätzt? → Antwort: Schätzung im Team: 50% oder durch Einzelne: 50% 4. Schätzmaß Stundenschätzung vs. Abstraktes Schätzmaß → Antwort: Stundenschätzung: 50% vs abstraktes Schätzmaß: 50% 5. „#noEstimates is easy“ (Vasco Duarte) → Antwort: 5 Personen waren im Vortrag, 2 finden noEstimate einfach
  5. 5. WORLD CAFE zum Erfahrungsaustausch
  6. 6. DIE METHODE     3 Tische mit unterschiedlichen Fragestellungen Jeweils 8 Minuten Zeit zur Erörterung und Dokumentation (auf dem Tisch) Wechsel der Gruppe an den nächsten Tisch Tischhost: einer bleibt und erklärt den anderen die bisherigen Ergebnisse
  7. 7. DIE FRAGESTELLUNGEN Tisch 1 Aus welcher Motivation schätzen wir als Scrum-Team? Tisch 2 Welche Impediments entstehen durch gemachte Schätzungen? Tisch 3 Mit welchen Ansätzen habt ihr gute Erfahrungen gemacht?
  8. 8. ERGEBNISPRÄSENTATION 5 Minuten pro Tisch
  9. 9. #1 MOTIVATION
  10. 10. #1 MOTIVATION Als Motivationsgründe für das Erstellen von Schätzungen wurden Dinge genannt, die die Teilnehmer in die Kategorien „nach innen“ und „nach außen“ unterteilt haben. Nach Außen: Kunde, Stakeholder ● Schätzungen geben Hilfestellungen bei der Kosten-Nutzen Betrachtung (ROI, „make-orbuy“) ● Sie werden verwendet für die Angebotsabgabe / Preiskalkulation ● Schätzungen helfen bei Planung und Controlling und lassen Prognosen zu (z.B. über Fertigstellungstermine) ● für das Einschätzen eines Risikos sind Schätzungen eventuell ebenfalls hilfreich (hohe Schätzung → hohes Risiko) Nach Innen: Team Schätzungen... ● helfen bei Auseinandersetzung und Einschätzung von Aufgaben. ● fördern den Informationsaustausch („warum so aufwändig?“, Auch: „Abwehrschätzung“ genannt) ● sind hilfreich für das Team, um Zusagen für den Sprintumfang zu machen (Commitment, Schutz vor Überlastung des Teams) ● sind Basis für Velocity-Messungen, die (für interne Zwecke) zur Performancemessung verwendet werden können
  11. 11. #2 Impediments
  12. 12. #2 Impediments Folgende Impediments entstehen durch Schätzungen:           Abstrakte Schätzgrößen werden nicht verstanden / müssen umgerechnet werden, was wiederum nur schwierig geht "Schätzungen sind Kosten"; Storypoints sind Aufwandschätzungen; Schätzungen sind Commitment (werden vom Kunden falsch verstanden bzw. als endgültig interpretiert) Storypoints sind Aufwandsschätzungen Teams werden auf Basis ihrer Schätzungen verglichen (Konkurrenz) Schätzung wird als Commitment gesehen (muss gehalten werden) Zeitdruck ist wichtiger als Qualität (schnell fertigstellen, um Schätzung zu halten) Schätzung wird nicht vertraut - man muss Beweise sammeln, „genauer“ schätzen Probleme entstehen, wenn die „falschen Leute“ Schätzungen machen bzw. für andere geschätzt wird. Umfang der Aufgabe ändert sich -> es erfolgt aber keine Anpassung der Schätzung Verifizierung soll/ist findet selten statt
  13. 13. #3 GUTE ERFAHRUNGEN
  14. 14. #3 GUTE ERFAHRUNGEN Gute Erfahrungen haben die Teilnehmer gemacht mit: ● ● ● ● ● ● ● ● ● ● ● ● Schätzungen im Team, gerade auch, wenn unterschiedliche Typen von Mitarbeitern im Team sind (Ausgleich Optimist <-> Pessimist), aber darauf achten, dass sich alle beteiligen (weniger Zurückhaltung) Schätzverfahren wie Planning Poker, Magic Estimation (für viele Stories) und Abstraktes Schätzen (Relationen: größer > kleiner) Gemeinsames Diskutieren von Anforderungsbeschreibungen, um Knackpunkte feststellen, Wissenstransfer zu erreichen und ein besseres Verständnis zu gewinnen (-> realistischere Schätzung) Erstellung von Spikes, um Machbarkeit zu testen Annahmen treffen, die als Basis für Schätzungen definiert werden Umstellung von Personentagen auf Story Points, aber: Für Angebote muss wieder umgerechnet werden Schnelles Schätzen: Aufwand reduzieren wenige Schätzgrößen / Ranges: high, low, Medium (S, M, L) Tasks zählen Besserer Soll-/Ist-Vergleich durch Projektdatenbank, Erfahrungswerte sammeln Aufschläge einrechnen (z.B. Faktor 2 oder prozentuale Aufschläge) Gültigkeitsdauer für Schätzung definieren (danach muss neu geschätzt werden)
  15. 15. ANREGUNGEN Experimentieren mit:  #noEstimates  Messen statt Schätzen (Stories zählen)   Weniger Schätzgrößen verwenden (T-Shirt Sizes) Business Value schätzen
  16. 16. LINKS   Objektspektrum-Artikel von jseibert: http://seibert.biz/agilesbeschaetzen Ergebnisse vom World Café auf den XP Days 2013: http://de.slideshare.net/pherwarth/20131114-och-nichtschonwiederschaetzen  https://infos.seibert-media.net/display/Websoftware/Agile+Vorhersagen  http://borisgloger.com/2013/06/07/warum-uberhaupt-schatzen/  http://agilenature.com/why-do-we-estimate/  http://blog.nayima.be/2009/04/21/why-estimate/    http://epf.eclipse.org/wikis/openup/core.mgmt.common.extend_supp/guidances/g uidelines/agile_estimation_A4EF42B3.html http://pm.stackexchange.com/questions/2765/why-use-story-points-instead-ofhours-for-estimating http://alphanodes.de/schaetzen-agilen-projekten
  17. 17. Ergebnisse und Erfahrungsaustausch via Twitter: @jseibert und @pherwarth

×