Requirements Engineering in einer agilen Umgebung – Waste oder Value?

Susanne Mühlbauer, HOOD GmbH

November 2012

HOOD GmbH

Keltenring 7

82041 Oberhaching

www.HOOD-Group.com

© HOOD GmbH

Unser Geschäftsfeld

-2-

Wir liefern unseren Kunden das Rüstzeug für die erfolgreiche Entwicklung komplexer

Produkte, Dienstleistungen und Systeme durch Training, Beratung und Coaching.

Unsere Kernkompetenz ist das Requirements Engineering mit all seinen

Schnittstellen im Systems und Software Engineering.

© HOOD GmbH

HOOD- Excellence

-3-

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:

http://blog.hood-goup.com

Unsere Konferenzen, Publikationen, Expertentalk

REConf®

HOOD ist der Veranstalter von

Europas größter RE-Konferenz

© HOOD GmbH

HOOD Portfolio

-4-

© HOOD GmbH -5-

Scrum und der Product

Owner

Wasteful und

valuable RE

Fazit

Was ist RE? Was ist Agile?

© HOOD GmbH

Requirements Engineering

-6-

Copyright © 2012 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechte

vorbehalten. Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der

HOOD Group verboten.

Verstehen Vereinbaren Sicherstellen

Was möchte der Kunde? Wie vereinbaren wir das? Wie stelle ich sicher, dass er das bekommt?

Agile

-7-

Agile

Prinzipien

Agile Werte

Praktiken z.B. Scrum, XP, Crystal,…

Das

agile

Manifest

Scrum Guide

© HOOD GmbH

Die Ideallinie für RE im agilen Umfeld finden!

-8-

Copyright © 2012 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechte

vorbehalten. Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der

HOOD Group verboten.

Konversation

Just-in-Time

Value-Orientiert

„Konventionell“ „Agile“

Schriftlich

Spezifikation

„Vollständig“ Requirements Engineering

„So wenig wie möglich, soviel wie nötig.“

© HOOD GmbH -9-

Scrum und der Product

Owner

Wasteful und

valuable RE

Fazit

© HOOD GmbH

Scrum – kurz und knapp

-10-

Product

Backlog

Potentiell lieferbares

Produktinkrement

Selected/

Sprint

Backlog

Scrum Team

Sprint

© HOOD GmbH

Wo haben wir es mit Anforderungen zu tun?

-11-

Product

Backlog

Potentiell lieferbares

Produktinkrement

Selected/

Sprint

Backlog

Sprint

Product

Vision/

Scope

Business/System

Requirements

Implementation

Requirements

Requirements

Acceptance

Scrum Team

• 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

So

ruce

: h

ttp

://w

allp

ap

ers

-fre

e.c

o.u

k/b

ackg

rou

nds/c

art

oon

s/d

isn

ey/T

he

-In

cre

dib

les.jp

g

So

urc

e: h

ttp

://w

ww

.ga

mg

ea

.co

m/w

p-c

on

ten

t/u

plo

ad

s/2

00

9/0

4/t

he

-incre

dib

les-1

-siz

ed

1.jp

g

Verantwortung des Product Owner

-12-

Product Owner ist ein

Full-time Job

PO

© HOOD GmbH

So

ruce

: h

ttp

://w

allp

ap

ers

-fre

e.c

o.u

k/b

ackg

rou

nds/c

art

oon

s/d

isn

ey/T

he

-In

cre

dib

les.jp

g

So

urc

e: h

ttp

://w

ww

.ga

mg

ea

.co

m/w

p-c

on

ten

t/u

plo

ad

s/2

00

9/0

4/t

he

-incre

dib

les-1

-siz

ed

1.jp

g

So

ruce

: h

ttp:/

/wa

llpap

ers

-fre

e.c

o.u

k/b

ackg

rou

nds/c

art

oon

s/d

isn

ey/T

he

-In

cre

dib

les.jp

g

• Project Management

• Product Management

• Kommunikationsfähigkeiten

• Fachliches Know How

• Technisches Know How

• Requirements Engineering

Fähigkeiten des Product Owner

-13-

PO

Product Owner ist

ein herausfordernder Job

© HOOD GmbH -14-

PO

Scrum Team

© HOOD GmbH

Dem Product Owner gehört das Produkt – Konflikte mit anderen Rollen

-15-

Produkt/

System

Product

Owner

Business Analyst

Produkt Manager

Projektleiter

UX-Spezialist

Unternehmens-

führung

Architekt

Marketing

Vertrieb

Anforderungs-

manager The Product Owner is responsible for maximizing the value of the product

and the work of the Development Team.

© HOOD GmbH

Stakeholders

Scrum Team

Development Team

Eine Lösungsmöglichkeit: Die bestehenden Rollen als Stakeholder betrachten

-16-

Scrum

Master

Product

Owner

Requirements

Engineering

LAS Zürich

September 2012

-17-

