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

8 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

  3. Sehr guter Podcast zu einem Thema, dass mich auch schon oft umgetrieben hat. Ich würde auch dazu tendieren die Bugbehebung in die Verantwortung des Teams zu geben, da sonst die Bugliste im Rücken selbst zur Demotivation führt. Außerdem wird die Behebung tendenziell teuerer, wenn man zu lange damit wartet.

    Eine Frage hätte ich nun jedoch: Wie geht ihr mit dem Commitment des Teams zum Sprintziel um, wenn es während des Sprints Bugs hagelt oder diese auch vor dem Sprint schon für diesen mitgenommen wurden. Auch ich lasse Bugs nicht schätzen, aus benannten Gründen. Auf der anderen Seite stehen aber die “wertschöpfenden Sprintziele” aus den Stories, welche liegenbleiben würden, wenn man Bugs die Überholspur zugesteht.

    Würde das Team zum Commitement stehen, würde das bedeuten, dass Überstunden benötigt würden, um “alles” zu schaffen. Vom “Pufferplanen” halte ich nichts, aus den gleichen Gründen aus denen Bugs nicht geschätzt werden können. Lasst ihr also konsequent Stories vom Ende des Sprint Backlogs liegen, wenn sich die Bughebebung als sehr aufwändig herausstellt und öffnet damit die Tür zum Scheitern des Sprints (= Sprintziel nicht erreicht) oder habt ihr eine andere Lösung?

    1. “Würde das Team zum Commitement stehen, würde das bedeuten, dass Überstunden benötigt würden, um “alles” zu schaffen.”

      Korrekt. Die technische Qualität ist die Verantwortung des Entwicklungsteams, es ist damit auch seine Aufgabe eine möglichst bugfreie Software abzuliefern. Wenn es in einem Sprint auf einmal Bugs hagelt, dann sehe ich da definitiv Rede- und Handelbedarf – mindestens in der Retrospektive. Tendenziell bedeuten viele Bugs natürlich eine verringerte Velocity, es ist damit also im Interesse des gesamten Scrum Teams eine bugfreie Software herzustelen.

  4. Zum Thema Bugtracker sei folgende traurige Geschichte (von Fefe) erwähnt, der einen Bug in umatrix melden wollte:

    Der Autor hat das Bugtracking-System zugemacht. Oben stand klar und deutlich drüber: Keine Bugs für Seiten melden, die man sich kaputtkonfiguriert hat. Und die Leute haben das gesehen und trotzdem lauter solche Bugs aufgemacht. Also hat der Autor das Bugtracking-System zugemacht und jetzt ist es für alle Scheiße. Und ich bin mir fast sicher, dass keiner von denen sich im Unrecht wähnt, oder auch nur verstanden hat, dass er das gerade für alle kaputt gemacht hat.

Schreibe einen Kommentar

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