it-swarm.com.de

Wie kann man Fehlerbehebungen in einen Scrum-Prozess integrieren?

Ich habe in den letzten Tagen etwas über Scrum gelernt 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 Nice-Buch Scrum und XP from the Graben :

  1. Der Produktbesitzer druckt die meisten Jira-Artikel mit der höchsten Priorität aus, bringt sie zum Sprint-Planungsmeeting .__ und bringt sie zusammen mit den anderen Geschichten an die Wand (Dabei implizit spezifiziert) die Priorität dieser Elemente im Vergleich zu den anderen Geschichten). 
  2. Der Produktbesitzer erstellt Storys, die sich auf Jira -Elemente beziehen. Zum Beispiel: "Beheben Sie die wichtigsten Kritischen Back-Office-Fehler, Jira-124, Jira-126 und Jira-180".
  3. Bugfixing wird als .__ außerhalb des Sprints betrachtet, d. H. Das Team Behält einen ausreichend niedrigen Fokusfaktor (für Beispiel 50%), um sicherzustellen, dass Zeit zur Behebung von Fehlern bleibt. Es wird dann einfach davon ausgegangen, dass das Team eine bestimmte Zeitspanne verbringt, um Fehler zu beheben, die von Jira gemeldet werden 
  4. Legen Sie den Product Backlog in Jira (D. H. Excel-Graben). Behandeln Sie Fehler einfach wie jede andere Geschichte.

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

87
Makis

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

  1. Wenn alle Fehler gleichermaßen mit Backlog-Elementen behandelt werden, klingt dies theoretisch nach einer guten Idee (Arbeit an einem einzigen Ort), funktioniert jedoch in der Praxis nicht gut. Bugs sind in der Regel weniger umfangreich und zahlreicher. Wenn Sie also für jeden Fehler eine eigene User Story erstellen, werden die "echten" Storys bald verdeckt. 
  2. Die explizite Zeit für jeden Sprint, die für Korrekturen reserviert ist, ist in Ordnung, wenn dies für den Produktbesitzer sichtbar ist. Fehler sollten während des täglichen Scrums erwähnt werden und die Diskussion über Fehler, die behoben wurden, sollte während der Sprint-Überprüfung auftreten. Andernfalls weiß der Produktbesitzer nicht, was im Projekt vor sich geht.
  3. Wenn Sie den gesamten Rückstand in das Bug-Tracking-Tool einbauen, führt dies zu den gleichen Problemen wie in 1. Außerdem sind die meisten Bug-Tracker nicht für Scrum konzipiert, und die Verwendung für diesen Zweck kann schmerzhaft sein.

Die Lösung, die wir als die befriedigendste Lösung fanden, bestand darin, für jeden Sprint eine einzelne User-Story namens "Tickets" oder "Bugs" hinzuzufügen. Eine solche Geschichte kann dann entweder in untergeordnete Aufgaben, die einen bestimmten Fehler beschreiben (falls während der Planung bekannt), oder in Meta-Aufgaben, die eine bestimmte Anzahl von Stunden für die allgemeine Fehlerbehebung reservieren, unterteilt werden. Auf diese Weise hat der Produktbesitzer Einblick in den Prozess und das Burndown-Diagramm spiegelt den Fortschritt wider. 

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

80
Adam Byrtek

Eigentlich denke ich, das Beste ist die Antwort von jpeacock von dieser Frage Zählen Sie die Stunden, die für Bugfixes aufgewendet wurden, in Richtung 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 ist 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 aufzunehmen, Und beginnen Sie damit, daran zu arbeiten. Dieses 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.
31
yoosiba

Der erste Schritt ist zu definieren, was ein Fehler ist. Ich lehre, dass ein Fehler nur ein Fehler ist, wenn es sich um Funktionen handelt, die in der Produktion nicht so funktionieren, wie sie beabsichtigt waren. Diese werden zu Fehlertyp-PBIs, die gegenüber neuen Entwicklungen priorisiert werden. Fehlende Funktionen in der Produktion sind ein Feature und werden zu einem normalen Produktrückstand. Jeder fehlerhafte Code, der während eines Sprints gefunden wurde, wird als unvollständige Arbeit betrachtet und da Sie nicht mit der nächsten Story fortfahren, bis die aktuelle abgeschlossen ist; Es ist nicht notwendig, diese Fehler im Sprint zu verfolgen, da das Team immer an dem fehlerhaften Code arbeitet. Post-its kann hier sehr praktisch sein, um sich schnell zwischen Teamkollegen zu erinnern. Das Beheben von fehlerhaftem Code hat immer Vorrang vor dem Schreiben von neuem Code. Wenn die Fehler auf ein Missverständnis der Geschichte zurückzuführen sind, müssen Sie vor dem Beginn der Geschichte an den Annahmebedingungen arbeiten.

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

