Existe-t-il des études sur les inconvénients de l'utilisation des systèmes de suivi des problèmes? [fermé]

9

Je n'aime pas les systèmes de suivi des problèmes car:

  • Il faut trop de temps pour en décrire les problèmes. Cela décourage son utilisation.
  • Vous créez un endroit pour garder vos bugs. Et s'il y a une place pour eux, les gens ne se soucient généralement pas trop de la correction d'un bogue car ils peuvent le mettre là pour qu'un jour quelqu'un puisse le réparer (ou non).
  • Avec le temps, les listes de bogues deviennent si longues que personne ne peut plus y faire face, ce qui prend beaucoup de notre temps.

Je préfère gérer les problèmes en utilisant des post-its sur un tableau blanc, des conversations en face à face et en supprimant les bugs importants dès qu'ils apparaissent. Je ne me soucie pas trop de garder une trace de l'historique des bogues, car je ne pense pas que cela en vaille la peine.

Suis-je seul ici? Existe-t-il des études (livre / article / autre) sur les inconvénients (ou les grands avantages) de l'utilisation des systèmes de suivi des problèmes?

project-management agile issue-tracking user1062120
la source
5
Voter pour fermer, trop localisé. Le problème ici ne semble pas être lié aux systèmes de suivi des problèmes, mais plutôt au processus de gestion des bogues de l'entreprise.
P.Brian.Mackey
1
Quels systèmes de suivi des problèmes avez-vous essayés (à part les notes post-it et les tableaux blancs)? Quel était le processus autour de leur utilisation?
FrustratedWithFormsDesigner
1
Parmi ceux-ci, je n'ai utilisé que Jira (je suis d'accord qu'il semble avoir beaucoup de frais généraux, jusqu'à ce que vous vous habituiez à son "rythme"). Pas un fan de l'interface utilisateur Web, mais il fait le travail. Ici, nous utilisons également MKS, qui effectue également le contrôle de source. C'est mieux que Jira. Aucun d'eux n'est parfait, mais ils sont tous encore meilleurs que les notes papier et les souvenirs organiques faillibles des gens.
FrustratedWithFormsDesigner
15
Je suppose que je suis confus par la question. L'utilisation de post-its sur un tableau blanc EST un système de suivi des problèmes. Si votre projet / équipe / base de code est suffisamment petit et que le post-face + fonctionne, vous aurez probablement du mal à vous convaincre d'ajouter plus de frais généraux au processus. Il existe de nombreux inconvénients à utiliser un système comme celui-ci, comme indiqué ci-dessous. Dès que le projet et l'équipe se développent, en particulier lorsque les membres de l'équipe peuvent ne pas être dans le même bâtiment, ville ou pays, d'autres systèmes commencent à briller comme indiqué dans les réponses ci-dessous.
s_hewitt
2
comment attachez-vous une trace de pile à une publication? ou une capture d'écran? ou un message d'erreur?
jk.

Réponses:

41

Il faut trop de temps pour en décrire les problèmes. Cela décourage son utilisation.

Si vous ne pouvez même pas décrire un bug, comment pouvez-vous commencer à le corriger?

Vous créez un endroit pour garder vos bugs. Et s'il y a une place pour eux, les gens ne se soucient généralement pas trop de la correction d'un bogue car ils peuvent le mettre là pour qu'un jour quelqu'un puisse le réparer (ou non).

C'est un problème avec votre équipe et non avec le logiciel.

Avec le temps, les listes de bogues deviennent si longues que personne ne peut plus y faire face, ce qui prend beaucoup de notre temps.

Encore une fois, vous décrivez un problème avec votre équipe.

Le but du logiciel de suivi des bogues n'est pas de vous aider à motiver votre équipe à corriger les bogues, c'est de garder un enregistrement afin que vous puissiez rechercher la cause des bogues et les empêcher de se reproduire. Aucun logiciel ne sera jamais un remplacement pour une bonne gestion.

