Product Canvas & Agiles RE

Transkript

1 Product Canvas & Agiles RE Der Werkzeugkasten für die Tools des Agilen Requirements Engineers Tools 4 Agile Teams 06. November 2014

2 Product Canvas Werkzeugkasten und Tools für den Agilen Requirements Engineer Tools 4 Agile Teams 06. November 2014

3 3 Agenda Agiles Requirements Engineering Business Model Canvas Werkzeugkasten Product Canvas Produktvision Rollen, Personas und Szenarien User Stories & Epics Design-Entwürfe & Nichtfunktionale Anforderungen 2014 andrena 2014 andrena objects objects ag ag

4 4 Weitere Werkzeuge Specification by Example / Automatisierte Akzeptanztests Refinement & Product Backlog Zerlegen von User Stories Agiles Schätzen Priorisieren Story Map Velocity & Release Planung Impact Mapping 2014 andrena 2014 andrena objects objects ag ag

5 5 Agile Requirements Engineering

6 6 Was ist Requirements Engineering (RE) ein systematischer und disziplinierter Ansatz zur Spezifikation und zum Management von Anforderungen mit den folgenden Zielen: 1. Die relevanten Anforderungen zu kennen, Konsens unter den Stakeholdern über die Anforderungen herzustellen, die Anforderungen konform zu vorgegebenen Standards zu dokumentieren und die Anforderungen systematisch zu managen. 2. Die Wünsche und Bedürfnisse der Stakeholder zu verstehen, zu dokumentieren sowie die Anforderungen zu spezifizieren und zu managen, um das Risiko zu minimieren, dass das System nicht den Wünschen und Bedürfnissen der Stakeholder entspricht. Definition: International Requirements Engineering Board (IREB)

7 7 Agilitätsdreieck

8 8 Prinzipien hinter dem Agilen Manifest 1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. 2. Anforderungsänderungen selbst spät in der Entwicklung willkommen heißen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. 6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

9 Das Projektmanagementdreieck Vom planbasierten zum nutzwertbasierten Ansatz Kosten Umfang Planbasiert Dauer Kosten festgelegt geschätzt Wertbasiert Umfang (durch Priorisierung) Dauer Nach: Dean Leffingwell: Agile Software Requirements

10 10 Empirischer bzw. agiler Ansatz Iterativ, inkrementell, Just in Time. Überprüfen und Anpassen, Selbstorganisation Scrum 1 Tag SPRINT 30 Tage Product Increment Product Backlog Sprint Backlog

11 12 Agile Requirements Engineering was muss es leisten? Wert-/Nutzenorientierung Iterativ und inkrementell Anforderungen Just-in-time Direkte Kommunikation

12 14 Werkzeuge des Agilen RE

13 15 Business Model Canvas

14 16 Business Model Geschäftsmodelle beschreiben, wie eine Organisation bzw. ein Unternehmen Mehrwert für Kunden erzeugt und einen Ertrag für die Organisation sichern kann. Geschäftsmodelle helfen, die Schlüsselfaktoren des Unternehmenserfolges oder -misserfolges zu verstehen, zu analysieren und zu kommunizieren.

15 17 Business Model Canvas Eine Methode zur Visualisierungen von Geschäftsmodellen Erarbeitung eines Geschäftsmodells für eine Firma, ein Produkt oder einen Service. Strukturierung der wesentlichen Fragen eines Geschäftsmodells und seiner Abhängigkeiten. Konzentration auf die Stärken und damit den Wert, der sich mit dem Geschäftsmodell generieren lässt.

16 18 Business Model Canvas Erleichtert die Erfassung gesamter Geschäftsmodelle Hilft dabei, stillschweigende Annahmen in eindeutige Informationen zu verwandeln. Geschäftsideen werden greifbar und erlauben eine zielführende, klare Diskussion und Anpassungen. Die Visualisierung haucht jedem Geschäftsmodell Leben ein und erleichtert die gemeinsame Ideenfindung.

17 19 Quelle:

18 20

19 21

20 22

21 23

22 24

23 25 Produktidee (Beispiel): Shirt-Creator Firma verkauft bereits T-Shirts, Polo-Shirts, Bisher werden nur feste Varianten davon angeboten Idee: Individuell konfigurierbare Varianten (bedruckbar) Personalisierte, qualitativ hochwertige Shirts Konfigurator für die Bestellseite