„Grooming the Backlog“

• Detaillierte

Requirements Analyse

• Grosse Anforderungen

splitten

• (Re-) Priorisieren

• (Re-) Schätzen

• Bearbeitungsreihenfolge

Quelle

: htt

p:/

/ww

w.p

fote

n-u

nd-c

o.d

e/f

oto

s/p

fle

geP

ferd

.jp

g

© HOOD GmbH

Requirements Engineering innerhalb des Scrum Teams

Scrum Team

Development Team Scrum

Master

Product

Owner

Stakeholders

Systemintegration

Architektur

Betrieb

QM

© HOOD GmbH -19-

Wasteful und

valuable RE

Fazit Erhebung Spezifikation Qualitäts- kriterien

Traceability

LAS Zürich

September 2012

Magic Backlog

Source: http://www.birgit-helfmann.de/pict/wunderlampe.jpg

Erhebungs- techniken

Beispiel: Von der Vision zur User Story

-21-

Vision

Business

Plan Business

Drivers

Minimum

Marketable

Product/

Feature Set

Feature Feature Feature

Epic

Feature

Epic

User

Story

User

Story Epic

User

Story

User

Story

Epic

Epic

Architektur-

vision

© HOOD GmbH

Product Vision - Beispiel

-22-

„All my music is in my pocket“

Copyright © 2012 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechte vorbehalten.

Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der HOOD Group verboten.

Apple

Vision

© HOOD GmbH

Requirements Engineering: Scope definieren

-23-

Systemgrenze, -kontext

und

Schnittstellen

Stakeholder

Analyse

© HOOD GmbH

Erhebung und Priorisierung mit MuSCoW

-24-

Product Backlog

EPIC

(ITEM)

EPIC

(ITEM)

EPIC

(ITEM)

Feature/

Epic

MuSCoW

EPIC

(ITEM)

EPIC

(ITEM)

EPIC

(ITEM)

User Story

MuSCoW

EPIC

(ITEM)

Feature/

Epic

MuS

EPIC

(ITEM)

User Story

MuS

EPIC

(ITEM)

User Story

CoW

EPIC

(ITEM)

Feature/

Epic

CoW

MuSCoW • Must Have – ohne das

funktioniert das System nicht

• Should Have

• Could Have

• Won‘t Have

© HOOD GmbH

Architekturrelevante Anforderungen

-25-

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.

Prinzip:

Deferred Decisions

Architektur-

vision

© HOOD GmbH

Quelle:

Codecentric, OS

Information Days

2012

Evolving Architecture

-26-

t

Architektur

Funktionalität

Architektur nicht

ohne Funktionalität

Funktionalität

validiert

Architektur

Architektur-

vision

© HOOD GmbH -27-

Wasteful und

valuable RE

Fazit

Spezifikation Qualitäts- kriterien

Traceability

© HOOD GmbH

Spezifikationen versus Product Backlog

-28-

Copyright © 2012 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechte

vorbehalten. Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der

HOOD Group verboten.

Product Backlog

Was ist ein Backlog?

Der Begriff „Backlog“ wird zum Beispiel in der

Auftragsverwaltung verwendet und beinhaltet alle

eingegangenen/ eingehenden Aufträge geordnet nach

ihrer Bearbeitungsreihenfolge.

Über diese Liste werden alle nachfolgenden

Prozessschritte, wie Beschaffung und Produktion, geplant

und gesteuert.

Das Backlog findet nun in der agilen Softwareentwicklung

analoge Anwendung. Es enthält alle potenziell

umzusetzenden Backlog Items, geordnet nach der

Reihenfolge ihrer Bearbeitung. Auf Basis dieser Liste

erfolgt die Planung und Steuerung der Umsetzung.

-29-

Product Backlog

Aufbau eines Backlog

-30-

Be

arb

eitu

ng

sre

ihe

nfo

lge

Evolving Backlog

Was sind Backlog Items

Backlog Items sind solche Items, die geplant Ressourcen verbrauchen. Dazu zählen

zum Beispiel:

-31-

Technische Anforderungen

Test Set (Test Run)

Defect

Issue

Nicht-funktionale Anforderungen

Use Cases

User Story

Features

Market Requirement

Needs

© HOOD GmbH

Umdenken beim Requirements Engineering

Funktionale Dekomposition Inkrementell, nutzenorientiert

-32-

Epic

User Story 1 User Story 2 User Story 3

Epic 1

User Story 1

User Story 2

Epic 2

User Story 1

User Story 2

Ergebnis sichern – Gewinne realisieren

„Wasserfallsprint“

-33-

Wasserfallsprínt

„Wasserfallsprint“

-34-

Realisation

Sprint 1

Requirements Definition Review

t Baseline Approval

Input für Sprint Planning

Wasserfallsprínt

Iterativ und inkrementell

-35-

Copyright © 2012 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechte

vorbehalten. Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der

HOOD Group verboten.