Tom Squires
la source
Le logiciel de suivi permet également de suivre les bogues à corriger. Une note collante peut tomber, et si quatre personnes vous présentent des bogues sur lesquels vous pouvez travailler, vous pouvez en corriger trois et oublier le quatrième. C'est utile même si vous ne faites pas attention aux causes des bugs.
David Thornley
et pour résoudre le problème avec votre équipe, vous pouvez utiliser la gamification -> en.wikipedia.org/wiki/Gamification
marc.d
11
@JoaoBosco: Les billets manuscrits sont perdus, griffonnés, jetés par accident ... les conversations en face-à-face sont géniales, sauf lorsque vous décrivez des bogues complexes à des personnes qui n'ont pas de mémoire photographique. Les gens vont oublier les choses de conversations, non pas parce qu'ils veulent , mais parce que c'est tout simplement ce qui se passe.
FrustratedWithFormsDesigner
3
@JoaoBosco: Qu'en est-il des captures d'écran d'erreurs GUI? Voulez-vous les redessiner à la main? Des échantillons de données incorrectes (s'il s'agit d'une erreur de base de données, êtes-vous prêt à écrire n lignes avec m colonnes de données incorrectes à la main)? D'autres formes d'artefacts numériques associés au défaut qui ne se traduisent pas bien en notes autocollantes? Tout cela peut facilement être attaché à un ticket dans un système de suivi des problèmes. Et si vous allez convertir plus tard votre pense-bête en fichiers texte, pourquoi pas une base de données qui vous permet de trier, de commander, de classer vos billets, puis un peu plus loin pour le suivi des problèmes.
FrustratedWithFormsDesigner
10
@ user1062120: "S'il n'y a pas de place pour garder les bogues, les gens commencent à les corriger plus souvent" - ou ils commencent à ignorer et à oublier les bogues. Ce n'est pas une «astuce pour motiver les gens» mais une tentative absurde de transformer une faiblesse en force.
Michael Borgwardt
12