24 26 Product Canvas

25 28 Produktplanung: Von der Erhebung bis zur Umsetzung Vision Übergeordnete Ziele Sprintplan (Taktik) Personas & Szenarien Releaseplan (Strategie) Epen & User Stories Refinement Product Backlog

26 32 Das Product Canvas Name Zielgruppe: Rollen Personas Vision / Ziel Big Picture : Szenarien Epen / User Stories Design-Skizzen Einschränkungen / NFAs Metriken Product Details: Sprintziele Ready Stories

27 34 Produktvision

28 35 Produkt Vision Kurz und prägnant Emotional und mitreißend Sichtbar als Text oder Bild Vision Für wen? Was? Wie? Besser als?

29 36 Elevator Pitch

30 37 Vision (Beispiel) Mit dem Shirt-Creator können modebewusste Individualisten mit selbstgestalteten hochwertigen Shirts auffallen. Kunde: Reseller, Designer, Individualisten Bedarf: hochwertiges individuelles Kleidungsstück Hauptvorteil: Kleinserien für Designer Produkt: Bedrucken von Shirts für alle über die Bestellplattform für jeden zugänglich machen.

31 38 Formulierung einer Vision Für Kunde die Beschreibung des Bedarfs ist das Produktname eine Produktkategorie, die Hauptvorteil, Grund dieses Produkt zu kaufen; anders als Alternative des Wettbewerbs kann unser Produkt Beschreibung des Hauptunterschieds.

32 39 Vision (Beispiel) Für Reseller, Designer und Individualisten, die sich nach hochwertigen individuellen Kleidungsstücken sehnen, ist der Shirt- Creator ein Produktkonfigurator, der es modebewussten Individualisten gestattet, mit selbstgestalteten hochwertigen Shirts aufzufallen. Im Gegensatz zu vergleichbaren Angeboten steht der Shirt Creator Resellern zur Verfügung und gestattet neben der Auswahl vorgefertigter auch die Verwendung und Bereitstellung selbst erstellter Motive.

33 40 Rollen & Personas

34 41 Stakeholder Stakeholder sind alle Menschen, die von Entwicklung, Einsatz und Betrieb des Systems betroffen sind (Projektbetroffene) Alle mit Einfluss auf die Anforderungen Anforderungen/Bedürfnisse aus Nutzersicht Kundennutzen (in den Nutzer hineinversetzen) Ein vergessener Stakeholder ist eine vergessene Anforderung Stakeholder identifizieren und mit ihren Rollen dokumentieren

35 42 Rollen (Beispiele) Kunden Händler Admin Bestandskunde Neukunde Reseller Auftragsbearbeitung Marketing Designer Support

36 43 Personas Personas sind am lebenden Menschen orientierte, imaginierte Personen, die unsere Produkte benutzen. Sie stehen stellvertretend für Mitglieder realer Nutzergruppen. Sie erhalten fiktive, persönliche Eigenschaften. Sind wirklickkeitsnah.

37 44 Personas Personas leisten einen wichtigen Beitrag zum besseren Verständnis der Nutzer-Anforderungen. Sie helfen, sich in die Situation der Nutzer zu versetzen. Sie fokussieren die Entwicklungsarbeiten auf die Ziele und Bedürfnisse der Nutzer (statt auf die der Projektentscheider, oder auf technische Restriktionen).

38 45 Vorlage einer Persona Name Beruf und Position im Unternehmen Erscheinungsbild (Foto bzw. Avatar/Skizze oder Beschreibung) Berufserfahrung Tägliche Aufgaben (auch außerhalb der Applikation) Vorlieben und Hobbys, Abneigungen Ziele

39 46 Persona (Beispiel) Lisa 33 Jahre, weiblich Alternativ, qualitätsbewusst Keine Lust auf Standardmode Kreativ: Basteln, Einrichten, Beruf: Marketing Familie, 1 Kind Ich wünsche mit die Möglichkeit, eigene Shirts zu gestalten. Ideen dazu entwickle ich selbst und meide Standardmode.

