Wie gehen wir mit Fehlern in der Scrum-Umgebung um?

Wir haben kürzlich begonnen, mit einem unserer Produkte an Scrum zu arbeiten. Davor haben wir mit einer Wasserfall-Methodik gearbeitet.

Wir haben Geschichten für das neue Feature erstellt und auch die Fehler für die nächste Version aufgenommen, und wir schätzen Geschichten in Story Points. Wir sind uns nicht sicher, wie wir mit Fehlern umgehen sollen. Müssen wir in Story Points oder in Tagen für Bugs schätzen?

Das Team stellt fest, dass bei einigen Fehlern der größte Teil des Aufwands auf die Analyse entfällt, da der Fehler eher Debugging- und Fehlerbehebungsbemühungen als die tatsächliche Codeimplementierung erfordert.

Wie schätzen wir diese spezifischen Fälle ein, in denen der Großteil des Aufwands für die Analyse aufgewendet wird und ein Teil dieser Analyse Tage bis Wochen dauern kann, bis sie abgeschlossen sind?

Bitte helfen Sie

Das scheint schon einmal gefragt (und beantwortet) worden zu sein, aber ich ziehe keine Duplikate hoch. Kann jemand anderes ein Duplikat finden, das ein gültiges nahes Ziel abgeben würde?

Antworten (3)

Wählen Sie einen konsistenten Schätzansatz, der Story Points verwendet (verlassen Sie sich nicht auf Stunden).

Sie haben Optionen:

Option 1:

Schätzen Sie niemals die Größe des Fehlers in Story Points. Begründung: Ein Mangel liegt vor, wenn ein vorheriges Abnahmekriterium aus einer bestehenden (bereits geschätzten) Story nicht erfüllt wurde. Durch die Schätzung des Mangels wird dann der Teil der Arbeit, der erforderlich ist, um die Geschichte zu liefern, doppelt gezählt.

Ergebnis: Iterationen mit vielen Fehlern zeigen eine geringere Geschwindigkeit. Das Team ist gezwungen zu diskutieren, warum ihre Geschwindigkeit gesunken ist und warum so viele Fehler auftreten. Con... es ist schwieriger für das Team, sich dazu zu verpflichten, alles in der Iteration abzuschließen, wenn sie es nicht formell bemessen haben.

Option 2:

Schätzen Sie die Größe des Defekts immer anhand von Story-Points ab. Überlegung: In einer Iteration wollen wir die Story-/Defect-Workload an dem ausrichten, was das Team fertigstellen kann.

Als Ergebnis behält das Team eine konsistente Geschwindigkeit bei und kann sich genau auf die Arbeit innerhalb einer Iteration festlegen. Con ... es ist empirisch nicht so offensichtlich, dass die Wertschöpfungsarbeit sinkt, wenn die Fehlerlast zunimmt.

Stundenschätzung und Tasking liegen in Scrum in Ihrem Ermessen. Persönlich rate ich davon ab, Aufgaben oder Stunden in Ihrer Scrum-Software formell zu verfolgen, da dies zusätzlichen Overhead verursacht und einigen Teams ein unerwünschtes Mikromanagement-Gefühl vermitteln kann.

„Dennoch ist es für das Team schwieriger, sich dazu zu verpflichten, alles in der Iteration abzuschließen, wenn sie es nicht offiziell bemessen haben.“ nicht wirklich, da dies während der Sprintplanung erfolgt - Sie verwenden Ihre Kapazität in Stunden, um diesen Fehlern Zeit zuzuweisen, und führen diese formelle Größenbestimmung genau dann durch.
Die Stundenschätzung während der Sprintplanung ist keine Anforderung von Scrum. Mit formaler Schätzung meine ich eine Story-Point-Schätzung. Es ist möglich, die Kapazität auf der Grundlage historischer Story-Pointing-Praktiken zurückzurechnen, aber auch hier wissen Sie nur, dass Sie X Gesamtkapazität haben, von denen Y Storys + Z Defekte sich zu X summieren sollten. Wenn Sie jedoch keine Defekte zeigen, tun Sie Y + Z kann gleich X sein oder nicht.

