Ein agiler Ansatz mit einer Wasserfallbereitstellung und der QA-Auswirkung

Mein Kunde hat eine wichtige Erweiterung einer bestehenden Anwendung genehmigt. Die Erweiterung wird als einzelnes neues Release ausgeliefert und ich kann dies nicht ändern. Wie wir jedoch zu dieser endgültigen Version kommen, liegt in meiner Kontrolle, und ich denke, wir könnten immer noch von einem Sprint-Modell profitieren.

Mein Ziel ist es, diesen großen Teil der Arbeit in kleinere User Stories / Tasks aufzuteilen und Sprints abzuhalten, während wir auf die Veröffentlichung hinarbeiten, die in einigen Monaten ab jetzt liegt. Mein Team ist mit agilen Methoden vertraut, und ich denke, es wird uns helfen, die Arbeit zu definieren, sie auf unser Team aufzuteilen, Dynamik aufzubauen usw.

Der Bereich, der mir nicht klar ist, ist, wann ich testen soll. Normalerweise würden wir jedes Element innerhalb des Sprints einer vollständigen QA unterziehen, aber bei so vielen Änderungen in der Anwendung und dem Fehlen von UAT, bis die gesamte Arbeit erledigt ist, fühle ich mich nicht wohl dabei, mich auf Tests zu verlassen, die Monate zuvor durchgeführt wurden, bevor sie übergeben wurden der Kunde.

Hat jemand Erfahrung mit einem ähnlichen Ansatz? Wann am besten testen? Sollte ich eine traditionelle Wasserfall-Testphase beibehalten, innerhalb der Sprints testen oder gibt es einen geeigneten hybriden Ansatz?

Wäre es eine Möglichkeit, dem Auftraggeber regelmäßig Vorschauen auf die bisher geleistete Arbeit zu geben, damit er Kritik üben kann, sich aber nicht abmelden muss? Es wäre keine vollständige UAT, aber es kann Ihnen einen Hinweis darauf geben, ob Sie die Dinge in die richtige Richtung gehen.
@BartvanIngenSchenau leider nicht. Ich stimme diesem Ansatz zu, aber ich kann den Kunden noch nicht einbeziehen.

Antworten (1)

Die Sprint-Timebox bietet Ihnen Iterationen, die ein bequemer Schrittmacher sind. In Bezug auf Ihre Frage möchten wir uns die Idee ansehen, dem Prozess eine inkrementelle Entwicklung hinzuzufügen. Bei der inkrementellen Entwicklung vervollständigen Sie regelmäßig voll funktionsfähige und potenziell auslieferbare Inkremente des Produkts. Sie kombinieren diese miteinander und Sie sollten in jedem Sprint ein potenziell überspringbares Produkt haben.

Der Vorteil selbst in einer Wasserfallumgebung besteht darin, dass Sie eine viel bessere Vorstellung davon haben, was vollständig ist und was nicht. Bei einem Phase-Gate-Ansatz wissen Sie bis zur Endabnahme der Phase nicht, ob etwas abgeschlossen ist. Wenn dies ein Vorteil ist, den Sie erhalten möchten, müssen Sie Tests innerhalb der Iteration durchführen, nicht in einer späteren Phase.

Es ist erwähnenswert, dass Agilität und Scrum viel umfassender sind als Sprints, daher konzentriert sich meine Antwort auf das Testen in Iterationen, nicht auf den „richtigen Weg“, Scrum zu praktizieren oder agiler zu sein.