OMI, votre point de départ est biaisé. Si les développeurs ne parviennent pas à corriger les bogues, le projet est voué à l'échec, qu'ils suivent les bogues en utilisant un outil de suivi des bogues approprié, des post-its, des gravures sur pierre ou pas du tout. Ce n'est pas la faute de l'outil s'il n'est pas utilisé ou mal utilisé. (Cela dit, il y a bien sûr de mauvais suiveurs de bogues / problèmes ... J'ai travaillé sur un projet en utilisant un outil totalement inadéquat pour ce travail, donc je pense que je sais à quel point il peut être mauvais. Mais il y en a aussi de bons, qui nécessitent une cérémonie et des frais généraux minimes, ce qui vous permet de vous concentrer sur les informations pertinentes.)

Si, cependant, les développeurs s'en soucient, et que le projet est plus grand que de taille triviale, et qu'il y a plus d'un développeur, et qu'il y a une sorte de gestion impliquée (qui sont assez courantes dans les projets du monde réel) ), des questions telles que:

  1. Lequel des bogues ouverts doit être corrigé en premier? (Remarque: dans un projet sain, cela devrait être décidé par le propriétaire du produit et / ou la direction, PAS par un développeur - pour lequel ils doivent être conscients de tous les bogues ouverts tout d'abord!)
  2. Combien de bogues ouverts avons-nous et de quelle gravité?
  3. Lequel de ceux-ci doit être corrigé avant que nous soyons prêts à sortir?
  4. Combien de temps pour planifier ces correctifs - conduisant souvent à: combien de temps il faut pour corriger un bogue en moyenne?
  5. combien de bogues ont été signalés par les clients dans la dernière version?
  6. qui a corrigé ceci et cela, quand et quels changements (code / configuration / données) le correctif a-t-il impliqué?
  7. quelles corrections de bugs sont incluses dans la version que nous sommes sur le point de publier?
  8. ...

Pouvez-vous répondre à ces questions [mettre à jour] de manière répétée, fiable et efficace [/ mettre à jour] sur la base de vos notes post-it?

Oui, la saisie de données de bogue dans un outil de suivi des problèmes entraîne des frais généraux. Cependant, il est plus que compensé par le temps et les efforts économisés dans la recherche et la création de rapports comme ci-dessus, à partir des données de bogues stockées.

Péter Török
la source
Les post-its ne répondront pas à tout. Ce n'est qu'un outil. Vous pouvez toujours les hiérarchiser, faire des statistiques sur les bogues ouverts, les corrigés, etc. Tout ce que je dis, c'est que je pense que les systèmes de suivi des problèmes peuvent être plus contre-productifs que vous aider à résoudre les problèmes de gestion que vous avez.
user1062120
7
@ user1062120: Et tout le monde dit que vous avez très, très tort. Les post-its sont un système de suivi des problèmes, juste un très pauvre qui manque de nombreuses fonctionnalités essentielles.
Michael Borgwardt
@ user1062120, bien sûr, en théorie, tous ces éléments pourraient être résolus à l'aide de notes autocollantes - si vous ajoutez des ID uniques à chacun, continuez à ajouter des commentaires d'historique détaillés sur eux (de sorte que vous commencez à avoir besoin de notes collantes plutôt volumineuses après un certain temps :-), et passer énormément de temps à les trier, à les trier à nouveau et à les réorganiser en fonction de la question actuelle (pour laquelle vous pourriez avoir besoin d'embaucher un nouveau gars dans un projet plus important ;-).
Péter Török
@ user1062120, par exemple, la planification donne la question 1 ci-dessus - réorganisons les notes autocollantes en fonction de la priorité. Bientôt PM demande Q2: oups, réorganiser par gravité. Mais Q1 est toujours ouvert, alors maintenant trions-les tous par priorité. Oups, 3 post-its ont été omis car ils étaient sur le bureau de Joe - recommencez! Puis Q6 - creusons les cases contenant les post-its historiques, parcourons-les toutes à la main pour trouver la bonne, puis essayons de lire le gribouillis sur le dos, destiné à décrire les changements ... oups, quelqu'un a ouvert un fenêtre à proximité, précipitez-vous pour éviter que vos post-it ne s'échappent par le vent ... etc.
Péter Török
9

Votre méthodologie peut fonctionner pour de très petits projets avec un nombre limité de programmeurs. Une fois qu'un projet prend de l'ampleur, le fait d'avoir un système de suivi des problèmes devient beaucoup plus important pour la coordination entre les différentes équipes, en particulier si des correctifs vont sortir dans différentes versions de code. Les projets complexes auront de nombreuses pièces / composants mobiles, et s'assurer que les problèmes sont planifiés et résolus est une grande partie d'une bonne mise en œuvre du suivi des problèmes

Certains articles / études qui pourraient vous intéresser incluent cet article sur l'utilisation de Jira par Zend et cette étude française sur l'utilisation des systèmes de suivi des bogues.

JW8
la source
1
Merci beaucoup pour les références. Je vais les regarder. Et oui, cela fonctionne au sein de 3 petites équipes ici.
user1062120
2
+1 pour les références, explicité demandée dans la question.
mattnz
4

Il peut y avoir des études, mais encore mieux sont les expériences durement gagnées des gens sur le terrain. La plupart des systèmes de suivi des problèmes souffrent des processus qui déterminent leur conception. Les trackers de problèmes doivent souvent prendre en charge 2 classes distinctes d'utilisateurs:

  1. L'équipe de développement
  2. Les utilisateurs du système

Cal Henderson (anciennement de Flickr) a un excellent article sur la conception de nombreux trackers de problèmes et pourquoi il préfère le tracker de problèmes GitHub (comme moi). Garrett Dimon a également couvert la conception de Sifter et a illustré un moyen de simplifier le processus pour un suivi plus efficace des problèmes . J'ai adopté certaines des idées de ces deux messages pour aider à simplifier le flux de travail de suivi des problèmes de mon équipe.

Cela dit, tout dépend des processus et des outils. Ma pensée générale est que les trackers de problèmes ont tendance à créer cet arriéré que vous devez gérer. Pendant le triage, les gens sont plus susceptibles de rationaliser ce qui est ou non un bug. Dans notre processus, nous prenons des décisions presque dès que le bogue est déposé pour savoir s'il s'agit ou non d'un problème. Une fois cette décision prise, le bogue passe dans Pivotal Tracker. La différence ici est que nous utilisons Tracker pour la priorisation , pas comme un stylo pour des choses que nous ne voulons pas faire. En fait, lorsque la Icebox commence à devenir trop grande, je supprime activement les éléments, y compris les bogues. Si un problème est suffisamment important pour être traité, il reviendra.

Nous avons rarement besoin de l'historique des bogues. Parfois, quelqu'un peut mentionner un symptôme d'un bogue et nous pouvons faire une recherche pour voir s'il est lié à un problème que nous avons déjà traité. Mais c'est rare.

TL; DR Concentrez-vous sur votre processus, choisissez des outils simples et résolvez les problèmes à mesure qu'ils surviennent.

kstewart
la source
C'est exactement ce que je voulais dire. Nous priorisons également les éléments dès qu'ils apparaissent et nous supprimons également les éléments non importants. Les choses importantes reviendront dans le temps. J'ai trouvé que les frais généraux pour garder une trace de tout n'étaient pas dignes. L'idée d'avoir un petit tableau blanc post-it est que vous ne pouvez pas tout enregistrer physiquement, juste les choses importantes. Donc, cette astuce vous oblige à le gérer dès que possible. Mais c'est mon cas, donc je ne sais pas si cela fonctionnerait partout.
user1062120
2

tuer les bugs importants dès qu'ils apparaissent

On dirait que vous entrez par la porte ouverte ici. Les bogues importants sont "tués" dès que possible, que vous utilisiez ou non le tracker de problème.

  • Oh et une partie "comme ils apparaissent" est assez glissante BTW. Dans un projet, nous avons eu un bogue important qui menaçait de mettre tout le produit hors service (quoi de plus important?). C'était très compliqué (erreur d'architecture) et nous savions qu'il faudrait du temps pour le réparer. Les clients ont aimablement accepté de nous donner un an pour réparer (avant de laisser tomber notre produit) et nous l'avons fait dans environ un an.

En ce qui concerne les trackers de problèmes, je les utilise depuis près de dix ans et, en règle générale, tous les programmeurs autour de moi ont passé assez peu de temps avec le tracker (notez que je parle des programmeurs; les gestionnaires sont une histoire différente). J'ai vu des cas (rarement) alors que ce n'était pas le cas - dans tous ces cas, quelque chose était gravement cassé.

En ce qui concerne les études sur les conversations en face à face et le suivi des problèmes, encore une fois, vous avez l'impression de vous enfoncer ici. Le suivi des problèmes est une communication écrite typique ; il y a des recherches montrant que beaucoup de choses à discuter, face2face communication est beaucoup plus efficace que sur le téléphone qui est à son tour beaucoup plus efficace que écrit .

  • En fait, étant donné que vous posez des questions sur f2f, vous avez l'impression d'utiliser (mal) le tracker pour discuter de choses - ce n'est pas son but. Pour comprendre son utilisation prévue, il suffit d'épeler son nom lentement et clairement: système de suivi des problèmes .

les listes de bogues deviennent si longues

D'après mon expérience, ce qui précède est un avantage et non un problème.

Avec une longue liste de bogues, les développeurs peuvent configurer une file d'attente et planifier des correctifs à l'avance. C'est aussi productif que possible; pour moi, c'est essentiellement un nirvana quand j'ai une telle file d'attente avec laquelle travailler. Premier bug - Correction - fait, second bug - fix - fait, suivant bug - fix - fait etc etc Aucune interruption stupide, pas de distractions douloureuses avec oh-so-efficaces conversations F2F, pur flux .

  • Je me souviens d'un seul cas où de longues listes de bogues ont été un problème. Cela s'est produit quand un idiot de la haute direction a décidé d'une politique qui obligeait les développeurs à choisir le prochain bogue d'une pile de 50 à 100 presque quotidiennement. Quel gâchis. Cela nous a pris quelques mois de douleur jusqu'à ce que nous comprenions comment escalader cela au-dessus de sa tête et le réparer.
    Quelque temps après avoir réussi à établir un flux de travail pratique, nous avons découvert que notre «arriéré sans fin» était magiquement vide.
moucheron
la source
2
Récemment, j'ai passé 2,5 jours à parcourir plus de 300 bogues ouverts (principalement l'interface utilisateur) accumulés en plus d'un an, tous attribués soit à des pigistes / stagiaires depuis longtemps disparus, soit au chef de projet qui n'avait pas le temps de les gérer. J'ai trouvé que je pouvais fermer environ la moitié d'entre eux comme étant déjà fixes ou plus pertinents. Les autres sont fixés à un taux décent après que je les ai assignés aux bonnes personnes. Le système de suivi des bogues a été mal utilisé, mais sans lui, tous ces bogues (pas de stop-show, mais certains assez laids) auraient sûrement été oubliés.
Michael Borgwardt
1
@MichaelBorgwardt ouais des listes si longues que personne ne peut y faire face dans mon expérience s'est toujours avéré gérable tant que l'on n'est pas gelé par des chiffres effrayants comme 200, 400, 1000. Je viens de faire un rapide examen de curiosité - pour l'année dernière, j'ai résolu plus de 300 problèmes - moi seul (!). Par curiosité, j'ai également vérifié d'autres gars en équipe en pensant que je suis peut-être unique - non, 200 à 400 corrections / an apparaissent juste un taux moyen. 500 bugs aussi effrayants que cela puisse paraître, cela peut être juste une demi-année de travail pour 4-5 développeurs, morceau de gâteau :)
gnat