Embed Size (px)
DESCRIPTION
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.
Citation preview
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
HOOD GmbHBüro MünchenKeltenring 782041 OberhachingGermany
Tel: 0049 89 4512 53 0www.Agile-by-HOOD.com
Andreas BeckerAgile Coach
