RE und Scrum - auf den zweiten Blick ein geniales Team

Andreas BeckerAgile-by-HOOD18.03.2014

RE und Scrum – auf den zweiten Blick ein geniales Team

Inhalt

• Einleitung• Refinement• Vision• Planung• Abstimmung• Erhebung und Feedback• Weitere Rollen• Zusammenfassung oder muss es immer Scrum sein?

Klassische RE-Aktivitäten

3

Umfang definieren(Scoping)

ErhebenSpezifizieren

VerwaltenModellieren

Konsolidieren

Konkretisieren Ableiten

Abstimmen / Review

Abnehmen

Stakeholder-Management

Scrum: 3 – 3 – 5

Product Backlog

Sprint Backlog

Potentiell lieferbares Produktinkrement

Sprint Planning Review

Retrospektive

Daily Sprint

SprintMax. 30 Tage

Definiton of Done

Stand: Scrum Guide 2013

In welchem Umfeld arbeiten Sie?

6

Kunde Product Owner

ScrumMasterEntwicklerteam

Kunde

Product Owner

ScrumMasterEntwicklerteam

Kunde =

Kunde

Kunde

Kunde

Kunde

Kunde

Kunde KundeKunde

KundeKunde

Kunde

Kunde

Kunde Kunde

KundeKunde

ODER

Refinement

8

Scrum - Framework

Product Backlog

Sprint Backlog

Potentiell lieferbares Produktinkrement

Sprint Planning Review

Retrospektive

Daily Sprint

SprintMax. 30 Tage

Definiton of Done

Scrum Guide 2013

UserStor

y

User Story

9

Als Administrator möchte ich Nutzer des Portal sperren können, um Missbrauch zu verhindern

Rolle

Funktionalität

Nutzen / Grund

Kommunikationsgrundlage

Quelle: http://www.informit.com/articles/article.aspx?p=1928232&seqNum=4

Backlog Refinement

User

Stor

y

11

Scrum - Framework

Product Backlog

Sprint Backlog

Potentiell lieferbares Produktinkrement

Sprint Planning Review

Retrospektive

Daily Sprint

SprintMax. 30 Tage

Definiton of Done

Scrum Guide 2013

Story Time

User

Story

„…10% der Zeit des Entwicklungsteams für die Beschäftigung mit zukünftigen Anforderungen…“

Akzeptanzkriterien – es müssen nicht immer Stichworte sein

12

Skizzen

Tabellen

Als Nutzer möchte ich mein Profil löschen können, um keine Daten im Netz zu hinterlassen.

Given - der Nutzer ist eingeloggt and er hat keine aktuellen Buchungen von

Mitfahrgelegenheiten

When - der Löschbutton wird betätigt die Anfrage wird bestätigt

Then - der Nutzer bekommt eine Bestätigungs-eMail and die Daten des Nutzers werden aus der

Datenbank gelöscht

Szenarien

UserStory

Konkretes Beispiel

Schätzung und Dialog

13

User

Story

Von der Idee zur Umsetzung

14

Epic

User Story

Erste Vorstellung der User Story +

Akzeptanzkriterien

Vollständig verstandene User Story + Akzeptanzkriterien

Kommunikative Ergänzungen zur User Story

REFINEMENT

Sprint Planning

Story Time

Sprint

Product Backlog

Schätzung der User Story Story Time

Agilität erleben

Backlog-ManagementPortfolio Backlog

Feature Backlog

Product Backlogs

Sprint Backlogs

NFA

Architektur- entscheidungen

User Story

User Story

User Story

User Story

User Story

User Story

Task

Task

Task

Task

Task

Task

Task

Task

Task

GesetzeGf-Ziele

Use CaseFeature …..

1. -----2. -----3. -----4. -----5. -----6. -----

1. -----2. -----3. -----4. -----5. -----6. -----

1. -----2. -----3. -----4. -----5. -----6. -----

1. -----2. -----3. -----4. -----5. -----6. -----

1. -----2. -----3. -----4. -----5. -----6. -----

1. -----2. -----3. -----4. -----5. -----6. -----

1. -----2. -----3. -----4. -----5. -----6. -----

1. -----2. -----3. -----4. -----5. -----6. -----

…

…

….

Nac

hver

folg

bark

eit

z.B. Sicherheits-anforderungen

Akzeptanz-kriterienAkzeptanz-

kriterienAkzeptanz-kriterien

Status „Ready“ und „Done“

• READY – Qualität der User Story (Anforderungen)• DONE – Abnahmekriterien für User Story (Anforderungen)

16

Product Backlog

Sprint Backlog

Potentiell lieferbares ProduktinkrementSprint Planning Review

Retrospektive

