Es war zwar einiges an Arbeit, aber Michelle hat aus ihren Fehlern gelernt (siehe Teil 1). Nachdem das erste agile Projekt nach kurzer Zeit am Testprozess gescheitert war, ist der Plan für den zweiten Anlauf, jenen automatisiert und parallelisiert abzuwickeln.
Die Parallelisierung soll verhindern, dass Entwickler zwischen Sprints Pausen einlegen müssen, um auf die Testergebnisse zu warten. Die Automatisierung soll es möglich machen, die Tests in der kurzen Zeit auch gewissenhaft durchzuführen. Michelle hat einen dedizierten Tester für die Durchführung des Testprozesses beauftragt.
Der musste dafür erst einmal geschult werden, denn er hatte bisher hauptsächlich manuell getestet. Doch Michelle ist sich sicher: die Schulung sowie die Wahl der Tools war ein Erfolg! Dieses Mal hat sie wirklich an alles gedacht: Ein Komplettpaket der agilen Softwareentwicklung in der Bank-IT; natürlich inklusive der altbekannten Dokumentation!
Die widerspricht zwar dem agilen Grundsatz, dass ein funktionierendes Produkt wichtiger ist als die sorgfältige Dokumentation, aber Michelle arbeitet nun einmal in einer Bank. Die regulatorischen Vorschriften müssen eingehalten werden; und damit auch die prüfungssichere Dokumentation. Glücklicherweise kennt Michelle den Dokumentationsvorgang aus früheren Projekten.
Der zweite Anlauf des Projekts startet… und stockt nach dem dritten Sprint. Was ist denn jetzt wieder los? Die Kollegen beschweren sich über einen Overhead und Verzögerungen. Wie konnte das passieren?
Was ist schiefgelaufen?
Michelles Projekt stockt an zwei Fronten: einerseits bei der Dokumentation, andererseits weiterhin bei den Tests.
Das Problem bei der Dokumentation: Während das Team den agilen Richtlinien zur Dokumentation folgt, dokumentiert es zusätzlich nach altbekannter Art und Weise. Das ist eine Vorsichtsmaßnahme. Michelle arbeitet in einer Bank und kann es sich nicht leisten, regulatorische Vorgaben unzureichend zu erfüllen. Um im Zweifelsfall prüfungssicher zu sein, wird deshalb die bekannte und somit sichere Dokumentation weitergeführt. Es entsteht ein Overhead an Dokumentation.
Das Problem beim Testprozess greift tiefer. Die Parallelisierung und Automatisierung der Tests war ein wichtiger erster Schritt, reicht jedoch nicht aus. Der Knackpunkt: ein Tester allein kann selbst mit automatisierten Tests nicht alles testen, insbesondere wenn die zu testende Software von Sprint zu Sprint größer bzw. komplexer wird. Wie ist das zu lösen?
Lösung:
Das Dokumentationsproblem ist einfach zu lösen. Mit dem richtigen Know-how und Erfahrung kann auch die Vorgehensweise der agilen Dokumentation prüfungssicher sein. Der Dokumentations-Overhead ist schlicht ein Symptom mangelnder Erfahrung.
Schwieriger ist das Testproblem. Hier muss das Mindsets der Mitarbeiter bzw. das Rollenverständnis umgekrempelt werden. Die strikte Trennung von Tester und Entwickler im agilen Umfeld funktioniert nicht. Wer entwickelt, ist auch Tester. Wer testet, ist auch Entwickler.
Im Idealfall werden die Komponententests sogar schon vor der Entwicklung geschrieben: Test Driven Development. Hier schreibt der Entwickler zunächst die Testszenarien, welche das Verhalten des Codes testen sollen. Im Anschluss erst wird der Code geschrieben und fortführend optimiert. Auch hilft es dem Prozess, in der Software bereits jetzt Vorkehrungen für eine Oberflächentestautomatisierung zu treffen und im Team zu kommunizieren, damit eine starke Parallelisierung der Entwicklungstätigkeiten stattfinden kann.
Norman Schmidt, Manager
Christoph Dibbern, Managing Consultant