40 47 Rollen und Personas Keine allgemeinen Begriffe wie Nutzer oder Kunde. Möglichst konkret: Konkretes Individum Persona Rolle oder Jobtitel Gruppe oder Abteilung

41 48 Szenarien

42 49 Szenarien Realistisches Beispiel, wie ein Benutzer mit dem geplanten System interagieren wird. Einfache Sätze beschreiben einen konkreten Ablauf aus Benutzersicht. Inhaltlich richtige Aussagen sind wichtiger als formale Korrektheit.

43 50 Szenarien Motivation: den Benutzer verstehen. Szenarien können iterativ oder zusammen mit den Benutzer erarbeitet werden. Die Reflektion am konkreten Beispiel erlaubt es Auftraggebern und Benutzern, Anforderungen in der konkreten Anwendungssituation zu vergegenwärtigen, zu überprüfen und zu ergänzen. Gute Grundlage für den Entwurf von User Stories.

44 51 Szenarien (Beispiel) Lisa, individuelles Shirt erstellen 20:00 Uhr Abends, Lisa ist zu Hause und surft im Internet Lisa hat eine gute Idee für ein individuelles Shirt Sie ruft den Shop auf und sucht sich mehrere Shirts aus Ihr Design lädt sie im Shirt-Creator hoch und betrachtet sich ihre Shirt- Modelle Sie wählt ein Shirt aus und legt es in den Warenkorb, um es zu kaufen Zwei Tage später wird ihr das Poloshirt nach Hause geliefert

45 52 Weitere Darstellungsformen für Szenarien Workflow Ereignisgesteuerte Prozesskette (EPK) Use Case

46 53 User Stories

47 54 Begrifflichkeiten Verschiedene Begriffe werden üblicherweise genutzt, um den relativen Umfang einer Anforderung zu beschreiben Die Verwendung ist nicht einheitlich geregelt Epic bzw. Epos Thema / Feature User Story Task

48 55 Epics / grobe User Stories (Beispiele) Lisa möchte individuelle Shirts erstellen können Als Designer möchte ich meine Designs anderen Benutzern zur kostenpflichtigen Nutzung bereitstellen können. Als Kunde möchte ich Unterstützung bei der Text- bzw. Bildgestaltung der Poloshirts (z.b. Transparenz, Farbgestaltung, ). Als Shop-Betreiber möchte ich Auswertungen über die Anwendung haben, damit ich die Kundenwünsche besser erfüllen kann.

49 56 User Story: Definition Eine User Story beschreibt eine Funktionalität, die entweder für einen User oder Käufer [ ] von Wert ist. Mike Cohn, User Stories applied

50 57 Format einer User Story Wer macht was, warum? Als will ich so dass Benutzerrolle das Ziel Grund für das Ziel

51 58 User Stories (Beispiele) Als Kunde Lisa möchte ich eine Vorschau angezeigt bekommen, damit ich einen Eindruck des Poloshirts erhalte. Der Käufer möchte hochgeladene Designs speichern können, damit diese später wiederverwendet werden können.

52 59 Vorteil von User Stories Beim Schreiben von User Stories nehmen wir bewusst die Sichtweise des Nutzers bzw. Kunden ein. Jede User Story zielt darauf ab, den Nutzer bzw. Kunden zufriedener zu machen.

53 61 Card, Conversation, Confirmation User Stories bedeuten, miteinander zu sprechen und zu wissen, wann ein Anforderung umgesetzt ist. Conversation & Confirmation Product Owner Team

54 63 Confirmation durch Akzeptanzkriterien Überprüfbare Anforderungen Gemeinsam erstellt vom Scrum-Team und den Stakeholdern Legen fest, ob ein Feature fertig umgesetzt ist Bilden die Basis für Akzeptanztests

55 64 Akzeptanzkriterien (Beispiele) Als Kunde möchte ich Bilder hochladen, um diese in meinen Designs zu verwenden. Akzeptanzkriterien: Der Kunde kann ein Bild auswählen und hochladen. Die Webshop zeigt das hochgeladene Bild in der Liste verfügbarer Bilder für Designs an. Wählt ein Kunde ein anderes Format als JPG und PNG aus, wird eine Fehlermeldung angezeigt. Bei Dateien größer als 2 MB wird eine Fehlermeldung angezeigt.

