prinzipiell kann ich Dir nur voll und ganz zustimmen.
Ich habe in Trackern schon Bugs gesehen die fast drei Jahre alt waren und auf Grund des abgeschafften Features gar nicht mehr gefixt werden konnten. Allein das sollte uns schon zu denken geben ob man nach 6 Monaten nicht ein autodelete einführt

Ich fände es wesentlich geschickter bei agilen Softwaremethoden wie Scrum oder XP die Fehler direkt zu fixen wenn es kritisch ist oder in das Backlog zu setzen wenn es für den Kunden von Relevanz ist.

Ich bin jedoch der Meinung, dass nach wie vor in der heutigen Zeit die Zahlen aus den BWLer-Köpfen (sei es Kunde oder Produktmanager) nicht wegzudenken sind und das Tracking für sie ein wichtiges Instrument ist ihre Reports nach oben oder durch die Gegend zu tragen.

lg,

Pete

> Zu “momentan”:
> Ja, es ist richtig, und auch wichtig, dem Berichterstatter
> des Fehlers zu sagen: Dein Fehler wird _momentan_ nicht behoben.
> Es ist eine harte, aber ehrliche Aussage, dass sein Bericht
> (was er sicherlich für wichtig empfindet) nicht beachtet wird.
> Aber es ist auch gleichzeitig ein klares Signal, das er jederzeit
> sich wieder an den Hersteller wenden kann, wenn er der Meinung
> ist, das der Fehler immer noch wichtig (oder noch wichtiger)
> geworden ist.

Oder – der Kunde reagiert frustriert, weil er sich abgewiesen vorkommt, und kauft zukünftig das Konkurrenzprodukt. Dem Kunden das Gefühl zu geben, dass sein Bug derzeit nicht als wichtig erachtet wird, stößt ihn vor den Kopf – denn für den Kunden *IST* er wichtig, sonst hätte er ihn nicht reported.

> Die Entscheidung, ob der Fehler behoben wird oder nicht, obliegt
> originär dem Kunden.

Nein! Dem Kunden obliegt lediglich die Möglichkeit, den Wunsch zu äußeren, dass ein Fehler behoben werden soll – ob er tatsächlich behoben wird, obliegt dem Hersteller der Software.

> [...] Dann kam man endlich zu der Erkenntnis, das es dem Kunden
> lieber ist, ein “nicht ganz vollständiges” Produkt in den Händen
> zu halten, aber eben lauffähig, stabil, mit hoher Qualität. Und
> obendrein auch noch zum versprochenen Termin. [...]

FULLACK. Lieber 20% der Features, die aber zu 100% funktionieren, als 100% der Features, die nur zu 20% funktionieren. Allerdings sehe ich die Analogie noch nicht …

> Genau die selbe Erkenntnis denke ich müssen wir auch beim Bugtracking
> bzw. -reporting haben. Klar ist es wichtig und unser aller Ziel, alle
> Bugs zu beachten und zu beheben, damit wir die
> Kunden- und Anwender-Zufriedenheit optimal bedienen können.

… so weit auch FULLACK, aber ich sehe die Analogie immer noch nicht …

> Es gibt aber Momente, in denen wir Kompromisse eingehen müssen, weil
> wir einfach konkurrierende Prioritäten haben können. In diesem Fall ist
> es meines Erachtens ehrlicher und der Kundenzufriedenheit mittel- bis
> langfristig zuträglicher, wenn man klar kommuniziert, das der Bug nicht
> beachtet wird, statt dem Kunden ein Jahr lang zu versprechen das sein
> Bug in der Liste steht und irgendwann bearbeitet wird, es aber nie
> dazu kommen wird weil andere Faktoren prioritärer gehandhabt werden.

… okay, jetzt sehe ich die Analogie, kann sie aber nur bedingt teilen: Ja, natürlich muss man Kompromisse eingehen, aber der => Kompromiss “Ohne Bugtracking weiß niemand, welche Bugs vor langer Zeit
> abgelehnt wurden, insbesondere aus welchen Gründen dies>
> geschehen ist.”
> -> Frage: Ist das für die Fehlerbehebung. für die Anwender-
> oder Kundenzufriedenheit wirklich relevant?

