Scrum? Susanne Mühlbauer. 10:30 bis 12:00 H 43

Transkript

1 @LeanAgileScrum #LASZH LAS Conference 2012 Sponsoren Machen Sie noch Anforderungsmanagement oder sind Sie schon READY for Scrum? Susanne Mühlbauer 10:30 bis 12:00 H 43 Der Scrumertinger Organisationsteam Patrick Baumgartner (Swiftmind GmbH) Andreas Buzzi (Credit Suisse) Reto Maduz (SwissQ AG) Mischa Ramseyer (pragmatic solutions gmbh)

2 HOOD- Excellence in Requirements Engineering Unsere Konferenzen, Publikationen, Expertentalk REConf HOOD ist der Veranstalter von Europas größter RE-Konferenz Im HOOD Blog diskutieren wir ständig aktuelle Themen und Trends des Requirements Engingeering. Wir freuen uns darauf, Sie auf unserem Blog begrüßen zu dürfen: -2-

3 Inhalte Was ist Anforderungsmanagement Erhebung und bestehende Spezifikationen Zusammenarbeitsmodelle und Planung Kontrolle versus Vertrauen -3-

4 Requirements Engineering Verstehen Vereinbaren Sicherstellen -4-

5 Die Ideallinie für RE im agilen Umfeld finden! Soviel wie nötig, so wenig wie möglich. Konventionell Agile Schriftlich Spezifikation Vollständig Requirements Engineering Konversation Just-in-Time Value-Orientiert -5-

7 Spezifikationen versus Product Backlog Product Backlog Alle anderen Scrum Team (s) -7-

8 Aufgabe: Ermitteln Sie die Anzahl der Anforderungen in dem vorgegebenen Text Das Verletzungsrisiko soll minimiert werden. Dies bedeutet, dass einjährige Kinder klassifizierbar sein müssen, um bei ihnen den Beifahrerairbag abschalten zu können. PS besteht aus einer Digitalkamera vom Typ Minolta R456, die in der Lage ist, einjährige Kinder erkennen zu können. Die Identifizierung des Kindes mit dem PS beruht auf einer Auswertung des digitalen Bildes durch noch zu entwickelnde Algorithmen. Die Kommunikation von PS mit seiner Umgebung und der Zugriff auf die Steuergeräte-Daten, erfolgt über den L-BUS. Das PS sendet zyklisch den aktuellen Status der Personenklassifizierung an das Steuergerät. Zusätzlich wird eine Information über den aktuellen Belegungszustand des letzten Messzyklußes ausgegeben. -8-

9 Probleme - Anforderungen sind nicht klar erkennbar - Zusatzinformationen sind enthalten - Viel Text alle Anforderungen enthalten? - Sind die vorgegebenen Lösungen zwingend? - Warum gibt es diese Vorgaben und Einschränkungen?

10 Maßnahmen Geschicktes Verwalten von Anforderungen Weg von Word oder Excel-Spezifikationen Hin zu Einzelanforderungen, datenbankbasierten Anforderungen Sichten auf die Anforderungen bilden User Stories Geschicktes Packetieren von Anforderungen Geschicktes Erheben von Anforderungen -10-

11 Aufgabe: Wieviele User Stories enthält der Text? Das Verletzungsrisko soll minimiert werden. Dies bedeutet, dass einjährige Kinder klassifizierbar sein müssen, um bei ihnen den Beifahrerairbag abschalten zu Als können. X PS besteht aus einer Digitalkamera vom Typ Minolta R456, die in der Lage ist, will ich Y, einjährige Kinder erkennen zu können. Die Identifizierung des Kindes mit dem PS beruht damit auf einer Auswertung Z. des digitalen Bildes durch noch zu entwickelnde Algorithmen. Die Kommunikation von PS mit seiner Umgebung und der Zugriff auf die Steuergeräte-Daten, erfolgt über den L-BUS. Das PS sendet zyklisch den aktuellen Status der Personenklassifizierung an das Steuergerät. Zusätzlich wird eine Information über den aktuellen Belegungszustand des letzten Messzyklußes ausgegeben. -11-

