Schöner scheitern – Die beliebtesten Missverständnisse im agilen RE

Schöner scheitern: Die beliebtesten Missverständnisse im agilen RE

oose.Innovative Informatik


Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik eG

© Thomas Wolf, www.foto-tw.de



Warum bin ich in diesem Vortrag?

60 sec.



1 Hindernisse beim agilen Vorgehen:

Erfahrungsberichte, Mythen und Lösungen

2 Vorgehen für agiles Requirements Engineering

3 Zusammenfassung

Agenda



Agenda




3 Zusammenfassung



Muster :: Kombination aus Wasserfall und Agilität

Design

Entwicklung Test

Betrieb

Analyse



Muster :: Kombination aus Wasserfall und Agilität

Analyse

„agiles“ Entwickeln

Betrieb



Mythos 1

Wenn wir nur genau genug analysieren,

erkennen und verstehen wir alle Anforderungen.

bekannte

Anforderungen

unbekannte

Anforderungen

unklare

Anforderungen

optimales

Produkt

{ {

Präsentation

lauffähiger

Software

Analyse-

techniken

1.

2.



Lösung

Analyse -- Analyse ++

Akzeptieren, dass nicht alle Anforderungen vor und unabhängig von der Realisierung erkannt werden können.

Raum für das Herumprobieren und Lernen lassen.

Nicht für alle Anforderungen wird die gleiche Detailtiefe benötigt.



Mythos 2

Anforderungsspezifikationen (textuelle oder grafische) sind selbsterklärend.



Lösung

Informationsgehalt

Direkte Zusammenarbeit und Kommunikation

Nur so viel Dokumentation der Analyse, wie unbedingt notwendig.

Just in Time. (Anforderungen sind eine verderbliche Ware.)



Mythos 3

„agil“ entwickeln

Anforderungs-

spezifikation

Ein Dokument für alle (Entwickler, Tester, Product Owner …)



Lösung

Welche Information werden in welcher Form benötigt?

Was muss dauerhaft dokumentiert werden?



Mythos 4

Absicherung und Schuldzuweisung

Anforderungsdokumente dienen zur eigenen Absicherung und als Grundlage für Schuldzuweisungen im eventuellen Streitfall.



Lösung

Ein Team, ein Produkt: gemeinsam am Erfolg arbeiten; keine Energie für den Fall des Scheiterns verschwenden.

Vertrauen statt Kontrolle.



Mythos 5

„agil“ entwickeln

Anforderungen – wie Use Cases und Prozesschritte – sind vollwertige Planungsmittel.



Lösung

Story Maps

Minimales marktfähiges Release

Umsetzung der Anwendungsfälle der Story Map mit Hilfe von User Stories im Product Backlog planen.



Anforderungs-

spezifikation

Muster :: Anforderungsanalyse wird überbewertet



Mythos 6

Product Owner

? ? ?

User Stories, Epics und Themen machen eine Anforderungsanalyse überflüssig.



Lösungen

Analyse: Breite vor Tiefe

Analyseelemente dort einsetzten, wo sie nötig sind

Klassenmodell als Begriffsmodell

Architekturüberblick

1. Breite

2. T

iefe



Agenda




3 Zusammenfassung



Produktvision

Rahmen- bedingungen

Systemkontext

Funktionale Anforderungen

Qualitäts- anforderungen

Release

1. Breite 2. T

iefe

Product Backlog

Bugwelle Refinement



Agenda




3 Zusammenfassung



Zusammenfassung

Ein bisschen agil funktioniert nicht

Akzeptieren Sie, dass Ihr Kunde zu Beginn nicht detailliert weiß, was er braucht (er meint es nicht böse).

Dafür sollte das Ziel für alle Beteiligten klar sein.

Arbeiten Sie eng und kontinuierlich mit Ihrem Kunden zusammen, um die Details dann zu erarbeiten, wenn sie für die Umsetzung gebraucht werden.

Verzichten Sie auf eine umfassende Anforderungsspezifikationen.

Dokumentieren Sie Anforderungen nur soweit, wie es zur Werterhaltung gerade notwendig ist (z.B. für Zulassung oder Wartung).



Was nehme ich aus dem Vortrag mit?

60 sec.