Ja, insbesondere für die Fehlerbehebung. Ich habe das Gefühl, dass Du immer davon ausgehst, dass eine Entwicklermannschaft sich nicht ändert über die Jahre. Wenn vor drei Jahren schon einmal entschieden wurde, dass ein Fehler aus bestimmten Gründen nicht gefixt wird, kann das für einen Entwickler, der erst seit einem Jahr dabei ist, eine durchaus relevante Information sein – so vermeidet man nämlich doppelte und dreifache Arbeit. Das heißt natürlich nicht, dass man nicht eine einmal getroffene Entscheidung noch mal überdenken könnte, aber man muss nicht jedes Mal das Rad von Grund auf neu erfinden.

> “Ohne Bugtracking weiß niemand, wie oft welcher Bug auftritt
> – dies kann man nur noch nach persönlichem Gutdünken schätzen.”
> -> Frage: Ist das wichtig? Wenn der Fehler alle 5 Min. auf
> einer E-Commerce-Website auftritt, dann wird der Kunde
> höchstwahrscheinlich sein Revenue schützen wollen und den
> Fehler sofort behoben wissen. Aber angenommen, der gleiche
> (offensichtlich unwichtige weil noch nicht gefixte) Fehler
> tritt nach einem Jahr nochmal auf. Wer kann sich daran
> erinnern? Ist es überhaupt wichtig das zu wissen? Welche
> Relevanz hat es bei der Fehlerbewertung und der Entscheidung
> zum Fix? Ich denke es liefert keinen merklichen Beitrag.

Es kann sich eben wahrscheinlich keiner mehr daran erinnern! Desto wichtiger ist es ja, dass man auf ein Archiv zurückgreifen kann, weiß, was schon einmal getan wurde, um dieses Mal gezielter an die Sache herangehen zu können! Auch hier wieder geht es um die Vermeidung von doppelter und dreifacher Arbeit.

Zudem gehst Du davon aus, dass jeder Entwickler alle Bugreports mitbekommt – was, wenn dem nicht so ist? Was weiß denn ich, welche Probleme direkt an meine Kollegen berichtet werden? Wenn so etwas zentral abgelegt ist, wo ich das ganze nachgucken kann, habe ich etwas handfestes, so aber habe ich nur Vermutungen, die zudem subjektiv verfälscht sein können.

Ganz davon abgesehen, dass es enorm hilfreich sein kann, Schritte zur Reproduktion auch nach einem Jahr noch einmal griffbereit zu haben. Auch hierfür ist ein Archiv hilfreich.

> “Ohne Bugtracking bekommt der Benutzer nur die Aussage, dass
> sein Bug momentan nicht behoben wird – was damit zukünftig
> geschieht, kann er nicht nachverfolgen.”
> -> Und? ist das wichtig, nachzuverfolgen, das sein Bug erst
> in einem halben Jahr oder Jahr angefasst wird? Es ist wie die
> Paketverfolgung bei der Post: Wenn es innerhalb von Tagen
> passiert (also im Software-Entwicklungs-Kontext relativ zügig),
> ist die Nachverfolgung sicherlich ein interessanter Beitrag
> und hilft dem Kunden, sich darüber zu freuen. Genausogut
> könnte der Softwarehersteller ihm zusichern, das der Fehler in
> der Version 3.x behoben sein wird. Nur die Antwort (die
> Entscheidung zum Fix) muss schnell passieren. Zurück zur
> Post-Metapher: Dauert die Lieferung eines Paketes von A nach
> B jedoch Monate und ist für den Benutzer nicht rational
> einschätzbar, ist die Nachverfolgung ansich wertlos.

Ja, das ist wichtig – zur Planung. So kann ich mich als Kunde nämlich a) mit dem Bug abfinden, b) einen Workaround suchen oder c) zu einem anderen Produkt wechseln – je nachdem, was mir als Zeithorizont genannt wird.

