Was ist der vorgeschlagene Ansatz für die Organisation von Sprints während der Testphase? Nehmen wir an, wir haben Entwicklungssprints abgeschlossen, interne Tests (Analysten & Entwickler) sind vorbei. Die Anwendung wird in einer Testumgebung für Benutzerakzeptanztests bereitgestellt. Diese Tests werden von Geschäftsbenutzern der Anwendung abgedeckt.
Was sollen wir jetzt tun?
Im Idealfall sollten Sie beim Erstellen der Anwendung nach jedem Sprint eine neue Version bereitstellen, damit sich die Testphase über einen längeren Zeitraum erstreckt.
Allerdings verstehe ich, dass es Kunden gibt, die erwarten, dass die Abnahmetestphase am Ende nach der Bereitstellung der gesamten Funktionalität durchgeführt wird.
In dieser Situation hat meiner Meinung nach das Beheben von Fehlern eine höhere Priorität als das Entwickeln neuer Funktionen. Sie haben hier einige Möglichkeiten:
Starten Sie einen neuen Sprint, planen Sie eine geringere Geschwindigkeit als üblich ein. Für den ersten Sprint kannst du deinem Bauchgefühl folgen, um die erwartete Geschwindigkeit einzustellen. Dann beheben Sie Fehler, sobald sie auftreten, was sich negativ darauf auswirkt, wie viel neue Arbeit Sie erledigen können. Auf diese Weise sollten Sie in der Lage sein, Fehler zu beheben und neue Aufgaben zu erledigen. Sie riskieren jedoch viele Kontextwechsel, da die Leute die Arbeit an neuen Aufgaben einstellen, um alte Fehler zu beheben.
Starten Sie einen neuen Sprint, aber nehmen Sie den Teil des Teams als Wartungsteam für das alte Projekt weg. Auf diese Weise haben Sie einen Standard-Sprint, wenn auch mit einer kleineren Gruppe von Personen und ein paar anderen, die sich mit eingereichten Fehlern befassen sollten. Sie können die Anzahl der Personen in beiden Gruppen nach jedem Sprint je nach fehlerbezogener Arbeitsbelastung anpassen. Die Geschwindigkeit des Teams, das an neuen Funktionen arbeitet, wird fließend sein, aber Sie schränken den Kontextwechsel ein. Sie riskieren jedoch die Frustration der Leute, die sich mit Fehlern befassen, da sie es mit Fehlern zu tun haben, die von ihnen selbst und von anderen verursacht wurden, die derzeit an neuen coolen Aufgaben arbeiten. Es ist eine gute Idee, wenn möglich, nach jedem Sprint Leute zwischen diesen Teams zu mischen.
Legen Sie Happy Hour/Days für die Fehlerbeseitigung fest – Tages-/Wochenzeiten, zu denen sich alle mit Fehlern befassen. Abgesehen davon bauen sie neue Funktionen. Sie können die Länge der Happy Hour an den Arbeitsaufwand anpassen, den Sie mit der Fehlerbehebung haben. Auch hier riskieren Sie, dass Leute Code reparieren, der von anderen geschrieben wurde, insbesondere wenn jemand ziemlich minderwertigen Code mit vielen Fehlern erstellt. Es führt jedoch eine Einstellung im Team ein, die normalerweise gut funktioniert.
Wenn es genug Bugfixing gibt, um alle Tage für das gesamte Team zu füllen, würde ich mit dem Start eines neuen Sprints warten, bis es zumindest jemanden gibt, der sich mit neuen Aufgaben befassen kann, egal welche Methode Sie wählen.
In der von Ihnen beschriebenen Umgebung wäre es ideal, die Funktionalität in kleinen Schritten bereitzustellen. Jeder Sprint sollte neue Funktionen oder erweiterte Funktionen einführen, die die Benutzer testen können.
Sie sollten nicht warten, bis die gesamte Entwicklungsphase vorbei ist und erst dann mit dem User Testing beginnen. Es fehlt irgendwie der Punkt der iterativen Entwicklung.
In dem Unternehmen, für das ich arbeite, haben wir Entwicklungsteams (die auch für Funktionstests verantwortlich sind) und dann haben wir ein Lösungstestteam. Die Entwicklungsteams liefern Inhalte in Sprints. Das Testteam auf Lösungsebene hat nachfolgende Sprints, in denen es die neuen Funktionen testet.
So können Sie frühzeitig Feedback von den Nutzern einholen, in dem Sie noch Änderungen vornehmen und sich auf die wichtigsten Features konzentrieren können.
Wenn Sie Scrum machen, würden Sie die Tests während des Sprints durchführen, in dem die Entwicklung stattfand. Das Feature wird entwickelt, das Feature wird getestet, beides wird im Sprint-Plan berücksichtigt – das Feature ist nicht „fertig“, bis es sowohl entwickelt als auch getestet wurde.
Wenn Sie die Tests nicht im selben Sprint abschließen können, brechen Sie Ihre Storys wahrscheinlich nicht in ausreichend kleine Stücke auf. Testen Sie im schlimmsten Fall jede Story im Sprint sofort, nachdem sie entwickelt wurde.
Wenn Sie eine Entwicklungsphase (Anzahl X Sprints) und eine Testphase (Anzahl Y Sprints) haben, ist das ein Wasserfall (oder iterativer Wasserfall).
Ich war bei der Verwendung von Scrum an Benutzerakzeptanztests beteiligt. Unsere UAT-Zyklen wurden vertraglich festgelegt und liegen außerhalb unserer Kontrollspanne. Wir hatten normalerweise 3 Tage UAT, gefolgt von 2 Tagen für Fehlerbehebungen, jede Produktversion hatte mindestens drei dieser UAT-Zyklen.
Also hat unser Team den gesamten UAT-Zeitraum – etwa zwei Wochen – in mehrere Mini-Sprints aufgeteilt. Nicht unbedingt im Scrum-Framework, aber das ist das Schöne an Scrum, Sie können und sollten es an Ihre Umgebung anpassen. Wenn der Kunde das Produkt und die Umgebung zum Testen gesperrt hatte, programmierten wir Fehlerkorrekturen. Wenn die Umgebung für Fehlerbehebungen an uns zurückgegeben wurde, stellten wir die Fehlerbehebungen aus dem vorherigen Fehlerbehebungs-Mini-Sprint bereit und führten Umgebungstests durch.
Wir haben festgestellt, dass wir während der UAT normalerweise einige Ersatzzyklen hatten, wenn wir unsere Arbeit gut gemacht hatten und es nicht viele Fehler gab. Wir nutzten diese Zeit für vernachlässigte Haushaltsaufgaben.
Alan Larimer