Kommunikation in der Anforderungsanalyse

Bilder sagen nicht immer mehr als 1000 Worte

Als Business–Analyst bin ich es gewohnt, dass Bilder, zum Beispiel in Form von Ablaufdiagrammen, meine Kommunikation in Software-Projekten unterstützen. Insbesondere auch in Diskussionen mit Entwicklern. In meinem aktuellen Projekt musste ich lernen, dass die Redewendung „Ein Bild sagt mehr als 1000 Worte“ nicht immer zutrifft. Warum das so ist, möchte ich in diesem Blog-Beitrag erläutern und der Ursache auf den Grund gehen.

Eine Kollegin und ich waren schon mehrere Wochen als Business-Analysten (BA) in einem großen Software-Projekt (im weiteren Projekt A) unterwegs, in engem Austausch mit einem Entwicklerteam. Wie in agilen Projekten üblich gab es dann eine gemeinsame Retro, in der wir unsere Zusammenarbeit auf den Prüfstand stellen und gegebenenfalls Verbesserungen anstoßen wollten. Bis dahin hatten wir den Eindruck eines erfolgreichen Miteinander gewonnen. Zudem waren meine Kollegin und ich beim gleichen Kunden in einem anderen Projekt (im weiteren Projekt B) schon vorher als BAs tätig gewesen und hatten dort ebenfalls positives Feedback vom Entwicklungsteam bekommen.

Die Retro hielt eine Überraschung bereit

In der Retro erfuhren wir, dass es seitens der Entwickler tatsächlich Änderungsbedarf an unserer Vorgehensweise als BA gab: unsere Ablaufdiagramme, die wir ergänzend zu den User Stories als Unterstützung der Spezifikation erstellt hatten, führten bei den Entwicklern eher zu Verwirrung als dass sie sie unterstützt hätten. Im Ergebnis der Retro verständigten wir uns auf ein angepasstes Vorgehen: die User Stories sollten keine detaillierten Abläufe und dafür mehr „fachliches Wollen“ enthalten.

Soweit, so gut. Mich hat diese Retro aber nicht in Ruhe gelassen. Nicht wegen der – berechtigten – Kritik, sondern weil ich nicht recht verstand, warum etwas in dem einen Projektkontext B gut funktioniert hatte und in dem anderen Projektkontext A jetzt nicht. Als Business Analyst bin ich davon ausgegangen, dass sich meine Methoden der Anforderungsanalyse gut übertragen und (fast) überall anwenden lassen. Also ging ich auf die Suche…

Ein Argument der Entwickler war, dass sie versucht hatten, die Implementierung entlang unseres Ablaufes vorzunehmen. Dabei stießen sie auf Probleme, da der schon vorhandene Code nicht zu unserem Ablauf passte. Zugegeben, unser Ablauf war sehr detailliert, stellte jedoch zunächst mal nur den für uns fachlich gewollten Ablauf dar und hatte nicht den Anspruch, die Software im Detail zu beschreiben. Aber er sollte natürlich nicht für Verwirrung sorgen. Das war aber ein erster Hinweis, der mich dazu brachte, die beiden Projekte A und B etwas näher unter die Lupe zu nehmen.

Prozess-getrieben versus Ereignis-getrieben

Beide Projekte wurden bzw. werden bei dem Kunden agil entwickelt, und zwar nach dem Scaled Agile Framework®, kurz SAFe®. Die Anforderungen werden durch Business Analysten getrennt von den Entwicklungsteams in Form von Features spezifiziert und dann in einzelne User Stories heruntergebrochen. Methodisch gibt es also keine Unterschiede. Anders sieht es bei der technischen Architektur aus und das führte mich auf die erste Spur.

Projekt B kann man mit dem Begriff Prozess-getrieben (neudeutsch Process-driven) belegen. Es wurde mit einer zentralen Workflow Engine umgesetzt, welche Nachrichtenflüsse zwischen verschiedenen IT-Systemen orchestriert. Die Besonderheit dabei: die Spezifikation erfolgte mit Hilfe von BPMN (Business Process Model and Notation). Die von uns als BAs modellierten Prozessmodelle wurden von den Entwicklern nur noch leicht adaptiert und flossen dann als XML direkt in den Source-Code der Software ein. Ergänzungen der Entwickler, welche sich auf das Prozessmodell bezogen, waren für uns als BA direkt in dem technischen Prozessmodell sichtbar, das gleichzeitig als technische Dokumentation diente. Hier gab es also eine sehr große Nähe zwischen fachlicher Spezifikation und technischer Umsetzung (siehe Abbildung 1).