56 66 Akzeptanztest Ein Akzeptanztest ist ein Ablauf, wie die Akzeptanzkriterien überprüft werden kann. Besteht aus: Vorbedingungen Ablauf eines Szenarios / Beispiels Nachbedingungen bzw. erwartetes Ergebnis

57 67 Akzeptanztest (Beispiel) Als Kunde möchte ich Bilder hochladen, um diese in meinen Designs zu verwenden. Akzeptanztest: Vorbedingung: Bild test.png auf Kundenrechner 1. Der Kunde wählt Bild hochladen. 2. Der Browser öffnet den Dateiauswahldialog. 3. Der Kunde wählt Bild test.png aus und wählt Öffnen 4. Der Webshop lädt das ausgewählte Bild hoch. Nachbedingung: Der Webshop zeigt das hochgeladene Bild in der Liste verfügbarer Bilder für Designs an.

58 69 User Stories in Kürze De-facto Standard für agiles Anforderungsmanagement Kurze Beschreibung der Anforderung aus Benutzersicht Details werden per Konversation ausgearbeitet und in den Akzeptanzkriterien festgehalten

59 70 Design-Entwürfe

60 71 Design-Entwürfe Skizzen Wireframes / Mockups Ablaufbäume/ -diagramme

61 72 Nichtfunktionale Anforderungen

62 73 Nicht funktionale Anforderungen (NFA) Performance Sicherheit Wartbarkeit Wiederverwendbarkeit Verfügbarkeit Datenschutz

63 74 Definition of Done Sorgt für ein gemeinsames Verständnis, ob eine Arbeit abgeschlossen ist. Was muss alles getan werden, damit eine Story als fertig angesehen wird? Done Es ist nichts mehr zu tun!

64 76 Das Product Canvas Name Zielgruppe: Rollen Personas Vision / Ziel Big Picture : Szenarien Epen / User Stories Design-Skizzen Einschränkungen / NFAs Metriken Product Details: Sprintziele Ready Stories

65 77 Anforderungsworkshop mit Product Canvas

66 78 Weitere Werkzeuge

67 79 Specification by Example

68 80 Häufige Probleme Anforderungen sind unklar oder mehrdeutig Anwender und Entwickler sprechen unterschiedliche Sprachen Domänen-Experten können keine Unit Tests schreiben bzw. überprüfen Die Dokumentation ist bei Änderungen am Produkt nicht mehr aktuell

69 81 Idee Konkrete Beispiele beschreiben das Verhalten Gemeinsame domänenspezifische Sprache verbessert die Kommunikation Ausführbare Beispiele als Lebende Dokumentation

70 82 Specification by Example Beispiele erzeugen Tests beschreiben prüfen Anforderungen Quelle: Gojko Adzic

71 83 Vorteile Bessere Zusammenarbeit der verschiedenen Rollen Besseres gemeinsames Verständnis der Anforderungen Automatisiertes Testen der fachlichen Anforderungen möglich Dokumentation passt zum Produkt (Living Documentation)

72 84 Quelle: Specification by Example: How Successful Teams Deliver the Right Software, Gojko Adzic

73 85 Spezifikation mit Beispielen 1. Use Context: Als ein _ will ich, _ so dass _ 2. Allgemeine Regeln des Features 3. Beispiele zu den Regeln Präzise, testbar, selbsterklärend Geschäftsfunktionalität, in Domänensprache Was, nicht Wie Weitere Fälle lassen sich ableiten Given - When - Then Sprache

74 86 Automatisierte Akzeptanztests

78 91 Werkzeuge für die Automatisierung

79 92 Selenium Tests

80 93 Product Backlog

81 94 Product Backlog Enthält alle Anforderungen (Backlog Items) Geordnet und geschätzt Grundlage für die Releaseplanung Kommunikationsgrundlage Verantwortet durch Product Owner 1 Tag SPRINT 30 Tage Product Increment Product Backlog Sprint Backlog

82 95 Eisberg der Anforderungen als nächstes umsetzen Priorität danach umsetzen später umsetzen

83 96 Refinement