Daily Sprint

SprintMax. 30 Tage

READY

DONE

Vision

18

Scrum

Product Backlog

Sprint Backlog

Potentiell lieferbares Produktinkrement

Sprint Planning Review

Retrospektive

Daily Sprint

SprintMax. 30 Tage

Definiton of Done

Scrum Guide 2013

Vision

Quelle: Alice im Wunderland, Film 2010

"Würdest Du mir bitte sagen, welchen Weg ich

einschlagen muss?"

"Das hängt in beträchtlichem Maße

davon ab, wohin du gehen willst"

"Oh, das ist mir ziemlich gleichgültig"

"Dann ist es auch einerlei, welchen Weg du

einschlägst"

Quelle „Alice im Wunderland“ Lewis Carroll / 26. 11 1865

Vision Board

21

Planung

„Wir können nicht hinter den Horizont schauen“ (Mike Cohn)

-24-

25

Scrum

Product Backlog

Sprint Backlog

Potentiell lieferbares Produktinkrement

Sprint Planning Review

Retrospektive

Daily Sprint

SprintMax. 30 Tage

Definiton of Done

Scrum Guide 2013

Abhängig vom Planungskontext sind unterschiedliche Planungshorizonte* notwendig

*: basierend auf Ellen Gottesdiener

PO und ManagementPO-TeamScrum-Team

Sprint Release (1-6 Monate)

Roadmap (6 Mon. – 2 Jahre)

Ziele der Planungshorizonte

*: basierend auf Ellen Gottesdiener

Ausblick auf kommende Themen / Epics / Feature

Gemeinsames Verständnis erzielen

Konkrete Fragen des Teams beantworten

Akzeptanzkriterien ergänzen

User Stories schätzen

Ermittlung von Abhängigkeiten

Epics / Feature

Epics in User Stories splitten

Grobe Varianten erörtern und schätzen

Nächste1-2 Sprints

Release- Vorschau

Das große GanzeRoadmap

Abstimmung

29

Scrum – ein Blick ins Daily

Product Backlog

Sprint Backlog

Potentiell lieferbares Produktinkrement

Sprint Planning Review

Retrospektive

Daily Sprint

SprintMax. 30 Tage

Definiton of Done

Scrum Guide 2013

30

Daily - Scrum„…und ich mach die

Toten“…Ich mache den

Task „DB-Modell“ anpassen …

…Ich mache den Task „Menueleiste

anpassen„…

?

…. Kündigung ….

„…die Toten machen wir

nicht…“

31

Scrum – mit vielen POs

Product Backlog

Sprint Backlog

Potentiell lieferbares Produktinkrement

Sprint Planning Review

Retrospektive

Daily Sprint

SprintMax. 30 Tage

Definiton of Done

Scrum Guide 2013

PRE Planning

Product Owner Pre-Planning

-32-

Velocity

Velocity

Velocity

Produktvision

Abgleich der geplanten Backlog Items mit Strategie

Fachliche Abhängigkeiten

Technische Abhängigkeiten

Know How Transfer

Sprint oder

Release

Architektur-Vision

Chief Product Owner

PO Pre-Planning

Product Owner

Product Owner

Product Owner

Abgestimmtes Backlog

Feedback ist essentiell

Anforderungserhebung

34

UserStory

User

Story

User

Story

Sprint Review – die traurige RealitätWo liegt der Fehler?

ScrumMaster

Entwicklerteam

Product Owner

Sprint Review als Feedback- und Erhebungsworkshop

„Das Ergebnis des Sprint Reviews ist ein potentiell neu organisiertes Product Backlog, bei dem die am höchsten bewerteten Product Backlog-Einträge am wahrscheinlichsten für das nächste Sprint Planning ausgewählt werden.“

Quelle: Scrum Guide 2013

Product Backlog

Sprint Backlog

Potentiell lieferbares Produktinkrement

Sprint Planning Review

Retrospektive

Daily Sprint

SprintMax. 30 Tage

Definiton of Done

Umdenken

Funktionale Dekomposition Agiles nutzenorientiertes Umfeld

Epic

User Story 1 User Story 2 User Story 3ü ü ü

ü

Epic 1

User Story 1ü

ü

Epic 2

User Story 1ü

ü

Feedback

Potentiell lieferbares Produkt-inkrement

Feedback

Potentiell lieferbares Produkt-inkrement

User Story 2

User Story 3

üü

Feedback im agil skalierten Umfeld

Hotline

Endanwender

Session-basiertes Testen

….

Beta-Kunden / Pilotierung

Endanwender EndanwenderPilotierungskunden

Optionale Nutzung

Product Owner

Review-Event(Feedback- & Erhebungsworkshop)

