Wir bauen ein ziemlich großes und wichtiges Feature in einem Scrum-Team auf. Der PM möchte diese Funktion in einen separaten Zweig stellen und erst nach 1-2 Monaten bereitstellen, damit die Benutzer sie vor der Veröffentlichung richtig testen können. Es scheint seltsam Wasserfall für mich.
Was denken Sie? Ist es in Agile in Ordnung, so etwas zu tun? Oder sollte ich als Scrum Master vorschlagen, das Feature in kleinere Teile aufzuteilen und es regelmäßig zu veröffentlichen?
Als Scrum Master ist es Ihre Aufgabe sicherzustellen, dass Ihr Team das Scrum-Framework befolgt. Der beste Weg, dies zu tun, besteht darin, die Folgen einer Nichtbefolgung von Scrum und die Auswirkungen auf die Organisation zu erklären.
Scrum spricht von einem potenziell auslösbaren Inkrement am Ende jedes Sprints. Der Wert bei diesem Ansatz ist folgender:
Der vorgeschlagene Ansatz mit 1-2 Monaten Akzeptanztests außerhalb von Sprints wird kein potenziell veröffentlichbares Inkrement liefern. Tatsächlich könnte es ein Problem sein; Wenn während des Abnahmetests größere Probleme entdeckt werden, war der scheinbar erzielte Fortschritt irreführend.
Wie Sie bereits erwähnt haben, ist es ein besserer Ansatz, das Feature aufzuteilen und häufiger zu veröffentlichen. Ich würde empfehlen, dies vorzuschlagen und zu erklären, warum dies der bessere Weg ist.
Ihr Team produziert am Ende jedes Sprints ein potenziell auslieferbares Produktinkrement. Ob diese dann Abnahmetests unterzogen und tatsächlich freigegeben werden, bleibt dem Auftraggeber überlassen.
Natürlich teilen Sie das große Feature in Product Backlog Items auf, die innerhalb des Scrum-Frameworks gehandhabt werden können, so dass es mehrere Sprints dauert, bis es fertig ist, aber der Kunde kann sich dafür entscheiden, keine Abnahmetests zu starten, bevor das Feature als Ganzes verfügbar ist .
Die Situation ist ähnlich wie in der Startphase eines Projekts. Niemand erwartet, dass Ihr Team am Ende von Sprint 1 oder 2 ein vollständiges Produkt hat, das alle Anforderungen erfüllt. Benutzer können mit den Inkrementen experimentieren, die während jedes Sprints produziert werden, aber Akzeptanztests für eine erste Version werden möglicherweise erst gestartet, wenn das Produkt tatsächlich dazu in der Lage ist einen angemessenen Teil der gestellten Anforderungen zu erfüllen.
Ein weiterer zu berücksichtigender möglicher Ansatz, der neben den bewundernswerten Vorschlägen hier zum Aufteilen der Funktion verfolgt werden könnte, besteht darin, Teile der Funktion "freizugeben", jedoch mit einem "Schalter", damit die Funktion deaktiviert oder nur aktiviert werden kann für bestimmte Benutzer/unter bestimmten Umständen, wenn die ersten Teile davon veröffentlicht werden. Dies kann hilfreich sein, wenn Sie eine regelmäßige Lieferkadenz haben und diese mit dem Rest des Codes live bringen müssen, aber dies wird in Bits geliefert. Es würde dazu beitragen, die Notwendigkeit eines separaten langlebigen Feature-Zweigs zu vermeiden, und es würde es ermöglichen, das Risiko der Releases zu verringern, indem nur bestimmten Benutzern erlaubt wird, diese Funktionalität live zu verwenden, sobald sie verfügbar ist.
In Scrum arbeitet das Team daran, das auslieferbare Produkt als Ergebnis jedes Sprints bereitzustellen. Es wird empfohlen, in jedem Sprint (1 bis 4 Wochen) dieselbe Timebox zu verwenden.
Laut Aussage will PM das Feature in einen eigenen Zweig stellen und Nutzern 1-2 Monate zum Testen ermöglichen. Es handelt sich eindeutig um eine Produktlieferung des Scrum-Teams (vorausgesetzt, das Scrum-Team wurde bereits am Ende getestet) und das Scrum-Team scheint nicht an der Abnahme beteiligt zu sein.
Abnahmetests sollten im Sprint-Review-Meeting jedes Sprints durchgeführt werden. Wenn das Scrum-Team das Produkt vor umfangreichen Abnahmetests als geliefert behandelt und das Team abbaut oder zu einem anderen Sprint mit anderen Funktionen und Testergebnissen wechselt, die im Backlog für die zukünftige Sprint-Planung hinzugefügt werden, ist es möglicherweise kein Anti-Scrum.
Sarow
Lukasz Kupiec