Und warum das wichtig ist – siehe ganz oben .

> “Ohne Bugtracking weiß niemand, wie viele gefundene,
> aber ungefixte Bugs es in einer Software gibt.”
> -> Wen interessiert das? [...]

Denjenigen, der entscheidet, ob die 20% Features nun zu 100% funktionsfähig sind oder nicht. Wie sonst soll ein Konfigurationsmanager, ein Setupverantwortlicher oder ein Produktmanager entscheiden können, ob ein Release deployed wird?

Da ja nicht alle Fehler in-house gefunden werden (dies sind sogar die wenigsten, die meisten Fehler findet logischerweise der Anwender), ist es durchaus wichtig, zu wissen, wie viele Tasks noch offen sind.

Auch um diese untereinander priorisieren zu können, und eine sinnvolle Planung aufstellen zu können, ist es wichtig.

> Bei dem heutigen Ansatz des überladenen Issue
> Managements sehe ich da kein deutliches
> Unterstützungspotential. Ganz im Gegenteil –
> durch die Existenz des Bugtrackers wird die
> Existenz eines Bugs legitimiert.

Nein! Das Problem ist nicht das Issue oder das Bug Management, sondern das Wörtchen “überladen”! Bugtracking sinnvoll (!) eingesetzt hilft nämlich anstatt zu schaden.

Du hast angesprochen, dass insbesondere große Firmen kein Bugtracking mehr wünschen – vielleicht ist das Prozedere dort aber auch einfach überfrachtet und bedarf einer Schlankheitskur?

Ich will Microsoft nun nicht über den grünen Klee loben, aber ich wage mal zu behaupten, dass diese Firma wie wenige andere weiß, wie man Software entwickelt: Und Microsoft verzichtet nicht auf Bugtracking. Ebenso zahlreiche andere größere Firmen auch nicht.

Viele Grüße,

Golo

natürlich ist das oberste Ziel Fehlerfreiheit, aber das ist doch Wunschdenken. Fehler passieren einfach, mit modernen Methoden zwar weniger, aber sie werden nie ganz verschwinden. Alles andere ist doch Utopie.

> “Welchen Mehrwert hat es für den Kunden oder die Organisation, zu wissen, was wann gefixed wurde?”
Er weiß in welcher Version der Fehler behoben wurde. Stichwörter: ChangeLog, ReleaseLog, …

> “Ist es nach dem Bugfix im Interesse des Kunden oder der Organisation, Zeit und Geld für die Optimierung von Fehlerbehebungen zu investieren, anstatt die Zeit der Prävention von Fehlern und der Weiterentwicklung des Produktes zu widmen?”
> “Angenommen, ein zuvor festgestelltes (und eventuell sogar behobenes) Problem taucht nochmal auf. Ist es für die Fehlerbewertung und Fehlerbehebung (aus Kundensicht) relevant, zu wissen, das dieses Problem schon in der Vergangenheit festgestellt wurde?”
Neben dem Kunden gibt es noch die Entwickler in dem Prozess und für die kann es durchaus eine enorme Bedeutung haben. Der Mensch vergisst schnell. – Also zumindest ich. – Und dem Kunden kommt es zugute wenn der Entwickler schneller Informationen besorgen kann und somit die Anforderungen effizienter umsetzen kann.

- Rene

sehr interessant! Stirnrunzeln bedeutet darüber nachdenken. Das ist schon mal ein gutes Zeichen!

Kurz zu den Punkten, die Dich verwundern:

Zu “momentan”:
Ja, es ist richtig, und auch wichtig, dem Berichterstatter des Fehlers zu sagen: Dein Fehler wird _momentan_ nicht behoben. Es ist eine harte, aber ehrliche Aussage, dass sein Bericht (was er sicherlich für wichtig empfindet) nicht beachtet wird. Aber es ist auch gleichzeitig ein klares Signal, das er jederzeit sich wieder an den Hersteller wenden kann, wenn er der Meinung ist, das der Fehler immer noch wichtig (oder noch wichtiger) geworden ist.

