Read this post in English.
Der Kern der agilen Software-Entwicklung nach Scrum ist die regelmäßige Auslieferung von Produktinkrementen an den Kunden. Die Software wird funktional also nach und nach erweitert, der Kunde bekommt aber bereits ab dem ersten Sprint eine Version seiner Software ausgeliefert. Dafür gibt es am Ende eines jeden Sprints ein Review-Meeting, in dem die neuen Funktionalitäten dem Kunden durch das Entwicklungsteam vorgestellt werden. Warum die Teilnahme an Reviews für den Kunden sinnvoll ist und warum er auch selbst frühzeitig und intensiv die für ihn erstellte Software testen sollte, zeigen wir in diesem Artikel.
Tests: Wie umfangreich wird getestet?
Zunächst fallen Tests, die ein fester Bestandteil der agilen Software-Entwicklung sind, in den Verantwortungsbereich des Entwicklungsteams. Schließlich möchte es bereits vom ersten Sprint an bis zum Projektende in den Reviews eine möglichst fehlerfreie Software präsentieren. Welchen Umfang dieses teaminterne Testing hat, wird zuvor mit dem Kunden vereinbart. Schließlich hat die Entscheidung, für welche Browser und Systeme eine Software optimiert werden soll, auch teils große Auswirkungen auf das Budget. Dabei ist das Team bestrebt, eine breite Abdeckung an manuellen Tests zu erreichen, indem die Teammitglieder mit verschiedenen Betriebssystemen und Browsern die Software durchgehen und die neu entwickelten Funktionalitäten testen. Dabei wird neben der funktionalen Prüfung ("Ist die Umsetzung entsprechend der Akzeptanzkriterien erfolgt?") auch auf die fehlerfreie Darstellung der Oberflächen geachtet.
Allerdings können diese Oberflächentests nicht immer alle erdenklichen Kombinationen von Browsern bzw. Browserversionen und Betriebssystemen abbilden - Der Mehraufwand wäre entsprechend hoch und müsste gegebenenfalls explizit mit dem Kunden abgestimmt werden. Auch in funktionaler Hinsicht kann das Team nur in dem Umfang prüfen, wie es gemeinsam mit dem Kunden in der Aufbereitung der User Stories besprochen wurde. Schließlich bleibt der Kunde der Experte für seine Fachdomäne und die Anwender.
Will dieser nicht in vollumfängliche Tests investieren, wird ein pragmatischer Mittelweg gesucht, der viele Fälle und Konfigurationen abdeckt, aber eben nicht alle erdenklichen. Die Herausforderung: Dem Team können Probleme und Fehler entgehen. Es kann aber auch passieren, dass die Umsetzung entsprechend der Akzeptanzkriterien erfolgt ist, sich diese aber dennoch als nicht optimal herausstellt. Und die Behebung später entdeckter Fehler ist aufwändig und entsprechend kostspielig.
Spät entdeckte Fehler sind teuer
In der Software-Entwicklung greift die sogenannte 1-10-100-Regel, die besagt, dass der Aufwand für Korrekturen und Anpassungen exponentiell zunimmt, je später Fehler und Probleme identifiziert werden.
Findet ein Entwickler während der Programmierarbeit einen Fehler, kann er ihn normalerweise rasch und ohne größeren Aufwand beheben (Faktor 1). Stößt ein Tester in einer Testinstanz der Software auf ein Problem, ist der Aufwand schon deutlich höher: Er muss den Fehler dokumentieren, ihn dem Entwickler übergeben und das Testsystem nach der Behebung aktualisieren und nochmals testen (Faktor 10). Der Worst Case tritt ein, wenn ein Bug erst im Live-System gefunden wird: Die reine Fehlerbehebung ist so aufwändig wie die im Testsystem. Zusätzlich muss auch die Live-Instanz aktualisiert werden. Und wirklich kritisch sind die Folgen: Bugs verärgern die Nutzer, gegebenenfalls müssen Funktionen deaktiviert werden, die eigentlich Umsatz generieren sollen, Nachrichten über fehlerhafte Software verbreiten sich im Netz schneller als je zuvor, die Imagekurve geht nach unten und so weiter (Faktor 100).
Es ist daher unbedingt ratsam, so früh wie möglich auf die systematische Fehlersuche zu gehen und umfangreich zu testen. Und die Voraussetzungen dafür sind, dass der Kunde darüber auf dem Laufenden ist, wie es um die Entwicklung seiner Software steht, und auch selbst aktiv wird.
Die Teilnahme am Review ist wichtig
Wir haben sehr gute Erfahrungen damit gemacht, dass Kunden regelmäßiger an den Reviews bei uns vor Ort teilnehmen und das Produkt mit dem Team zusammen ansehen. Diese persönliche Zusammenarbeit ist mit Abstand der beste Weg, wichtige Informationen zwischen dem Kunden und dem Entwicklungsteam auszutauschen. Einer der größten Vorteile der Software-Entwicklung nach dem Scrum-Modell ist ja die Möglichkeit der tiefen Integration des Kunden in den Prozess.
Das wollen auch wir in unseren Projekten leben und das Produkt gemeinsam mit dem Kunden gestalten und entwickeln. Die Entwicklung ist für ihn keine "Black Box", bei der er erst ganz am Ende ein Ergebnis präsentiert bekommt, sondern transparent und beeinflussbar: Das Resultat deckt sich viel besser mit der Software-Lösung, die sich der Kunde vorstellt, und hohe Mehrkosten durch späte Nachbesserungen und Änderungen am Produkt lassen sich vermeiden.
Außerdem gibt es je nach Projekt noch weitere Stakeholder, deren Meinungen zum Entwicklungsstand ebenfalls bedeutsam sind. Auch die Einbeziehung dieser Beteiligten in die Reviews kann später notwendige Änderungen abfangen.
Der Kunde muss Funktionen ernsthaft prüfen und abnehmen
Aber nicht nur die Teilnahme am Review ist empfehlenswert und wichtig, denn auch in diesen Meetings, in denen die neuen Funktionen vorgestellt und abgenommen werden, lässt sich nicht jedes Detail bedenken und testen.
Darüber hinaus sollte der Kunde, sofern er vollumfängliche Tests nicht explizit mit dem Team abgestimmt hat, das Produkt nach jedem Sprint selbst ernsthaft prüfen und abnehmen, um Kosten zu sparen. Weitere und vor allem kurzfristige Oberflächentests des Produktinkrements helfen, Anpassungsbedarf schnell zu identifizieren und späte (und damit teure) Änderungen möglichst zu vermeiden.
Fazit: Mehraufwand für den Kunden, der sich lohnt
Ja, regelmäßige Besuche beim Entwicklungsteam bedeuten erst einmal Aufwand für den Kunden. Und auch das Testen verschlingt Zeit und Ressourcen. Doch ein größeres und regelmäßiges Zeit-Investment ist sinnvoll: Fehler werden schneller entdeckt und lassen sich schneller und einfacher beheben; der Kunde ist tatsächlich in die Entwicklung und Qualitätssicherung integriert und erhält ein Produkt, das wirklich seinen Vorstellungen entspricht. Der Mehraufwand lohnt sich - bei //SEIBERT/MEDIA stehen die Türen jedenfalls allen Kunden offen! 🙂
Ihr Partner für individuelle Software-Entwicklung mit Scrum
Sie planen ein Software-Projekt? Sie möchten ein bestehendes System erweitern oder eine Software-Plattform migrieren? Sie benötigen Schnittstellen zwischen Anwendungen im Unternehmen? Und bei all dem muss höchste Qualität jederzeit gewährleistet sein?
Dann ist //SEIBERT/MEDIA der richtige Partner für Sie. Wir legen größten Wert auf Erweiterbarkeit, Performanz, Skalierbarkeit, Plattformunabhängigkeit und Testbarkeit und schaffen so individuelle High-End-Software-Lösungen, die sich auch im Nachhinein flexibel ausbauen und verändern lassen. Bitte sprechen Sie uns unverbindlich an! Ausführliche Informationen finden Sie auch in unserem öffentlichen Wiki: Einstieg in die Software-Entwicklung mit //SEIBERT/MEDIA.
Weiterführende Infos
Sprint-Begleitung vor Ort: Darum ist eine regelmäßige Kundenpräsenz beim Entwicklungsteam so sinnvoll
Welche Vorteile bietet mir als Kunde ein Scrum-Projekt?
99 Argumente für Scrum: Was Scrum-Projekte dem Kunden bringen
Beginn eines Happy Ends: Der Anforderungs-Workshop im Scrum-Projekt
Mehr über die Creative-Commons-Lizenz erfahren
