Gute User Stories schreiben reicht nicht Requirements … · 2019-01-29 · Product Owner. Public...

Gute User Stories schreiben reicht nicht

Requirements Engineering-Bedarf in agilen Projekten

Olga Boruszewski, 23.11.2017

http://www.continental.de Tires Division

Public

Agile Requirements Engineering

› Erfahrungsbericht zu Requirements Engineering in agilem Projekt

› Ziele:

› Zeige Praxis-Herausforderungen auf

› Tausche Erfahrungen und Lösungsideen aus

› Kontext:

› Interne IT-Abteilung: Software für Fachabteilungen der Reifen-F&E

› Projekt: Führe Aktivitäts-Management-Software ein

› Konsolidiere 5 Business Units (d.h. Identifiziere Gemeinsamkeiten und Unterschiede)

› Je bis zu 9 Haupt-Nutzergruppen (Rollen / Abteilungen)

› ~ 330 User Stories

Einführung

23 November 2017

2Olga Boruszewski, © Continental AG

Public


Scrum und Requirements Engineering

23 November 2017


Definiere &

Priorisiere

User Stories

Validiere

Software

Implementiere

User Stories

Teste

Software

US 01

US 02

US 03

EntwicklerProduct

Owner

Public


Scrum und Requirements Engineering

23 November 2017


Definiere &

Priorisiere

User Stories

Validiere

Software

Implementiere

User Stories

Teste

Software

US 01

US 02

US 03

Entwickler

User-

Vertreter

Management

Rückkopplung

in Fachbereich

Prozess

Steuere

User Story

Erstellung &

Validierung

US 11

US 12

US 13US 21

US 22

US 23

Scope

Prio 1

Prio 2

Prio ...

Out of Scope

US 23

US 8

US 33

US 11

US 5US 14

US 2

US 9

US 19

US 30

US 6US 17

Abstimmung

Scope, Prio,

Rahmen-

bedingungen

Binde

User-Vertreter

ein

Product

Owner

Public


› Benötigt Struktur, in der Stakeholder selbständig

arbeiten können

› Herausforderungen:

› Stelle für Stakeholder genau richtige Menge an

Infos bereit (alles, was über den Kontext

bekannt sein muss)

› Backlog für einzelne Stakeholder zu komplex

› Zusammenhänge zwischen Rollen darstellen

› Effektive Aufspaltung zwischen Ausbaustufen

(rudimentär vs. vollumfänglich)

1. Einbeziehung der Stakeholder in Definition und Abnahme der User Stories

5

23 November 2017

Olga Boruszewski, © Continental AG

Backlog

US 13

US 13

US 13

US 13

US 13

US 13

Wohin?

Vollständig?

Abhängige Stories?

User-

Vertreter

US 11

US 12

US 13

US 21

US 22

US 23

Product

Owner

Public


Lösungsansatz: User Story Map statt eindimensionalem Backlog

1. Einbeziehung der Stakeholder in Definition und Abnahme der User Stories

23 November 2017


Epic 04

Actors: Launch

Manager, Engineer

Epic 01

Actor: Group

Leader

US 05

US 11

US 01

US 08

US 12

US 04

Epic 07

Actor: Engineer

US 09

US 17

Release 01

Release 02

Release 03

Launch Manager

US 11

US 12

US 13

US 21

US 22

US 23

Interaktion, die Mehrwert

für Akteur bringt

(3-5 pro Nutzergruppe)

Teil-Interaktion, die für den

Epic notwendig ist

(5 – 20 pro Epic)

Ausbaustufen auf Releases

aufgeteilt und im Epic

gebündelt

Offen:

Granularitätssprünge

Darstellung von

Abhängigkeiten schwierig in

User Story-Form

Tire

Engineer

Vorteile:

Gute Struktur und Filterung für

Stakeholder

Public



› Stelle rechtzeitige Anforderungs-Definition und –Abnahme sicher

2. Steuerung des RE-Prozesses

23 November 2017


Public


Lösungsansatz: Verwende Scrum-Framework für Requirements-Erstellung & Validierung

2. Steuerung des RE-Prozesses

23 November 2017


Business Concept

Sprint

Velocity: 15

Implementation

Sprint

Velocity: 20

US 03

Vorbereitung

DefinitionImplementierung

Test

Validierung &

Einarbeitung Feedback

Abnahme

Meeting:Concept Sprint

Planning

Meeting:Sprint Planning

