Gedanken über agiles Requirements Engineering

Ich hatte die Ehre, gestern den Eröffnungs- und Impulsvortrag mit dem Titel "Agiles Requirements Engineering" auf der 9. REConf zu halten. Weil das Thema für die Szene verhältnismäßig neu ist, möchte ich etwas ausführlicher über über meine Thesen und Gedanken dazu berichten, was der Einleitung meiner Keynote entspricht.

Requirements Engineering (RE) an sich kostet nur. Jedes RE muss daher einen Nutzen bringen, der seine Kosten deutlich übersteigt. Darum ist es wichtig, dass sich die Erhebung und Beschreibung von Anforderungen in Menge, Form und Zeitpunkt am Nutzen für ihre jeweiligen konkreten Empfänger orientiert. Die Erwartungen an das RE sind soweit normal und haben mit agilem RE noch nicht viel zu tun. Wer Requirements Engineering über die klare Kosten-Nutzen-Abwägung hinaus als Selbstzweck betreibt, ist bereits mit klassischem RE unproduktiv.

Interessant ist nun, dass agile Softwareentwicklungsverfahren weitgehend ohne RE auskommen. Sie funktionieren dank der regelmäßigen kurzfristigen Evaluierung lauffähiger Inkremente trotzdem sehr gut beziehungsweise besser. Dazu gehören die Fähigkeiten, Änderungen willkommen zu heißen, und eine gute, kontinuierliche Kommunikation mit dem Kunden. Insofern lässt sich aus agiler Sicht die Frage stellen: Brauchen wir überhaupt irgendein fortgeschrittenes Requirements Engineering?

These 1:
Klassisches RE ist auf Perfektion konditioniert: Anforderungen möglichst weitgehend verstehen und präzise beschreiben. Nichts steht beim Übergang zum agilen RE mehr im Weg als der Perfektionismus des RE. Insofern haben es erstklassige REler nicht leicht, agil zu werden!

These 2:
Agile Verfahren wie Scrum und XP basieren de facto auf Benutzergeschichten, Epen, Themen u.Ä. und damit auf einfachsten RE-Mitteln. Sie reichen zusammen mit grundlegenden Rückkopplungs- und Lernmechanismen aus, um erfolgreich zu arbeiten. Nichts steht aber einem effizienten agilen RE mehr im Weg als die Nichtbeherrschung fortgeschrittener RE-Techniken. Insofern haben Scrum- und XPler es nicht leicht, erstklassig zu werden.

Der Übergang vom Wasserfall zum Iterativen sorgt dafür, dass nicht alle Anforderungen vorab fertig gestellt werden, sondern über den gesamten Projektzeitraum prioritätsgesteuert verteilt. Das ist der erste Schritt zu einem agilen RE – und wer den Schritt noch nicht gegangen ist, das belegen viele eingängige Studien, hat wahrscheinlich verdammt gute Gründe oder arbeitet hoffnungslos rückständig.

Der nächste Schritt betrifft die aktive Steuerung der Unvollkommenheit und ist, da iteratives Vorgehen sich durchgesetzt hat, der derzeit wichtigere fürs RE. Hier teilen sich jetzt aber die Wege:

• Die klassischen Rler sollten die gezielte Unvollkommenheit als notwendigen Optimierungsschritt akzeptieren lernen.
• Die erfahrenen Agilisten sollten anspruchsvollere RE-Techniken beherrschen lernen.

Der Übergang vom Wasserfall zum Iterativen bedeutet, für jede einzelne Anforderung zu entscheiden, wann sie dran kommt, wann der richtige Zeitpunkt für sie ist. Auf die Kriterien dafür, unter anderem der Geschäftswert, gehe ich später kurz ein.

Der Übergang vom iterativen zum agilen RE bedeutet zusätzlich, für jede einzelne Anforderung zu entscheiden, wie sehr sie überhaupt verstanden werden muss (Steuerung der Verständnistiefe) und welche RE-Technik(en) hierfür dann am besten ist.

Eine wichtige agile Strategie ist, die Zeit vom Erkennen oder Beachten einer Anforderungen bis zur Akzeptanz ihrer Umsetzung möglichst kurz zu halten. Der Wasserfallprozess maximiert die Zeitspanne. Iteratives Vorgehen reduziert die Zeitspanne prinzipiell. Zusätzliche Zeit- und Aufwandsersparnisse werden dadurch möglich, das Anforderungen in Verständnistiefe und methodischer Handhabung nicht einheitlich behandelt werden, sondern jede Anforderung nur soweit vertieft wird, wie es individuell gut genug ist. Dieser Effizienzhebel ist mindestens genauso groß wie der, iterativ vorzugehen!

Die Kernfragen lauten also:

1. Welche Faktoren beeinflussen, wann eine Anforderung genug verstanden wurde?
2. Welche RE-Techniken sind bei welchen Indikatoren/Faktoren besser geeignet?

Folgende Fragen können helfen herauszufinden, wie viel RE investiert werden soll beziehungsweise wie viel von den Anforderungen verstanden werden sollte:

• Wie vertraut sind die Beteiligten (Product Owner, Fachabteilung, Anforderungsanalytiker, Entwicklungsteam etc.) mit der fachlichen Domäne?
• Wie homogen werden Geschäftsprozesse und Anwendungsfälle von verschiedenen Benutzern durchgeführt beziehungsweise bearbeitet?
• Wie viele fachliche Varianten und Ausnahmen sind zu berücksichtigen beziehungsweise werden erwartet?
• Wie neu oder verändert ist der Ablauf?
• Wie viele verschiedene Personen sind als Anforderungsgeber oder -beeinflusser zu berücksichtigen?
• Wie hoch ist das Risiko, durch zu wenig RE wichtige Abhängigkeiten oder Details zu vergessen, die später Mehrkosten oder Verzögerungen verursachen?
• Wie gravierend sind die Folgen, wenn wichtige fachliche Varianten oder Details vergessen werden?

Meines Erachtens ist also nicht die Frage, ob klassische RE-Techniken auch in agilen Projekten angewendet werden können, sondern nur, für welche der Anforderungen Sie wie tief einsteigen und welche der Konzepte und Techniken Sie in welchen konkreten Situationen am nutzbringendsten anwenden. Es ist die Entscheidung des Product Owners oder des RE-Experten in jedem Einzelfall.

Sollte jemand Scrum dennoch konsequent ohne fortgeschrittene RE-Techniken anwenden, also etwa ausschließlich mit Benutzergeschichten, Epen und Themen arbeiten, funktioniert der Entwicklungsprozess trotzdem – nur eben weniger effizient, weil dann wichtige Rückmeldungen und Erkenntnisse vor allem erst nach der Inkrementierung, nach einer jeden Iteration entstehen, während mit fortgeschrittenen RE-Mitteln ein nennenswerter Teil davon ohne großen Aufwand vorher hätte antizipiert werden können. ()