Videoaufzeichung

Scouts beim Endkunden

Workshops

Usability Prototyping

UX Usability Testing

Rollen im Business-Team

40

Der PO – ein Superheld?

Product Owner

Terminator

Quelle: http://www.fuenf-filmfreunde.de/2009/04/23/ist-arnold-schwarzenegger-im-neuen-terminator-salvation-doch-zu-sehen/

NORMator

Quelle: http://prem666.deviantart.com/art/Terminator-Robot-Face-398031009

NORMator – der Mann / die Frau für das regulierte Umfeld

NORMator

44

Dokumentation

Product Backlog

Sprint Backlog

Potentiell lieferbares ProduktinkrementSprint Planning Review

Retrospektive

Daily Sprint

SprintMax. 30 Tage

Definiton of Done

NORMator

Software

Development

Document

DoR / DoD

Sprint Notes

Team Charta

Architecture Notes

Release Notes

Test Documentation

Prozess

Agilität erleben 45

NORMator im Überblick

NORMator

Validierung der Gebrauchstauglichkeit- User- Gebrauchsformen - Szenarien - Schnittstellen

Risikomanagement- Risikoanalyse - Maßnahmen- Dokumentation

Traceability sicherstellen

……

Vollständigkeit der Dokumentation - Prozessvorgehen - Sprintnachweis- Architektur- Teamcharta- ….

46

Business-Team mit PO und NORMator

NORMator

Product Owner

47

Der Business Analyst – was wird aus ihm?

Business Analyst

Story Mapping

Prozess (zeitlicher Ablauf)

… … … ……

Aktivitäten

Ranking

Aufgaben/ Tasks

……..

……..

……..

……..

…….. ……..

…….. ……..

……..

……..

……..

……..

……..

……..

Story Mapping – Beispiel „Buchversand“

Prozess (zeitlicher Ablauf)

Buchungfinden

Angebotesichern

Bestellen-daten

Bestellinfor-mationen

Zahlungs-möglichkeiten

Aktivitäten

Ranking

Aufgaben/ Tasks

Warenkorblegen

Merklistespeichern

Wunschlistespeichern

Lieferadresseeingeben

Rechnungs- adresseeingeben

Voraus-überweisung

Per PayPal zahlen

Bestellstatus-Informationen einsehen

Kreditkarte nutzen

Suche durch Titel

Suche nachAutor

Suche nach ISBN-Nr

……..

Per Rechnungzahlen

50

Business-Team mit PO, BA und NORMator

NORMator

Product Owner

Business Analyst

Prozess (zeitlicher Ablauf)

Aktivitäten

Ranking

Aufgaben / Tasks

Zusammenfassung

52

Scrum und mögliche Erweiterungen

Product Backlog

Sprint Backlog

Potentiell lieferbares Produktinkrement

Sprint Planning Review

Retrospektive

Daily Sprint

SprintMax. 30 Tage

Scrum Guide 2013

Story Time

UserStor

y

Vision

READY

DONE

PRE PlanningNORMator

Software-Entwicklung ist häufig komplex

Technologie

Anfo

rder

unge

n

bekannt unbekannt

beka

nnt

unbe

kann

t

Merkmale eines agilen Requirements Engineering – es muss nicht immer Scrum sein

RE ist eine kontinuierliche Tätigkeit und endet nicht nach einer Phase

Abkehr von der Vorstellung einer vollständigen Spezifikation / Änderungen sind willkommen

Direkte Kommunikation steht im Mittelpunkt und nicht die Spezifikation

„Wert“ einzelner Funktionen steht im Fokus und beeinflussen Rangfolge

Kontinuierliches Feedback

Teammitglieder und deren Know-how werden involviert

Abkehr einer „in Stein gemeißelten“ Kosten- und Zeitplanung am Anfang eines Projekts

Verschwendung vermeiden

Das Agile Manifest – 12 Prinzipien

-55-

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.

Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.

Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

Funktionierende Software ist das wichtigste Fortschrittsmaß.

Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler

und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

Ständiges Augenmerk auf technische Exzellenz und

gutes Design fördert Agilität.

Einfachheit -- die Kunst, die Menge nicht getaner Arbeit

zu maximieren -- ist essenziell.

Die besten Architekturen, Anforderungen und Entwürfe

entstehen durch selbstorganisierte Teams.

In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden

kann und passt sein Verhalten entsprechend an.

Fragen und Diskussion

Andreas.Becker@HOOD-Group.com

HOOD GmbHBüro MünchenKeltenring 782041 OberhachingGermany

Tel: 0049 89 4512 53 0www.Agile-by-HOOD.com

Andreas BeckerAgile Coach