Ideen, Tutorials und Updates von unserem Team.
Eine Benachrichtigung, auf die niemand reagiert, bringt allen bei, die nächste zu ignorieren. Wie ich in BugDump entschieden habe, wer von einer Änderung an einer Aufgabe erfährt: Wer benachrichtigt wird, ergibt sich aus der Aufgabe selbst, über deine eigenen Änderungen kommt nichts, und eine Serie von Triage-Klicks geht als eine Nachricht raus.
Benutzerdefinierte Felder wünscht sich jedes Team, und fast jedes bereut sie später. Der Test, der ein Feld, das sich lohnt, von einem trennt, das in sechs Wochen leer ist, und die vier Felder, die sich auszahlen.
Jeder Bug-Tracker bringt niedrig/mittel/hoch/kritisch mit, und jedes Team benennt die Stufen im Kopf still um. Wofür eine Prioritätsskala eigentlich da ist, wie viele Stufen du brauchst und warum die Wörter deine eigenen sein müssen.
Die meisten Bug-Dashboards zählen Dinge. Die nützlichen beantworten eine einzige Frage: Kommt das Team hinterher? Vier Metriken, die das leisten, die beliebten, die unbemerkt in die Irre führen, und ein fünfminütiger Wochen-Review, der auf ihnen aufbaut.
Eine Bug-ID ist keine Zeilennummer in der Datenbank. Sie ist ein Wort, das Leute zueinander sagen. Warum eine Nummerierung pro Projekt und ein kurzer Projektschlüssel wie BD-42 das Reden über Bugs leichter machen, und welche Abwägungen hinter dem Design stecken.
Die meisten Teams sind nicht langsam darin, zu entscheiden, welche Bugs wichtig sind. Langsam sind sie bei allem drumherum. Ein Workflow für die Bug-Triage, der die Navigation abschafft, statt von dir zu verlangen, schneller zu denken.
Das Design liegt in Slack, das Log auf einem Laufwerk, die Spezifikation in irgendeinem Postfach. Warum Anhänge zu Fehlerberichten über viele Tools verstreut landen, was das kostet, wenn der Bug wiederkommt, und wie jede Datei beim Bug selbst bleibt.
Wie Agenturen Mail-Threads voller Bug-Meldungen durch ein Widget auf jeder Kundenwebsite ersetzen: strukturierte Berichte, ein Board pro Projekt und saubere Übergaben.