Vorweg, der folgende Post soll primär zeigen wie gut wir mit Bugs umgehen, nicht das Gegenteil. Ich denke auch, dass wir einen hochwertigen Entwicklungsprozess haben, den wir immer weiter verbessern, dieser Post soll dabei helfen.
Das folgende Diagramm zeigt die Entwicklung der aktiven Bugs seit dem 13 November 08 für www.camping.info.
Wie läst sich hohe Anzahl der Fehler erklären?
Nach Sichtung der offenen Fehler, lassen sich folgenden Gründe finden:
1:) Verbesserungen werden als Bug erfasst. Oft sind die Grenzen zwischen Bug und UserStory verwaschen. Ob die nicht vorhandene Benutzernachricht ein Fehler oder ein Verbesserungswunsch ist, ist oft eine Grenzfrage. Der Vorteil eine Verbesserung als Bug zu erfassen liegt vermeidlich darin, dass der Verbesserungswunsch/Bedarf, nicht in der Vielzahl von UserStories untergeht.
2) Alte Bugs werden nicht reviewed und geschlossen. Ein Fehler der nicht der aktuellen Iteration zugeordnet ist geht gerne unter, auch wenn er schon lange nicht mehr besteht. Denn das Reviewen und Schließen kostet in jedem Fall Zeit und unser Kunde brauch neue Features!
3:) Fehler die reported wurden, aber nicht zuzuordnen sind. Beispielsweise wurde mehrfach beobachtet, dass das CSS der Seite im Firefox nicht geladen wurde. Auch wenn sich im entsprechenden Bug die Lösungsansätze sammeln, konnte der Fehler konnte noch nicht nachvollzogen werden. In dieser Kategorie haben wir einige Fehler die wir vermutlich auch nicht so schnell lösen werden und sollten, mit Blick auf die richtige Prioritisierung.
Bug: Als Entwicklungsfeedback
Das folgende Diagramm zeigt die geschlossenen Bugs seit dem 13 November:
Hier ist es möglich, das eine Prozess-Problem dokumentiert wird. Entwicklungen werden umgesetzt und geclosed. Mark unser Tester deployed auf den Stage-Server und findet Fehler die als Bug-reported werden. Ein Verbesserung könnte erreicht werden, in dem wir konsequenter UserStories auf “zu Testen” setzen und Probleme in weiteren Aufgaben, Fragen und Testfällen dokumentieren.
Insgesamt würde ich mir wünschen, das wir weg kommen vom Ansatz Bugs als Kommunikationsmittel zu verwenden, hin zu eine Arbeitsweise in der Bugs als Qualtitätsmetrik nützlich sind.
In wieweit eine solche Perspektive Projekten wirklich hilft, scheint mir schwer zu sagen, wobei ich ein bisschen hoffe, dass sich Prozesse durch Formalisierung und Analyse verbessern und optimieren lassen.