Software-Projekte sind mit vielen Risiken behaftet. Die Ursachen für Fehlschläge sind oft Fehler im Management der Anforderungen und mangelhafter Einbezug der Benutzer. Agile Vorgehensmodelle wollen genau dieses Problem lösen. Allerdings wird die Thematik in den ursprünglichen Konzepten zu stark vereinfacht und dadurch oft missverstanden.

1. Creasoft Akademie
Diszipliniertes
Anforderungsmanagement in agilen
Projekten

2. Stefan Matt
Geschäftsleitung / Software -
Entwickler

3. Themen
• Agiles Anforderungsmanagement?
• Arten von Anforderungen
• Umsetzen von Anforderungen
• Ausblick / Offene Punkte
Quelle: Google Bildsuche

4. Themen
• Agiles Anforderungsmanagement?
• Arten von Anforderungen
• Umsetzen von Anforderungen
• Ausblick / Offene Punkte
Quelle: Google Bildsuche Requirements

5. Anforderungsmanagement?
Top Tens Lists of Software Project Risks:
Evidence from the Literature Survey
By Tharwon Arnuphaptrairong 2011
1. Misunderstanding of the requirements
2. Lack of management commitment and support
3. Lack of adequate user involvment
4. Failure to gain user commitment
5. Changes to requirements
6. Lack of an effective project management methodology

6. Agiles
Anforderungsmanagement?
• Bei der agilen Vorgehensweise geht es vor allem darum, wie
Anforderungen umgesetzt werden.
• Sie kümmern sich nicht darum wie Anforderungen gefunden
oder gewürdigt werden.
• Das ursprüngliche Konzept der ‚User Story‘ ist nicht
leistungsfähig genug.

7. Iteratives Vorgehen ‚klassisch‘
agil!
Einsatz +
Feedback
• User
Anforderungen
erarbeiten
• PO, Team
Anforderungen
umsetzen
• Team
Testen
• Team, Tester
Abnahme
Sprintende
• PO
• Iteration über den ganzen Zyklus um Anforderungen zu klären ist ineffizient!

8. Iteratives Vorgehen in Stufen!
• Weitere Feedbacks einführen.
• Das steigert Effizienz und
reduziert Risiko
• Schleifen können parallel laufen
Analyse
Spezifikation
Prototyp
Feedback
Akzeptanz
(Feedback)
Architektur
Entwickeln
Test
Stabilisieren
Feldtest Feedback
Anforderungen
Entwicklung
Konsolidierung
Evolution
Planung

9. Anforderungen dokumentieren
• Agile manifesto: Working software is valued
more than documentation.
• Aber: Es heisst nicht ‚Dokumentation ist
verboten‘
• Xtreme Programming: ‚The tests are the
documentation.‘
• Erstellen der Anforderungsdokumentation ist
nicht geregelt.
• ‘Analysis Paralysis’ vermeiden

10. Resultate dokumentieren
• The tests are the specification  Das kann nur
ein Entwickler sinnvoll finden
• Der Feedback Loop vom Backlog in eine
Produktspezifkation fehlt in der Theorie völlig.
• Es ist somit schwierig zu belegen oder zu
dokumentieren (Handbuch) was die Software
eigentlich kann.
• Es ist schwierig, sich einen Überblick zu
verschaffen

11. Themen
• Agiles Anforderungsmanagement?
• Arten von Anforderungen
• Umsetzen von Anforderungen
• Ausblick / Offene Punkte
Quelle: Google Bildsuche

12. Arten von Anforderungen
Klassische (und nützliche) Sicht der Anforderungen:
Business
Requirements
Vision and Scope
Document
Quelle: Karl E. Weigers
User
Requirements
Use Cases
Functional
Requirements
Software Requirements
Specification
Quality
Attributes
Other
nonfunctional
Requirements

13. Eine andere Sicht
Lösung
Anforderungen
Erfordernisse
Nutzungskontext
LösungsraumProblemraum
Empirische
Basis
Inspiration: Thomas Geis, ProContext
(Needs)
(Requirements)
Nutzungsanf.
Systemanf.

14. Eine andere Sicht
Lösung
Anforderungen
Erfordernisse
Nutzungskontext
LösungsraumProblemraum
Empirische
Basis
Inspiration: Thomas Geis, ProContext
(Needs)
(Requirements)
Nutzungsanf.
Systemanf.
Darum geht’s
heute

15. Themen
• Agiles Anforderungsmanagement?
• Arten von Anforderungen
• Umsetzen von Anforderungen
• Ausblick / Offene Punkte
Quelle: Google Bildsuche

16. Umsetzen von Anforderungen
• Wer beschäftigt sich mit Anforderungen?
• Strukturmodell Anforderungen
• Dokumentation von Anforderungen
• Management von Anforderungen

17. Umsetzen von Anforderungen
• Wer beschäftigt sich mit Anforderungen?
• Strukturmodell Anforderungen
• Dokumentation von Anforderungen
• Management von Anforderungen

