Sollten Bugs als Storys oder als Tasks behandelt werden?

Ich verwende eine modifizierte Version von Scrum mit meinen Teams in wochenlangen Sprints. Das Product Backlog ist von oben nach unten nach Wichtigkeit geordnet. Das Entwicklungsteam nimmt die obersten Elemente vom Stapel und bearbeitet sie.

Wenn das Feature am Ende der Woche nicht fertig ist, besprechen wir, was am Ende des nächsten Sprints erledigt wird, und die Arbeit an den unvollständigen Elementen wird fortgesetzt.

In Managing Bugs in Scrum schlägt der Autor Mark Summer vor, Bugs genauso zu behandeln wie ein teilweise implementiertes Feature. Genau genommen ist das genau das, was ein Bug ist. Es ist ein bestimmter Teil einer Funktion, die nicht vollständig implementiert ist.

Ich habe derzeit eine Fehlerliste und eine Feature-Liste. Ich erwäge, sie zusammenzuführen und die Fehler als unvollständige Funktionen zu behandeln, wie vom Blog-Autor vorgeschlagen. Dies wird die Herausforderungen, denen ich bei der Priorisierung von Aufgaben gegenüberstehe, erheblich vereinfachen, und es wird es Entwicklern erleichtern, Aufgaben aus dem Product Backlog Stack zu ziehen.

Meine Empfehlung für Teams, die ich coache, ist, Fehler in zwei Arten zu unterteilen:

• Die Fehler/Defekte, die auf einen Fehler in der AKTUELLEN Arbeit zurückzuführen sind (z. B. Story aus dem aktuellen Sprint) – für diese empfehle ich, sie als Aufgaben in dieser Story zu verfolgen und als Blocker dafür, dass diese Story DONE/Accepted wird.

• Bugs/Defekte, die erkannt wurden, aber vermutlich schon seit einiger Zeit vorhanden sind, vielleicht sogar bereits in der Produktion vorhanden sind – behandeln Sie diese als Rückstandselemente, die Sie priorisieren müssen. Das ist normalerweise eine Entscheidung/Richtlinie des Produktmanagements/Eigentümers. Das Endergebnis KANN sein, dass Sie sie sofort beheben, aber es hängt von der Priorität ab.

Das Wunderbare an Agile ist, dass wir Konzepte wie die Anforderungsbaseline zurückgezogen haben, sodass der Unterschied zwischen einem Fehler und einer Geschichte für ein agiles Team kein Argument ist, das sich lohnt. Beide repräsentieren "Zeug", das Sie brauchen.

Wenn der Fehler Teil der Arbeit ist, die in einer Iteration/einem Sprint durchgeführt wird, und wir ihn in diesem Sprint/in dieser Iteration beheben möchten, behandeln Sie ihn wie eine Aufgabe. Andernfalls fügen Sie es dem Product Backlog hinzu.

Wenn sich der Fehler im Produkt-Backlog befindet, ist es sinnvoll, ihn zu beheben, andernfalls sollte er nicht im Backlog sein. Der Fehler sollte auch geschätzt werden, sonst haben Sie Schwierigkeiten bei der Planung und Messung.

Es gibt einen Sonderfall, in dem eine neue Entwicklung einen latenten Fehler aufdeckt, der so schwerwiegend ist, dass er sich auf die gesamte Iteration auswirkt, und ich glaube nicht, dass es für diesen Fall eine einfache Antwort gibt.

Bei mir kommt es auf die Größe, Schwere und wann sie gefunden wird an.

Wenn es beim Testen eines geplanten Features gefunden wird, geht es zurück in die Entwicklung, um überarbeitet und im Scrum besprochen zu werden.

Wenn es sich um wichtige, rote Alarm- und Warnsignale handelt, muss wahrscheinlich eine eigene Aufgabe in den nächsten Sprint eingefügt werden.

Wenn während des allgemeinen Testens ein Haufen kleinerer Fehler mit normaler Priorität gefunden wird, neige ich dazu, Karten zu erfinden, auf denen steht: "Fixiere 5 ausstehende Fehler" (oder eine andere geeignete Zahl), weise ihm einen kleinen Wert zu und aber im Rückstand mit allen andere Aufgaben.

Hängen Sie sich nicht an der Terminologie auf – stellen Sie einfach sicher, dass sie nachverfolgt, repariert und abgerechnet werden können.

Was ist der Unterschied zwischen einer Geschichte und einer Aufgabe? Oder eine Geschichte und ein Epos? Oder ein Fehler und eine Geschichte?

Meiner Meinung nach ist das alles Arbeit.

Wenn in einer Story, an der wir im aktuellen Sprint arbeiten, ein Fehler gefunden wird, wird die Story zurück in die Sprint-Ready-Warteschlange verschoben und durchläuft den Prozess erneut.

Wenn es etwas ist, das nichts mit dem aktuellen Sprint zu tun hat und von der PO priorisiert wird, egal ob es sich um einen Fehler mit zuvor gelieferter Arbeit oder etwas Neues handelt, wird es in die Sprint-Ready-Warteschlange verschoben und fließt durch den Prozess zurück.

Ich stimme zu: - wenn ein Teil der Arbeit am aktuellen Feature, behandeln Sie es als Teil des Sprints und nicht als separaten Fehler - wenn es außerhalb des Sprints liegt (z. B. von einem Produktionsproblem), dann erstellen Sie ein Bug-Element im Backlog.

Solltest du ihnen Story Points geben:

