Planlos mit Plan

1.650 Aufrufe

Veröffentlicht am

Ein Widerspruch? Nein kein Widerspruch! Nur die Fokussierung auf das Wesentliche unter Berücksichtigung der Herausforderungen des Schätzens. Von der Produktplanung über die Release- / Ressourcenplanung und die Sprintplanung werden die verschiedenen agilen Verfahren zur Schätzung und Planung erörtert und mit den klassischen Verfahren verglichen. Weiterhin werden die notwendigen Grundlagen eines validen Schätzens diskutiert. Brauchen wir überhaupt einen Plan? Welchen Nutzen bringt der uns? Sind agile Schätzverfahren wirklich schneller? Ist agiles Planen genauer als klassische Verfahren? Was ist empirisches Management? Und … wo bleibt mein Gantt?

Veröffentlicht in: Software
0 Kommentare
4 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.650
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
315
Aktionen
Geteilt
0
Downloads
26
Kommentare
0
Gefällt mir
4
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Planlos mit Plan

  1. 1. Planlos mit Plan Wie erhöhe ich die Verlässlichkeit der Planung? Frank Düsterbeck @fduesterbeck
  2. 2. WARUM?
  3. 3. DER PLAN WAS IST DAS?
  4. 4. Was muss ich wann tun? 1. Handlungsschritt 2. Handlungsschritt 3. Handlungsschritt 4. … Was brauch ich? 1. Mittel 2. Menschen 3. Geld 4. … Was will ich erreichen? Vision  Produkt E N T S C H E I D U N G S G R U N D L A G E
  5. 5. WELCHE PLÄNE BRAUCHT MAN? (oder welche werden gefordert?)
  6. 6. WELCHE FRAGEN SOLLEN BEANTWORTET WERDEN? (oder welche Bedürfnisse befriedigt?)
  7. 7.
  8. 8. GIBT’S GRENZEN?
  9. 9. SOFTWARE (-ENTWICKLUNG) IST KOMPLEX
  10. 10. Kleine Software
  11. 11. Die Zukunft kann man nicht berechnen!
  12. 12. Komplex ist Überraschung
  13. 13. Komplexitätstreiber Anforderungen ändern sich Neue Technologien Neue Prozesse und Methoden Team kennt sich nicht Wechselnde Teammitglieder Stakeholder Interessen Echtzeit Chancen und Risiken Gelerntes nicht 1:1 anwendbar Alter Code Infrastruktur
  14. 14. Und nu? Toll!
  15. 15. Die meisten Softwaresysteme und deren Entwicklung sind komplex und somit nicht linear UND nicht vorhersagbar.
  16. 16. K O M P L E X I TÄT R E D U Z I E R E N
  17. 17. K O M P L E X I TÄT B E H E R R S C H E N
  18. 18. K O M P L E X I TÄT B E G E G N E N
  19. 19. DAS AGILE QUIZ Auf komplexe Sachverhalte mit komplexen Methoden zu reagieren ist falsch, weil... DAS AGILE QUIZ ???...sich dadurch die Komplexität weiter erhöht!
  20. 20. INSPECT & ADAPT PROBE – SENSE – RESPOND
  21. 21. DER PRODUKTPLAN
  22. 22. DIE BASIS?
  23. 23. WERT SCHAFFEN
  24. 24. SCHNELL FLEXIBEL HOCHWERTIG GÜNSTIG
  25. 25. ? Was will ich erreichen? Vision / Produkt
  26. 26. VisionZiel des Projektes Erstellung eines Produktes Ergebnis des Produktes Welche Veränderung soll erzielt werden? Nutzen des Produktes Welche Verbesserung soll aus dem Ergebnis resultieren? Zielgruppe Wer soll mit dem Produkt arbeiten? Business Case
  27. 27. Ein Satz zu meiner Vision Meine neuen Stärken Wer möchte was und wozu Die „messbaren“ Ziele Meine Stakeholder Risiken und Chancen Als wer Möchte ich was ganz großes Damit wozu Als wer Möchte ich was ganz großes Damit wozu DAS SUPER PRODUKT VISION POSTER
  28. 28. Produkt- planung
  29. 29. Gemeinsames Verständnis Das ist eine Schlange Das ist ein Baum Das ist eine Höhle Das ist ein Berg
  30. 30. Epos 31 Epos 19 Epos 12 Epos 9 Epos 4 Epos 7 Epos 2 User Story 4 User Story 33 User Story 14User Story 13User Story 3 User Story 1 User Story 6 User Story 2 User Story 5    Status Ready K O M P L E X I TÄT R E D U Z I E R E N
  31. 31. DER RELEASEPLAN
  32. 32. Wann krieg ich was? Release Thema: …Sprint Ziel: …
  33. 33. “Value is created with every Sprint” “The product increment at the end of a Sprint is potentially usable” Und wie geht dann die Releaseplanung? Warum dann überhaupt ein Release? Weil ein Release auch immer eine Klammer für Prototypen, Installation, Migration, Schulung, Change Management, usw. ist
  34. 34. DIE BASIS?
  35. 35. SCHÄTZEN!!!
  36. 36. Schätzungen werden zu einem VERSPRECHEN!!! Werden sie nicht eingehalten leidet das VERTRAUEN!!!
  37. 37. Zeit 1x 4x 0,25x 2x 0,5x 0,67x 1,5x 1,25x 0,8x DER KEGEL DER UNSICHERHEIT Barry Boehm Schätzunsicherheit
  38. 38. Das ist mir viel zu unsicher. Dann müssen wir genauer schätzen. Gib mir mal einen Daumen. Wir haben grob geschätzt! Das Projekt hat nen Aufwand von 15 bis 240 Tagen.
  39. 39. Schätzaufwand hoch niedrig DER SCHÄTZAUFWAND Schätzgenauigkeit hochniedrig
  40. 40. Entscheide lieber ungefähr richtig, als genau falsch! K O M P L E X I TÄT E R H Ö H E N
  41. 41. Die Entwicklung eines Produkt(-inkrements) ist IMMER* Teamarbeit *fast
  42. 42. DAS AGILE QUIZ Wie viele Windows Lizenzen brauchen wir? 240 DAS AGILE QUIZ
  43. 43. DoD WASTE / PRIVATE DINGE TUN ABSTIMMEN BESPRECHEN FORTBILDEN Ideales Netto Reales Brutto ENTWERFEN CODIEREN REFAKTORIEREN DOKUMENTIEREN REVIEWEN TESTEN ORGANISIEREN
  44. 44. Cyril Parkinson: „Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht.“ Douglas Hofstadter: „Es dauert immer länger als man erwartet, selbst wenn man Hofstadters Gesetz berücksichtigt.“
  45. 45. Bin ich schlecht! 1. Ich schätz nur meine idealen Nettozeiten. 2. Große Mengen kann ich gar nicht und komplexe Dinge krieg ich auch nicht auf die Reihe. 3. Und eigentlich kann ich eh nur vergleichen.
  46. 46. MUSS ICH DENN WIRKLICH SCHÄTZEN?
  47. 47. 1 2 3 5 8 13 20 40 K O M P L E X I TÄT B E G E G N E N STORY POINT UNSICHERHEIT
  48. 48. Kuchen essen OHNE Krümel und Dreck (ohne technische Schuld) Größe, Dichte  Größe Verzehrart, Krümellimit  Komplexität Trockenheit, Geschmack, Allergene  Unsicherheit
  49. 49. DAUER
  50. 50. EPIC
  51. 51. Toll – und wie sieht die Releaseplanung jetzt genau aus?
  52. 52. User Story 8 1 2 3 5 8 13 20 40 Epos 31 Epos 19 Epos 12 Epos 9 Epos 4 Epos 7Epos 2 User Story 4 User Story 33 User Story 14 User Story 13 User Story 3 User Story 5  User Story 6  User Story 2  User Story 1  K O M P L E X I TÄT R E D U Z I E R E N User Story 25 User Story 14 User Story 15 TEAM ESTIMATION GAME
  53. 53. MENNO! Ich find Schätzen trotzdem doof! Ach ist doch gar nicht so schlimm. Ist doch eher Kategorisieren – oder?
  54. 54. … und wenn neue Stories im Refinement reinkommen oder geschnitten werden?
  55. 55. Diskussion zum gemeinsamen Verständnis PLANNING POKER
  56. 56. Muss die Summe der Schätzung von zerlegten Stories eigentlich gleich der original Story sein?
  57. 57. Als wer Möchte ich was großes Damit wozu Als wer Möchte ich was Damit wozu Als wer Möchte ich was Damit wozu Als wer Möchte ich was Damit wozu Als wer Möchte ich was Damit wozu≠∑
  58. 58. … OK und weiter? Wie geht jetzt die Releaseplanung? Wir gehen erstmal davon aus, dass wir so 12 Story Points pro Sprint schaffen und messen was wir wirklich hinkriegen.
  59. 59. 0 1 2 3 4 5 6 5 10 15 20 Velocity = 11,5 Velocity 15 8 K O M P L E X I TÄT B E G E G N E N
  60. 60. RELEASETERMIN FIX FUNKTIONSUMFANG FIX KW 45 KW 44 KW 43 KW 42 KW 41 Geht Könnte klappen Geht nicht BESSER! (DIE ESSENZ IST GELIEFERT)
  61. 61. Und das soll jetzt genauer sein als herkömmliches Schätzen und Planen? Klar! Das genau ist empirisches Management!
  62. 62. Lastenheft Agil Welches Angebot ist genauer? Welches kostet mehr? Plichtenheft Product Backlog CR CR Klassisch Preisindikation Angebot UmsetzungUmsetzung Umsetzung Preisindikation
  63. 63. Eins ist noch sehr wichtig um mit Unsicherheiten bei der Releaseplanung umzugehen. Was denn? Wir schneiden keinen Elefanten in Scheiben!
  64. 64. K O M P L E X I TÄT B E G E G N E N
  65. 65. Das ist mir irgendwie noch zu unkonkret!
  66. 66. Warenkorb Story Mapping SucheLogin Bestellung ... *   Jeff Patton Benutzer- verwaltung Bestellprozess
  67. 67. RELEASE 1: MINISHOP RELEASE 2: AUKTIONEN RELEASE 3: MARKTPLATZ
  68. 68. DER SPRINTPLAN
  69. 69. DAILY SCRUM SPRINT PLANNING Product Backlog Product Backlog SPRINT BACKLOG PRODUCT BACKLOG PRODUCT BACKLOG PRODUCT BACKLOG PRODUCT BACKLOG PRODUCT BACKLOG PRODUCT BACKLOG PRODUCT REVIEW RETROSPECTIVE REFINEMENT
  70. 70. Och bidde – geht‘s auch ganz ohne Schätzen?
  71. 71. DER RESSOURCENPLAN
  72. 72. Und was soll das kosten? 𝐾𝑜𝑠𝑡𝑒𝑛 𝑆𝑃 = 𝐾𝑜𝑠𝑡𝑒𝑛 𝑆𝑝𝑟𝑖𝑛𝑡 𝑉𝑒𝑙𝑜𝑐𝑖𝑡𝑦
  73. 73. Projektbudget und -dauer (Soll) Wartungsbudget (Soll) Projektbudget und -dauer mit Puffer (Soll) Zeit Kosten Anforderungen Entwurf Programmierung Test
  74. 74. Wartungsbudget (Ist) Projektbudget und -dauer (Ist) Zeit Kosten
  75. 75. Projektbudget und -dauer (Soll) Wartungsbudget (Soll) Zeit Kosten
  76. 76. Projektbudget und -dauer (Ist) Wartungsbudget (Ist) Zeit Kosten
  77. 77. Zeit Kosten
  78. 78. F A Z I T
  79. 79. DER WERT TREIBT NICHT DER PLAN K O M P L E X I T Ä T G E R E C H T W E R D E N
  80. 80. TREFFE ENTSCHEIDUNGEN AUF BASIS DES BEKANNTEN NICHT AUF BASIS DES UNBEKANNTEN K O M P L E X I T Ä T G E R E C H T W E R D E N
  81. 81. Und äh … … wo bleibt mein Gantt?
  82. 82. DAS AGILE QUIZ “Wer A sagt, der muss ... ???...nicht B sagen. Er kann auch erkennen, dass A falsch war.“ (Bertolt Brecht) DAS AGILE QUIZ Responding to change over following a plan
  83. 83. Frank Düsterbeck frank.duesterbeck@HEC.de @fduesterbeck de.slideshare.net/fduesterbeck

×