12 Das Ziel muss erkennbar sein 1. Das Verletzungsrisiko muss um tbd % reduziert werden Ziel/ Vision 2. Wenn ein einjähriges Kind auf dem Beifahrersitz sitzt muss der Beifahrerairbag abschaltbar sein. Feature 3. Einjährige Kinder müssen klassifziert werden. Epic/ User Story 4. PS besteht aus einer Digitalkamera vom Typ Minolta R456. Akzeptanz- Lösung kriterium -12-

13 Vision Von der Vision zur User Story Architekturvision Business Plan Business Drivers Minimum Marketable Product/ Feature Set Feature Feature Feature Feature Epic Epic User Story User Story Epic User Story User Story Epic Epic -13-

14 Product Vision - Beispiel Vision All my music is in my pocket Apple -14-

15 Requirements Engineering: Scope definieren Systemgrenze, -kontext und Schnittstellen Stakeholder Analyse -15-

16 Einfluss/ Macht Stakeholder-Analyse Interesse am Produkt Hoch Diese Stakeholder müssen unbedingt involviert werden, da sie dem Projekt/ Produkt auch schaden können Diese Stakeholder sollten unbedingt befragt werden Niedrig Diese Stakeholder müssen eher nicht befragt werden Ausgewählte Stakeholder sollten befragt werden Niedrig Hoch -16-

17 Architekturvision Architekturrelevante Anforderungen Prinzip: Deferred Decisions 1. Architekturrelevante Anforderungen sind Anforderungen, die implizit oder explizit architekturrelevant sind. 2. Implizite Architekturanforderungen sind Anforderungen, die über ihre Eigenschaften als architekturrelevant eingeordnet werden. Alle Anforderungen mit hohem Risiko, hoher Priorität oder geringer Stabilität können als architekturrelevant betrachtet werden. 3. Explizite Architekturanforderungen sind meist nicht-funktionale Anforderungen. -17-

18 Emerging Architecture Architekturvision Funktionalität Funktionalität validiert Architektur Architektur nicht ohne Funktionalität Architektur Quelle: Codecentric, OS Information Days 2012 t -18-

19 Gut genug für den Moment 1. Minimum Marketable Product/ Feature Set 2. Walking Skeleton 3. Die einfachste Lösung, die funktioniert 4. Nur das Notwendigste wird vom System unterstützt 5. Potentiell lieferbar 6. Akzeptanzkriterien streichen 7. Bereits während der Erhebung priorisieren -19-

20 Als Marketing-MA will ich einen Text auf der Webseite publizieren können. Text erstellen Review Freigabe Aufgabe: Machen Sie daraus 3-4 User Stories Veröffentlichen Copyright 2012 HOOD Ltd. Vertraulich. Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung ohne vorherige -20-

21 Reihenfolge Lösung: Als Marketing-MA will ich einen Text auf der Webseite publizieren können. Text erstellen 1. Als Marketing-MA will ich einen Text erstellen können. Review 2. Als Marketing-MA will ich ein Review für einen Text durchführen können. Freigabe 3. Als Marketing-MA will ich eine Freigabe für einen Text erhalten. Veröffentlichen 4. Als Marketing-MA will ich einen Text auf der Webseite publizieren können. Copyright 2012 HOOD Ltd. Vertraulich. Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung ohne vorherige -21-

22 Reihenfolge Akzeptanzkriterien Text erstellen Review Lösung 2: Als Marketing-MA will ich einen Text auf der Webseite publizieren können. 1. Als Marketing-MA will ich einen Text auf der erstellen und publizieren können. 2. Als Marketing-MA will ich eine Freigabe für einen Text erhalten. Freigabe 3. Als Marketing-MA will ich ein Review für einen Text durchführen können. Veröffentlichen Copyright 2012 HOOD Ltd. Vertraulich. Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung ohne vorherige -22-

23 Erhebung und Priorisierung mit MuSCoW EPIC (ITEM) EPIC (ITEM) EPIC (ITEM) EPIC (ITEM) MuSCoW Must Have ohne das funktioniert das System nicht Should Have Could Have Won t Have MuS EPIC (ITEM) EPIC (ITEM) User Story EPIC (ITEM) EPIC (ITEM) EPIC (ITEM) MuSCoW CoW EPIC (ITEM) EPIC (ITEM) MuS User EPIC Story (ITEM) MuSCoW CoW User EPIC Story (ITEM) Product Backlog -23-