18. Wer beschäftigt sich im Agilen mit
Anforderungen?
• Xtreme Programming: Onsite Customer
• Scrum: Product Owner
Probleme:
• Single Ressource
• Das funktioniert beim Outsourcing nur
bedingt
• Gute Leute haben meist keine Zeit übrig

19. Ein Vorschlag
An
Anforderungsmanagement
Projektleiter
Software
Produktmanager
Kunde

20. Project - Stakeholder
Quelle: www.loggerbleiben.de

21. Rollen im Projekt
Produkt entwickeln
Entwickler
Software entwicken
Tester
Anforderungen
managen
Projektleiter
Endbenutzer
Produktmanager
Big Boss

22. Aufgaben Produktmanager
• Blick zum Markt
• Produkt Roadmap ca. 1 Jahr voraus detaillieren
• Release Planung grob mit Projektleiter
• Release Backlog zusammen mit Projektleiter
verwalten (Feature Ebene)
• Priorisieren (!)
• Akzeptanzkriterien mit Benutzern (und Testern)
erarbeiten
• Budgetkontrolle
• Abnahme von Features und Stories

23. Aufgaben Projektleiter
• Blick zum Projekt
• Release Backlog zusammen mit Produkt
Manager verwalten
• Releaseplanung im Detail
• Features in Stories der passenden Grösse
aufteilen
• Genügend Stories in Zustand ‘Ready’ bringen
für Entwicklung
• Koordination von Entwicklern + Testern
• Spezifikation auf Stand halten
• Budgetkontrolle
• Reviews

24. Aufgaben Big Boss
• Produkt Vision
• Grobe Roadmap für die nächsten Jahre
• Budget bereitstellen
Bild: distility.com

25. • Information über Erfordernisse
• Typische (und untypische!) Szenarien
schildern
• Hilfe bei Akzeptanzkriterien
• Feldtest
Aufgaben Benutzer

26. Umsetzen von Anforderungen
• Wer beschäftigt sich mit Anforderungen?
• Strukturmodell Anforderungen
• Dokumentation von Anforderungen
• Management von Anforderungen

27. Begriffe
Begriff Erklärung
Backlog Item Etwas, das im Backlog steht
Feature Features werden in Releases realisiert. Sind wie grosse
User Stories beschrieben
Story Stories werden in Iterationen (Sprint) realisiert. Es gibt
verschiedene Arten von Stories.
User Story Als Benutzer [A] kann ich [B] tun um [C] zu erreichen
Problem Fehlverhalten im gelieferten Produkt
Spec Change Etwas passt nicht, war aber auch nicht spezifiziert
Other Work Item Technische Stories z.B. Refactoring, Architektur,
Planung
Acceptance Test Szenarien, mit denen die Funktion eines/r
Feature/Story geprüft wird.

28. Strukturmodell Anforderungen
Specification
Nonfunctional
Requirement
Use Case
Backlog Item
Functional
Requirement
determines
Epic Feature Story
User Story Problem Spec Change Other Work Item
Task Bug Fix
1..* 1
contains 0..*1 contains
1..*
1
provides context for
0..*
0..*
constrains
System Qualities Test
0..*
1..* Compliant when passes
0..*1 is implemented by1..*0..1 is realized by1..*0..1 is realized by
Story
Acceptance
Test
1..*
1
is done when passes
Feature
Acceptance
Test
1..*
1
is done when passes
Vision Theme
1..*
0..1
is realized by
Unit
Test
0..*
Inspiration: Dean Leffingwell, Agile Software Requirements

29. Struktur Ausschnitt
SpecificationUse Case
1..* 1
contains
Nonfunctional
Requirement
0..*1 contains
Backlog Item
1..*
1
provides context for
0..*
0..*
constrains
Feature Story
1..*0..1 is realized by
Feature
Acceptance
Test
1..*
1
is done when passes
Story
Acceptance
Test
1..*
1
is done when passes
User Story
Problem
Spec Change
Other Work Item
Inspiration: Dean Leffingwell, Agile Software Requirements

30. Umsetzen von Anforderungen
• Wer beschäftigt sich mit Anforderungen?
• Strukturmodell Anforderungen
• Dokumentation von Anforderungen
• Management von Anforderungen

31. Dokumentation von
Anforderungen
• Die Spezifikation hat nicht ausgedient.
• Projektstart auf jeden Fall mit Spezifikation in
ausreichendem Detailierungsgrad
• Evolution der Anforderungen im Backlog
• Rückübertragung vom Backlog in die
Spezifikation nach Abnahme eines Features

32. Auch hier ein Zyklus
Spezifikation
erstellen/nachführen
Features ins Backlog
stellen
Realisieren

33. Struktur der Spezifikation
• Es gibt viele Beispiele und Vorlagen im
Internet  eine auswählen und anpassen.
• Wichtig: Die richtigen Fragen stellen!
• Richtig: Was tut der Benutzer?
• Falsch: Was kann das Programm?

