Beste Möglichkeiten, um Fehlerbehebungen in einen Scrum-Prozess zu integrieren? [geschlossen]

Ich habe in den letzten Tagen über Scrum studiert und gelesen und über Sprint-Planung und Aufgaben gelesen. Ein Problem, das mir in den Sinn kam, ist der Umgang mit Fehlern in Scrum. Henrik Kniberg listet in seinem sehr schönen Buch Scrum and XP from the Trenches einige Möglichkeiten auf, mit diesem Problem umzugehen :

1. Der Product Owner druckt die Jira-Artikel mit der höchsten Priorität aus, bringt sie zum Sprint-Planungsmeeting und bringt sie zusammen mit den anderen Storys an die Wand (wobei implizit die Priorität dieser Items im Vergleich zu den anderen Storys angegeben wird).
2. Der Product Owner erstellt Storys, die sich auf Jira-Artikel beziehen. Beispiel: "Beheben Sie die kritischsten Back-Office-Fehler, Jira-124, Jira-126 und Jira-180".
3. Die Fehlerbehebung wird als außerhalb des Sprints liegend angesehen, dh das Team hält einen Fokusfaktor niedrig genug (z. B. 50%), um sicherzustellen, dass es Zeit hat, Fehler zu beheben. Es wird dann einfach angenommen, dass das Team bei jedem Sprint eine bestimmte Zeit damit verbringen wird, von Jira gemeldete Fehler zu beheben
4. Legen Sie das Produkt-Backlog in Jira (dh Graben Excel). Behandle Fehler wie jede andere Geschichte.

Muss das wirklich pro Projekt entschieden werden oder gibt es bessere Lösungen? Ich kann mir Probleme mit jedem dieser Ansätze vorstellen. Gibt es einen Hybrid aus diesen Ansätzen, der am besten funktioniert? Wie gehen Sie in Ihren Projekten damit um?

Dies ist eine sehr gute Frage, und ich habe einige Beobachtungen, wenn es um verschiedene Ansätze für dieses Problem geht.

1. Die gleichmäßige Behandlung aller Fehler mit Backlog-Elementen mag theoretisch nach einer guten Idee klingen (Arbeit an einem einzigen Ort), funktioniert aber in der Praxis nicht gut. Fehler sind normalerweise auf niedriger Ebene und zahlreicher. Wenn Sie also für jeden Fehler eine individuelle User Story erstellen, werden die "echten" Storys bald verdeckt.
2. Die explizite Zeit in jedem Sprint, der für Korrekturen reserviert ist, ist in Ordnung, wenn dies auf eine Weise erfolgt, die für den Product Owner sichtbar ist. Fehler sollten während des täglichen Scrums erwähnt werden und Diskussionen über behobene Fehler sollten während der Sprintüberprüfung stattfinden. Andernfalls weiß der Product Owner nicht, was im Projekt vor sich geht.
3. Das Einfügen des gesamten Rückstands in das Bug-Tracking-Tool führt zu denselben Problemen wie in 1. Darüber hinaus sind die meisten Bug-Tracker nicht für Scrum konzipiert, und ihre Verwendung für diesen Zweck kann schmerzhaft sein.

Die Lösung, die wir am befriedigendsten fanden, bestand darin, bei jedem Sprint eine einzelne User Story mit dem Namen "Tickets" oder "Bugs" zu erstellen. Dann kann eine solche Geschichte entweder in Aufgaben auf niedriger Ebene unterteilt werden, die einen bestimmten Fehler beschreiben (falls dies während der Planung bekannt ist), oder in Meta-Aufgaben, bei denen eine bestimmte Anzahl von Stunden für die allgemeine Fehlerbehebung reserviert wird. Auf diese Weise hat der Product Owner Einblick in den Prozess und das Burndown-Diagramm spiegelt den Fortschritt wider.

