Wie berücksichtigen Fehlerberichte einen Sprint?

Ich habe kürzlich über Scrum gelesen. Nach meinem Verständnis wird vor Beginn des Sprints ein Meeting abgehalten, um zu entscheiden, was vom Produkt-Backlog in das bevorstehende Sprint-Backlog verschoben wird. Sobald eine Funktion im aktuellen Sprint abgeschlossen ist, wird sie in den Bereich "Bereit zur Qualitätssicherung" verschoben, und an diesem Punkt bin ich verwirrt. Gehen Fehlerberichte zurück in das Produkt-Backlog? Ich gehe davon aus, dass sie nicht in den Sprint-Rückstand zurückkehren können, da wir bereits entschieden haben, welche Arbeiten für diesen Zyklus durchgeführt werden sollen. Was passiert, wenn die Qualitätssicherung einen Fehler findet? Wohin geht es?

So wie ich das sehe, gibt es zwei Hauptlösungen dafür:

1. Weisen Sie dem aktuellen Sprint nicht 100% Ihrer Zeit zu. Lassen Sie 10-15% Ihrer Zeit für Bugfixing und andere Support - Aktivitäten, wird während des Sprints kommen. Wenn dann ein Blockierungsfehler auftritt, haben Sie die Zeit, ihn im aktuellen Sprint zu beheben.

   Wenn ein nicht blockierender Fehler auftritt, können Sie ihn entweder am Ende des aktuellen Sprints beheben, wenn Sie noch Zeit haben, oder er geht in den "Pot" für den nächsten Sprint.

2. Führen Sie von Zeit zu Zeit einen Sprint zur Fehlerbehebung durch. Wahrscheinlich kurz vor der nächsten Hauptversion. Sie können dies verwenden, um so viele Fehler wie möglich zu "beseitigen", die Sie für die nächste Version beheben können / möchten.

Keine dieser Lösungen trifft wahrscheinlich auf "reines" Scrum zu, aber sie funktionieren in der realen Welt.

Während eines "normalen" Sprints können Sie weiterhin Aufgaben zur Behebung bestimmter Fehler einschließen und diese wie eine neue Funktionalität behandeln.

In einer idealen Scrum-Welt gibt es keinen "Bereit für QA" -Eimer (zumindest außerhalb des Teams nicht sichtbar), da eine Funktion erst abgeschlossen wird, wenn die QA-Aktivitäten abgeschlossen und die Fehler behoben sind. Dies bedeutet, dass sich Mitarbeiter im Team befinden sollten, die die QS-Aktivitäten übernehmen können.

In der realen Welt haben Sie möglicherweise ein separates QS / Test-Team, das parallel zum Scrum-Team (Entwicklungsteam) arbeitet. In diesem Fall könnte der folgende Ansatz gut funktionieren:

1. Kurz bevor ein Feature in den Bucket "Bereit für die Qualitätssicherung" gestellt wird, setzen sich der (Haupt-) Entwickler dieses Features und der QS-Vertreter, der es (wahrscheinlich) übernehmen wird, zusammen und gehen durch das Feature. Zu diesem Zeitpunkt festgestellte Probleme werden behoben, bevor die Funktion in den Bereich "Bereit für die Qualitätssicherung" gestellt wird. Beachten Sie, dass dies kein früher Teil einer Sprint-Demo ist. Es soll die niedrig hängenden Früchte in den Problemen so schnell wie möglich lösen.

2. Alle Probleme, die nach der Übergabe an die Qualitätssicherung festgestellt wurden, sollten als Storys in das Produkt-Backlog aufgenommen werden, um bei der nächsten Planungsbesprechung berücksichtigt zu werden.

3. Reservieren Sie für Show-Stopper-Fehler eine feste Zeit für jeden Sprint. Wenn gegen Ende des Sprints noch Zeit in diesem Puffer verbleibt, kann er mit Problemen niedrigerer Priorität gefüllt werden.