84 97 Refinement Als Verfeinerung [Refinement] des Product Backlogs wird der Vorgang angesehen, in dem Details zu Einträgen hinzugefügt, Schätzungen erstellt, oder die Reihenfolge der Einträge im Product Backlog bestimmt werden. Die Verfeinerung ist ein kontinuierlicher Prozess, in dem der Product Owner und das Entwicklungsteam gemeinsam die Product Backlog-Einträge detaillieren. (Scrum Guide)

85 98 Refinement Product Backlog Überprüfen Überarbeiten Priorisieren Product Backlog Items Analysieren & Klären Zerlegen Schätzen Die Verfeinerung des Product Backlog ist ein kontinuierlicher Prozess. Das Entwicklungsteam wendet dafür bis zu 10% der Sprintzeit auf.

86 99 Iterative Detailierung Aktueller Sprint Nächster Sprint Nächster nächster Sprint Sprint 4-8 UserStory UserStory UserStory UserStory UserStory UserStory UserStory UserStory UserStory UserStory UserStory Spike UserStory UserStory UserStory UserStory UserStory UserStory UserStory UserStory UserStory. PO clarification UserStory UserStory UserStory UserStory UserStory

87 101 Refinements - Ziele Kleine und gut verstandene Backlog Items für die nächsten Sprints ( Ready ) Verstandene Backlog Items bis zum nächsten Release Geschätztes und geordnetes Backlog Entwickeln und Anpassen des Release Plans

88 104 Zerlegen von User Stories

89 105 Gründe für das Zerlegen User Stories müssen in einem Sprint fertigzustellen sein. Kleinere User Stories lassen sich besser schätzen. Kleinere User Stories gestatten eine detailliertere Priorisierung.

90 107 Zerlegen von User Stories Etablierte Muster für das Zerlegen von User Stories 1. Workflow-Schritte 2. Variation der Geschäftsregeln 3. Größter Aufwand 4. Komplexität 5. Datenvariation 6. Schnittstellenvariation 7. Nachlagern von NFRs 8. Operationen 9. Spike herausbrechen

91 118 Praxistipps Geeignete Methode zum Zerlegen verwenden In wichtigere und weniger wichtige User Stories zerlegen Stories nicht in Taskgröße zerlegen Ein Spike ist die letzte Möglichkeit Stories in einem Sprint umsetzbar Stories besser schätzbar Detaillierter zu priorisieren

92 119 Agiles Schätzen

93 120 Agiles Schätzen Nur eine Schätzung! Entwicklungsteam schätzt Schätzen der Größe Abstrakte Einheit: Story Points S M L Relatives Schätzen (Referenz) Nichtlineare Skala: 1, 2, 3, 5, 8, 13, 20, 40, 100

94 124 Magic Estimation Schätzwerte ausgelegt Keine Kommunikation! Reihum: 1. Neue Story nehmen & auslegen (schätzen) 2. Oder Story umlegen Mehrfach umgelegte Stories raus

95 126 Planning Poker Jeder Planning-Pokerkarten Diskussion der User Story Jeder wählt eine Karte Karten gleichzeitig aufdecken Unterschiede diskutieren Dann ggf. erneut schätzen

96 128 Priorisieren

97 129 Mögliche Einflüsse auf die Priorisierung Aufwand Nutzen, Geschäftswert Risiko (z.b. Risikomatrix) Abhängigkeiten Cost of Delay (COD) (Kosten einer späteren Umsetzung)

98 130 Priorisierungsmöglichkeiten Kano-Modell (siehe nächste Folie) Rangliste / Direkter Vergleich Sortierung / Ping-Pong-Bälle Bauchgefühl MVP (Minimum Viable Product)

99 131 Kano-Modell Zufriedenheit Kreativitätstechniken Begeisterungsfaktoren Leistungsfaktoren Erfüllungsgrad Beobachtung Basisfaktoren

100 132 Story Map

101 Priorität 133 Story Map Rückgrat Lauffähiges Gerippe R1 R2 R3 Zeit [1]

102 134 Story Map (Beispiele)

103 135

104 136 Releaseplanung

105 137 Release Planning Backlog Ein guter Releaseplan erfordert ein geordnetes und geschätztes Backlog. Velocity Ein guter Releaseplan erfordert eine bekannte Velocity.