Die Entscheidung, ob der Fehler behoben wird oder nicht, obliegt originär dem Kunden.

Zu “Ehrlich, sachlich, klar”:
Ich möchte hier mal eine Analogie zum Projekt-Management wählen, um es besser erklären zu können. Vor einigen Jahren war man der Meinung, dass man an der Qualität und an der Kapazität des Projektes schrauben muss, um ein Software-Produkt on-time fertigzustellen. Man war immer der Auffassung: “der Kunde braucht alle Features zum Datum X, damit er glücklich wird”. Das Resultat: Druck, Überstunden, Over-Budget, Over-Time. Die Deadline wurde in 80% der Fälle gerissen und der Kunde bekam alle Features – aber zumeist verpätet und dazu auch noch in minderer Qualität. Das Ende vom Lied: Unzufriedener Kunde!

Dann kam man endlich zu der Erkenntnis, das es dem Kunden lieber ist, ein “nicht ganz vollständiges” Produkt in den Händen zu halten, aber eben lauffähig, stabil, mit hoher Qualität. Und obendrein auch noch zum versprochenen Termin. Man hat erkannt: An den Features zu schrauben macht alle zufriedener als vorher. Es ist zwar immer noch nicht optimal, weil der Kunde nicht das bekommen hat, was er sich vorgestellt hat (also alle Features zum Datum X mit hoher Qualität), aber es ist immerhin für den Kunden verkraftbarer, weil man ihm ehrlich gesagt hat, das man es nicht komplett schafft. Dafür garantiert man ihm, das er das, was er zum Datum X in den Händen halten wird, auch zuverlässig verwenden kann. Ein wunderbares Beispiel dafür ist die agile Management-Bewegung, also Scrum, Chrystal oder ähnliches.

Genau die selbe Erkenntnis denke ich müssen wir auch beim Bugtracking bzw. -reporting haben. Klar ist es wichtig und unser aller Ziel, alle Bugs zu beachten und zu beheben, damit wir die Kunden- und Anwender-Zufriedenheit optimal bedienen können. Es gibt aber Momente, in denen wir Kompromisse eingehen müssen, weil wir einfach konkurrierende Prioritäten haben können. In diesem Fall ist es meines Erachtens ehrlicher und der Kundenzufriedenheit mittel- bis langfristig zuträglicher, wenn man klar kommuniziert, das der Bug nicht beachtet wird, statt dem Kunden ein Jahr lang zu versprechen das sein Bug in der Liste steht und irgendwann bearbeitet wird, es aber nie dazu kommen wird weil andere Faktoren prioritärer gehandhabt werden.

Und abschliessend noch zu deiner Auflistung:

“Ohne Bugtracking weiß niemand, welche Bugs vor langer Zeit abgelehnt wurden, insbesondere aus welchen Gründen dies geschehen ist.”
-> Frage: Ist das für die Fehlerbehebung. für die Anwender- oder Kundenzufriedenheit wirklich relevant?

“Ohne Bugtracking weiß niemand, wie oft welcher Bug auftritt – dies kann man nur noch nach persönlichem Gutdünken schätzen.”
-> Frage: Ist das wichtig? Wenn der Fehler alle 5 Min. auf einer E-Commerce-Website auftritt, dann wird der Kunde höchstwahrscheinlich sein Revenue schützen wollen und den Fehler sofort behoben wissen. Aber angenommen, der gleiche (offensichtlich unwichtige weil noch nicht gefixte) Fehler tritt nach einem Jahr nochmal auf. Wer kann sich daran erinnern? Ist es überhaupt wichtig das zu wissen? Welche Relevanz hat es bei der Fehlerbewertung und der Entscheidung zum Fix? Ich denke es liefert keinen merklichen Beitrag.