34. Abnahmekriterien
• Abnahmekriterien gehören dazu, wenn ein
Feature fertig spezifiziert sein soll
• Es ist möglich, diese schon zum Zeitpunkt der
Spezifikationserstellung in hoher Qualität
fertigzustellen
• Man hat immer Zeit nachher zu reparieren,
aber nie vorher nachzudenken.

35. Umsetzen von Anforderungen
• Wer beschäftigt sich mit Anforderungen?
• Strukturmodell Anforderungen
• Dokumentation von Anforderungen
• Management von Anforderungen

36. Management der Anforderungen
Ein paar Schlagworte:
• Backlog
• Release
• Features und Stories
• Confirmed / Accepted
• Defintion of Ready / Definition of Done
• Iteration
• Backlog Item Lifecycle

37. Backlog
• Enthält Schritte für die Umsetzung der
Spezifikation
• Sammelbecken für Ideen
• Muss durchsuchbar und sortierbar sein
• Gegliedert nach Releases
• Zugriff für Product Manager
( Hauptaufgabe)
• Muss gepflegt werden (Grooming)

38. Release / Iteration
Release
2013 Q1
Release
2013 Q2
Release
2013 Q3… …
… ……
Iterationen Iterationen Iterationen
• Release: Richtgrösse 3 Monate
• In Releases werden Features realisiert
• Iteration: Richtgrösse 2 – 3 Wochen
• In Iterationen werden Stories realisiert

39. Release
Release Planning
• Monatlich 1h
• Priorisierung von Features und Stories, Aufräumen
• Product Manager + Projektleiter
Product Roadmap Planning
• Planung vierteljährlich 2h-4h
• Product Manager + Projektleiter
• Roadmap als Schriftstück, das sichtbar ist
Plan einhalten! Schnellschüsse vermeiden!

40. Iteration
• Planung alle 2 Wochen durch Entwicklungsteam
am Iterationsende / Start
• Realisierung von Stories die ‘Ready’ sind durch
‘Tasks’
• Erzeugen eines ‘Potentially Shippable Increment’
• Möglichst keine Änderungen an geplanten Stories
während der Iteration
• Gleichzeitig vorbereiten der nächsten Iteration
durch Projektleiter

41. Features / Stories
• Features werden in Releases realisiert
• Stories werden in Iterationen realisiert
• Features können in Stories aufgeteilt werden
• Stories (und kleinere Features) werden mittels
Tasks implementiert
• Tasks werden von den Entwicklern angelegt
• Tasks werden innert eines Tages erledigt

42. Priorisieren
• 1
Ohne dieses Feature ist das Release nicht
brauchbar
• 2
Dieses Feature bringt Nutzen und Wert. Ein
Fehlen macht das Release aber nicht
unbrauchbar.
• 3
Nur erledigen wenn noch Zeit vorhanden.

43. Definition of Ready (DoR)
Was ist nötig, damit mit der Entwicklung
begonnen werden kann?
Bei Creasoft:
• Spezifikation erstellt
• Grössenschätzung
• Grösse passt
• Akzeptanzkriterien sind bekannt
• OK von Entwicklung + Testern
• Risiken betrachtet

44. Defintion of Done (DoD)
Wann ist die interne Entwicklung fertig?
Bei Creasoft:
• Alle untergeordneten Aufgaben erledigt
• Code ist dokumentiert
• Code kompiliert ohne Warnungen
• Alle automatischen Tests laufen ok
• Übersetzungen zu Texten erstellt
• Manuell getestet
• Falls Review nötig? durchgeführt?
• Spezifikation nachgeführt?

45. Lifecycles von Backlog Items
• Verschiedene Arten von Items können
verschiedene Lifecycles haben
• An die eigenen Firma anpassen
• Pragmatisch sein

46. Lifecycle Story/Feature ohne
Stories
open
confirmed
ready (DoR)
activated
in progress
closed
accepted
done (DoD)
in test
implemented
reject

47. Lifecycle Feature mit Stories
open
confirmed
in progress
closed
accepted
done
reject

48. Minimize ‘Work in Progress’
• Eine Person sollte nur an einer Sache
gleichzeitig arbeiten
• Vermeiden von vielen Stories und Tasks die
gleichzeitig ‘in progress’ sind.
• Arbeiten abschliessen und an Kunden zur
Abnahme weiterleiten.
• KANBAN

49. ‘Work in progress’ sichtbar
machen
• Taskboard
• Mittels Zetteln oder elektronisch

50. Themen
• Agiles Anforderungsmanagement?
• Arten von Anforderungen
• Umsetzen von Anforderungen
• Ausblick / Offene Punkte
Quelle: Google Bildsuche

51. Ausblick / Offene Punkte
• Verbesserung Backlog Management (Suchen,
Gruppieren, Grooming (!), etc.)
• DoR / DoD konsequent anwenden
• Online Release Planung
• Kapazitätsplanung
• Generierung der Spezifikation aus DB

52. Vielen Dank für Ihre
Aufmerksamkeit
Für Fragen und Diskussion stehen wir
gerne zur Verfügung