Requirements Engineering in Zeiten der Agilität

Inhaltsverzeichnis

Der Hype um agile Vorgehensweisen in der Softwareentwicklung ist vorbei. Vielerorts haben sie sich durchgesetzt. Häufiger jedoch ist heute ein Mix aus klassischen und agilen Techniken anzutreffen. Wie wirkt sich die Mischung auf das Requirements Engineering aus, und wie wird es in agilen Projekten eingesetzt?

"Unser Projektteam arbeitet agil." Die Aussage hört man immer häufiger in unterschiedlichen Branchen. Betrachtet man die Projekte etwas näher, stellt sich heraus, dass die meisten keinem streng agilen Vorgehen folgen, wie von ihren Urhebern vorgegeben. Vielmehr haben sich Methoden der klassischen Softwareentwicklung mit unterschiedlichen Aspekten der Agilität vermischt. Viele Teams führen ihre Projekte leichtgewichtiger als noch vor einigen Jahren durch.

Das Requirements Engineering befindet sich aktuell im Umbruch. Man muss nicht mehr streng nach dem Wasserfallmodell oder anderen schwergewichtigen Vorgehen spezifizieren. Vielmehr sind die Methoden um agile Techniken erweitert. Requirements Engineering und damit der Systemanalytiker müssen nicht mehr zwangsläufig kurz vor Beginn der Implementierung ein seitenstarkes und komplexes Werk von Anforderungen als Ergebnis liefern.

Das Zeitalter der klassischen Anforderungsdokumente, die ihre Leser mit unzähligen Seiten unstrukturierter und nicht formalisierter Prosa überschütten, neigt sich offenbar seinem Ende zu. Angesichts dessen bleibt offen, wie Requirements Engineering in der Ära agiler Softwareentwicklung aussehen soll. Wie kann oder muss es verwirklicht werden, damit es im Rahmen der neuen Bedingungen nicht mit veralteten Methoden zum belastenden Relikt mutiert? Wie viel Requirements Engineering benötigt man in agilen Projekten wirklich?

Weniger dokumentieren

Viele Projekte setzen heute einen Aspekt des Agilen Manifests besonders um: "Dokumentieren Sie nur so viel wie nötig, jedoch so wenig wie möglich." Für Anforderungen bedeutet das, Informationen wegzulassen, die früher zwar dokumentiert, doch von niemandem genutzt wurden. Damit reduziert sich der Umfang des Spezifikationsdokuments. Um eine Entscheidung zu treffen, wie viel nun wirklich zu dokumentieren ist, sind die Projektrisiken zu betrachten. Anforderungen sind nur zu dokumentieren, falls die Dokumentation die Eintrittswahrscheinlichkeit eines oder mehrerer Risiken verringert oder falls die Anforderungen unmittelbar für andere Rollen im Projekt und ihre alltägliche Arbeit vonnöten sind.

Das Ende des Wasserfalls

Das Vorgehen nach dem Wasserfallprinzip stirbt langsam aus. Projekte bewegen sich hin zu iterativen und inkrementellen Prozessen. Iterationen und Inkremente gab es zwar schon vor der Geburtsstunde der Agilität – nun sind sie allerdings akzeptiert und nicht mehr aus Projekten wegzudenken. In relativ kurzen Iterationen (beispielsweise drei Wochen) zu arbeiten und innerhalb der Zeit Analyse, Architektur, Implementierung und Test durchzuführen, sodass am Ende jeder Iteration eine getestete und lauffähige Version einer Software steht, bringt den großen Vorteil mit sich, Feedback schnell beachten zu können. Und – nicht minder wichtig – die Anpassung des Projekts an sich ändernde Randbedingungen geht viel leichter vonstatten, als wenn sich das Projekt in einem fest definierten starren Vorgehen bewegt. Projekte sind heute aufgefordert, ihre Scheuklappen abzusetzen, über den Tellerrand zu sehen und Produkt, Prozess und Vorgehen ständig zu reflektieren und gegebenenfalls anzupassen.

Die Erfahrung zeigt jedoch, dass Projektteams ein derartiges Verfahren erst erlernen müssen. Das gilt auch für die Systemanalytiker. Teams, die es gewohnt sind, in Phasen von drei bis sechs Monaten zu denken und zu arbeiten, können schlecht von heute auf morgen auf Iterationen von drei Wochen umschalten. Die Planung der ersten Iterationen ist deshalb genau unter die Lupe zu nehmen. Nicht selten verschätzen sich Projekte hier enorm. Auf die Frage, welche Arbeitspakete sich in den nächsten drei Wochen abarbeiten lassen, antworten Beteiligte mit viel zu vielen Arbeitspaketen. Das ist jedoch kaum zu vermeiden und darf passieren. Denn hier kommt erneut die Agilität ins Spiel. Agile Vorgehensweisen setzen auf lernende Teams. Sofern sich die Planung und Durchführung von Iteration zu Iteration immer transparenter und realistischer gestaltet, ist das völlig in Ordnung. Das Team lernt, was es wirklich bewältigen kann. Dadurch steigen meist die Zufriedenheit und die Motivation der Projektmitglieder. Grundlage dafür sind das Reflektieren vergangener und sich daraus ableitende Maßnahmen für zukünftige Iterationen.