Wenn alle Fehler gleichermaßen mit Backlog-Elementen behandelt werden, klingt dies theoretisch nach einer guten Idee (Arbeit an einem einzigen Ort), funktioniert jedoch in der Praxis nicht gut. Bugs sind in der Regel weniger umfangreich und zahlreicher. Wenn Sie also für jeden Fehler eine eigene 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 riechen Bugs immer. Sie sind nicht cool und wenn Sie viele davon haben, müssen Sie die Ursachen herausfinden, diese beseitigen und aufhören, sich auf das Verfolgen von Fehlern zu konzentrieren.

24

Fehler auf einer Liste nicht aufspüren, finden und beheben - Mary Poppendieck

Wenn Inventar Abfall ist, wie sieht es mit einem Defekt-Inventar aus? 

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

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

6
Pascal Thivent

Es gibt keine einheitliche Lösung, und jedes Projekt ist anders. Bugs können auch von geschäftskritisch bis schwer reparierbar eingestuft werden.

Wenn es nicht kritisch für den Betrieb des Systems ist, bevorzuge ich, dass Fehler zu Story Cards werden. Das macht die Priorität der Feature-Entwicklung gegenüber der Fehlerbehebung deutlich. In einem Szenario, in dem Fehlerbehebungen als "außerhalb des Sprints" betrachtet werden, kann die Fehlerbehebung möglicherweise dazu führen, wirklich geringfügige Fehler zu beheben, während wirklich wichtige Geschäftsfunktionen nicht entwickelt werden.

Wir haben eine Reihe von Permutationen durchlaufen, bevor wir den Fehler als Story-Ansatz betrachten. Probieren Sie verschiedene Dinge aus und wiederholen Sie sie bei Retro-Meetings. 

2
leonm

In unserem Fall (Greenfield-Entwicklung, 2-3 Entwickler) werden gefundene Fehler aufgeschrieben, eindeutig als Fehler markiert und aufgrund ihres Schweregrads der nächsten Iteration zugewiesen oder im Rückstand gespeichert. Bei kritischen und dringenden Fehlern werden sie zur laufenden Iteration hinzugefügt.

1

Ich weiß nicht, warum etwas so einfaches wie das Beheben von Fehlern mit Regeln kompliziert ist. Scrum hat sehr wenige Regeln, denken Sie daran? Jedes Feature, Support, Empfehlung oder Defekt ist ein Backlog-Problem in Scrum, es gibt keine Differenzierung. Wie der Scrum-Leitfaden sagt: Die Aufgaben in einem Sprint sind niemals auf das beschränkt, was Sie während des Planungstreffens festgelegt haben Das Daily Scrum hilft Menschen, auf ihrem Weg "Hindernisse" zu diskutieren. 

Warum? 

Sie besprechen und denken als Team rational, wenn Sie möchten, dass der Fehler, d. H. Das Backlog-Problem, in PBI auftritt oder in diesem Sprint verbleibt und ihn liefert ... 

1

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

Wenn Sie Fehler identifizieren und dokumentieren, müssen Sie sie zu einem späteren Zeitpunkt ausloten und beheben. Dies führt zu "Stabilisierungssprints", d. H. Einem ganzen Sprint, nur um Fehler zu beheben. Oder Sie können sie wieder in den Backlog aufnehmen und als Teil eines zukünftigen Sprints priorisieren .. __ Es bedeutet auch, dass Sie bereitgestellte Software mit bekannten Fehlern bereitstellen (P3 & P4 oder Kosmetik) und Moll).

Das ist nicht wirklich beweglich? 

0
user3433518

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

Die Idee ist, dass es allen Entwicklern ermöglicht wird, sich gemeinsam auf die Fehlerbehebung zu konzentrieren, sich nur auf neue Geschichten in regelmäßigen Sprints konzentrieren zu können und sich regelmäßig auf die Reduzierung der Tech-Schulden zu konzentrieren.

Fehlerbehebungen werden in relevante Artikel gruppiert und priorisiert. Der Schwerpunkt liegt nicht auf der Größenbestimmung vor dem Sprint, da die Entwickler sich schwer bemühen, die Fehlerbehebungen zu beheben, ohne dabei festzuhalten, um die Art des Defekts zu verstehen.

Hat jemand das versucht oder hat er eine Rückmeldung darüber, wie er der Meinung ist, dass dies funktionieren könnte?

Cheers, Kevin.

0
Spionred