Agiles Anforderungsmanagement bei HEC
•Als PPTX, PDF herunterladen•
0 gefällt mir•478 views
Ein kurzer Rundumschlag zum Thema Agiles Anforderungsmanagement. Aufgrund der Größe der Themas kann dieser Vortrag ruhigen Gewissens als "quick & dirty" bezeichnet werden.
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Agiles Anforderungsmanagement bei HEC
Ähnlich wie Agiles Anforderungsmanagement bei HEC (20)
Agiles Anforderungsmanagement bei HEC
- 1. Christian Seedig christian.seedig@hec.de Agiles Anforderungsmanagement (quick & dirty) @chseedig linkedin.com/in/seedig/
- 2. Was ist dieses „Agil“ überhaupt? Trend New Work 🚫 Start-Up Kultur im Unternehmen Scrum, Kanban, Lean & Co. Freie Gehaltswahl Selbst- bestimmtes Arbeiten
- 3. Agilität ist ein Wertesystem! Offenheit (Transparenz Vertrauen) Respekt Mut Fokus Selbst- verpflichtung Vermeidung von Verschwendung
- 4. Manifest für Agile Softwareentwicklung Individuen und Interaktionen > Prozesse und Werkzeuge Funktionierende Software > umfassende Dokumentation Zusammenarbeit mit dem Kunden > Vertragsverhandlung Reagieren auf Veränderung > das Befolgen eines Plans Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein. Quelle: http://agilemanifesto.org/iso/de/
- 5. Agile Prinzipien Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
- 7. Warum sollten wir agiler werden? …dem Unternehmen geht‘s doch seit Jahrzehnten gut. …technologisch sind wir innovativ und weit vorne mit dabei.
- 14. Warum machen wir nicht wenigstens klassisches Projektmanagement? …hat doch immer gut funktioniert.
- 15. Mittwoch, 15.02.2017 18:15 Uhr Quelle: Spiegel Online
- 17. Eignung von VorgehensmodellenTechnologie sicher stabil unsicher volatilAnforderungen bekannt stabil unbekannt volatil Chaos Komplex Ursache – Wirkung ist klar –> Tagesgeschäft erkennen – beurteilen - reagieren definierte Prozesse
- 18. Eignung von VorgehensmodellenTechnologie sicher stabil unsicher volatilAnforderungen bekannt stabil unbekannt volatil Chaos Komplex Ursache – Wirkung braucht Analyse –> planbare Arbeit erkennen – analysieren - reagieren Bewährte Praktiken
- 19. Eignung von VorgehensmodellenTechnologie sicher stabil unsicher volatilAnforderungen bekannt stabil unbekannt volatil Chaos Komplex Ursache – Wirkung im Nachhinein sichtbar –> try & error probieren - erkennen - reagieren Emergente Praktiken Produkt & Softwareentwicklung
- 20. Technologie sicher stabil unsicher volatilAnforderungen bekannt stabil unbekannt volatil Chaos Komplex Eignung von Vorgehensmodellen Keine Ursache – Wirkung im System –> einfach machen Innovative Praktiken handeln - erkennen - reagieren
- 22. Cynefin Habitat, Lebensraum Einfach Definierter Prozess /Best Practice erkennen beurteilen reagieren Verwirrung Kompliziert Good Practice erkennen analysieren reagieren Komplex Emergent Practice probieren erkennen reagieren Chaotisch Novel Practice handeln erkennen reagieren Dave Snowden
- 23. Exkurs in ein wenig Statistik…
- 24. Agiles Projektmanagement! Quelle: GPM Studie – Status Quo Agile 2016/17
- 25. Agiles Projektmanagement! Quelle: GPM Studie – Status Quo Agile 2016/17
- 26. Agiles Projektmanagement! Quelle: GPM Studie – Status Quo Agile 2016/17
- 27. Agiles Projektmanagement! Quelle: GPM Studie – Status Quo Agile 2016/17
- 28. Agiles Projektmanagement! Quelle: GPM Studie – Status Quo Agile 2016/17
- 29. Agiles Projektmanagement! Quelle: GPM Studie – Status Quo Agile 2016/17
- 30. Und was bedeutet jetzt agiles Anforderungsmanagement?
- 31. Agiles Anforderungsmanagement! Weniger Planen mehr ausprobieren Ein-Eindeutige Priorisierung Detailplanung nur für die nächsten 2-3 Iterationen Lasten- und Pflichtenhefte sind „cover your ass“ Verschwendung Bring Kunden und Entwickler zusammen
- 32. Budget & Zeit 1 2 3 4 5 6 7 9 8 Unzufriedenheit Akzeptanz Erwartung Scrum Klassisches Vorgehen Konzeptphase Projektstart NutzenNutzenkurve n Sprint
- 33. DAS GROSSE HEFT DER LASTEN (1602 SEITEN) UNDURCHSUCHBAR UNAKTUELL UNNÜTZ
- 34. DAS GROSSE HEFT DER LASTEN (1602 SEITEN) UNDURCHSUCHBAR UNAKTUELL UNNÜTZ
- 35. Wie sage ich dem Team was ich benötige? …und ein Lastenheft wollen sie ja nicht …irgendjemand muss denen ja sagen was sie wie machen sollen
- 36. Agile Anforderungsaufnahme! Erstelle eine Prouktvision Diese stellen sicher, dass alle das gleiche Verständnis haben Schneide große Dinge kleiner Definiere Deine Zielgruppe(n) durch fiktive Personas Plane MVP und Walking Skeleton Erstelle Impact Map, Story-Map, und Backlog
- 37. ?Was will ich erreichen? Vision / Produkt Vision
- 38. Ziel 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 Vision
- 39. Eindeutig, konsistent verständlich beschrieben Mess- und Prüfbar Zielklassen (Beispiel) Zeitlich Finanziell Leistung Sozial Akzeptiert von allen Stakeholdern Unabhängig von der Lösung Vision -> Ziele
- 40. Produkt- planung
- 41. 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
- 42. Das ist eine Schlange Das ist ein Baum Das ist eine Höhle Das ist ein Berg Gemeinsames Verständnis
- 43. Personas Fiktive Repräsentanten von Benutzern oder Benutzergruppen genauer als Zielgruppen • Katja Katzenlady • 63 Jahre • 5 Katzen • Möchte mal wieder Urlaub machen • Nicht online-affin • Kein Reisebüro vor Ort • …
- 44. HEC Personas Poster Bild Name Wichtige Informationen Hintergrundinformationen Nutzungsverhalten Charaktereigenschaften Persona anfühlbar machen
- 45. Personas Poster Heutige Alternativen Konkurrenzprodukte Was möchte die Persona? Was hat die Persona für Probleme?
- 46. Als wer Möchte ich was großes Damit wozu Als wer Möchte ich was Damit wozu Als wer Möchte ich was großes Damit wozu 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 Das muss ich tun Das muss ich tun Das muss ich tun Das muss ich tun Das muss ich tun Kunde PO Als wer Möchte ich was ganz großes Damit wozu SMDEV Anforderungen schneiden
- 48. Das minimale Set an Funktionen... ...die für uns den maximalen… ...Lerneffekt herstellen. Schick Benutzbar Wertvoll Funktional Minimum viable product
- 49. Walking Skeleton
- 50. Das Unbekannte kennen... ...über den ganzen Geschäftsprozess(e)... ...über alle Hauptkomponenten.
- 51. Was? Impact Map Bester Fe-Wo Service Viele Ferienwohungen vermitteln Vermieter Mehr Kunden erreichen Mehrsprachig- keit Kunden Einfache Buchungss- möglichkeit Suche Belegungs- kalender Freunde überzeugen Facebook Integration Geschäftswert Warum? Rollen Anforderung / Nutzen Funktionen Vision Wer? Wie? Geschäftswert prüfenFeatures erkennen
- 52. Suchfilter Story Mapping Erweiterte SucheSchnellsuche Kalender & Buchung Wohnungen verwalteln * Jeff Patton Suche Warenkorb * neu fertig unwichtig *
- 53. RELEASE 1: Wohnungsbestand RELEASE 2: Buchungsprozess RELEASE 3: Zusatzleistungen
- 54. DAS GROSSE HEFT DER LASTEN (1602 SEITEN) UNDURCHSUCHBAR UNAKTUELL UNNÜTZ
- 55. Suchfilter Story Mapping Erweiterte SucheSchnellsuche Kalender & Buchung Wohnungen verwalteln * Jeff Patton Suche Warenkorb * neu fertig unwichtig * DURCHSUCHBAR AKTUELL NÜTZLICH Story Map
- 56. Der Story Mapping Workshop 1. Alle machen mit, die mit der Produktentwicklung zu tun haben 2. Definiere Benutzer und deren Hauptziele (fachlich und nicht fachlich) 3. Definiere die Tätigkeiten der Benutzer 4. Gruppiere die Tätigkeiten und benenne die Gruppen 5. Trenne die Tätigkeiten in kleinere Stories oder Funktionen auf 6. Priorisiere jede Story nach Wert, Risiko, Nutzen, Wichtigkeit 7. Definiere und Schätze den Walking Skeleton 8. Definiere und Schätze das erste Release Vergiss nie die Vision / das Big Picture! Kunden Einfache Buchungs- möglichkeit Buchungs- bestätigung
- 57. Product Backlog The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. A Product Backlog is never complete. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists. The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. … Quelle: Scrum Guide Product Backlog Items
- 58. Product Backlog Eisberg Mike Cohn Sprint Release Future Releases
- 59. Epic Product Backlog Eisberg Mike Cohn Sprint Release Future Releases
- 60. How deep is your Backlog? Detailed appropriately angemessen detailliert Estimated geschätzt D E Emergent dynamisch, veränderlichE Prioritized Priorisiert, besser geordnetP
- 61. Sinnvolle Ergänzungen? GUI Entwürfe Abläufe / Prozesse Design / Anwendungslayout (Grobe) Architektur …
- 62. Name & Adresse erfassen Zahlungs- daten erfassen Daten bestätigen Buchungs- bestätigung Persönliche Daten erfassen Wohnung wählen Starte und iteriere Wohnung buchen
- 63. Und wie schreibe ich es auf?
- 64. Anforderungen fachlich beschreiben! Wir arbeiten mit User-Stories Große Pakete werden in Epics zusammengefasst Der PO sagt uns WAS er benötigt Formulierung: Als <Rolle> möchte ich <Aktion>, um <Nutzen> Das Team ent- scheidet WIE etwas umgesetzt wird
- 65. Epic / User Story … aber Best Practice Nicht im Scrum Guide erwähnt Fokus von Schreiben auf Sprechen Fokus auf das Ziel einer Aktion Gleich verständlich für Kunden und Entwickler Anforderungen fachlich beschreiben!
- 66. User Story 3 Cs einer User Story Card Conversation Confirmation
- 67. Card Als <Rolle> möchte ich <Aktion>, um… <Nutzen> Eine gute User Story passt auf eine Karteikarte! Vorne die Story, hinten die Akzeptanzkriterien
- 68. Conversation Die User Story ist eine Aufforderung des Teams zur Diskussion mit dem PO über Umsetzung und Details
- 69. Confirmation Verbindliche & testbare Akzeptanzkriterien Schlüssel- wörter identifizieren Fragen- katalog verwenden Fragen im Team diskutieren Akzeptanz- kriterien ableiten Quelle: http://blog.hood-group.com/blog/2011/12/06/akzeptanzkriterien-fur-user-stories-definieren-aber-nur-wie/ Was nicht in Akzeptanzkriterien steht, ist nicht Teil der Umsetzung!
- 70. Confirmation Verbindliche & testbare Akzeptanzkriterien Schlüssel- wörter identifizieren Fragen- katalog verwenden Fragen im Team diskutieren Akzeptanz- kriterien ableiten Quelle: http://blog.hood-group.com/blog/2011/12/06/akzeptanzkriterien-fur-user-stories-definieren-aber-nur-wie/ Was nicht in Akzeptanzkriterien steht, ist nicht Teil der Umsetzung!
- 71. Kriterien für gute User Stories Independant (unabhängig von anderen Stories)I Negotiable (verhandelbar, kein Gesetz) Valuable (wertvoll) Estimatable (schätz- und damit überschaubar) Small (passt in einen Sprint) Testable (test- bzw. überprüfbar) N V E S T
- 72. Wie sage ich dem Vorstand wieviel das Projekt kostet? …ohne genaue Analyse kann das doch gar nicht klappen. …das Budget muss ja eingestellt werden
- 73. 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 150 bis 240 Tagen. Minuten zuvor… Ich lasse das Team mal eine Kalkulation machen!
- 74. Sollten wir die 50 Tage Kapazität nicht lieber in die Entwicklung stecken? Der Vorstand braucht einen detaillierten Plan mit genauem Aufwand! …sind doch eh-da Kosten! Eine Schätzung dauert einen halben Tag mit dem ganzen Team
- 75. Agile Schätzung! Eine Schätzung ist immer falsch Risiken lassen sich nicht in Projektkosten beziffern Eine Analyse kostet auch Geld Die Anforderungen werden sich während des Projektes ändern PERT-Kalkulation ist nicht genauer
- 76. Exkurs: PERT Drei-Punkt-Schätzung! 𝒐𝒑𝒕𝒊𝒎𝒊𝒔𝒕𝒊𝒔𝒄𝒉 + 𝟒 ∗ 𝒓𝒆𝒂𝒍𝒊𝒔𝒕𝒊𝒔𝒄𝒉 + 𝒑𝒆𝒔𝒔𝒊𝒎𝒊𝒔𝒕𝒊𝒔𝒄𝒉 𝟔 o Es muss vorher eine Analyse aller Anforderungen durchgeführt werden o Wenn (noch) unzureichende Informationen vorliegen, liefert die Drei-Punkt-Schätzung wie jede andere Schätzmethode sehr unsichere Ergebnisse o Selbst bei großen Unklarheiten oder Risiken liefert die PERT-Schätzung ein Ergebnis für jedes Arbeitspaket Dies kann zur Fehlinterpretation führen, was eine Anforderung genau kostet o Es sind mehrere Expertenschätzungen und damit jeweils Analysen notwendig, um ein belastbares Ergebnis zu erzielen. Folge: Hohe Kosten für die Schätzung * Zzgl. pauschale Zuschläge für QS, Projektmanagement etc. *
- 77. Wenige Infos – trotzdem schätzen?
- 78. • Die ungefähre Höhe am Anfang zu kennen vereinfacht die Planung des Weges • Eine schlechte Schätzung ist besser als keine Schätzung des Gesamtaufwandes • Durch Schätzungen erkennen wir Unsicherheiten und Aufwandstreiber frühzeitig • Nur ein geschätztes Backlog ermöglicht eine Fortschrittskontrolle
- 81. Zeit 1x 4x 0,25x 2x 0,5x 0,67x 1,5x 1,25x 0,8x Schätzunsicherheit KEGEL DER UNSICHERHEIT Barry Boehm
- 82. Schätzen Aber was? WASTE / PRIVATE DINGE TUN ABSTIMMEN BESPRECHEN FORTBILDEN Ideales Netto Reales Brutto ENTWERFEN CODIEREN REFAKTORIEREN DOKUMENTIEREN REVIEWEN TESTEN ORGANISIEREN
- 83. Schätzung Maßeinheit sind Story Points 1 2 3 5 8 13 20 40 STORY POINT UNSICHERHEIT RISIKO
- 84. Kuchen essen OHNE Krümel und Dreck (ohne technische Schuld) Größe, Dichte Größe Verzehrart, Krümellimit Komplexität Trockenheit, Geschmack, Allergene Unsicherheit
- 85. DAUER
- 86. Das Team Die Aufgaben Einfache Gehirn-OP durchführen 1000 Briefmarken anlecken Was bekommt mehr Story-Points? Quelle: Mike Cohn
- 87. Das Team Die Aufgaben Einfache Gehirn-OP durchführen 1000 Briefmarken anlecken Beide bekommen gleich viele Punkte, da der Aufwand für das Team identisch ist
- 88. Agile Schätzung! Es schätzt immer das komplette Team Um ein gesamtes Projekt zu schätzen nutzen wir das Team-Estimation Game Abweichende Schätzungen werden bis zur Einigung diskutiert Scrum Master und PO werden durch die Laufzeit bewertet
- 89. Team Estimation Game 1. Ein zu schätzendes Element wird von einem Teammitglied vorgestellt und an der Wand platziert. 2. Ein weiteres Element wird vom nächsten Teammitglied vorgestellt und an der Wand platziert: • links vom vorhandenen Element -> geringerer Aufwand • unterhalb des vorhandenen Elements -> gleicher Aufwand • rechts vom vorhandenen Element -> höherer Aufwand 3. Das nächste Teammitglied kann jetzt entscheiden • ein weiteres Element vorzustellen und zu platzieren • ein vorhandenes Element zu verschieben (inkl. Erläuterung weshalb das Element verschoben wurde) 4. Fahre fort bis alle Elemente platziert sind 5. Clusterung der Elemente (Maximal 6-7 Cluster) 6. Schätzung der Cluster (z.B. mittels Planning Poker) 7. Für eine Budgetkalkulation wird ein StoryPoint mit Kosten bewertet, dann lassen sich die Gesamtkosten anhand der Gesamtzahl der StoryPoints ableiten
- 90. Woher weiß ich wann ich fertig bin?
- 91. Agile Fortschrittsmessung! Wir ermitteln die Velocity, also wieviele StoryPoints das Team im Sprint schafft Die Velocity tragen wir aufsummiert in ein BurnUp Chart ein und ziehen eine Gerade
- 92. Das Burn-Up Chart SP Backlog gesamt SP fertig gesamt höchste Velocity geringste VelocityBacklog Baseline Backlog Entwicklung
- 93. Und das Budget Das wäre nicht agil. Transparenz = Holschuld Können Sie mir das nicht schicken? Ich brauche mal einen Statusbericht.Den Status kann man am Taskboard und dem Burn-Up Chart ablesen Nach einiger Zeit… 𝐾𝑜𝑠𝑡𝑒𝑛 𝑆𝑃 = 𝐾𝑜𝑠𝑡𝑒𝑛 𝑆𝑝𝑟𝑖𝑛𝑡 𝑉𝑒𝑙𝑜𝑐𝑖𝑡𝑦
Hinweis der Redaktion
- Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell. Unnötige Dinge vermeiden = Zeit sparen
- Cynefin: Aussprache „Kü-NE-win“ (Walisisch) Einfach: Schnitt in den Finger -> Pflaster, Verband, nichts Kompliziert: Sturz auf den Arm -> Experte (!) -> Bruch, Stauchung, … Komplex: Hautausschlag -> Medikament testen -> funktioniert gut (ok), funktioniert nicht -> anderes Medikament testen Chaotisch: kein Zusammenhang zwischen Handlung und Ergebnis Verwirrung: Wo stehe ich?