Endlich! Die agile Transformation hat auch in Michelles Bank Einzug gehalten. Michelle verspricht sich viel von dem neuen Framework. Vor allem aber schnellere Ergebnisse! Einen ersten Test kann Michelle direkt mit dem neuen Projekt durchführen.
Aufgrund der regulatorischen Anforderungen der Aufsicht an Banken kann Michelles Projekt nicht ganz so lean und clean verlaufen wie agile Projekte in anderen Softwarehäusern. Darüber hinaus ist das Projekt auch noch das erste agile Projekt in ihrer Bank! Michelle schaut also mit positiven Erwartungen, aber auch mit Sorge auf das Projekt.
Doch von nichts kommt nichts. Also: User Stories erstellt, Definition of Done geklärt und los geht es!
Der erste Sprint läuft entgegen Michelles Erwartungen recht flüssig ab. Sie ist positiv überrascht.
Doch dieses Glück hält nicht lange: Der hochgelobte Geschwindigkeitsvorteil der agilen Entwicklung zeichnet sich nicht ab. Die Sprints sollen jeweils gleich lang dauern, doch tatsächlich werden sie immer länger, da die Sprintziele nicht rechtzeitig erreicht werden. Agilität – nur ein Hype?
Nach einer Überprüfung der Arbeitsabläufe kann Michelle den Testvorgang als Problemkern isolieren. Aber was muss geändert werden?
Was ist schiefgelaufen?
Michelle hat das Vorgehen der agilen Softwareentwicklung in Grundsätzen korrekt aufgezogen. Einen wichtigen Bestandteil hat sie jedoch außer Acht gelassen: Das agile Testen.
Die agile Softwareentwicklung lebt von dem graduellen Aufbau einer Entwicklungsstufe (Sprint n) auf die vorherige (Sprint n-1), die wiederum auf die davor erstellte Entwicklungsstufe aufgebaut hatte (Sprint n-2). Eine Entwicklungsstufe, und damit ein Sprint, ist allerdings erst tatsächlich abgeschlossen, wenn auch der Testprozess abgeschlossen ist.
Michelle war zu sehr in ihren klassischen Denkstrukturen gefangen und hat den Testprozess, wie im klassischen Entwicklungsprozess üblich, hintenangestellt. Das funktioniert bei der agilen Entwicklung jedoch nicht: Die Erkenntnisse aus dem Test der Ergebnisse aus Sprint 1 müssen bei Sprint 2 bereits vorliegen. Wird der Test hintenangestellt können die Entwickler entweder erst weiterarbeiten, wenn der Prozess abgeschlossen ist, oder sie arbeiten mit einer ungetesteten Software aus Sprint 1 weiter. Hier entsteht das Risiko, dass diese Version kritische Fehler aufweist, die erst später festgestellt werden und eine noch zeitaufwändigere Fehlerbehebung nach sich ziehen. In beiden Szenarien verliert die agile Softwareentwicklung den Vorteil der schnell möglichen Releases. Was also tun?
Lösung:
Die Lösung niederzuschreiben ist einfacher, als sie umzusetzen: Der Testprozess muss parallel zum Entwicklungsprozess laufen, um den Geschwindigkeitsvorteil der agilen Softwareentwicklung ausnutzen zu können. Tester und Entwickler dürfen nicht mehr getrennt voneinander arbeiten.
Durch die Parallelisierung können die Testergebnisse aus Sprint 1 direkt in Sprint 2 beachtet werden. Dies wird durch eine Testautomatisierung ermöglicht: Manuelles Testen kann den Arbeitsaufwand nicht bewältigen.
Um diese Testautomatisierung im agilen Umfeld umsetzen zu können, müssen die richtigen Tools ausgewählt und Tester geschult werden.
Wie also wird Michelle die Herausforderung der Testparallelisierung und -automatisierung lösen; und wird dadurch ihr Projekt zum Erfolg? Das finden Sie in Teil 2 heraus!
Norman Schmidt, Manager
Christoph Dibbern, Managing Consultant
