Agile Software-Entwicklung: Den Prozess immer im Blick
In einem Kundenprojekt kam es zu folgender Situation: Bei der Einführung eines neuen Releases, welches nach agilen Methoden entwickelt wurde, gab es über einen Zeitraum von ca. 6 Wochen tägliche Emergency Fixes. Daraus entstand der Eindruck bei den Stakeholdern, dass es Qualitätsprobleme in der Software-Entwicklung gab. Auch das Vertrauen der Nutzer in die Software war dadurch angeschlagen.
Ein korrektes agiles Vorgehen garantiert noch keinen Erfolg
Die untere operative Ebene wurde durch ein agiles Entwicklungsteam gebildet. In diesem Team waren neben Entwicklern auch Tester und Product Owner. Somit waren die optimalen Voraussetzungen gegeben. Am Ende eines jeden Sprints wurde ein Software-Teilprodukt fertig gestellt, welches durch den jeweiligen Product Owner auch abgenommen wurde. Als Qualitätssicherungsmaßnahme wurden periodische Regressions-Sprints eingeführt, in denen priorisierte Funktionalitäten (Stories) regressiv getestet wurden. Während dieses Sprints ruhte die Weiterentwicklung, so dass auch die Entwickler Teile der Software testeten. Fehler wurden gefunden und behoben. Soweit ein lehrbuchkonformes Vorgehen bei agiler Software-Entwicklung. Dennoch kam es zu den oben beschriebenen Emergency Fixes und großer Unzufriedenheit bei Auftraggeber und Nutzern.
Der Grund: Das große Ganze nicht im Blick
Im beschriebenen Fall war das agile Team vom übergeordneten Ziel abgeschnitten. Das heißt, jedes Teammitglied wusste zwar, was im aktuellen Sprint verlangt wird, hatte aber über den Rand einer Story nie hinausgesehen. Es fehlte der „rote Faden“, die Story-übergreifenden Abhängigkeiten wurden bei diesem Vorgehen nicht betrachtet.
Die Empfehlung:
Auch in einem agilen Software-Entwicklungsprojekt muss das zu erstellende Produkt zunächst einmal definiert werden. Die Frage bei der Produktkonzeption lautet:
Was soll das Produkt tun?
Welche Funktionalität muss es zur Verfügung stellen?
Welche Prozesse müssen die Benutzer ausführen um die gewünschten Resultate zu erzielen?
Genau diese Prozesse gilt es zu dokumentieren und transparent zu gestalten. Diese Prozesse sind zwingend als Teil des Integrations-/Regressionstests durchzuführen. Nicht nur die Story als solche muss getestet werden, darüber hinaus müssen zusammenhängende und voneinander abhängige Stories im Verbund (integrativ) untersucht werden. Dies wird am sinnvollsten auf Geschäftsprozessebene durchgeführt. Der Product Owner steuert dabei, welche Funktionalitäten umgesetzt werden sollen und die Tester unterstützen mit der Analyse auf Testbarkeit und klären eventuelle Ungenauigkeiten. Idealerweise werden die Stories entlang der Prozesse abgebildet. Nach jedem Sprint ist ersichtlich, wie weit der Prozess bereits als Funktionalität abgebildet wurde bzw. welchen Reifegrad der Prozess erreicht hat. Abhängig vom Reifegrad kann ein „Regressions Sprint“ eingeplant und durchgeführt werden. Somit wird eine Forderung der agilen Methode qualitativ hochwertig erfüllt: Am Ende eine Sprints steht ein fertiges (Teil-)Produkt zur Verfügung. Dieses Produkt kann mit dem Product Owner als Stellvertreter der Nutzer abgenommen werden.
Fazit: Testen entlang der Geschäftsprozesse hilft Lücken in der agilen Softwareentwicklung zu entdecken. Weiterhin gibt dieses Vorgehen den Product Ownern eine Struktur an die Hand, die Umsetzung der in den Stories beschriebenen Funktionalitäten priorisiert zu steuern.