Basierend darauf, wie Sie Ihren Workflow anhand einer Story beschreiben, mit einem Produkt-Backlog, einem Sprint-Backlog und anderen Buckets (ich gehe davon aus, dass sie ungefähr so ​​aussehen wie "in Bearbeitung / in Entwicklung", "bereit für die Qualitätssicherung", "fertig" "), es hört sich so an, als würden Sie Scrum einige Elemente von Kanban hinzufügen - eine nicht ungewöhnliche Kombination, die manchmal als Scrumban bezeichnet wird . Der Begriff Kanban begrenzt die Größe jedes Buckets, um zu verhindern, dass Ihre Entwickler zu viele Storys ausführen oder Ihre Tester zu viele Tests durchführen. Es ähnelt der Geschwindigkeit für das Verschieben von Elementen aus Ihrem Produkt-Backlog in Ihr Sprint-Backlog, jedoch innerhalb eines Sprints.

Ich würde mich dem Problem nähern, indem Ihre Aufgaben die User Stories sind, wobei Ihre User Stories vom Produkt-Backlog zum Sprint-Backlog zum laufenden Bucket zum QA-fähigen Bucket zum fertigen Bucket wechseln. Nachdem der Entwickler die Story fertiggestellt hat (basierend auf Ihrer Definition von fertig), verschiebt er sie in den Eimer "Bereit für die Qualitätssicherung", in dem die nächste Person sie herauszieht und daran arbeitet. Wenn es Probleme damit gibt, wird ein Fehler in Ihr Tracking-System eingegeben und die User Story wird in den fertigen Bucket verschoben, da sie implementiert und getestet wurde. Wenn es keine Probleme damit gibt, bewegt es sich direkt in den fertigen Eimer.

Wenn der Fehler aus Ihrem Sprint stammt, ist es kein Problem, ihn wieder in den Sprint-Rückstand (oder in eine Art "in Bearbeitung" -Eimer) zu stellen. Eine Geschichte mit bekannten Mängeln wird normalerweise als unvollendet angesehen. Wenn festgestellt wird, dass nicht genügend Zeit zum Beenden der Geschichte vorhanden ist oder die Fehler darauf zurückzuführen sind, dass die Geschichte nicht verstanden wurde, besteht eine Option darin, sie vollständig aus dem Sprint zu entfernen, bis Sie die Notwendigkeit besser verstehen können. In diesem Fall würde ich dies nicht empfehlen einschließlich der fehlerhaften Implementierung in Ihrem freigegebenen Produkt.

Wenn die Geschichte aufgrund Ihres Defekts in Ihrem Sprint nicht beendet wird, wird dies in Ihren Geschwindigkeitsberechnungen für zukünftige Sprints angezeigt. Unvollendete Geschichten (fehlerhafte Geschichten) bringen Ihnen keine Story-Punkte, sodass Sie kleinere Sprints planen. Weniger komplexe Storys führen zu mehr Zeit für Tests und ermutigen Sie dazu, sich mehr Mühe zu geben, Fehler frühzeitig zu finden. Das Verhindern von Fehlern ist nicht nur billiger, sondern nimmt auch weniger Zeit in Anspruch als die Summe der Zeit, die zum Erkennen eines Problems benötigt wird, um das Problem zu finden Beheben Sie das Problem beim Entwurf oder bei der Implementierung und wiederholen Sie den Test, um sicherzustellen, dass das Problem ohne weitere negative Auswirkungen auf das System behoben wurde. Da die Zeitbox der Schlüssel ist, führt die Fähigkeit, Fehler zu vermeiden, in Zukunft zu produktiveren Sprints.

Unabhängig davon, was Sie tun, sollten Sie den Product Owner (der hoffentlich ein Kunden- / Benutzervertreter ist) in die Entscheidung einbeziehen, wie Fehler priorisiert werden sollen. Es kann akzeptabel sein, dass einige Fehler in eine Version aufgenommen werden, wenn es Problemumgehungen gibt oder sie selten sind, was bedeutet, dass der Fehler in einem zukünftigen Sprint als Story angezeigt wird. Andere Mängel können dringend sein und "Showstopper" - diese müssen sofort behoben werden und ein Produkt kann nicht verwendet werden, wenn sie vorhanden sind.

Wenn die für Defekte aufgewendete Zeit von einer Feder zur nächsten ziemlich konstant ist, müssen Sie sie nicht wirklich verwalten - Ihre Teamgeschwindigkeit wird dies widerspiegeln.

Andernfalls können Sie die Fehlerbehebung planen (dh Sie können die Behebung für die Dauer eines Sprints verschieben).

Andernfalls hat Scrum keine gute Antwort - Fehler sind eine ungeplante Änderung des Sprintinhalts während eines Sprints, was bedeutet, dass Sie Ihre Verpflichtungen neu zuordnen müssen.

Ein Sprint sollte in sich geschlossen sein. Das bedeutet, dass alle Aktivitäten, einschließlich Qualitätssicherung, Fehlerbehebung und Dokumentation, vor dem Ende des Sprints abgeschlossen sein sollten. Aktivitäten vor der Bereitstellung sollten auch stattfinden, bevor der Sprint beendet ist.

Das Problem, wenn Sie nicht fertig sind, ist, dass Sie beim nächsten Sprint abgelenkt werden.

Wenn Sie in Sprint B Ihre Aufmerksamkeit wieder auf den Code aus Sprint A richten müssen, um Fehler zu beheben, geht Ihre Fähigkeit, sich auf die Aufgaben in Sprint B zu konzentrieren, aus dem Fenster. So auch Ihre Vorwärtsgeschwindigkeit.

Bei meinem letzten Job wurden Sprints nach dem Konzept der "idealen Stunden" geplant. An einem 8-stündigen Entwicklertag waren 5 Stunden Head-Down-TDD für neue Funktionen, die es noch nie gab. Die anderen drei machten alles andere; E-Mails, Besprechungen, Kompilieren / Festschreiben / Aktualisieren von Code, Refactoring-Arbeiten und Fehlerbehebungen.

Wir haben einen Job in Betracht gezogen, der erledigt wurde, aber Fehler aufwies, die immer noch für die Teamgeschwindigkeit gelten. Fehler waren jedoch technische Schulden, die bei ihrer Entstehung zurückgezahlt werden mussten und daher offensichtlich vermieden werden mussten. Wir hatten nie ein wirkliches Problem mit Leuten, die schlampige Arbeit verrichteten. niemand wollte zurückgehen müssen.

Hin und wieder gab es auch Sprints zur Fehlerbehebung. Wir hatten das zweifelhafte Glück, einen Kunden zu haben, der die Anforderungen nicht in dem Tempo erfüllen konnte, in dem wir sie verbrauchen konnten. Um den Rückstand ein wenig aufzubauen, planten wir oft zwei Wochen ein, in denen das Ziel darin bestand, "so viele Fehler wie möglich zu beseitigen" so viel technische Schulden wie möglich abbezahlen ". Technisch gesehen ist die Geschwindigkeit für einen solchen Sprint Null, aber dies ist Arbeit, die erledigt werden muss und die den Kunden glücklich macht, also lohnt es sich.