Wenn Sie Scrum betreiben, machen Sie es sich zur Regel, dass Sie während des täglichen Standup-Meetings über den Fortschritt von Fehlern sprechen. Wenn Sie wissen, was die Grundursache ist, können Sie beginnen, den Fehler als User Story zu behandeln: Sie können Größe oder Schätzungen angeben, weil Sie wissen, womit Sie es zu tun haben.

Wenn Sie keinen Fortschritt hören – sagen wir in 2 oder 3 Tagen – sollten Sie etwas dagegen unternehmen, da ein schwerwiegender Fehler Ihr Projekt gefährden kann. Sie können entweder vorschlagen, dass sich mehr Personen mit dem Problem befassen, Sie können den Sprint abbrechen (besprechen Sie diese Möglichkeit mit Ihrem PO), oder Sie können die Situation eskalieren und um Vorschläge vom PO oder anderen Teams bitten.

Das wichtigste zuerst

Wenn die Fehlerbehebung Tage oder sogar Wochen dauert, ist dies ein klares Zeichen für schlechtes Code-Design . Dies bedeutet, dass Ihr Projektcode schwer zu testen ist, was Ihnen viel mehr Sorgen bereiten sollte als die Schätzung von Fehlern.

Einschätzung

Da Sie mit Scrum beginnen und an Schätzungen von Tagen/Stunden gewöhnt sind, schlage ich vor, dass Sie vier Arten von Problemen behandeln:

  1. Benutzer Geschichte. Fügt die benutzerseitige Produktfunktionalität hinzu. Beispiel: „Als Benutzer möchte ich mich über Facebook anmelden“. Schätzen Sie User Storys in Story Points .
  2. Teilaufgabe. Kind einer User Story. Gibt an, was getan werden sollte, um die Story abzuschließen. Jede Story sollte mindestens eine Unteraufgabe haben. Beispiel: „Anmeldeansicht implementieren“. Schätzen Sie die Teilaufgaben in Stunden .
  3. Insekt. Die Diskrepanz zwischen der erwarteten Funktionsweise des Systems und dem tatsächlichen Verhalten. Beispiel: „Das Aufgeben einer Bestellung leitet einen Benutzer auf die 404-Seite um“. Schätzen Sie Bugs in Stunden .
  4. Aufgabe. Alles, was nichts mit User Experience zu tun hat und zu keiner User Story gehört. Beispiel: „Jenkins einrichten und konfigurieren“. Aufgaben in Stunden schätzen .

So profitieren Sie von einem solchen Ansatz:

  • Sie können messen, wie sich Ihr Produkt entwickelt. Verwenden Sie einfach die Sprint-Geschwindigkeit basierend auf Story Points. Was deutlich zeigt, dass sich Ihr Produkt nicht weiterentwickelt, wenn Ihr Sprint mit Aufgaben und Fehlern gefüllt ist.
  • Sie können Ihren Sprint-Burndown nachverfolgen. Alles, was Sie im Sprint tun, ist entweder eine Teilaufgabe einer Story, ein Fehler oder eine Aufgabe. Sie schätzen sie in Stunden und können die Leistung innerhalb des Sprints verfolgen.

Aber achten Sie bitte auf den ersten Absatz. Fehlerbehebungen sollten niemals Tage oder Wochen dauern.

Danke für die Antwort. Der Grund dafür, dass es länger dauert, ist, dass der Produktcode ursprünglich nicht vom Team geschrieben wurde. Das Team erhielt den Code aufgrund des Lieferantenmanagements durch den Kunden. Ursprünglich wurde es von einer anderen Firma bearbeitet und jetzt sind wir dafür verantwortlich, daran zu arbeiten. Ja, wir hatten einen anfänglichen Wissenstransfer, aber Sie können die Lücke beim Verständnis der Funktionalität und der Codeimplementierung erwarten. Dies führt also zu Verzögerungen bei der Behebung von Fehlern
@ramu: Wenn die Unkenntnis (von Abschnitten) des Codes ein Problem darstellt, sollten Sie dies in Ihre Schätzungen einbeziehen.
Wie gehen wir mit Fehlern in der Scrum-Umgebung um?
AntwortenHierDatenschutz-Bestimmungen1y, 0v