Denken Sie daran, alle "Fehler", die tatsächlich neue Funktionen sind, gnadenlos zu schließen und neue Backlog-Elemente für sie zu erstellen. Stellen Sie außerdem sicher, dass alle Fehler behoben sind, die für den aktuellen Sprint gemeldet wurden, bevor der Sprint beendet ist, um den Sprint als erledigt zu betrachten.

Eigentlich denke ich, dass die beste Antwort von jpeacock auf diese Frage ist. Zählen Sie die Stunden, die für Fehlerbehebungen aufgewendet wurden, für das Gedränge?

Lassen Sie mich es zitieren:

• Wenn der Fehler einfach / schnell zu beheben ist (ein Liner usw.), beheben Sie ihn einfach.
• Wenn der Fehler nicht trivial und kein Blocker ist, fügen Sie ihn dem Backlog hinzu.
• Wenn der Fehler ein Blocker ist, fügen Sie eine Aufgabe (zum aktuellen Sprint) hinzu, um die zur Behebung erforderliche Arbeit zu erfassen und mit der Arbeit zu beginnen. Dies erfordert, dass etwas anderes (vom aktuellen Sprint) in das Backlog verschoben wird, um die neuen Stunden zu berücksichtigen, da sich Ihre insgesamt verfügbaren Stunden nicht geändert haben.

Der erste Schritt besteht darin, zu definieren, was ein Fehler ist. Ich lehre, dass ein Fehler nur dann ein Fehler ist, wenn es sich um eine Funktionalität handelt, die in der Produktion nicht so funktioniert, wie sie beabsichtigt / entworfen wurde. Diese werden zu PBIs vom Fehlertyp, die gegenüber Neuentwicklungen priorisiert werden. Fehlende Funktionen in der Produktion sind ein Feature und werden zu einem normalen Product Backlog-Element. Jeder fehlerhafte Code, der während eines Sprints gefunden wurde, gilt als unvollständige Arbeit. Da Sie erst mit der nächsten Story fortfahren, wenn die aktuelle erledigt ist. Es ist nicht erforderlich, diese Fehler im Sprint zu verfolgen, da das Team immer an dem fehlerhaften Code arbeitet. Post-its können hier sehr praktisch sein, um sich schnell an Teamkollegen zu erinnern. Das Beheben von fehlerhaftem Code hat immer Vorrang vor dem Schreiben von neuem Code.

Inventar ist Verschwendung. Fehlerverfolgung ist Inventar. Fehlerverfolgung ist Verschwendung.

Die gleichmäßige Behandlung aller Fehler mit Backlog-Elementen mag theoretisch nach einer guten Idee klingen (Arbeit an einem einzigen Ort), funktioniert aber in der Praxis nicht gut. Fehler sind normalerweise auf niedriger Ebene und zahlreicher. Wenn Sie also für jeden Fehler eine individuelle User Story erstellen, werden die "echten" Storys bald verdeckt.

Wenn Sie so viel mehr Fehler als Funktionen haben, müssen Sie an Ihren Konstruktionspraktiken arbeiten. Dies ist ein Geruch, dass etwas anderes nicht stimmt und Tracking nicht die Antwort ist. Grab tiefer. Eigentlich stinken Käfer immer. Sie sind nicht cool und wenn Sie viele davon haben, müssen Sie die Grundursachen finden, diese beseitigen und sich nicht mehr auf das Verfolgen von Fehlern konzentrieren.

Verfolgen Sie keine Fehler in einer Liste, finden Sie sie und beheben Sie sie - Mary Poppendieck

In der Tat, wenn Inventar Abfall ist, was ist mit einem Inventar von Mängeln ...

Deshalb versuche ich immer, eine Stop-the-Line- Mentalität mit testgetriebener Entwicklung und kontinuierlicher Integration zu implementieren , damit wir die meisten Fehler finden und beheben, anstatt sie auf eine Nacharbeitsliste zu setzen.

Und wenn Fehler auftreten, beheben wir sie, bevor wir neuen Code schreiben (Geschichten mit Fehlern werden sowieso nicht erstellt). Dann versuchen wir, unseren Prozess zu korrigieren, um ihn fehlerfreier zu machen und Fehler sofort zu erkennen, sobald sie auftreten.