106 138 Basistypen der Release Planung Date Target Planning Das Produkt wird zu einem bestimmten Datum released. Wie viel des Product Backlog wird an einem bestimmten Datum fertig sein? Feature Target Planning Das Produkt wird released, wenn bestimmte Features fertig sind. Wann wird Feature A, B und C fertig sein?

107 140 Velocity Die Velocity beschreibt die Geschwindigkeit, mit der das Entwicklungsteam Product Backlog Items pro Sprint abarbeitet.

108 Story Points 141 Planung mit Velocity Sprint Bester Fall: Top 3 => Ø 23 Wahrscheinlichster Fall: Mittlere 3 Ø 19 Schlechtester Fall: Unterste 3 Ø 14

109 143 Product Backlog Größe: 13 Größe: 20 Größe: 20 Größe: 3 Größe: 5 Größe: 1 Größe: 8 Größe: 13 Größe: 3 Größe: 13 Größe: 3 A 6 Wochen Wann wird Feature A wahrscheinlich geliefert? Mittlere Team Velocity = 32 Sprint Länge= 2 Wochen

110 144 Product Backlog Größe: 13 Größe: 1 Größe: 2 Größe: 8 Größe: 5 Größe: 13 Größe: 3 Größe: 13 Größe: 5 Größe: 8 Größe: 2 Das Alles Was wird in 8 Wochen alles geliefert? Mittlere Team Velocity = 16 Sprint Länge= 2 Wochen

111 145 Release Burndown Features Heute Fertigstellung Velocity: tatsächliche beste durchschnittliche schlechteste Zeit

112 146 Impact Mapping

113 148 Impact Map Gemeinsam erstellt von Fachabteilung und Entwicklung Mind-Map aus der Diskussion um die vier Fragen Warum? Wer? Wie? Was? Visualisierung von Scope und zugrundeliegenden Annahmen Annahmen tranparent machen und in Frage stellen Ausrichtung aller Aktivitäten auf die Business Ziele Bessere strategische Planung

114 150 Aufbau einer Impact Map Ziel Person Effekt Feature Wie? Was? Wer? Wie? Warum? Wer? Wie? Was? Wie?

115 Agile Requirements 151 Engineering Warum? Wer? Wie? Was? Quelle: andrena objects ag

116 154 Ziel Person Effekt Feature Impact Map (Beispiel) Für Freunde bestellen Mehrere Adressen Geschenkverpackung Kunde Größere Bestellungen Mengenrabatt Shirt Verkauf verdoppeln Spontankäufe Top 10 Designs anpreisen Rabatt-Aktion Designer Designs für Freunde Eigene Designs teilen

117 155 Impact Map Alles unterstützt das Ziel! (wenn die Annahmen stimmen) Mapping von Features auf Ziele Scope und Annahmen visualisiert Überprüfen der Annahmen möglich Konzentrieren auf einzelne Zweige möglich

118 157 Zusammenfassung Agiles Requirements Engineering Business Model Canvas Werkzeugkasten Product Canvas Produktvision Rollen und Personas Szenarien User Stories & Epics Design-Entwürfe Nichtfunktionale Anforderungen Weitere Werkzeuge Specification by Example / Automatisierte Akzeptanztests Refinement & Product Backlog Zerlegen von User Stories Agiles Schätzen Priorisieren Story Map Velocity & Release Planung Impact Mapping 2014 andrena 2014 andrena objects objects ag ag

119 158 Danke

120 159 Hauptsitz Karlsruhe Albert-Nestler-Straße 11 D Karlsruhe Tel. +49 (0) Fax +49 (0) Weitere Standorte: Frankfurt München Stuttgart

121 160 Zusammenfassung Agiles Requirements Engineering Business Model Canvas Werkzeugkasten Product Canvas Produktvision Rollen und Personas Szenarien User Stories & Epics Design-Entwürfe Nichtfunktionale Anforderungen Weitere Werkzeuge Specification by Example / Automatisierte Akzeptanztests Refinement & Product Backlog Zerlegen von User Stories Agiles Schätzen Priorisieren Story Map Velocity & Release Planung Impact Mapping 2014 andrena 2014 andrena objects objects ag ag