Für Projekt A trifft das Schlagwort Ereignis-getrieben (neudeutsch Event-driven) zu. Verschiedene (Micro-)Services kommunizieren über einen Event-Bus, in diesem Fall Kafka. Die einzelnen Komponenten arbeiten autark, es gibt keine „Zentrale“, welche die im System abgebildeten fachlichen Prozesse übergreifend steuert. Aus Sicht der Spezifikation bedeutet das: man modelliert gegebenenfalls auch einen Ablauf (von „Prozess“ spreche ich hier bewusst nicht), und dieser Ablauf wird von den Entwicklern dann in Code umgesetzt. Wird hier aber etwas ergänzt oder ggf. vom technischen Ablauf her ganz anders umgesetzt als fachlich spezifiziert (es muss am Ende ja nur das korrekte Ergebnis geben), dann bekommen wir das als BA erst einmal nicht mit (siehe Abbildung 2). Die technische Dokumentation findet sich zunächst nur im Code wieder.

Erweiterungen in der Software als Stolperstein

Die unterschiedliche technische Architektur in den beiden Projekten wirkt sich also auf die Kommunikation zwischen BA und Entwickler aus. Dort liegt meines Erachtens auch die Ursache für die geschilderten Probleme. Nach weiteren Gesprächen mit Entwicklern aus Projekt A hat sich herausgestellt, dass die detaillierten Ablaufdiagramme nicht an sich kontraproduktiv sind, sondern bei Erweiterungen der Software an ihre Grenzen stoßen. Wenn ein Entwickler in Projekt A auf der grünen Wiese anfängt, seine Methoden zu schreiben, dann hilft ihm der vom BA vorgegebene Ablauf durchaus, sich eine erste Struktur zu überlegen. Bei Erweiterungen durch die Entwickler passiert aber Folgendes:

Als BA kenne ich die technische Umsetzung nicht im Detail. Wenn dann aber fachliche Abläufe sowohl schon Umgesetztes als auch Neues enthalten, dann treffe ich Annahmen oder blende Bestandteile aus, die für das Feature bzw. die User Stories gerade nicht relevant sind. Ist der Entwickler dann damit konfrontiert, die unklaren oder fehlenden Informationen aus dem fachlichen Ablauf auf die Code-Struktur zu übertragen, entstehen große Fragezeichen (siehe Abbildung 3).

Anders sah es hier im Projekt B aus. Im nächsten Spezifikationszyklus konnte ich auf dem von den Entwicklern adaptierten, technischen Prozessmodell aufsetzen. Und selbst ohne diesen Rückfluss waren alle Erweiterungen und Änderungen im Prozessmodell für die Entwickler klar erkennbar, und das neue fachliche Modell floss so wieder als XML in die Software ein (siehe Abbildung 4). Es gab also wenig Spielraum für Interpretationen, und der alte und neue Softwarestand waren direkt vergleichbar. Ihre Änderungen nahmen die Entwickler nur innerhalb der Prozess-Elemente vor, also zum Beispiel bei einem Service-Task, der eine Java-Klasse aufruft. Das Grundgerüst war durch das fachliche Prozessmodell vorgegeben.

Technische Architektur mit Auswirkung auf die Spezifikation

Was folgt nun daraus? Zum einen habe ich gelernt, dass ich als Business Analyst in meiner Arbeit nicht völlig unabhängig bin von der technischen Architektur der Software, die ich spezifiziere. Zum anderen sehe ich Optimierungspotenzial bei der Art und Weise, wie Business Analysten und Entwickler gerade in Software-Projekten mit Ereignis-getriebener Architektur zwischen ihrer fachlichen und technischen Ebene kommunizieren und ihre jeweiligen Ergebnisse dokumentieren. Denn auf Bilder möchte ich doch nicht so ganz verzichten.