Das Thema Requirements Engineering wird in der agilen Community durchaus immer noch kritisch gesehen. Es wird gerne gleichgesetzt mit einer „vollständigen“ Vorabspezifikation und einem Wasserfall-Vorgehen – kurz Waste.
Requirements Engineering (RE) ist kein Selbstzweck. Sehen wir RE jedoch als eine Disziplin im Software- oder Systems-Engineering, die uns hilft die richtigen und qualitätiv hochwertige Produkte und Systeme zu entwicklen, verfolgen wir damit einen Großteil der Ziele von agilen Vorgehensweisen.
In diesem Beitrag beleuchten wir, am Beispiel von Scrum wie Requirements Engineering in einer agilen Umgebung Value liefert. Hierzu betrachten wir den Product Owner, der eine zentrale und dennoch stiefmütterlich behandelte Rolle im Scrum Team spielt. Wir zeigen auf, wie RE-Methoden ihn und das Entwicklungsteam in seiner Arbeit da unterstützen, wo Scrum keine Antworten liefert.
Abschliessend machen wir uns auf die Suche nach Ursachen, die dazu führen, dass Aktivitäten des RE in einem agilen Umfeld als Waste empfunden werden: Sind Erhebungstechniken, Spezifikation, Qualitätskriterien, Traceability oder auch Requirements Management tatsächlich Waste?
Teams und Umfeld sind nicht alle gleich – ein „ideales“ Scrum-Umfeld, indem genau ein Team genau ein Produkt entwickelt ist nicht überall gegeben. Die Verwendung von RE in Organisationen, die z.B. mit vielen Teams ein Produkt entwickeln, wird notwendiger sein, als in dem oben beschrieben „idealisierten“ Scrum-Umfeld.
Wie erreichen wir auch in solchen Konstellationen ein Umdenken zu einem Umgang mit Requirements Engineering, um echten Value aus agilem Vorgehen zu erzielen?
12. Soruce: http://wallpapers-free.co.uk/backgrounds/cartoons/disney/The-Incredibles.jpg
Source: http://www.gamgea.com/wp-content/uploads/2009/04/the-incredibles-1-sized1.jpg
Verantwortung des Product Owner
• Product Backlog
• Fachliche Klärung der
Backlog Items
• Wert des Produkts/ der Arbeit
(ROI)
PO
• Priorisierung und
Reihenfolge der Backlog
Items
Product Owner ist ein • Abnahme der
Full-time Job Produktinkremente
• Release Planung
-12-
20. Magic Backlog
Erhebungs-
techniken
Source: http://www.birgit-helfmann.de/pict/wunderlampe.jpg
LAS Zürich
September 2012
21. Beispiel: Von der Vision Vision
zur User Story
Business Business
Plan Drivers
Architektur-
vision
Minimum
Marketable
Product/
Feature Set
Feature Feature Feature Feature
Epic User User
Epic Story Epic
Story Epic
User User
Story Epic
Story
-21-
29. Was ist ein Backlog?
Der Begriff „Backlog“ wird zum Beispiel in der
Auftragsverwaltung verwendet und beinhaltet alle
Product Backlog
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-
31. Was sind Backlog Items
Backlog Items sind solche Items, die geplant Ressourcen verbrauchen. Dazu zählen
zum Beispiel:
Features
Issue
Test Set (Test Run)
Needs
User Story
Technische Anforderungen Market Requirement Defect
Use Cases
Nicht-funktionale Anforderungen
-31-
38. Die Säulen der Qualität
User Story
I ndependent
N egotiable
Akzeptankriterien
INVEST (Bill Wake)
V aluable
E stimable
S mall
T estable
Card Conversation Confirmation
-38-
39. Beispiel für Akzeptanzkriterien
User Story: User Story
„Als Marketing-MA will ich einen
I ndependent Webseite
Text auf der
publizieren können.“
N egotiable
Akzeptankriterien
Akzeptanzkriterien:
V 1. Das System muss ein
aluable
Review des Textes
ermöglichen
E stimable
2. Das System muss eine
Freigabe des Textes
S mall
ermöglichen
3. …
T estable
Card Conversation Confirmation
-39-
40. Qualität von Akzeptanzkriterien
Verständlich User Story
Atomar
I ndependent
Eindeutig
N egotiable
Akzeptankriterien
Nachweisbar
V aluable
Widerspruchsfrei
E stimable
Notwendig
Realisierbar
S mall
Lösungsneutral
T estable
Card Conversation Confirmation
-40-
41. „Als Marketing-MA will ich einen Text auf der Webseite publizieren
können.“
Akzeptanzkriterien
Text erstellen
Review
Aufgabe:
Machen Sie daraus 3-4 User Stories
Freigabe
Publizieren
-41-
42. Lösung:
„Als Marketing-MA will ich einen Text auf der Webseite publizieren
können.“
Text erstellen 1. „Als Marketing-MA will ich einen Text
erstellen können.“
Review Reihenfolge 2. „Als Marketing-MA will ich ein Review für
einen Text durchführen können.“
Freigabe 3. „Als Marketing-MA will ich eine Freigabe für
einen Text erhalten.“
Publizieren 4. „Als Marketing-MA will ich einen Text auf der
Webseite publizieren können.“
-42-
43. Lösung 2:
„Als Marketing-MA will ich einen Text auf der Webseite publizieren
können.“
Text erstellen 1. „Als Marketing-MA will ich einen Text
erstellen und publizieren können.“
2. „Als Marketing-MA will ich eine Freigabe für
Review Reihenfolge einen Text erhalten.“
3. „Als Marketing-MA will ich ein Review für
einen Text durchführen können.“
Freigabe
Publizieren
-43-
48. Requirements Engineering im agilen Umfeld
Sprint
Verstehen Vereinbaren Sicherstellen
Was möchte der Kunde? Wie vereinbaren wir das? Wie stelle ich sicher, dass er das bekommt?
Erheben Sprintziel Retro
Scope Handschlag Automatisierung
Vision MMP
Doku Review
Ziel Visualisieren DoD Akzeptanzkriterien
Commitment frühes Feedback
Konversation
Fokus auf Value Traceability
Stakeholder potentially Shippable Akzeptanzkriterien
User Stories
-49-