Kategorien
Bug free development
Heute möchte ich mal wieder ein Thema aus der Praxis anschneiden. Dabei handelt es sich um den Umgang mit Bugs, denn auch in die Projekte der Besten schleichen sich gerne mal Fehler ein. Schockierend, aber wahr. Eine Art mit diesen Fehlern umzugehen, will ich heute vorstellen: Bug free development (BFD). Soll aber nicht heißen, dass man keine Fehler mehr macht, sondern sie möglichst schnell wieder behebt. Da ich keine offizielle Definition gefunden habe, versuche ich mich selbst daran es kurz zu erklären.
Prinzipiell setzen wir den Fokus auf das Beheben der Bugs und nicht die Entwicklung neuer Features. Sobald ein Fehler auftritt, so muss er so schnell wie möglich ausgemerzt werden. Auf diese Weise schafft man es die bekannten Fehler in einem System nahe an Null zu halten. Natürlich kann man diesen Zustand nicht so mir nichts, dir nichts herstellen.
In unserem „aktuellen“ Projekt haben wir ungefähr vor drei Monaten damit angefangen den Fokus zu verlagern. Das Problem bei uns waren die ca. 50 Bugs im System, von denen wir wussten. Was natürlich für uns bedeutet hat, dass wir den ersten Monat nur am beheben von irgendwelchen Problemen waren und keine neuen Features liefern konnten. Zum Glück hatten wir in der Hinsicht die Unterstüzung von Oben, denn der Benefit der neuen Herangehensweise konnte klar kommuniziert werden.
Aber vielleicht sollte ich noch ein paar Punkte zum Gewinn aufzählen. Der wichtigste Punkt ist wohl die Verhinderung des Broken Window Effekt. Hat man erst mal alle Fehler beseitigt, so werden alle Entwickler ihr bestes geben, dass das System sauber bleibt. Ein weiterer Benefit ist die steigende Kundenzufriedenheit. Mit besserer Reaktionszeit beim Beheben von Bugs, steht auch die Zufriedenheit beim Endkunden.
Bei diesem Ansatz gibt es natürlich immer auch ein paar Ausnahmen. Bei uns im Team wird natürlich vorher abgewägt, ob ein Bug das aktuell Enwickelte Feature unterberechen darf. Blocker Bugs werden natürlich zwischen geschoben, alle anderen werden aber erst nach der Fertigstellung des akuellen Features begonnen.
Es gibt keine „Borken Windows Effek“ lediglich eine Theorie die nie belegt wurde. Der Effekt bleibt also gerade aus.
Ok, vielleicht wurde die Theorie nie als gemeingültig anerkannt, aber für mich gilt sie auf jeden Fall. Solange ich eine sauberes System habe, versuche ich auch alles es sauber zu halten.
Wäre wünschenswert wenn Projekte immer so gehandhabt werden würden, aber vielen dank das du mir jetzt ein „Marketing wirksamen“ Namen gegeben hast, so kann man es besser Vertriebs/Marketing-Menschen beibringen.
Also meiner Meinung nach gibt es keinen Programmierer der fehlerfrei programmiert, auch wenn das immer gerne behauptet wird.
Von daher sollte das Fehlerbeheben immer Priorität Nummer 1 haben denke ich.
Denn kein Kunde ist begeisterst, wenn zwar ein neues Feature drin ist, aber das alte nicht richtig funktioniert. Da hat man immer einen negativen Beigeschmack.
Unser Vorteil war halt, dass wir als Intranet System nur interne „Kunden“ haben. Da ist der Druck von außen gleich mal ein wenig kleiner. Außerdem ist es nicht das Rückgrat der Firma, da niemand finanziell davon abhängig ist.
Kann schon ein Vorteil sein, nicht den Produkt-Stress zu haben, den die „wirklichen“ „Geldbringer“ in einer Firma haben, hat aber auch Nachteile, da die Rückendeckung nicht immer gegeben ist und man leicht mal „ge-outsourced“ werden kann.
@PHPBlogger: Das Problem ist nur: fixed du einen kleinen nicht „wirklich“ kritischen Bug oder stellst du lieber das kommende Killerfeature fertig. Ist eine schwere Entscheidung.
Ich finde die Diskussion sehr nötig. Ein Problem was durch nicht-Behebung von Bugs entstehen kann, ist, dass diese in Vergessenheit geraten (wer packt schon gerne einen alten Bug an, der schon eine ganze weile im Tracker rumgammelt?). Zum zweiten können dadurch Seiteneffekte entstehen. Und zwar in einer begrenzteren aber auch – und dort vielleicht gerade – in einer öffentlichen Entwicklung. Ein kleiner Bug, der eigentlich sich nur auf eine begrenzte Funktionalität auswirkt kann so zu einem richtigen Killer werden. Auch können Bugs Anzeichen dafür sein, das etwas nicht richtig programmiert wurde und auf weitere Fehler hinweisen kann. Ich denke das kennt man als Programmierer.
Und dann wären da noch bei öffentlichen Entwicklungen die tausenden von Leuten, die dann anfangen an ihrer Kopie hier und dort „lokal“ zu debuggen. Beim nächsten Update fliegt wieder alles um die Ohren bzw. das Update macht wirklich viel Arbeit.
Last but not least kann es auch noch dazu führen, das Leute keine Bugs mehr reporten und damit ist die Entwicklung dann ziemlich tief unten angekommen.
Oder wie der der PHPBlogger schrieb: „[Es gibt keine Programmierer] keinen Programmierer der fehlerfrei programmiert“. Schade wäre es doch, wenn keine Bugs mehr reportet, geschweige denn behoben werden würden.
Sehe das auch eher etwas kritisch. Natürlich ist eine fehlerfreie Anwendung vom Entwickler, als auch vom Kunden wünschenswert. Was daraus werden kann, wenn mans ignoriert, zeigt zur Zeit MySQL sehr eindrucksvoll. 😉
Andererseits ist die Grenze zwischen „Was ist ein Bug?“ und „Was ist ’nur‘ ein unerwünschtes Verhalten?“ recht schwammig. Und nur Debuggen allein bringt ein öffentliches Projekt nicht weiter, da zieht dann die Konkurrenz ganz gemütlich vorbei.
Das grundsätzliche Problem hier ist, dass ein kleines Projekt durchaus fehlerhaft sein kann, ohne das der Fehler jemals auftritt. Bei populären Projekte wird früher oder später so jedes denkbare Ereigniss einmal eintreten. Da bleibt die Frage, ob ich wegen jeder kleinen Unzulänglichkeit (zB Warnings oder bei exotischer Konfiguration), die bei einem von tausend Nutzern einmal aufgetreten ist, wirklich die Weiterentwicklung anhalten möchte. Zumal es nicht bei einem „1 aus 1000“-Report bleibt.
Die generelle Umstellung des gesamten Team auf solch eine Arbeitsweise halt ich auch für kritisch. Der Kunde wünscht sich ja eine fehlerfreie Applikation, aber auch gewisse WEiterentwicklungen werden verlangt. Daher sollte lieber versucht werden, nur einen Teil des Teams für die Käferjagd zu verwenden, während der größere Teil sich mit der Weiterentwicklung beschäftigt. Sonst handelt man sich sehr schnell, dass von KingCrunch angesprochene Phenomän ein, dass die Konkurenz aufschliesst oder vorbei geht.
Sofern das Team so vielschichtig ist, dass einer nicht herausgenommen ist, kann man auch „Wartungtage“ festlegen. Z.B. hat jedes Teammitglied einen Tag in der Woche nur mit der Fliegenklatsche zu schwingen, die restlichen darf produktiv gearbeitet werden. Bei 5 Teammitgliedern deckt man so spielend eine Woche ab und hat jeden Tag für eine besser Welt gesorgt.
Kritische und das System gefährdende Fehler sind bei dieser herangehensweise ausgenommen, diese müssen egal was gerade ist, sofort behoben werden.