24 Bestehende Spezifikationen: Needs, Epics und Stories extrahieren Product Backlog Miteinander reden statt Anforderungen - Verstehen - Gruppieren - Konsolidieren - Priorisieren - Abstimmen - Verlinken gegeneinander schreiben Quelle: mir leider unbekannt -24-

25 Die richtigen Fragen stellen: Das Sesamstrassen-Prinzip

27 Soruce: Source: Verantwortung des Product Owner PO Product Owner ist ein Full-time Job Product Backlog Fachliche Klärung der Backlog Items Wert des Produkts/ der Arbeit (ROI) Priorisierung und Reihenfolge der Backlog Items Abnahme der Produktinkremente Release Planung -27-

28 Soruce: Soruce: Source: Fähigkeiten des Product Owner Project Management Product Management Kommunikationsfähigkeiten PO Product Owner ist ein herausfordernder Job Fachliches Know How Technisches Know How Requirements Engineering -28-

29 PO -29-

30 Dem Product Owner gehört das Produkt Konflikte mit anderen Rollen Projektleiter Business Analyst Unternehmensführung Produkt Manager Produkt/ System Architekt UI-Spezialist Product Owner Marketing Anforderungsmanager -30- Vertrieb

31 Dem Product Owner gehört das Produkt Konflikte mit anderen Rollen Jede Rolle vertritt bestimmte Stakeholder und deren Anforderungen an das Produkt. Der Business Analyst beispielsweise trägt dafür die Verantwortung, dass das zu entwickelnde System die Geschäftsprozesse geeignet unterstützt. Theoretisch löst der Product Owner diese Rollen ab. Je nach Komplexität/ Größe des Produkts/ Systems oder Unternehmen hat der PO jedoch weder die Kapazität noch alle erforderlichen Fähigkeiten, um die Aufgaben all dieser Rollen zu übernehmen. Mögliche Lösungen könnten sein: - Die bestehenden Rollen arbeiten dem PO zu die Entscheidungskompetenz hat alleine der PO - Gibt es mehrere POs wird eine übergeordnete Instanz (z.b. Ein Chief-PO oder Meta-PO) eingesetzt -31-

32 Lösungsmöglichkeit: Die bestehenden Rollen als Stakeholder betrachten Requirements Engineering Product Owner Scrum Master Development Team Stakeholders Scrum Team -32-

33 Lösungsmöglichkeit: Der PO übernimmt die Aufgaben einzelner bestehender Rollen Alle Fähigkeiten im Team! Business Analyse Produktmanagement Projektmanagement Anforderungsmanagement UI-Design... Product Owner Scrum Master Development Team Scrum Team -33-

34 Lösungsmöglichkeit: Die bestehenden Rollen arbeiten dem PO zu Product Owner Scrum Master Development Team Team des PO Scrum Team -34-

35 Frage: Warum sind diese Rollen nicht Teil des Scrum Teams? Stichwort: Alle Fähigkeiten im Team z.b. BA, UI Product Owner Scrum Master Development Team Scrum Team -35-

36 Mehrere Product Owner Product Owner Product Owner Product Owner Architekt Chief Product Owner Viele Teams Viele Produkte/ Komponenten Viele Projekte Viele Kunden Fachliches und Technisches Know How Gesamtsystemverantwortung -36-

37 Strategie PO Pre-Planning Produktvision Architekturvision Sprint oder Release Velocity Product Owner Architekt PO Pre-Planning Abgestimmtes Backlog Velocity Velocity Product Owner Product Owner Chief Product Owner Abgleich der geplanten Backlog Items mit Strategie Konsolidierung Fachliche Abhängigkeiten Technische Abhängigkeiten Know How Transfer -37-

38 Planung RE Q1 Q2 Q3 Q4 Q1 Ziele /Needs Q3 Need A Need B Need C Features Q 2 Rollierende Planung und RE Feature A Feature B Storys Q1 User Story User Story -38-

39 Schätzung Budget* *Anmerkung aus Publikum: statt Budget von Investment sprechen Planung RE Schätzung Q1 Q2 Q3 Q4 Q1 Ziele/ Needs Q4 Need A Need B Management/ Kunde Need C Features Q3 Feature A Feature B Storys Q2 PO + Team User Story User Story -39-

