Kommentare zu: Bugfree the VZ way

Von: manuel

manuel — Sun, 29 Nov 2009 12:28:18 +0000

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.

Von: Martin

Martin — Tue, 24 Nov 2009 13:16:32 +0000

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.

Von: Stefan Riedels Blog

Stefan Riedels Blog — Tue, 24 Nov 2009 12:19:11 +0000

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…

Von: Nils Langner

Nils Langner — Tue, 24 Nov 2009 11:46:07 +0000

@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.

Von: Cem Derin

Cem Derin — Tue, 24 Nov 2009 11:43:13 +0000

@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 …

Von: Bastian Hofmann

Bastian Hofmann — Tue, 24 Nov 2009 10:53:37 +0000

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

Von: Dennis Becker

Dennis Becker — Tue, 24 Nov 2009 10:10:53 +0000

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!