Kategorien
Bugfree the VZ way
Nachdem ich ja so viel über die PHP Conference 2009 geschrieben habe, wollen wir uns heute mal wieder einem anderen Thema widmen. Es handelt sich um ein Stück Projektmanagement, bei dem ich mir noch nicht so sicher bin, ob ich es für eine tolle Idee halte. Der CTO der VZ Gruppe hat in seiner Keynote auf der IPC (jetzt rede ich ja schon wieder drüber) einen interessanten Ansatz vorgestellt.
Die VZ Gruppe, also StudiVZ, SchülerVZ und MeinVZ haben vor kurzem auf agile Methoden umgestellt und schmücken sich seit kurzem mit dem Attribut Bugfrei zu sein. Ok, ist eine feine Sache alle bekannten Fehler in seinem System beseitigt zu haben. Jetzt will man natürlich wissen, wie man dies schaffen kann. War es der neue CTO, der zaubern kann? Ist es vielleicht das agile Vorgehen, dass das System besiegt hat? Oder ist es vielleicht Supermann? Nein! Es ist viel leichter. Man „löscht“ einfach die Datenbank mit allen bekannten Bugs und schon ist das Wunder passiert. Klingt doof? Das habe ich am Anfang auch gedacht.
Machen wir uns also mal ein paar Gedanken über das Vorgehen und den nächsten Schritt, der damit einherging. Bug Datenbanken wie Jira oder Bugzilla sind häufig bis zum Limit gefüllt mit irgendwelchen richtig alten Bugs. Viel davon wurde mal reportet war aber nie wichtig genug angegangen zu werden. Wie schlimm wäre es einen solchen Fehler zu löschen? Wahrscheinlich würde es niemanden auffallen. 90% der Fehler in der DB sind also unnötig. Würde ich jetzt mal so schätzen. Der neue CTO ist also hingegangen und hat ähnlich gedacht. Mit diesem Ansatz wird man natürlich alleine nicht glücklich. Zusätzlich hat er die Direktive aufgestellt, dass jeder ab jetzt reinkommende Bug innerhalb von 24h gefixed sein muss. Auf diese Art und Weise kann man ein bugfreies System anscheinen aufbauen.
Diese Vorgehensweise funktioniert aber nur, falls nicht hunderte von Fehlern täglich aufpoppen. Wenn jeder Tag nur einen Fehler mit sich bringt, dann sollte das System wunderbar aufgehen. Ich würde es auf jeden Fall auch gerne mal probieren. Das tolle daran ist, dass man die alte Datenbank ja nicht wirklich wegwirft, sondern einfach mal ausschaltet. Falls das Modell nicht funktioniert, kann man ja immer noch drauf zurück.
Ich finde den Ansatz ganz gut und auch nachvollziehbar: Ich kenne es nur zu gut, dass im Laufe der Zeit immer wieder Bugs hinzu kommen die erstmal auf die lange Bank geschoben werden (aus den verschiedensten Gründen).
Auch da habe ich schon das eine oder andere Mal einiges an Bugs (nicht alles ;-)) einfach gelöscht da diese im Laufe der Zeit so stark in den Hintergrund gerückt sind das es garkeinen Sinn mehr gemacht hätte diese zu beheben, …
Inwieweit sowas natürlich wirklich funktioniert, gerade bei großen, stark frequentierten Projekten (und Teams!) weiß ich allerdings nicht, ich denke aber das es wirklich funktionieren KANN, wenn das ganze Team hinter diesem Credo steht alles innerhalb von maximal 24h zu beheben.
Auch ich wäre für einen Pilotversuch bei uns im Unternehmen. 😉
Also lieber Nils. Die agile Entwicklungsmethode heisst Scrum (ich dachte das kennst du? 😉
Den „No-Bugs“ Ansatz kenne ich auch und wir verfolgen ihn auch – erfolgreich. Mir fällt zu deinem Artikel folgendes ein:
Bugs die 2 Jahre alt sind interessieren keine Sau mehr und sind evtl. auch gar nicht mehr da. Ist es ein nerviger Bug, wird er auch wieder auftauchen (das würde er übrigens mit Bugtracker auch wieder). Der Unterschied ist: Mit Bugtracker würdest du den Bug auf Duplicate stellen und ihn trotzdem nicht fixen. Dadurch, dass du Bugs immer vor alles andere stellst, erreichst du nicht nur fehlerfreiere Software, der Nutzer ist auch zufriedener (seine Bugs werden ja gefixt) und du hast keinen Bugtracker mit 50.000 Items
Das ist halt immer das Problem: Was macht man mit Altlasten, wenn man auf ein neues, komplett anderes System umstellt?
Ich finde den Bugtracker leeren Ansatz gut, bin aber auch der Meinung, dass man einfach alle Bugs anhand der neuen Methode fixen sollte, wenn es nicht zu viele sind
Hallo Nils,
ich habe mir auf der PHP Konferenz auch die Keynote über Scrum angeschaut.
Bei der Keynote kam es mir so vor, als ob man, je nach Blickpunkt, Theorien und Vorgänge positiv darstellen kann. Ich vertrete genau wie Du die Meinung, dass das 24 Stunden pro Bug Konzept nur aufgehen kann, wenn in dieser Zeit auch nur ein Bug anfällt.
Der CEO hat sich die Sache erst einmal einfach gemacht und alle Bug aus dem Bugtracker gelöscht. Was ich nicth sehe, interessiert mich nicht…
Die zwei offenen „Bugs“, die dann präsentiert wurden (der eine war eine von Apple noch nicht frei geschaltete iPhone App…) waren dann auch mehr geschönt, also wirkliche Programmfehler.
Diese Keynote war meiner Meinung nach einer der schlechtesten Vorträge in der ansonsten sehr guten PHP Konferenz 2009.
Gäääähn, Moin!
VZ-CEO hält Vortrag über Fehlerfreiheit?
Ja, ist denn scho‘ Weihnachten?
Warum langweilen manche Dinge immer und immer wieder?
Und warum gibt es so wenig Menschen mit Ehre?
Und kann man Wasser auch weit über 100% kochen?
Cheerio!
Jeder der der Meinung ist, dass man innerhalb von 24 Stunden nur einen Bug fixen kann, hat es offensichtlich noch nie ausprobiert und sollte dies mal tun!
Im Übrigen bedeutet die Aussage „Wir haben keine Bugs“ nicht, dass es insgesamt keine Bugs gibt (das wäre utopisch), sondern dass es derzeit keine offenen Bugs gibt.
Die Frage die ich mir bei Bugtrackern immer stelle: Wer pflegt die eigentlich. Denn oft sind ja eintragene Bugs eher Feature-Requests („Der User sollte das ja auch machen können, wenn er dies und jenes machen kann“).
Bugfixing innerhalb von 24h halte ich auch für sinnvoll. Insbesondere wenn er dann agil und test-driven produziert wird, d.h. de Bug wird durch einen fehlgeschlagenen Tests reporudziert und dann wird er gefixt. Somit sollte er danach nicht mehr auftauchen können.
Ich hab’s im Vortrag nicht geglaubt, und ich glaube es jetzt auch immer noch nicht! Spontan fallen mir mindestens 2 weitere Bugs ein! Aber wo einreichen?
Interessant wäre natürlich zu wissen, wie die VZ-Leute ihre Issues klassifizieren. Denn dadurch kann man auch schon vieles abfangen …
Aus meiner Sicht machen es sich die Jungs doch ein wenig zu leicht. Ich würde mir wünschen, dass lieber eine Person / ein Team für das Management des Trackers verantwortlich ist. So könnte man Bugs/Feature Requests sauber kategorisieren, überprüfen und ggf. auch wieder wegfallen lassen. Aber einfach alles Löschen ist Augenwischerei und verhindert auch eine saubere Projektdokumentation.
Außerdem sehe ich auch noch rechtliche Schwieirigkeiten, wenn bspw. durch einen gemeldeten Bug sicherheitsrlevante Bereiche berührt werden und dadurch Nutzdaten gehackt werden können. Ich könnte mir vorstellen das in einem solchen Falle Gerichte entscheiden könnten das eine gewisse Sorgfaltpflicht verletzt wurde.
Ich würde „löschen“ nicht so ganz wörtlich nehmen. Es wurden sicherlich kritische Bugs übernommen. Aber vor allen Dingen wurden hunderte von wahrscheinlich ziemlich banalen Dingen wie „wenn ich da Klicke passiert nichts“ gelöscht. Solche Tickets hat glaube ich schon jeder mal gesehen. Dann schaut man sich den Account des Kunden an um festzustellen, dass ihm die Vorraussetzungen fehlen um die Aktion auszuführen … Solche Tickets gibt es bei den VZ Netzwerken sicherlich zu Hauf!
Mal ein paar Ergänzungen hierzu:
– Bugfree bedeutet, dass alle uns bekannten Bugs gefixt sind.
– Die Liste mit den zwei vorhandenen Bugs, waren alle Bugs, die länger als 24h offen waren
– Wichtig bei dem System ist auch, dass jeder Bug, der nicht innerhalb von 24h gefixt werden kann, eskaliert wird. So dass (überspitzt gesagt) das ganze Team am Ende daran arbeitet.
– Natürlich muss der Bug nicht nur gefixt, sondern der Fix auch releast werden. Das heißt viele kleinere Releases und nach jedem Sprint ein größeres, anstatt wie vorher zwei oder drei Releases mit kritischen Fixes und alle zwei Wochen ein „Mega“ Release.
– Bugfixing muss immer wichtiger sein, als neue Features zu entwickeln. Wenn halt 100 Fehler an einem Tag aufpoppen, dann sind alle Entwickler damit beschäftigt diese abzuarbeiten. Wenn das nicht innerhalb von 24h möglich ist, wird es ans Management eskaliert. Mögliche Reaktionen wären dann z.B. Abbruch des aktuellen Sprints.
@Thilo Habenreich
Und genau war das Problem mit unserem alten System. Es wurde sehr viel Zeit und Energie darauf verschwendet Bugs zu verwalten, zu priorisieren, in Releases einzutakten, Entwicklern zuzuweisen, usw.
Dadurch werden Bugs, die nicht sofort nachvollziehbar sind und Nachfragen nötig sind oder „nicht schlimme“ Bugs so weit aufgeschoben, dass sie sich bei so einem großen Projekt nach ein paar Monaten zu einem riesigen Berg an Tickets auftürmen, der sich nur noch schwer bewältigen lässt.
Löschen darf man wirklich nicht zu wörtlich nehmen: die Tickets sind alle noch im System da, werden aber ignoriert, also praktisch gelöscht 😉
@Cem Darin:
Einreichen von Bugs geht über den Support http://www.studivz.net/Contact bzw. http://www.studivz.net/l/help der leitet das dann entsprechend weiter
@Bastian Hoffmann: Und was soll ich als Betreff auswählen? Mal ganz abgesehen von der Tatsache, dass ich als Benutzer gar keine Lust habe dutzende mögliche Betreffzeilen durchzulesen um die richtige zu finden …
@bastian danke für den insiderblick. Ich finde euer vorgehen beneidenswert das. Wäre für uns nicht so einfach das so unseren Kunden zu verkaufen. Sinnvoll schätze ich. es aber auf jeden Fall ein.
So und ab jetzt bin ich für 2 Wochen pm Urlaub. Viel spass euch.
Einige Kommentare hier lassen an der neutralität der Antworten zweifeln. Man sollte mal nur über das Verfahren nachdenken und nicht, wer es „vorgestellt“ hat…
Also mich überzeugt das Vorgehen nicht wirklich. Aber offensichtlich gab es ja doch sehr viele Probleme mit dem existenten Bug-Reporting. Wenn sich über lange Zeit „Türme von Tickets“ anhäufen können, scheint ja etwas im Wartungs-Prozess nicht zu stimmen. Insofern war die Prozessänderung zwar radikal aber scheinbar erfolgreich. Probleme sehe ich nur, wenn sich Fehler nicht schnell beheben lassen und/oder keine Priorisierung mehr möglich wird.
Ich finde es schon ziemlich kurios, das gerade der CTO der VZ Gruppe diesen Vortrag gehalten hat. Wir erinnern uns, vor einigen Wochen begang ein IT-Spezialist Selbstmord, weil er einen Bug / Sicherheitsloch bei SchuelerVZ ausgenutzt hat.