Comment gérez-vous des tas toujours croissants de problèmes à résoudre «quelquefois»?

Nous utilisons JIRA pour suivre les problèmes dans nos projets logiciels. Un effet que nous avons remarqué est que nous créons souvent un nouveau problème mais nous ne savons pas encore quand / si le problème va être résolu du tout. Nous avons donc inventé un faux jalon «Distant Future» auquel ces problèmes sont attribués.

En l'occurrence, la pile de problèmes attribués à ce jalon ne cesse de croître, il semble donc que ce ne soit pas une bonne approche. Il y en a tellement maintenant qu'il a fallu beaucoup de travail pour les examiner tous afin de vérifier leur validité. Certains d'entre eux sont devenus invalides depuis la suppression du composant qui leur est lié. Certains d'entre eux ont été dupliqués par d'autres problèmes. Certains d'entre eux ont une description si mal formulée que personne ne sait vraiment de quoi ils parlent.

Comment les autres équipes de développement logiciel gèrent-elles les problèmes qui sont valides, mais qui ne peuvent pas être résolus à tout moment Prenez-vous la peine de les enregistrer? Les affectez-vous à la prochaine version prévue et les réexaminez-vous à l'approche de la prochaine version? Autre chose?

Ce sont de bons bogues de premier contact à corriger pour les nouveaux développeurs qui viennent de rejoindre votre entreprise. Ou pour les développeurs juniors de développer leur connaissance du système.

Si ce n'est pas le cas, vous pouvez les marquer "ne résoudra pas" s'ils ne sont pas suffisamment sérieux pour justifier le temps qu'il faudrait pour les corriger.

Vous ne devez corriger un bogue que si l'application a plus de valeur sans le bogue.

Si un champ de texte est mal aligné et qu'il faut trois jours pour le corriger, le coût est probablement trop élevé et vous devez le laisser. Au contraire, si les utilisateurs ne peuvent pas écrire du tout dans le champ de texte, vous devez le corriger rapidement.

En général, il est plus facile de résoudre un problème immédiatement après sa découverte. Si vous laissez passer le temps, les développeurs peuvent oublier le fonctionnement de cette partie du code et corriger le bogue prendra plus de temps et sera donc plus cher.

Certaines entreprises n'écrivent pas de ligne de nouveau code s'il reste des bogues en attente. D'autres ne se soucient pas avant la phase de test avant la livraison.

Dans votre entreprise, vous laissez évidemment passer beaucoup de temps avant de corriger de nouveaux bugs pour qu'ils s'accumulent. Il est également mauvais pour le moral de l'équipe de voir une énorme liste de bugs.

Je vous suggère de passer une journée juste pour trier les bogues existants, décider ceux qui méritent d'être corrigés et ceux qui ne le sont pas et attribuer ceux à corriger aux membres de l'équipe existants dans le but de résoudre les problèmes avant le prochain jalon .

Dans notre suivi des problèmes, il y a un statut "prescrit". Si un problème remonte à plusieurs mois, voire plusieurs années, et qu'aucun client ne le demande ou ne le refile, ce statut est utilisé comme statut final. Cela ne se fait pas automatiquement, mais manuellement, chaque fois que les gestionnaires nous demandent de nettoyer les problèmes ouverts. Au cours de ce processus, il est également probable que certains des problèmes soient résolus car ils sont faciles à résoudre et / ou relativement importants (bien qu'ils ne soient pas exhortés ou remplacés).

Je n'utilise pas JIRA, j'ai fogbugz au travail mais je suis sûr que cela s'applique à la plupart des trackers de bugs. En écrivant ceci, j'ai réalisé que ma façon de travailler est plus agile que la cascade, les délais ne sont pas concrets pour moi et ce qui compte est prioritaire.

• Si votre patron se soucie de trop de billets ouverts, ne créez pas les plus triviaux en premier lieu. Vous devez être pragmatique et ne pas ajouter de fonctionnalités / correctifs qui n'ont aucun avantage. Si cela vous facilitera la vie pour peaufiner du code ou modifier l'interface utilisateur, alors bien sûr, ajoutez-le. Ne vous contentez pas de travailler pour vous-même en essayant de corriger les défauts mineurs du produit, rien n'est parfait.
• Mettez les bogues / fonctionnalités sans importance dans le jalon actuel mais sous une faible priorité. Si plus de plaintes / demandes sont mentionnées sur le problème, vous pouvez augmenter la priorité.
• Fermez / résolvez ce que vous ne pouvez pas corriger, ne pouvez pas reproduire, dupliquer, etc. Certains bogues sont trop triviaux pour être corrigés ou ce sont des demandes de fonctionnalités qui prendraient beaucoup trop de temps. Parfois, il vous suffit de dire à la personne qui demande ces correctifs / fonctionnalités "Non Désolé, nous n'avons pas le temps".
• Hiérarchisez les bogues selon vos besoins et faites classer votre liste de tickets par priorité et jalon.
• S'ils ne vont pas faire le jalon, déplacez-les dans un jalon futur.
• Si un ticket dépend de la finalisation d'un autre ticket, marquez-le comme bloqué ou organisez les tickets dans une hiérarchie, il est donc évident que ticket-x et ticket-y sont liés.
• Si un ticket nécessite des commentaires de quelqu'un, attribuez-le à cette personne.

En fin de compte, vous aurez toujours un tas de billets de faible priorité, mais les points ci-dessus devraient vous aider à minimiser cela.

Nous utilisons JIRA et avons un état de résolution supplémentaire appelé Suspended- si une fonctionnalité / bogue est quelque chose que nous devons simplement abandonner pendant un certain temps, il est résolu comme suspendu. De cette façon, il ne se mêle ni à la liste des problèmes actuellement actifs sur lesquels nous devons garder notre attention, ni à la liste des problèmes résolus qui, nous le savons, ont été traités satistfactory, et il est toujours dans la base de données.

La liste des problèmes suspendus est quelque chose que je revois périodiquement (mais pas très souvent) pour la rouvrir si nécessaire.

Pas sûr de la terminologie JIRA correcte, mais pensez à mettre une date d'expiration sur chaque "ticket". S'il n'a pas été escaladé, en fonction des besoins en fonctionnalités ou de la gravité des bogues, à la mise en œuvre dans un certain laps de temps, ce n'était probablement pas si important en premier lieu. Cela devrait aider à garder automatiquement la pile coupée. Je reçois souvent des billets basés sur "ça ne serait pas bien" ou "cela ne fonctionne pas parfaitement comme je le souhaite". Si personne d'autre ne pousse assez pour cela, ou si cet utilisateur n'a pas assez d'influence, cela ne se fait pas et je ferme le ticket après quelques mois.