Folge 5: Der geschätzte Bug

Erschienen am 30.09.2016



In Folge 5 geht es um Käfer. Wir wollen die kleinen Kerlchen aber nicht wertschätzen, sondern sprechen darüber, wie man in agilen Softwareprojekten mit Bugs umgehen kann. Anhand unserer eigenen Erfahrung beantworten wir die Fragen, ob es sinnvoll ist, Bugs zu schätzen, wie man Bugfixing transparent gestalten kann und wie man mit neu auftauchenden Bugs umgeht. Zu guter letzt sprechen wir über Bugtracker und Handhabung langer Buglisten.

Links

Pick der Woche

4 Gedanken zu „Folge 5: Der geschätzte Bug“

  1. Mir gefällt die Perspektive, dass Bugs die durchschnittliche Velocity reduzieren und damit die Planung realistischer machen. Das also Bugs nicht geschätzt werden.
    Ich habe aber aus einem Projekt auch schon mitgenommen, dass das Dev Team sich eher wertgeschätzt fühlt, wenn “Bugs” als neue User Story auf das Board kommen. Dahinter stand die Annahme, dass bei der Abnahme einer User Storie die Akzeptanzkriterien offensichtlich erfüllt waren. Wenn also etwas nicht so funktioniert wie es soll, wurde es wohl nicht beim Schreiben der User Story berücksichtigt.

    Habt ihr Vergleichswerte zwischen:
    – Bugs sofort lösen -> Reduzierung der Velocity
    – Bugs als neue User Story bzw. Task

    Bzgl. Stimmung im Team; Anzahl Bugs / pro Sprint

    1. Das mit der Wertschätzung liegt daran, dass ganz klar definiert sein muss, was ein Bug ist. Wenn eine User Story nicht so ist, wie es sich der Product Owner vorgestellt hat, etwa weil er ein Akzeptanzkriterium vergessen hat, dann gehört das auf jeden Fall als neue Story ins Backlog und ist niemals ein Bug. Das gilt auch dafür, wenn der Product Owner eine Story abnimmt, dann aber feststellt, dass doch noch was fehlt. Das unterminiert sonst tatsächlich die Wertschätzung, die das Team fühlt und verwässert außerdem den Begriff Bug und den Begriff User Story. Ich habe nämlich keine Ahnung mehr, was eine User Story wirklich kostet und wie lange sie wirklich braucht, wenn ich noch im Nachhinein über Bugs Anpassungen vornehme.

      Zu den Vergleichswerten:
      Ich hatte mal ein Team, das Bugs “für spätere Sprints” gesammelt hat. Die waren zwar nicht explizit im Backlog, es kam aber quasi aufs gleiche raus. Sowas frustriert ungemein und führt letztendlich zu Bug-Tagen/-Wochen/-Monaten. Im konkreten Fall hat das Team dann tatsächlich einen Monat lang NUR Bugs gefixt. Es gab 150 Bugs, sie haben im Monat 200 geschlossen und danach waren immer noch 50 offen (Nachzulesen hier: http://www.agileblog.org/2013/01/the-evilness-of-bugtrackers.html). Meiner Erfahrung nach führt “Bugs sofort lösen” auf lange Sicht gesehen zu besserer Stimmung im Team (keine Bugliste im Rücken), dem Gedanken, wie man Bugs überhaupt vermeiden kann und auch zu höherer Velocity. Der letzte Punkt mag erstmal unintuitiv erscheinen, aber durch das sofortige Beheben der Bugs, fangen Teams tatsächlich eher an, sich darüber Gedanken zu machen, wie man denn generell die Qualität des Produktes erhöhen kann. Und das führt auf lange Sicht gesehen zu weniger Bugs und damit höherer Velocity. In einem konkreten Fall hat das bei mir dazu geführt, dass sich die Anzahl der Bugs/Monat halbiert hat (steht auch im oben verlinkten Artikel), während die Velocity fast um das Doppelte gestiegen ist.

  2. Die Idee, alle Bugs zwingend immer sofort zu lösen, finde ich aus Sicht der von Euch erläuterten Teamstimmung nachvollziehbar. Allerdings widerspricht das m.E. dem Ziel der Priorisierung nach Value durch den PO.
    Je nach Kontext des Produkts dürfte z.B. das von Euch mehrfach in dieser Folge bemühte Beispiel des Pixelfehlers (o.ä.) vom Product Owner als “good enough for now” empfunden bzw. stattdessen die Konzentration auf Stories die value schaffen als wichtiger erachtet werden. Ich würde daher solche Bugs tatsächlich weiter unten ins Backlog leben (wenn ich als PO weiterhin vor habe den Bug später zu lösen). Ansonsten natürlich konsequent löschen (was leider in Backlogs viel zu selten passiert…).

    1. Da kann man sich sicherlich länger darüber streiten. Meine Meinung dazu ist, dass Bugs in die Verantwortlichkeit des Entwicklungsteams fallen. Das Team ist dafür zuständig ein technisch einwandfreies Produkt abzuliefern. Lässt du den Product Owner über die Priorität entscheiden, dann gibst die Kompetenz über die technische Qualität in Teilen an den Product Owner ab.

      Davon abgesehen, führt Bugs sammeln auch immer zu ewig langen Bug-Backlogs. Meiner Erfahrung nach kann man Bugs, die man nicht direkt behebt, in 80% aller Fälle auch direkt wieder aus dem Bugtracker löschen. Beispiel: Ein Bug, den ich 2009 bei Netbeans geöffnet habe, ist heute noch auf Status “NEW”: https://netbeans.org/bugzilla/show_bug.cgi?id=164149

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.