Realisation

Sprint 4 Sprint 1 Sprint 2 Sprint 3

Requirements Definition Review

t Baseline Approval

Input für Sprint Planning

© HOOD GmbH

„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. Was wäre, wenn wir heute liefern

müssten (potentiell lieferbar)

6. Akzeptanzkriterien streichen

7. Bereits während der Erhebung

priorisieren

-36-

© HOOD GmbH -37-

Wasteful und

valuable RE

Fazit

Qualitäts- kriterien

Traceability

Die Säulen der Qualität

-38-

I ndependent

N egotiable

V aluable

E stimable

S mall

Card Confirmation Conversation

T estable

Ak

ze

pta

nk

rite

rie

n

User Story

INV

ES

T (

Bill

Wake)

Beispiel für Akzeptanzkriterien

-39-

I ndependent

N egotiable

V aluable

E stimable

S mall

Card Confirmation Conversation

T estable

Ak

ze

pta

nk

rite

rie

n

User Story User Story:

„Als Marketing-MA will ich einen

Text auf der Webseite

publizieren können.“

Akzeptanzkriterien:

1. Das System muss ein

Review des Textes

ermöglichen

2. Das System muss eine

Freigabe des Textes

ermöglichen

3. …

Qualität von Akzeptanzkriterien

-40-

I ndependent

N egotiable

V aluable

E stimable

S mall

Card Confirmation Conversation

T estable

Ak

ze

pta

nk

rite

rie

n

User Story Verständlich

Atomar

Eindeutig

Widerspruchsfrei

Notwendig

Realisierbar

Nachweisbar

Lösungsneutral

„Als Marketing-MA will ich einen Text auf der Webseite publizieren können.“

-41-

Text erstellen

Review

Freigabe

Publizieren

Aufgabe:

Machen Sie daraus 3-4 User Stories

Akzeptanzkriterien

Lösung: „Als Marketing-MA will ich einen Text auf der Webseite publizieren können.“

-42-

Text erstellen

Review

Freigabe

Publizieren

1. „Als Marketing-MA will ich einen Text

erstellen können.“

4. „Als Marketing-MA will ich einen Text auf der

Webseite publizieren können.“

2. „Als Marketing-MA will ich ein Review für

einen Text durchführen können.“

3. „Als Marketing-MA will ich eine Freigabe für

einen Text erhalten.“

Reih

enfo

lge

Lösung 2: „Als Marketing-MA will ich einen Text auf der Webseite publizieren können.“

-43-

Text erstellen

Review

Freigabe

Publizieren

1. „Als Marketing-MA will ich einen Text

erstellen und publizieren können.“

3. „Als Marketing-MA will ich ein Review für

einen Text durchführen können.“

2. „Als Marketing-MA will ich eine Freigabe für

einen Text erhalten.“ R

eih

enfo

lge

© HOOD GmbH -45-

Wasteful und

valuable RE

Fazit

Traceability

Bestehende Spezifikationen: Needs, Epics und Stories extrahieren

-46-

Product Backlog

Anforderungen

- Verstehen

- Gruppieren

- Konsolidieren

- Priorisieren

- Abstimmen

- Verlinken

„Miteinander reden statt

gegeneinander

schreiben“

Quelle: mir leider unbekannt

© HOOD GmbH

Traceability

-47-

SW-Design

Benutzerdoku/

Fachliche

Doku

Source

Code

Testfall Testlauf

Epic

User

Story

User

Story

beinhaltet

realisiert

testet

dokumentiert

© HOOD GmbH -48-

Fazit

Sprint

Requirements Engineering im agilen Umfeld

-49-

Verstehen Vereinbaren Sicherstellen

Erheben

Vision

Visualisieren

Stakeholder

Ziel

Scope

Konversation

Sprintziel

MMP

Akzeptanzkriterien

Fokus auf Value

DoD

Handschlag

Commitment

potentially Shippable

Retro

Doku

Akzeptanzkriterien

frühes Feedback

Review

Automatisierung

Traceability

User Stories

Was möchte der Kunde? Wie vereinbaren wir das? Wie stelle ich sicher, dass er das bekommt?

Nutzen Sie agile Werte und Prinzipien und werden Sie zu:

-50- © HOOD GmbH

http://www.drooglab.com/

Fragen/ Diskussion

Kontakt

-52- © HOOD GmbH

Susanne Mühlbauer

Susanne.Muehlbauer@HOOD-Group.com

HOOD GmbH

Büro München

Keltenring 7

82041 Oberhaching

Germany

Tel: 0049 89 4512 53 0

www.HOOD-Group.com

http://blog.hood-goup.com

Quellen/ Links/ Zusatzinformation

1. www.agilemanifesto.org

2. www.scrum.org/Scrum-Guides

3. Innovation Games: Creating Breakthrough Products Through Collaborative

Play [Paperback], Luke Hohmann

-53- © HOOD GmbH