Anforderungsmanagement im agilen Umfeld

Der kürzlich erschienene Artikel zum agilen Systems Engineering wurde sehr positiv aufgenommen. Die Resonanz zeigte deutlich, dass das Thema agil nach wie vor hochaktuell ist.

Die Anmeldung für das Modeling Craftsmanship Camp am 18.11. in Hannover läuft (Anmeldung >>), und das  systems.camp Nord der GfSE am 7.10. in Hamburg ist bereits halb ausgebucht (Anmeldung >>)

Ein sehr wichtiger Teilbereich des Systems Engineering ist das Requirements Engineering. Da Maik Pfingsten kürzlich ein Gespräch zu dem Thema mit Michael Mahlberg beim Zukunftsarchitekten geführt hat, möchte ich das Thema hier aufgreifen.

Das Gespräch war interessant und ist hörenswert. An einigen Stellen konnte ich zunächst den beiden nicht unqualifiziert zustimmen. Im Laufe des Podcasts merkte ich aber, dass dies wohl daran lag, dass der Kontext nicht explizit gesetzt wurde. Die Fragen von Mike spielten darauf an, agiles RE im Bereich Embedded und funktionaler Sicherheit einzusetzen. Die Antworten von Michael implizierten, dass er eher an die reine Softwareentwicklung dachte in Bereichen, wo Sicherheit eine untergeordnete Rolle spielt. In beiden Bereichen kann agiles RE betrieben werden, aber die Anforderungen an die Entwicklung unterscheiden sich erheblich. Gerade solche Nuancen machen solche Aufnahmen interessant und regen zum Denken an.

Wer ist im agilen RE für die Anforderungen verantwortlich?

Die Kernfrage von Maik war, wie sich RE im agilen Umfeld vom traditionellen Umfeld unterscheidet. Dabei wurde implizit davon ausgegangen, dass die Zuhörer mit RE im traditionellen Umfeld zumindest rudimentär vertraut sind. Vor diesem Hintergrund stellt sich die Frage, wer im agilen Umfeld überhaupt für die Anforderungen verantwortlich ist, denn die Rolle des Requirements Engineers gibt es in der Regel gar nicht. Wer sich in agiler Entwicklung auskennt, der würde auf den Product Owner tippen, doch laut Michael ist dies weder wünschenswert noch realistisch, da dieser selten alle erforderlichen Kompetenzen vereint. Stattdessen sieht er es als Teamarbeit, die Anforderungen zu bearbeiten.

Es ist – bei den realen Besetzung dieser Rolle – weder wünschenswert noch realistisch, dass der Product Owner alle Anforderungen alleine beschreibt (Michael Mahlberg) Twittern

Anforderungen werden auch nicht fertiggestellt und dann umgesetzt. Hier wurde die Analogie zum traditionellen Lastenheft gezogen, das an den Umsetzer übergeben und in der Form eines Pflichtenhefts beantwortet wird. Stattdessen verglich er die Anforderungen mit einem Klumpen, der im Laufe des Projekts umgeformt wird. Dabei stellte sich die Frage, welche Elementtypen denn im agilen Umfeld eingesetzt werden. Hier kam die Antwort, dass im agilen Umfeld die Artefakte eher aus „im Wiki zusammengetackerten Elementen“ bestehen.

An dieser Stelle vertrete ich eine andere Meinung: Im agilen Umfeld ist der Umgang mit Änderungen ein wesentlicher Erfolgsfaktor. Um jedoch mit Änderungen umgehen zu können, brauchen wir saubere Grenzen zwischen Informationselementen und sauber definierte Beziehungen (Traceability). Das hier beschriebene Vorgehen kann sicher für kleine Projekte funktionieren. Aber ich sehe hier Skalierungsprobleme, insbesondere, wenn die Entwicklung Aspekte der funktionalen Sicherheit beinhaltet. Und im Bereich der funktionalen Sicherheit ist so ein Vorgehen nicht akzeptabel. Was übrigens auch später von Maik aufgegriffen wurde.

Lifecycle: Ein wichtiger Unterschied im agilen RE