“Ohne Bugtracking bekommt der Benutzer nur die Aussage, dass sein Bug momentan nicht behoben wird – was damit zukünftig geschieht, kann er nicht nachverfolgen.”
-> Und? ist das wichtig, nachzuverfolgen, das sein Bug erst in einem halben Jahr oder Jahr angefasst wird? Es ist wie die Paketverfolgung bei der Post: Wenn es innerhalb von Tagen passiert (also im Software-Entwicklungs-Kontext relativ zügig), ist die Nachverfolgung sicherlich ein interessanter Beitrag und hilft dem Kunden, sich darüber zu freuen. Genausogut könnte der Softwarehersteller ihm zusichern, das der Fehler in der Version 3.x behoben sein wird. Nur die Antwort (die Entscheidung zum Fix) muss schnell passieren. Zurück zur Post-Metapher: Dauert die Lieferung eines Paketes von A nach B jedoch Monate und ist für den Benutzer nicht rational einschätzbar, ist die Nachverfolgung ansich wertlos.

“Ohne Bugtracking weiß niemand, wie viele gefundene, aber ungefixte Bugs es in einer Software gibt.”
-> Wen interessiert das? Den Kunden? Es mag sein, dass eine Software hunderte von Bugs hat. Aber wenn alle diese Bugs so “unwichtig” sind, dass sie nicht sofort behoben werden, dann interessiert es augenscheinlich den Kunden wenig, dass sein Produkt (die Software) hunderte von Fehler hat. Statt dessen konzentriert er sich auf die wichtigen Fehler oder die Features, die ihn wirklich interessieren. Sollte es einmal zu dem Punkt kommen, wo es den Kunden interessiert, einen Fehler, der schon vor einem Jahr bekannt war behoben zu wissen, dann wird der Fehler eben dann gefixed. That’s it. Das System des “Wegwerfens von Bugreports” und des “Eliminierens von Bugtracking” bei schon bestehenden Software-Produkten hat zur Folge, das die Qualität der Software sich an den Qualitätsanforderungen des Kunden orientiert.

Letztendlich biete ich mit der Eliminierung des Issue Trackings für Software-Projekte einen Denkanstoss und einen validen Ansatz, die Methodik innerhalb der Software-Entwicklung derart zu ändern, dass die folgende Zielsetzung aktiv unterstützt:

“wenn man wirklich das Produkt stetig weiterentwickeln möchte auch immer sich zum Ziel setzen muss, ein möglichst fehlerfreies Produkt auszuliefern”.

Bei dem heutigen Ansatz des überladenen Issue Managements sehe ich da kein deutliches Unterstützungspotential. Ganz im Gegenteil – durch die Existenz des Bugtrackers wird die Existenz eines Bugs legitimiert. Ein Unding, oder nicht?

Gruß,
Ilker

Interessante Ansichten, das hätte ich nicht erwartet. Denn gerade bei großen Unternehmen mit Multiprojekten, Portfolios, Business Development und Product Management will man keinen Bugtracker haben. Man distanziert sich von zentralen Prozessen wie z.B. dem Issue Tracking. Statt dessen wählt man explizit leichtgewichtige und dezentrale Informations- und Kommunikationsflüsse, um den Betrieb (also das eigentliche arbeiten zum Ziel hin) nicht zu stören.

Bugtracking funktioniert bei kleineren Unternehmen (bis ca. 100) vielleicht noch ganz gut, aber sobald die Organisation größer ist, werden genau eure Einwände zu einem Problem, teilweise sogar zu einem großen Problem.

@Ralf: konkret zu Deinen Punkten.

Zu 1:
Es ist wichtig, Bugtracking (Nachverfolgung & Archivierung) nicht mit Bugreporting (Fehlermeldung, Beschreibung & Verifikation) zu vermengen. Bugreporting ist essentiell, um auch den Schweregrad und den “negativen Geschäftswert” des Fehlers einschätzen zu können. Bugtracking jedoch ist nichts anderes als minderwertiger Verwaltungsaufwand, man kann schon fast sagen es ist ein “Beamtenwerkzeug” (das Wort “minderwertig” ist hier wortwörtlich zu verstehen. Ergo: es hat einen minimalen ökonomischen Wert, eine zentrale Fehlerverwaltung einzusetzen).

