Ist der häufig in agil arbeitenden Organisationen zu hörende Satz „wir arbeiten agil und benötigen kein RE mehr“ tatsächlich zutreffend? Ist die Zeit des RE durch die Verbreitung von agilen Methoden (z.B. durch das Scrum-Framework) abgelaufen? Der Eindruck könnte auf den ersten Blick entstehen, da die Aktivitäten des Requirements Engineering in der agilen Entwicklung nicht isoliert betrachtet werden.
Auf den zweiten Blick stellt sich heraus, dass Kenntnisse rund um RE-Methoden im agilen Umfeld nötiger sind denn je. Dies ergibt sich aus der Tatsache, dass immer größere Organisationen den Umstieg von ihren an Phasen und Dokumenten orientierten Prozessen zu einer agilen Entwicklung anstreben. Dies hat zur Folge, dass diese Organisationen häufig nicht individuell für genau einen Kunden implementieren, sondern zahlreiche Produkte für eine größere Kundenanzahl entwickeln. In einem agil-skalierten Umfeld.
Ein kleines Beispiel: In einem Review Meeting mit mehreren anwesenden Stakeholdern erhalten die Anwesenden einen Einblick in die bisherige Produktimplementierung und ergänzen die bisherige Implementierung mit neuen Wünschen - also mit weiteren Kundenanforderungen. Diese Anforderungen können sich widersprechen und schon muss der Product Owner die Anforderungen konsolidieren – eine typische RE-Aktivität.
Dieser Vortrag orientiert sich an zahlreichen dieser kleinen Beispiele, die in der alltäglichen Praxis vorkommen, und belegt dadurch die wachsende Bedeutung von RE-Kenntnissen im agil-skalierten Umfeld.
2. Inhalt
• Einleitung
• Refinement
• Vision
• Planung
• Abstimmung
• Erhebung und Feedback
• Weitere Rollen
• Zusammenfassung oder muss es immer Scrum sein?
5. In welchem Umfeld arbeiten Sie?
6
Kunde Product
Owner
ScrumMaster
Entwicklerteam
Kunde
Product
Owner
ScrumMaster
Entwicklerteam
Kunde =
Kunde
Kunde
Kunde
Kunde
Kunde
Kunde Kunde
Kunde
KundeKunde
Kunde
Kunde
Kunde Kunde
Kunde
Kunde
8. User Story
9
Als Administrator
möchte ich Nutzer des
Portal sperren
können, um Missbrauch
zu verhindern
Rolle
Funktionalität
Nutzen / Grund
Kommunikationsgrundlage
11. Akzeptanzkriterien – es müssen nicht immer Stichworte sein
12
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
Konkretes Beispiel
13. 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
R
E
F
I
N
E
M
E
N
T
Sprint Planning
Story Time
Sprint
Product Backlog
Schätzung der User Story Story Time
14. Backlog-Management
Agilität erleben
Portfolio
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 Case
Feature …..
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. -----
…
…
….
Nachverfolgbarkeit
z.B. Sicherheits-
anforderungen
Akzeptanz-
kriterienAkzeptanz-
kriterienAkzeptanz-
kriterien
15. 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
Produktinkreme
ntSprint Planning Review
Retrospektive
Daily Sprint
Sprint
Max. 30 Tage
R
E
A
D
Y
D
O
N
E
19. "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
24. Abhängig vom Planungskontext sind unterschiedliche
Planungshorizonte* notwendig
*: basierend auf Ellen Gottesdiener
PO und ManagementPO-Team
Scrum-Team
Sprint Release
(1-6 Monate)
Roadmap
(6 Mon. – 2 Jahre)
25. 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ächste
1-2 Sprints
Release-
Vorschau
Das große Ganze
Roadmap
34. 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
Sprint
Max. 30 Tage
Definiton
of Done
35. 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
46. Story Mapping
Prozess (zeitlicher Ablauf)
… … … ……
Aktivitäten
R
a
n
k
i
n
g
Aufgaben/ Tasks
……..
……..
……..
……..
…….. ……..
…….. ……..
……..
……..
……..
……..
……..
……..
47. Story Mapping – Beispiel „Buchversand“
Prozess (zeitlicher Ablauf)
Buchung
finden
Angebote
sichern
Bestellen-
daten
Bestellinfor-
mationen
Zahlungs-
möglichkeiten
Aktivitäten
R
a
n
k
i
n
g
Aufgaben/ Tasks
Warenkorb
legen
Merkliste
speichern
Wunschliste
speichern
Lieferadresse
eingeben
Rechnungs-
adresse
eingeben
Voraus-
überweisung
Per PayPal
zahlen
Bestellstatus-
Informationen
einsehen
Kreditkarte
nutzen
Suche durch
Titel
Suche nach
Autor
Suche nach
ISBN-Nr
……..
Per Rechnung
zahlen
48. Business-Team mit PO, BA und NORMator
50
NORMator
Product Owner
Business
Analyst
Prozess (zeitlicher Ablauf)
Aktivitäten
R
a
n
k
i
n
g
Aufgaben / Tasks
50. Scrum und mögliche Erweiterungen
52
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Review
Retrospektive
Daily Sprint
Sprint
Max. 30 Tage
Scrum Guide 2013
Story Time
User
Stor
y
Vision
R
E
A
D
Y
D
O
N
E
PRE Planning
NORMator
52. 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
53. 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.
Es muss nicht immer agil verwendet werden.Einfache = leicht erkennbar, wiederholbare MusterKompliziert = nicht einfach, aber immer noch erkennbar, das System ist vorhersehbarKomplex = nicht vollständig erkennbar, aber teilweise vorhersehbarChaotisch = weder erkennbar noch vorhersehbar.Bsp.:Mein Autoschlüssel ist einfach.Es dauerte etwa drei Sekunden, um zu verstehen, wie meine Autoschlüssel funktioniert. OK, vielleicht ist das nicht ganz richtig. Meiner hat eine Batterie drin. Wenn ich es auseinander zu nehmen, es könnte mich noch drei Stunden, um die Details zu verstehen. Aber ja, ich bin klug, ich werde zu verwalten.Mein Auto ist kompliziert.Es würde mich Jahre zu verstehen, wie mein Auto funktioniert. Und ich habe nicht die Absicht. Aber wenn ich es täte, dann eines Tages in ferner Zukunft würde ich mit Sicherheit der Zweck jeder Mechanismus und jedem Stromkreis kennen. Ich würde verstehen, wie sie zu kontrollieren, und ich wäre in der Lage, mein Auto auseinander nehmen und wieder zusammenbauen, fahren sie genau so, wie ich früher. In der Theorie, natürlich. In der Praxis tun nur echte Männer solche Dinge.Auto Verkehr ist komplex.Ich kann reisen und auf der gleichen Straße für 20 Jahre, und die Dinge würden jedes Mal anders. Es gibt keinen Weg, um vollständig zu verstehen und wissen, was um mich herum passiert auf der Straße, wenn ich fahre, wie andere Fahrer ihre Fahrzeuge zu betreiben, und wie die Menschen in den Straßen zu interagieren. Ich kann Vermutungen anstellen, und ich kann in Erfahrung Prognosen zu gewinnen. Aber ich werde nie sicher wissen.Auto Verkehr in Lagos (Nigeria) ist chaotisch.Wenn die Dinge zu komplex zu bekommen, sie leicht chaotisch. Verkehr in Lagos ist so schlecht, es ist nicht einmal vorhersehbar. Schlechte Infrastruktur und Planung, Haufen von Abfall, Umweltverschmutzung, mangelnde Sicherheit, Überschwemmungen und viele mehr Probleme machen es zu einem der schlimmsten Orte der Welt zu sein, als eine einfache Autofahrer.