Ein wesentlicher Unterschied besteht bezüglich des Lifecylces in der Entwicklung. Dabei sieht Michael traditionell vieles vorgelagert („Wasserfall“), während beim agilen RE viele Anforderungen erst im Prozess entstehen. Dabei wies er auch auf kleine aber wichtige Unterschiede der verschiedenen Vorgehen hin, bspw. Scrum vs. Lean. Das halte ich auch für einen sehr wichtigen Aspekt, denn agil ist nicht gleich agil. Ein Diskussionspunkt war der zeitliche Aufwand für die Erstellung eines Lastenhefts, wobei eine Dauer von 6-9 Monaten genannt wurde, was durchaus in der traditionellen Praxis vorkommt. Das kann jedoch laut Michael auch im agilen Umfeld vorkommen, wobei das Schreiben des Lastenhefts dann nicht vorgelagert ist, sondern ein Transformationsprozess von Lastenheft zu Pflichtenheft ist, der parallel zu der Entwicklung abläuft. Auch hier stimme ich nicht ganz zu: für mich sollten auch im agilen Umfeld Problem und Lösung voneinander getrennt bleiben.

Mit Änderungen umgehen

Erst spät in der Diskussion kam ein Thema auf, welches ich im agilen Umfeld für extrem wichtig halte: Baselines, Traceability und ein daraus abgeleitetes Änderungsmanagement.

Michael vertrat den Standpunkt, dass Baselines für Revisionssicherheit overkill sein können, da in einem (bspw.) Wiki-basierten System jede Seite sowieso versioniert wird und somit die Historie leicht greifbar ist. Das hat er durchaus recht, aber das ist meiner Meinung nach nur ein möglicher Anwendungsfall von Baselines. Der Clou bei Baselines ist es ja, dass eine Gruppe von Elementen zusammengefasst wird. Der klassische Anwendungsfall ist es, dass eine Baseline mit einer anderen, oder dem aktuellen Stand, verglichen wird. In dem Scenario interessieren mich nicht alle kleinen Änderungen, sondern nur der Unterschied zwischen den beiden Baselines. Wenn dabei ein einzelnes Element auffällig wird, kann dessen Historie im Detail untersucht werden.

Ebenso die Frage nach der Traceability. Dort sah Michael die Anwendung primär darin, die Auswirkungen von Änderungen abzuschätzen, also die klassische Impaktanalyse. Er sah weniger Wert darin, im Nachhinein Änderungen nachzuvollziehen – primär wegen des anfangs angesprochenen Umwandlungsprozesses: Die zu verfolgende Information ist nach der Weiterentwicklung vielleicht schon verschwunden.

Einen Baum vom groben Requirement bis zum Detail habe ich im agilen Umfeld auch, nur zu einem viel späteren Zeitpunkt (Michael Mahlberg) Twittern

Das ist der Grund, warum ich – gerade im agilen Umfeld – eine klare Trennung von Problem und Lösung für so wichtig halte: Während sich die Lösung sehr schnell ändern kann (und wird), bleibt die Problemstellung relativ stabil. Wenn sich aber die Problemstellung ändert, ist es umso wichtiger, alle Implikationen davon zu prüfen. Das klassische Mittel von fast allen RE-Werkzeugen sind die „suspekten Links“. Konkretes Beispiel aus dem Podcast: „Der Nutzer muss sich authentisieren.“ Nun kann eine Lösung iterativ entwickelt werden. Wenn sich während der Entwicklung der Lösungsansatz ändert, so ist das für die Problemstellung irrelevant. Wenn die Problemstellung jedoch ergänzt wird, bspw. „mit 2-Faktor Authentisierung“, so ist es wichtig, alle abhängigen Lösungselemente als „suspekt“ zu markieren. Ansonsten würde vielleicht beim Password-Recovery-Link der zweite Faktor vergessen werden.

Während des Podcasts musste ich lachen, denn Maik bemerkte, „Du hast etwas beschrieben, was in meiner Welt ein hochiteratives V-Modell darstellt“. Dem wiederum kann ich voll und ganz zustimmen: Das ist auch das, was ich im Artikel „agile Systementwicklung beschrieben hatte“. Um so etwas jedoch leben zu können, müssen Artefakte sauber getrennt und sauber verknüpft sein.

Agiles RE ist in meiner Welt ein hochiteratives V-Modell (Maik Pfingsten) Twittern

Fazit

Der Podcast war voller guter Ideen. Die teilweise widersprüchlichen Aussagen ließen sich dadurch erkennen, dass hier agiles RE von zwei unterschiedlichen Richtungen beleuchtet wurde: Sowohl aus dem bekannten Bereich der agilen Softwareentwicklung, als auch aus der sicht der Embedded-Entwicklung, in der agiles RE noch nicht so weit verbereitet ist. Diese nicht explizit ausgesprochenen Unterschiede können unter Umständen beim Hörer zur Verwirrung führen.

Aber mit diesem Unterschied im Kopf machten Maiks Kommentare zu über funktionale Sicherheit und Systems Engineering Sinn. Michael hingegen sprach über Eingabemasken und Softwarecode. Für solche Entwicklungen kann ein Wiki durchaus ausreichend sein.