Zu 2:
Korrekt. Anwender & Kunde sind zwei verschiedene Rollen. Sogar Kunde und Sponsor können unterschiedliche Rollen sein, aber in den seltensten Fällen. Im Regelfall ist der Kunde der Sponsor. Wenn dem so ist, dann entscheidet der Kunde über die Gewichtung. “Ist die Fehlerbehebung wichtiger oder das Feature?”. Entscheidet sich der Kunde für die Fehlerbehebung, so wird der Bug gefixed. Fertig. Entscheidet er sich für das Feature, so wird der Bugreport ignoriert. Mehr noch, er wird komplett aus der zukünftigen Planung (nenn es Roadmap, Backlog oder was auch immer) ausgeschlossen. Der Fehlerbericht wird weggeworfen. Ein Aufschub macht keinen Sinn, denn zu einem späteren Zeitpunkt ist der Kontext und das Produkt mit großer Wahrscheinlichkeit schon ein ganz anderer. Überdies kann der Kunde seine Strategie zu seinem Produkt ja ändern, so dass der Fokus des Fehlers gänzlich irrelevant wird. Ist es jedoch genau anders herum – also steigt das Interesse des Kunden an der Fehlerbehebung – so wird der Kunde dieses Thema sowieso mit Nachdruck zu einem späteren Zeitpunkt wieder anbringen. So einfach ist das.

Zu 3:
Das mag vielleich für Open-Source-Projekte oder “Klitschen” (wie due es nennst) gültig sein, aber große Unternehmen wollen genau das Gegenteil. Große Unternehmen wollen sich nicht an den Fehler vor einem halben Jahr erinnern, weil es schlichtweg ein zu großer Aufwandstreiber innerhalb ihrer Organisation ist. Es kostet viel zu viel, einen “Bug”, der nicht wichtig genug war um ihn sofort zu beheben, zu tracken. Verwunderlich das Du diese Erfahrung noch nicht in großen Unternehmen gemacht hast. Ich kenne Kollegen und Bekannte die wie ich in größeren Unternehmen arbeiten – alle leiden sie unter diesen Symptomen – und alle wollen das Issue-Tracking (für Software-Entwicklung) abschaffen.

Zu 4:
Refelxartig wird garnichts gemacht – schon garnicht in der professionellen Software-Entwicklung. Sondern es wird das gemacht, was für die Zielerreichung des Kunden am zuträglichsten ist. Der Kunde wird natürlich informiert – er muss ja die Wertigkeit abschätzen und schlußendlich (nach eventuellen technischen Konsultationen) entscheiden. Aber der Kunder wird das sicher nicht für 10 oder 20 Bugs machen wollen. Mal abgesehen davon, dass der Kunde spätestens beim dritten schwerwiegenden Fehlerbericht, der an ihn herangetragen wird stirnrunzelnd seinen Auftraggeber fragen wird ob er überhaupt seinen Job richtig macht.

Und noch generell:
Es geht nicht darum, das Team zu tyrannisieren, sondern effizient und professionell zu arbeiten. In der professionellen Software-Entwicklung wendet man nicht agile Verfahrensweisen an, um den Entwicklern einen Gefallen zu tun, sondern um seine Zielerreichung effizient und ökonomisch optimiert zu gestalten. Eine wichtige Erkenntnis großer Organisationen ist es in den letzten Jahren gewesen, dass man dazu nicht nur die operativen Werkzeuge ändern muss, sondern ebenfalls die Organisation und Prozessstruktur selbst (teilweise drastisch) anpassen muss – ich erinnere da nur an Conway’s Gesetz.

@Rene:
Versuche doch mal die folgenden Fragen für dich selbst zu beantworten:
- Welchen Mehrwert hat es für den Kunden oder die Organisation, zu wissen, was wann gefixed wurde?
- Ist es nach dem Bugfix im Interesse des Kunden oder der Organisation, Zeit und Geld für die Optimierung von Fehlerbehebungen zu investieren, anstatt die Zeit der Prävention von Fehlern und der Weiterentwicklung des Produktes zu widmen?
- Angenommen, ein zuvor festgestelltes (und eventuell sogar behobenes) Problem taucht nochmal auf. Ist es für die Fehlerbewertung und Fehlerbehebung (aus Kundensicht) relevant, zu wissen, das dieses Problem schon in der Vergangenheit festgestellt wurde?

Abschliessend sollte ich vielleicht mein Statement etwas erweitern:
Bugtracking ist sinnlos! Vor Allem für großen Unternehmen!

ich kann dem Artikel auch nicht zustimmen – siehe auch http://www.des-eisbaeren-blog.de/post.aspx?id=9524dfd7-5140-4bd1-ac7d-4a85451dcd5d

Viele Grüße,

Golo

Klar sollten die Leichen, also offene und alternde Reports, nicht für immer das System vollmüllen und nach einer gewissen Zeit evtl. entfernt werden. Diese Kandidaten lassen sich in mit einem ordentlichen Bugtracking System aber auch ausfindig machen, filtern und / oder entfernen.

Von daher kann ich Ralf Westphal nur zustimmen.

Wo ein wenig systematischer gearbeitet wird oder der Laden größer ist, da funktioniert das jedoch nicht mehr.

1. Der Bug kommt beim Support rein, der ihn maximal reproduziert. Eine Entscheidung, ob und wann und von wem der Bug behoben wird, trifft der Support nicht. Deshalb muss der Bug protokolliert werden. Das geschieht in einem Bug-Tracking-System. Das Team holt ihn dort irgendwann ab und entscheidet über das weitere Vorgehen.

2. Anwender und Kunde sind zwei Rollen. Nur weil ein Anwender sich von einem Bug genervt fühlt, heißt das nicht, dass der Kunde ihn auch sofort behoben haben möchte. Bugfixing und Fertigstellung anderer Features sind abzuwägen. Ein Bug darf nicht zwangsläufig zu einem “Notaus” für die Arbeit an einem Projekt führen. Also müssen Bugs wie Features “getrackt” werden, weil sie erst später abgearbeitet werden.

3. Nicht jeder Bug lässt sich sofort reproduzieren. Ein Fix mag nicht daher jetzt nicht möglich sein. Aber man möchte den Fehler natürlich auch nicht vergessen, denn wenn er später wieder gemeldet wird, möchte man sich daran erinnern und Fehlersituationen vergleichen. Also ist Tracking nötig.

4. Ob eine Fehlfunktion aus Sicht des Anwenders letztlich ein Bug ist oder auf eine mangelhafte Anforderung zurückzuführen ist, muss womöglich in Gesprächen mit dem Kunden entschieden werden. Davon hängen womöglich vertragliche Konsequenzen ab. Ein reflexartiges Fixing verbietet sich in solchen Fällen. Also muss der Bug “getrackt” werden bis zu Fix.

Alles in allem sehe ich nicht, was das Problem mit dem Bugtracking ist. Es ist nur eine simple Liste, die hilft, die Arbeit ein wenig zu organisieren. Bugs dürfen bei allem Verständnis dafür, dass sie nerven und eigentlich nicht vorkommen sollten, ein Team nicht tyrannisieren. Also darf es sein, dass Bugs nicht sofort gefixt werden. Zudem fungiert ein Bugtracker als Gedächtnis. Er ist ein Mittel zur Reflektion.

Noch kurz zu Clean Code Developer (CCD): Die Initiative hat zwar ihren Ausgangspunkt beim Buch “Clean Code” von Robert C. Martin. Aber CCD hat ausdrücklich nichts mit der Software Craftsmanship Bewegung zu tun. Bei CCD geht es um konkrete Bausteine zur Verbesserung der inneren Qualität von Software. Bei den Craftsmen geht es um die Entwicklung einer “moralischen Position” bzw. charakterlichen Haltung von Menschen, die Software produzieren.

-Ralf