US 03

Geplante Lösung

Business Concept Effort:

5

Business Owner: Müller

US 02

Geplante Lösung


5


US 01

Geplante Lösung

Business Concept Effort: 5

Business Owner: MüllerUS 02

US 01

Offen:

RE-Aufwand schätzen

Zwei synchronisierte Sprints

vs. ein langer Sprint?

Vorteile:

Messbarkeit und Struktur für

indirekte Scrum-Teilnehmer

Entkopplung von “Korrektur”

und neuer User Story

Public


› Abstimmung Scope & Prio mit Management & User-Vertretern

› Berücksichtigung von Rahmenbedingungen, wie Prozess, Applikationslandschaft


› Passende Anforderungsartefakte benötigt

› Abhängigkeiten zwischen verschiedenen Anforderungsartefakten verstehen

3. Erarbeitung des Rahmens für User Stories

23 November 2017


Public


Lösungsansatz: Verwende mehrere Artefakte & verlinke diese [1]. Hier: auf Epic-Ebene


23 November 2017


Prozess

Epic 04Epic 01

US 05

US 11

US 01

US 08

US 12

US 04

Epic 07

US 09

US 17

[1] O. Boruszewski: Unterstützung der Koexistenz von agilen und traditionellen Anforderungsartefakten. epubli, 2016.

Vorteile:

Immer richtiges Artefakt zur

Kommunikation zur Hand

Guter Grad an Vorarbeit

Offen:

Nur Verlinkung von

Artefakten reicht nicht.

Inhalte müssen geknetet

werden

Public


Lösungsansatz: „Big Picture“ & Releases für Scope & Prio


23 November 2017


Offen:

Ewige Epics vs. viele

Elemente

Vorteile:

Wichtige Stichworte auf einen

Blick machen Kommunikation

effektiver

Public



› Mehr Freiheitsgrade, als nur Umsetzung

› Gewünschte Interaktion unterstützen?

› Anpassung der Interaktion?

› Anpassung des Geschäftsprozesses?

4. Rückkopplung ins Unternehmen

23 November 2017


Public


Lösungsansatz:

› Outcome aus Concept Planning und Validierung

› Verknüpfung mit Epics

4. Rückkopplung ins Unternehmen

23 November 2017


Business Concept

Sprint

US 03

Definition

Validierung &

Einarbeitung Feedback

US 03

Geplante Lösung


5


US 02

Geplante Lösung


5


US 01

Geplante Lösung

Business Concept Effort: 5

Business Owner: Müller US 02US 01

Change Management

Maßnahmen

Prozess Meeting:Concept Sprint

Planning

Vorbereitung

Offen:

Unterstützung des

Entscheidungsprozesses

-> Viele Rückkopplungen

brauchen Zeit

Public


› Viele Herausforderungen

› Toolbox an RE-Methoden benötigt

› Spannungsfeld zwischen Summierung von Methoden und Einfachheit

Zusammenfassung

23 November 2017


Public


Fragen?

23 November 2017


Definiere &

Priorisiere

User Stories

Validiere

Software

Implementiere

User Stories

Teste

Software

US 01

US 02

US 03

Entwickler

User-

Vertreter

Management

Rückkopplung

in Fachbereich

Prozess

Steuere

User Story

Erstellung &

Validierung

US

11US

12

US

13US

21

US

22

US

23

Scope

Prio 1

Prio 2

Prio ...

Out of Scope

US

23US 8

US

33 US

11

US 5US

14

US 2

US 9

US

19

US

30

US 6US

17

Abstimmung

Scope, Prio,

Rahmen-

bedingungen

Binde

User-Vertreter

ein

Product

Owner

Offen:

Unterstützung des

Entscheidungsprozesses

-> Viele Rückkopplungen

brauchen Zeit

Offen:

Ewige Epics

vs. viele

Elemente

Offen:

Nur Verlinkung von

Artefakten reicht

nicht. Inhalte müssen

geknetet werden

Offen:

RE-Aufwand schätzen

Zwei synchronisierte Sprints

vs. ein langer Sprint?

Offen:

Granularitätssprünge

Darstellung von

Abhängigkeiten schwierig

in User Story-Form

Gute User Stories schreiben reicht nicht Requirements … · 2019-01-29 · Product Owner. Public...

Documents

Transcript of Gute User Stories schreiben reicht nicht Requirements … · 2019-01-29 · Product Owner. Public...