Idées, tutoriels et nouveautés de notre équipe.
Une notification dont personne ne fait rien apprend à ignorer la suivante. Comment j'ai décidé qui est prévenu d'un changement de tâche dans BugDump : des destinataires déduits de la tâche elle-même, rien sur vos propres modifications, et une rafale de clics de tri envoyée en une seule fois.
Tous les bug trackers sont livrés avec basse/moyenne/haute/critique, et toutes les équipes les renomment discrètement dans leur tête. À quoi sert vraiment une échelle de priorité, combien de niveaux il vous faut, et pourquoi les mots doivent être les vôtres.
La plupart des tableaux de bord de bugs comptent des choses. Les plus utiles répondent à une seule question : est-ce qu'on suit le rythme ? Quatre métriques qui y répondent, celles qui induisent en erreur sans qu'on s'en aperçoive, et une revue hebdomadaire de cinq minutes construite dessus.
Une méthode pour les bugs que vous n'arrivez pas à reproduire — les causes habituelles, le contexte qui les élucide et la façon d'éviter qu'ils reviennent.
Une campagne de recette produit un tableur de soixante lignes, dont la moitié inexploitables. Le problème vient rarement des testeurs. Il vient du canal de signalement, qui jette les preuves au moment précis où elles existent.
Chaque équipe écrit un modèle de rapport de bug. La plupart sont ignorés au bout d'un mois, parce qu'ils demandent aux gens un travail qu'un navigateur pourrait faire à leur place. Voici un modèle qui mérite d'être gardé, et pourquoi supprimer les trois quarts de ses champs.
Séparer les rapports des tâches, c'est la petite décision de structure qui empêche une boîte de réception de bugs de devenir un cimetière, et qui fait des rapports en double votre meilleur atout pour déboguer.