Fast scheint es, als schwinge etwas Wehmut mit, wenn IT-Consultant Christopher Koch über die „Anforderungstapete“ redet. Er meint damit den Dschungel, der traditionell bei komplexen Softwareprojekten schon während der Festlegung der Anforderungen entsteht. Förderlich für den Entwicklungsprozess ist das freilich nicht – und schon gar nicht bei einer agilen Herangehensweise.
Zum Glück gibt es andere Ansätze. Diese kamen bei ITGAIN beispielsweise für eine Versicherungsgruppe zum Einsatz und bestehen grob aus zwei Komponenten: Behavior Driven Development (BDD) und Test Driven Development (TDD).
Kürzere Entwicklungszeiten, bessere Kommunikation
Behavior Driven Development (BDD) verbessert die Abstimmung zwischen Fachleuten und Softwareentwicklern: Anforderungen werden mittels einer einfachen formalen Syntax definiert, die gleichzeitig die Grundlage für automatisierte Tests darstellt. Fachleute und Programmierer sprechen also die gleiche Sprache.
Test Driven Development (TDD) ist ideal, um diese formal definierten Anforderungen in Software umzusetzen. Im Gegensatz zur konventionellen Entwicklung startet man hier nämlich mit der Definition eines erfolgreichen Software-Tests. Die Programmierung folgt anschließend diesen Testanforderungen solange, bis der Test letztlich erfolgreich verläuft. Dadurch wird der Code schlanker und besser, es wird Zeit gespart und nachträgliche Änderungen der Anforderungen können sehr viel besser eingepflegt werden.
3 Fragen an Christopher Koch
Herr Koch, neue Methoden einzuführen kostet immer auch Geld. Lohnt sich das im Fall von BDD/TDD wirklich?
Natürlich bedeutet so etwas auch immer eine gewisse Investition. Allerdings spart die testgetriebene Entwicklung mittel- bis langfristig sehr viel Geld: Teure Fehlermeldungen und Systemabstürze werden vermieden, Entwicklungsressourcen viel effizienter genutzt, man kann sehr viel schneller auf das Marktgeschehen reagieren – um nur einige handfeste Vorteile zu nennen.
Haben Sie schon Schwierigkeiten bei der Umstellung erlebt?
Klar stehen manche Entwickler, die schon 20 Jahre nach der alten Methode arbeiten, vor gewissen Herausforderungen bei der Umstellung. Es handelt sich ja um einen Paradigmenwechsel. Aber wenn man einmal nach den neuen Prinzipien gearbeitet hat, merkt man schnell, wie sinnvoll diese sind. Bei unserem Kunden ist nun außerdem BDD/TDD fest im Schulungskonzept verankert, sodass zum Beispiel Azubis und Studenten dies bereits von Anfang an lernen.
Würden Sie sagen, dass BDD/TDD bei der digitalen Transformation hilft?
Absolut! Markt und Kunden wünschen neue Funktionen in immer kürzeren Abständen. Mit dem neuen Ansatz hat man innerhalb von zwei bis drei Wochen Ergebnisse, die erweiterbar sind. Es geht auch darum, schnell in den Entwicklungsprozess einzusteigen, auch wenn man noch nicht alle Anforderungen bis ins Detail kennt. Insofern ist BDD/TDD die Voraussetzung für eine moderne agile Entwicklungsmethode.
Experiment bestätigt Überlegenheit von BDD/TDD
Neue Methoden einzuführen bedeutet immer auch eine gewisse Umgewöhnungsphase. Deshalb wollte man es bei ITGAIN ganz genau wissen: Lohnt sich BDD/TDD? Ein Experiment sollte Klarheit bringen: Eine Entwicklungsaufgabe wurde bei ITGAIN parallel nach der neuen Methode und nach der traditionellen Herangehensweise gelöst. Das Ergebnis: Die Entwicklung entlang von spezifizierten Testanforderungen ging wesentlich schneller und das Ergebnis war wesentlich schlanker. Der Grund dafür ist, dass der Entwickler sich nicht auf Nebengleisen verliert, sondern immer und ausschließlich genau entlang der Anforderungen entwickelt. Der Fokus wird so sehr viel schärfer.
„Ich würde so weit gehen zu sagen, dass BDD/TDD Voraussetzung für eine wirklich agile Herangehensweise ist“, resümiert Christopher Koch. Durch den modularen und formalen Aufbau der Anforderungen entstünden kleinere „Häppchen“ – das begünstige die Modularisierung und schnelle Implementierung von neuen Anforderungen. Auch werde durch die Orientierung an Tests die Fehleranfälligkeit deutlich reduziert.
Ein wesentlicher Grund für die Effizienz von testgetriebenen Ansätzen ist allerdings weniger technisch als organisatorisch. Die Methode erfordert neue Formen der Zusammenarbeit. Entwickler und Fachleute finden an einen Tisch zusammen und verständigen sich. „Früher lief es oft so, dass der Entwickler einen Zettel mit Anforderungen bekam, die er dann prompt zurückspielen musste, weil er nicht verstand, was man von ihm will“, schildert Koch die Situation. „Mit BDD/TDD passiert das seltener und es entstehen weniger Reibungsverluste – ein immenser Vorteil, gerade bei komplexen Aufgaben wie in der Versicherungs- oder Finanzbranche.“