• Ja : bedeutet, dass sie wie Geschichten behandelt werden und bei der Genauigkeit Ihres Planungsprozesses helfen. Es impliziert jedoch auch, dass sie einen geschäftlichen Mehrwert schaffen und Teil Ihrer Team-Velocity-Messung sind, was sie nicht sollten

• Nein : bedeutet, dass sie nicht als Mehrwert für das Unternehmen behandelt werden und die Geschwindigkeit bestraft wird, wenn Sie ein Qualitätsproblem haben, das angegangen werden muss, und sinkende Geschwindigkeit wäre ein Indikator. Es bedeutet auch, dass es Ihnen möglicherweise schwer fällt, Ihre Releases gegen den Rest Ihres Backlogs zu planen.

Ein Fehler ist per se ein Fehler und sollte als Aufgabe behandelt werden. Ich sehe keinen Unterschied, Sie können einen Sprint mit Aufgaben zur Fehlerbehebung haben.

Für mich ist der Fehler in der Implementierung normalerweise eine Aufgabe.

Fehler in Design/Architektur sind normalerweise nicht so einfach zu beheben und enden in der Regel als Geschichte.

Etwas, das mehr Wert beimisst, ist ein Feature oder eine Geschichte. Ein Fehler ist ein Fehler in einem abgeschlossenen Feature/einer Geschichte.

So nehmen Sie eine Seite von Notch, dem Schöpfer von MineCraft:

Ich habe ein paar Pläne und Visionen, aber meine einzig wahre Designentscheidung ist, es unterhaltsam und zugänglich zu halten. Es gibt kein Designdokument, aber es gibt zwei Listen; eine für Fehler und eine für Funktionen, die ich hinzufügen möchte, aber denke, dass ich sie vergessen könnte.[ 1 ]

Sein Ansatz impliziert, dass, wie andere gesagt haben, beide Softwareelemente darstellen, die geliefert werden müssen. Das Kombinieren der Listen, wie es jmort253 vorgeschlagen hat, würde jedoch helfen, den Rückstand zu priorisieren.

Mit unserem Team behandeln wir sie als Hybridartikel. So wie wir Scrum machen, bekommen Stories immer Punkte und Aufgaben nie. Bugs erhalten keinen vom Team zugewiesenen Story Point-Wert. ABER wenn wir unsere Sprint-Rückstände festschreiben, brauchen wir eine Möglichkeit, Fehler abzuschätzen, richtig? Aus Gründen der Planung und Geschwindigkeit ordnen wir jeden einzelnen Fehler einer 2-Punkte-Geschichte zu – während einige viel größer und andere viel kleiner sind, finden wir, dass dies für Schätzungszwecke gut funktioniert.

Ein Fehler ist eine Ausgabe von „Verification“ und eine Eingabe für „Project Planning“ und „Requirements Development“ (gemäß CMMI ). Um eine transparente Rückverfolgbarkeit zwischen Artefakten zu gewährleisten, sollten Sie sich daher auf Ihre Fehler beziehen, wenn Sie Änderungen an "Geschichten" vornehmen und neue "Aufgaben" planen.

Eine Praxis, von der ich gehört habe, besteht darin, eine Reihe verwandter Fehler in einem einzigen Produkt-Backlog-Eintrag zu gruppieren. Das macht für mich Sinn, da es in einem großen System Hunderte von Fehlern geben kann und die Verfolgung aller als separate Produkt-Backlog-Elemente eine beträchtliche Menge an Backlog-Grooming-Verschwendung verursachen würde.

Auf diese Weise ist es auch einfacher, dem Endbenutzer einen Wert zuzuschreiben, und wir vermeiden auch Schätzungen in Bruchteilen eines Story Points, die sonst bei trivialen Fehlern unvermeidlich wären.

Hier gibt es also einige Mehrdeutigkeiten von Begriffen, die wir meiner Meinung nach zuerst ansprechen müssen. Lassen Sie uns alle sicherstellen, dass wir uns einig sind, was ein "Bug" ist. Ich würde einen Fehler als ein Problem in der Software in Bezug auf das, was der Produkteigentümer von der Software erwarten würde, betrachten, das nicht während des aktuellen Sprints eingeführt wurde.

Mit dieser Definition eines Fehlers verdeutlicht sie meiner Meinung nach etwas, wie der Fehler behandelt werden sollte. Die Software verhält sich auf eine Weise, die der Besteller nicht mag, so dass sie in gewissem Sinne eine Bugfix-Anfrage einreichen, in einem anderen Sinne einfach eine Feature-Anfrage stellen. Aus dieser Perspektive scheint es ziemlich klar zu sein, dass Fehler als Geschichten behandelt werden und als solche funktionieren sollten.

Jetzt aus den Schützengräben. Meiner Erfahrung nach hat das, was wir klassischerweise als Bugs bezeichnen würden (sich schlecht verhaltende Software), eine höhere Variabilität in ihrer tatsächlichen Größe gegenüber der geschätzten Größe als eine „Standard“-Story. Ich denke nicht, dass das ein überzeugender Grund dafür ist, Fehlerkorrekturen NICHT als Geschichten zu behandeln, aber es ist etwas, das mir aufgefallen ist. Eine Technik, die ich verwendet habe, um dies zu überwinden, besteht darin, das Entwicklungsteam einige Minuten damit verbringen zu lassen, bevor es den Fehler untersucht. Ich ermutige zu einer leichten Überprüfung des Problems, und ich denke, es hat zur Genauigkeit der Schätzung beigetragen.