Für Agilität doch noch nicht zu spät?

Stellen Sie sich vor, Sie arbeiten jahrelang als Systemanalyst im Automotivekontext. Die Methoden des klassischen Requirements Engineering sind Ihnen in Fleisch und Blut übergegangen, Sie kennen die Stärken und Schwächen. Nun werden Sie mit agilen Werten und Prinzipien konfrontiert. Wurde der Samen einmal gepflanzt, ist ein Umdenken nicht mehr aufzuhalten.

Ich möchte kurz meine Tätigkeit und den damit verbundenen Arbeitsalltag skizzieren. Als Systemanalyst im klassischen Requirements Engineering ist es meine Aufgabe, als Übersetzer zwischen Kunden auf der einen und Entwicklern auf der anderen Seite zu agieren. Verhandlungen mit dem Kunden sind langwierig, jede Anforderung wird auf die Goldwaage gelegt. Bis es zu einem für beide Seiten akzeptablen Stand kommt, vergeht viel Zeit. Generell hat die akribische Dokumentation von Anforderungen einen hohen Stellenwert. Der Prozess, der zu einer Anforderungsspezifikation führt, ist komplex und erfordert viel Einarbeitungszeit. Komplexe Prozesse bedeuten wiederum Trägheit. In den letzten vier Jahren hat sich trotz vermehrter Probleme nichts an der generellen Vorgehensweise geändert.

Vor kurzem wurde ich bei meinem Kunden nun mit dem agilen Manifest und den darin enthaltenen Werten konfrontiert. Diese lauten:

• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen
• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Reagieren auf Veränderungen mehr als das Befolgen eines Plans

Diese vier einfachen Prinzipien haben mich zum Nachdenken gebracht – und ich stelle fest, dass diese das genaue Gegenteil meines Alltags darstellen. Wird es vielleicht Zeit umzudenken?

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen

Direkt fällt mir ein, wie viel Zeit ein Projekt sparen könnte, wenn es nicht in der Anfangsphase durch träge und langwierige Vertragsverhandlungen blockiert würde. Ist es wirklich notwendig, das Anforderungsdokument nach einhundert Iterationen auch zum einhundertersten Mal infrage zu stellen? Oder wurde eine ausreichende Reife nicht längst erreicht? Ist es wirklich problematisch, dass eine Anforderung nicht exakt nach Lehrbuch formuliert wurde, wenn aber doch jeder versteht, was gemeint ist? Die Erfahrung zeigt, dass die Produktentwicklung bereits lange vor Finalisierung des Lastenhefts beginnt, und die Spezifikation nur noch ein reines Vertragsdokument ist, welches im Falle von Problemen wieder hervorgeholt wird – um den oder die Schuldigen zu finden. Hier erkennt man auch gut das grundsätzliche Problem: fehlendes Vertrauen. Wäre das Vertrauen zwischen Kunde und Lieferant größer, und beide Seiten gingen davon aus, dass sie ihr Möglichstes tun, um das Produkt zum Erfolg zu führen, wären zähe Vertragsverhandlungen schlicht unnötig, und man könnte die wertvolle Zeit lieber direkt in die Produktentwicklung fließen lassen.

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Gerade das Thema Prozesse und die zugehörigen Werkzeuge erlebe ich im Alltag vielmehr als Last, denn als Bereicherung. Oftmals von Theoretikern ohne Praxisbezug erdacht, schränken unnötig komplizierte Prozesse die Zusammenarbeit zwischen Projektbeteiligten ein. Was in der Theorie als tolle Idee erscheint, wirft in der Praxis Fragen und Probleme auf, die man ohne diese Prozesserweiterung gar nicht gehabt hätte. Der Prozess wird zum Selbstzweck. Wie viel einfacher ist es doch, seinen Schreibtisch zu verlassen und sich mit einem Problem zum Kollegen zu begeben, anstatt z.B. einen aufgeblähten Change Management Prozess zu befriedigen!

Funktionierende Software mehr als umfassende Dokumentation

Meiner Erfahrung nach neigen die meisten Projekte dazu, viel zu viel zu dokumentieren. Die Anforderungsspezifikation ist so komplex, dass sie gar nicht als Basis für die Entwicklung dienen kann, denn sie ist zum Entwicklungsstart schlicht und einfach noch lange nicht fertig. Dadurch sinkt natürlich auch die Akzeptanz der Spezifikation. Wenn es ohne sie möglich ist, das Produkt zu entwickeln, welchen Mehrwert soll sie einem eh schon skeptischen Entwickler noch bieten? Man muss sich also die Frage stellen, in welcher Tiefe eine Dokumentation vorhanden sein soll. Ich plädiere dafür, so wenig wie möglich, und so viel wie nötig zu dokumentieren. Overhead in der Dokumentation erzeugt nur Belastungen bei den Projektbeteiligten. Gerade bei einem streng definierten Prozess erzeugt jede überzählige Anforderung Aufwände, die vermieden werden könnten. Auch der Zeitpunkt der Dokumentation ist einen Blick wert – denn, wann wird die Dokumentation benötigt? Nicht Monate vor der Entwicklung, wo die Anforderungen noch völlig abstrakt erscheinen, aber auch nicht erst nach der Implementierung, sodass die Dokumentation zur reinen Geschichtsschreibung wird. Anforderungen sollten genau dann geschrieben werden, wenn sie benötigt werden. Die Spezifkation sollte also gemeinsam mit der Entwicklung voranschreiten.

Reagieren auf Veränderungen mehr als das Befolgen eines Plans

Dieser letzte Punkt erscheint mir zugleich auch am schwersten umzusetzen, denn er wird stark beeinflusst durch alle drei vorher skizzierten Probleme. Trägheit bei Vertragsverhandlungen, Trägheit im Prozess und Trägheit bei der Erstellung der Dokumentation sorgen dafür, dass das gelebte Vorgehen im Requirements Engineering nahezu zementiert erscheint. Das Thema wird derart komplex, dass sich niemand mehr traut, ein Einzelteil aus diesem Gerüst herauszuziehen – aus Angst, alles würde zusammenstürzen?

Die Auseinandersetzung mit diesen agilen Werten hat mich zum Nach- und Umdenken gebracht. Ich zweifle an der Richtigkeit vermeintlich altbewährter Praktiken und versuche, mich jeden Tag daran zu erinnern, wie viel einfacher, wie viel agiler die Entwicklung doch voranschreiten könnte – es bedarf nur eines mutigen, ersten Schrittes, alte Lasten über Bord zu werfen!

Marcel Klein

Kontaktieren Sie Marcel Klein

Marcel Klein arbeitet bei der HOOD GmbH als Consultant und als Trainer im Bereich Requirements Engineering. Seine Tätigkeitsschwerpunkte liegen in der Unterstützung unserer Kunden beim Einsatz von Requirements Engineering und zugehöriger Werkzeuge (z.B. DOORS). Zu seinen Aufgaben zählen die Erhebung, Verbesserung und Dokumentation von funktionalen und nicht-funktionalen Anforderungen, die Prozessverbesserung sowie die Erstellung von objektorientierten Modellen. Als Trainer hat er sich vor allem auf die gute Formulierung textueller Anforderungen und die nachhaltige Etablierung von Requirements Engineering in einem Unternehmen spezialisiert. Er veröffentlicht regelmäßig zu beiden Themen Artikel und Blogs.