Es gibt keine einheitliche Lösung und jedes Projekt ist anders. Fehler können auch von geschäftskritisch bis kaum behebbar eingestuft werden.

Sofern dies für den Betrieb des Systems nicht kritisch ist, ziehe ich Fehler vor, um Story Cards zu werden. Das macht die Priorität der Feature-Entwicklung gegenüber der Fehlerbehebung sehr deutlich. In einem Szenario, in dem Fehlerkorrekturen als "außerhalb des Sprints" betrachtet werden, kann die Fehlerbehebung dazu führen, dass wirklich triviale Fehler behoben werden, während wirklich wichtige Geschäftsfunktionen nicht entwickelt werden.

Wir haben eine Reihe von Permutationen durchlaufen, bevor wir uns auf den Fehler als Story-Ansatz festgelegt haben. Probieren Sie verschiedene Dinge aus und spielen Sie sie bei Team-Retro-Meetings erneut ab.

In unserem Fall (Greenfield-Entwicklung, 2-3 Entwickler) werden gefundene Fehler aufgeschrieben, deutlich als Fehler markiert und basierend auf ihrem Schweregrad der nächsten Iteration zugewiesen oder im Backlog belassen. Bei kritischen und dringenden Fehlern werden sie der laufenden Iteration hinzugefügt.

Ich weiß nicht, warum etwas so Einfaches wie das Beheben von Fehlern mit Regeln kompliziert ist. Scrum hat nur sehr wenige Regeln, erinnerst du dich? Jede Funktion, jeder Support, jede Empfehlung oder jeder Fehler ist ein Backlog-Problem in Scrum. Es gibt keine Unterscheidung. Wie der Scrum-Leitfaden sagt: Die Aufgaben in einem Sprint beschränken sich nie auf das, was Sie während des Planungsmeetings entscheiden. Das Daily Scrum hilft den Menschen dabei, "Hindernisse" auf ihrem Weg zu besprechen.

Warum?

Sie diskutieren und denken also rational als Team, wenn Sie möchten, dass das Problem mit dem Defekt, dh dem Rückstand, in PBI eingeht oder in diesem Sprint verbleibt und es liefert ...

Die bessere Frage ist, wie ich in der Entwicklungsphase aufhöre, Fehler zu erstellen. siehe -> http://bit.ly/UoTa4n

Wenn Sie Fehler identifizieren und dokumentieren, müssen Sie diese zu einem späteren Zeitpunkt untersuchen und beheben. Dies führt zu "Stabilisierungssprints", dh einem ganzen Sprint, nur um Fehler zu beheben. Oder Sie können sie wieder zum Backlog hinzufügen und sie als Teil eines zukünftigen Sprints priorisieren. Dies bedeutet auch, dass Sie Software mit bekannten Fehlern (P3 & P4, auch bekannt als kosmetisch und geringfügig) bereitstellen und erwarten, dass Sie abgemeldet und veröffentlicht werden.

Das ist nicht wirklich agil?

Ich habe in unserem Projekt die Idee eingereicht, jeden dritten Sprint einen kurzen Bugfix-Sprint einzuführen. Unsere aktuellen Sprints dauern drei Wochen.

Die Idee ist, dass sich alle Entwickler auf die gemeinsame Fehlerbehebung konzentrieren können, sich in regelmäßigen Sprints auf neue Geschichten konzentrieren können und sich regelmäßig auf den Abbau von Tech-Schulden konzentrieren.

Fehlerkorrekturen werden in relevante Storys gruppiert und priorisiert. Der Schwerpunkt liegt nicht auf der Größenbestimmung vor dem Sprint, da Entwickler Schwierigkeiten haben, Fehler zu beheben, ohne sich auf die Art des Fehlers einzulassen.

Hat jemand dies versucht oder hat er Feedback dazu, wie er glaubt, dass dies funktionieren könnte?

Prost, Kevin.