41 Kontrolle versus Vertrauen 100% genaue Schätzung versus Budget Schätzungen werden teurer, aber nicht genauer Puffer wird eingebaut -41-

42 Kontrolle versus Vertrauen Push versus Pull Puffer wird eingebaut -42-

43 Kontrolle versus Vertrauen Geleistete Stunden versus Ergebnis/ erzielter Business Value Fortschritt nicht erkennbar Keine verlässlichen Daten für Folgeprojekte Es wird so rapportiert, dass die Summe stimmt -43-

44 Kontrolle versus Vertrauen Kennzahlen versus Team Einschätzung Das Team wird sich so verhalten, dass es die Kennzahlen erfüllt unabhängig vom Produkterfolg -44-

45 Kontrolle versus Vertrauen Lösung versus Ziele/ Problem Es wird nicht nach der besten Lösung gesucht -45-

46 Kontrolle versus Vertrauen Spezifikation statt Gespräch Keine Zusammenarbeit Kein Know-How Transfer -46-

47 Das Management ist gefragt! Strategie: Langfristig Produktvision Die Architekturvision ergänzt die Produktvision Leitplanken: kurz- und mittelfristig Was sind unsere kritischen Erfolgsfaktoren? z.b. Qualität verbessern Kundenzufriedenheit erhöhen Kosten senken Prioritäten und Reihenfolge der aller Tätigkeiten in den Teams Architekturentscheidungen Vision und Leitplanken liefern uns Orientierung für die Verteilung der Budgets, die Priorisierung und die Umsetzung -47-

48 Beispiele für weitere Erfolgsfaktoren (Business Driver) Kosten Qualitätsverbesserung Innovative Funktionen Risikobewertung Wettbewerbsvorteil Gewinnmaximierung Produktstabilität Kundenzufriedenheit ROI Kosteneinsparungen Personalaufwand Wachstumschancen First to market Opportunitätskosten Kosten bei Nicht-Umsetzung Kosten bei zu später Umsetzung Wunschhäufigkeit von Stakeholdern -48-

49 Priorisierung messbar machen (Beispiel mit ROI) Business Value Priorität = = ROI Aufwand (Kosten) User Stories ( ) Business Value/ Kosten bei Nichterfüllung Aufwand (Schätzung) ROI Reihenfolge User Story ,23 3 User Story User Story ,6 2 User Story ,

50 Transparenz schaffen: Planung der User Storys als White-Box Product Backlog Geplant für den Sprint Burndown Chart für User Stories -50-

51 Planung der s als Black-Box Product Backlog Geplant für den Sprint Sprint als Black Box Selbstorganisierendes Team Potentiell lieferbares Produktinkrement -51-

52 Ranking Physisches Board OPEN IN WORK DONE Committed Defined Completed User Story User Story Die wichtigste Story soll als erstes fertiggestellt werden User Story -52-

53 Physisches Board OPEN IN WORK DONE Committed Defined Completed User Story Neuer Neuer Neuer Neuer User Story User Story Bei Sprint Planning wurden s vergessen Commitment gefährdet? -53-

54 Physisches Board OPEN Committed Defined IN WORK DONE Completed User Story User Story Alles angefangen nichts fertig User Story -54-

55 Physisches Board OPEN Committed Defined IN WORK DONE Completed User Story User Story User Story -55-

56 Selbsteinschätzung des Teams: vom Team, PO, Stakeholder Mögliche Indikatoren: - Liefertreue - Kundenfokus - Transparenz - Flexibilität - Agile Werte - Scrum Regeln - Disziplin

57 Machen Sie noch Anforderungsmanagement oder sind Sie schon READY for Scrum? Fazit -57-

58 Requirements Engineering Sprint im Agilen Umfeld Verstehen Vereinbaren Sicherstellen Erheben Scope Vision Ziel Visualisieren Konversation Stakeholder Sprintziel Handschlag MMP DoD Akzeptanzkriterien Commitment Fokus auf Value potentially Shippable User Stories Retro Automatisierung Doku Review frühes Feedback Traceability Akzeptanzkriterien -58-

59 Ob agil oder konventionell Kontinuierliche Verbesserungen sind besser als hinausgezögerte Vervollkommnung - Mark Twain

60 Vielen Dank! Susanne Mühlbauer HOOD GmbH Büro München Keltenring Oberhaching Germany Tel: