Bugtracking ist sinnlos!
Es ist nun schon einige Zeit vergangen, seit dem ich das letzte Mal über Bugs gebloggt habe. Damals habe ich mich etwas näher mit dem Thema Bugreporting auseinandergesetzt. Und nach wie vor bin ich der Meinung, dass das Bugreporting ein wichtiger und wesentlicher Bestandteil des Issue Managements ist. Was das Bugtracking allerdings angeht, so bin ich anderer Meinung.
Ich möchte gleich mal eine provokante Aussage in den Raum werfen: Bugtracking für Software-Projekte ist sinnlos. Jedenfalls in den meisten Fällen. Mehr noch, Bugtracking sollte soweit wie nur irgend möglich vermieden werden!
Was will ich damit sagen? Man betrachte einmal das mittlerweile so “selbstverständliche” Tooling bei Software-Projekten: Man nehme ein SCM (z.B. SVN oder git), ein CI-System (z.B. TeamCity oder CruiseControl) und einen IssueTracker (z.B. Bugzilla oder Trac). Man kann das ganze natürlich auch als Gesamtpaket haben, z.B. mit TFS. So, damit hat man die Eckpfeiler einer Software-Entwicklungsumgebung parat und kann frisch und fröhlich programmieren. Ich denke allerdings das dieses Toolset nicht ganz so glücklich gewählt ist.
Bugtracking ist Zeitverschwendung
In einer Zeit, in der viel getan wird, um einen sauberen Code zu produzieren ist meiner Meinung nach die jetzige “Methodik des Bugtrackings” nicht mehr adequat. Entwickler versuchen mit agilen Methoden (teilweise krampfhaft) mehr Qualität und Stabilität in ihre Produkte zu bringen. Ein aktuelles Beispiel ist die Beachtung und Anwendung der Prinzipien der Clean Code Developer Bewegung, die Ihre Kernaussage aus der Craftsmanship-Ideologie von UncleBob schöpft. Darüber hinaus beschäftigt sich die gesamte Softwareentwicklungsindustrie seit Jahren mit Themen wie z.B. Continuous Integration oder Test-Driven-Development, die mitunter das Ziel haben, die Qualität des Softwareproduktes schon während der “Produktionsphase” stetig hoch zu halten. Flankiert wird das ganze auch noch mit agilen Managementmethoden wie z.B. Scrum oder Kanban, die auch einen besonderen Anspruch auf stetige, hohe Qualität legen.
Nichtsdestotrotz findet man in jedem Tool-Setup den altbekannten “Bugtracker” wieder. Wieso? Auf der einen Seite strebt man nach dem “Zero-Defect”, nach hochqualitativer Software. Aber mit dem gleichen Atemzug gibt man sich dennoch geschlagen, indem man von vornherein mit Bugs rechnet. Denn einen Bugtracker zu betreiben ist in den allermeisten Fällen nichts anderes als ein Geständnis. Undzwar das Geständnis sich selbst gegenüber, doch nicht alles “hundertprozentig” zu machen. Es ist ein Widerspruch in sich. Jaaaa, Clean Code, TDD, BDD, DDD und noch eine handvoll anderer bewährter Methoden, von mir aus noch Pair Programming, Continuous Integration / Deployment und Scrum. Aber: Ein Bugtracker muss auf jeden Fall auch her.
Bugtracker ist nicht gleich Liste und schon garnicht Archiv
Man mag mir entgegenbringen, dass mit einem “Issue Tracking”-System nicht nur Bugs verwaltet werden, sondern auch Feature-Requests und ähnliches. Featurelisten sind eine wunderbare Sache, vor Allem wenn man sie priorisieren kann. Aber dazu braucht man keinen Bugtracker. Im Allgemeinen reichen einfachere Tools aus.
Das am meisten erwähnte Gegen-Argument ist wohl, das man mit dem Bugtracker die Bugs “verwalte”, um sie ja nicht zu vergessen und Ihnen angemessene Priorität zu geben. Lächerlich! Eine Farce, denn in der professionellen (wirtschaftlich orientierten) Softwareentwicklung ist solch ein Ansatz absolut kontraproduktiv. Erstens schafft es einen weiteren Verwaltungs- und Organisationsapparat, den es erst mal zu bewältigen gilt. Zweitens mutiert es mit der Zeit zu einer Halde (ich will schon fast sagen Müllhalde) von unwichtigen Bugs und Feature-Requests, die man irgendwann einmal angehen will. Drittens stellt es automatisch und implizit ein Konkurrenzsystem zur Roadmap dar. Warum?
Na ganz einfach: wenn ein Bug wirklich ein wichtiger Bug ist, dann wird er sofort gefixed. Alles andere ist entweder nicht wichtig oder wird dann erst wichtig, wenn die wichtigeren Dinge schon erledigt sind. So einfach ist das.
Außerdem: Gefühlt implementiert nahezu jeder, der was auf sich hält seine Software mit agilen Methoden und Praktiken. Scrum und XP sind schon längst angekommen; und mit TDD und Clean Code wir bewegen uns auf einem hohen Niveau, oder nicht? Unsere Grundmotivation ist es doch, fehlerfreie Software auszuliefern, oder nicht? Ok, 100%ig gibt es nie, aber wir streben doch zumindest die three nines der “High Quality” an, oder nicht? Ich denke schon – zumindest ist das mein Verständnis. Wenn dem so ist, warum brauchen wir dann ein Bugtracking-Tool?
Bugreporting ist wichtig, Bugtracking jedoch unwichtig
Ich möchte mit meiner provokanten Aussage nicht erreichen, das man grundsätzlich das Issue Management anzweifelt. Es ist eher das Gegenteil der Fall. Ich stärke sogar die Wichtigkeit & Effizienz, zumal nach wie vor ein richtiges Bugreporting und eine Bug Triage entscheidend sind, um die richtige Entscheidung treffen zu können. Mein Augenmerk gilt der Bugverwaltung an sich, also der zentralisierten Auflistung, Verwaltung und Archivierung von Fehlerprotokollen. Im Lean Management sind zentrale Prozesspunkte ein “rotes Tuch”. Statt dem sternförmigen Kommunikations- und Prozessmodell wird dort das, Netzmodell favorisiert. Dieser Ansatz ist meiner Meinung nach besonders auf das Issue Management anwendbar.
Natürlich kann ich nicht generell sagen, dass ein Bugtracking-Tool sinnlos ist. Es gibt immer wieder Situationen und Rahmenbedingungen, die auch ein Bugtracking-Tool und eine zentrale Fehlerverwaltung rechtfertigen. So ist es z.B. bei einem Produkt, bei dem die User-Gemeinde aktiv die Bugs berichten und einsehen kann sicherlich sinnvoll, ein Bugtracking-System einzusetzen. Allerdings ist es nur in den seltensten Fällen wirklich notwendig.
Man könnte ein Bugreporting auch derart gestalten, dass man sich beim Reporter für den Bericht bedankt und ihm verspricht, das Problem zu analysieren. Dann schaut man sich den Fehler an. Ist er wichtig genug, wird er sofort gefixed – und der Benutzer ist glücklich. Ist er nicht wichtig genug (also ist entweder ein anderer Bug oder ein anstehendes Feature wichtiger), so wird der Report weggeworfen. Der Benutzer wird benachrichtigt dass der Fehler momentan nicht korrigiert wird. Ehrlich, sachlich, klar. Der Berichterstatter kann nun nochmals (mit Vehemenz) darauf pochen, den Fehler behoben zu wissen. So kann man z.B. bei benutzerorientierten Produkten auch ein Voting einsetzen (wie z.B. bei Codeplex). Erhöht sich das Voting (die Priorität) nicht, wird der Bug nicht gefixed und weggeworfen. That’s it.
Es gibt nur ein Go oder Nogo für einen Bugfix
Ich bin der festen Überzeugung das diese Verfahrensweise vor Allem dann effizient ist, wenn man in der Software-Entwicklung agile Methoden anwendet. Für mich sind Software Craftsmanship, TDD, XP und all die weiteren modernen Methoden einfach nicht mit dem veralteten Zentralverwaltungs-Muff “Bugtracking” vereinbar. Statt dessen sollte man ein leichtgewichtiges Bugreporting etablieren und die Entscheidung über den Fix oder No-Fix des Bugs schnell herbeiführen. Nur so kann man sich selbst dazu erziehen, von Anfang an in der Software-Entwicklung das Qualitätsbewusstsein zu schärfen und die Qualität konstant adequat hoch zu halten. Denn nur mit dieser “KO-Entscheidung” über den Fix eines Bugs kommt man (leidend, aber relativ schnell) zu der Erkenntnis, dass man wenn man wirklich das Produkt stetig weiterentwickeln möchte auch immer sich zum Ziel setzen muss, ein möglichst fehlerfreies Produkt auszuliefern.
Die Erkenntnis, Bugs nicht zu verwalten und sofort zu entscheiden, ob es gefixed werden soll oder einfach ignoriert werden soll ist meiner Meinung nach ein wichtiger Bestandteil für qualitative, agile Software-Entwicklungs-Methoden.
Ergo: Bugtracking ist sinnlos!
Bugs nicht lange auf eine Halde legen, hört sich gut an.
Leider scheint die Welt nicht so einfach.
Wo ein Anwender mit seinem Bugreport direkt den Entwickler ansprechen kann, mag es so funktionieren. Viele “Klitschen” funktionieren auch so. Auf Zuruf lassen Entwickler dort alles stehen und liegen und kümmern sich zuerst um einen Bug.
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
Arbeitest Du denn immer an Nichts und wartest bis jemand einen Bug meldet? Wohl kaum oder? Natürlich sollte man einen schwerwiegenden Bug nicht zu lange vor sich herschieben, aber meistens benötigt man noch die Schritte zur Reproduktion, Logfiles und z.B. ein paar Screenshots um effizient arbeiten zu können. Und diese Daten müssen halt irgendwo hinterlegt werden. Im praktischen Alltag bietet sich dafür einfach ein Tracker an. Zettel und Stift mögen bei Ein-Mann-Projekten ausreichend sein, aber sobald man im Team arbeitet funktioniert das nicht mehr. Auch ist die Protokollierung für die spätere Recherche und Analyse ein wichtiger Aspekt:
Was wurde wann gefixt?
Wo lässt sich noch etwas optimieren?
Hatten wir nicht schon einmal ein solches Problem?
…
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.
Hallo Ilker,
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
Ralf & Rene,
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!
Hi Golo,
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
Hallo Ilker,
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
Hallo Ilker,
> 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
Hey Ilker,
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
Hallo Ilker,
ich bin nicht deiner Meinung, dass ein Bugtracking – Tool bis auf wenige Ausnahmen sinnlos ist. Im Gegenteil.
Der Softwareentwicklungsprozess ist in verschiedene Teilprozesse unterteilt – sollte er zumindest.
Diesen Teilprozessen sind Aufgaben zugeordnet, denen wiederum HR zugeordnet werden. Da eine Software in Time und Budget entwickelt werden muss ist es notwendig eine vernünftige Zeitplanung aufzustellen. Damit Kunde und Auftragnehmer nachvollziehen können, wie der Entwicklungsstand der Software ist, werden sinnigerweise Tools eingesetzt. Bei der Softwareentwicklung geht es letztendlich darum, dass alle Anforderungen fehlerfrei umgesetzt sind. Da selbst der beste Entwickler nicht alle Seiteneffekte vorhersehen kann, ‘muss’ er Fehler machen. Diese Bugs müssen selbstverständlich behoben werden, vorallem wenn sie kritischer Natur sind. Ich finde, dass sich aus diesem Umstand einfach ein Tool empfiehlt, damit nachvollzogen werden kann, ob ein Fehler behoben ist oder nicht, welche Priorität er hat und wann geplant ist, dass er behoben wird. Denn immerhin wirken sich zu behebene Fehler auf den Zeitplan aus, der für das Release/Meilenstein gesetzt wurde. Und das könnte sich wiederum auf die Kosten auswirken. Ein wesentlicher Faktor bei der Entwicklung von Software. Über Bugtracking und einem Fehler-Clearing vermittelt man dem Kunden auf tranparente Weise, dass man ihn ernst nimmt und die Qualität der Software hoch hält.
Ihre Meinung ist gefragt!
Archiv
Diskussionen
Meta
Auszeichnungen
Copyright Ilker Cetinkaya using CC BY-NC-SA 3.0 DE | Powered by WordPress | Log in | Artikel (RSS) | Kommentare (RSS) | Styled with gmblue v0.1 (the next arthemia)