Agile Softwareentwicklung benötigt mehr Werkzeuge

In den 90er Jahren und noch zu Beginn des Jahrtausends haben wir sogenannte CASE-Tools (Computer Aided Software Engineering) verwendet, um zuerst ein Design in Form eines großen, komplett durchdachten UML-Modells zu erstellen, bevor wir anfingen, die Details zu kodieren. Rückblickend habe ich mich gefragt, was uns damals dazu gebracht hat, solch ein “Big Upfront Design” zu erstellen. Nicht nur ich, sondern auch meine Kollegen waren damals der festen Überzeugung, dass dies die einzige Möglichkeit sei, am Ende ein robustes Stück Software zu erhalten und nicht mit einer durch Änderungen verunstalteten, nicht mehr wartbaren Menge an Quellcode zu enden.

Einige Jahre später stellte ich fest, dass wir nicht mehr dieses “Big Upfront Design” erstellten und trotzdem besseren Code denn je erzeugten. Was hatte sich geändert?

Es erschien mir plötzlich so, dass Klassenstrukturen einfach direkt im Code entstanden, die wir früher bedächtig mit unseren CASE-Tools planten. Inzwischen verwendeten wir eine Entwicklungsumgebung, die das Aufräumen von Code praktisch per Fingerschnipp ermöglichte. Das Umbenennen von Klassen, das Umziehen von Methoden, das Anpassen von Referenzen, alles Dinge, die uns früher Stunden gekostet hätten, gingen mittlerweile in Minuten, wenn nicht Sekunden vonstatten und man konnte das Design nun viel schneller an geänderte Bedürfnisse anpassen.

Dieses Beispiel zeigt mir, dass Werkzeuge, in diesem Falle die Refactoring-Komponente der Entwicklungsumgebung, durchaus dazu in der Lage sind, das Reagieren auf Veränderung zu unterstützen, einen Wert des Manifests für Agile Softwareentwicklung. Doch was bedeutet das generell für die Bewertung von Werkzeugen für die agile Softwareentwicklung? Im Agilen Manifest heißt es doch auch:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Sollte man daher nicht annehmen, dass Werkzeuge in der agilen Softwareentwicklung in den Hintergrund treten, oder dass es gar Werkzeuge gibt, die schlecht für agile Softwareentwicklung sind?

Werkzeuge werden durch Menschen genutzt, die damit einen bestimmten Zweck verfolgen. Das Werkzeug erfüllt oder unterstützt idealerweise den beabsichtigten Zweck.

In meinen Augen lassen sich Werkzeuge hinsichtlich ihrer Tauglichkeit für agile Softwareentwicklung am ehesten an ihrem beabsichtigten Zweck beurteilen. Ein für agile Softwareentwicklung untaugliches Werkzeug wäre beispielsweise eines, das als Zweck die Fremdkontrolle durch Vorgesetzte oder das strikte Befolgen von Plänen unterstützt. Taugliche Werkzeuge dagegen würden z.B. als Zweck die Zusammenarbeit mit dem Kunden oder, wie in unserem obigen Beispiel, das Reagieren auf Veränderung unterstützen. Um weitere positive Zwecke zu finden, können wir uns auch an den Zwölf Prinzipien Agiler Softwareentwicklung bedienen.

Wir sehen also, dass es durchaus noch Potential zur Innovation von Werkzeugen im agilen Umfeld gibt.

Die Wahrscheinlichkeit, dass ein Werkzeug tatsächlich einem sinnvollen Zweck im Sinne des Agilen Manifests gerecht wird, ist umso höher, je näher das Werkzeug an der Tätigkeit ist, auf die es ankommt, dem Schaffen funktionierender Software. Als Beispiel sei an dieser Stelle der Beitrag “Dokumentation von Anforderungen mit Code Based Modeling” genannt, in dem mein Kollege Bertil Muth einen Ansatz vorstellt, mit dem man den Code zu einer verständlichen Anforderungsspezifikation erhebt. Leider fehlt uns heute noch eine ausgereifte Werkzeugunterstützung dafür. Langfristig benötigen wir mehr Werkzeuge.

Philip Stolz

Kontaktieren Sie Philip Stolz

Herr Philip Stolz ist als Senior Consultant im Bereich Requirements Engineering (RE) tätig. Seine Schwerpunkte liegen in der Einführung und Prozessverbesserung von Requirements Engineering (RE). Herr Stolz verfügt über eine fundierte Ausbildung im Bereich Software Engineering (Dipl.-Inf., Softwaretechnik). Durch Erfahrung aus unterschiedlichen Entwicklungsprojekten in verschiedenen industriellen Branchen sind ihm typische Projektsituationen sowie das Vorgehen bei der Einführung methodischer Verfahren innerhalb von Projektteams bekannt.