Catégoriser les tâches / bogues par risque de changements

Le projet sur lequel je travaille actuellement a un problème: les bugs et les tâches sont souvent assignés à des gens qui sont trop nouveaux ou trop inexpérimentés et leur travail finit par produire plus de bugs en cours de route. Le problème est que certaines parties de notre logiciel sont beaucoup plus "dangereuses" à travailler que d'autres en raison de problèmes de qualité du code. J'ai essayé de lutter contre ce problème en estimant le risque associé aux tâches et en accordant une attention particulière aux développeurs qui sont assignés à quelles tâches.

Nous utilisons JIRA, j'ai donc commencé à étiqueter les problèmes pour suivre cette estimation. J'ai remarqué que j'ai fini par utiliser plusieurs mesures pour catégoriser un bogue / une tâche:

• Comme c'est clair / simple. Par exemple, que ce soit quelque chose qui nécessitera beaucoup de travail de conception ou simplement une simple correction de bogue dans l'interface utilisateur.
• La maintenabilité de la zone affectée du code. Est-ce une zone bien conçue ou une grosse boule de boue.
• Quelle proportion du programme, je pense, sera affectée par le changement requis.

Mes étiquettes sont un peu en désordre car je n'avais pas d'idée claire quand j'ai commencé quelles seraient les catégories possibles et je ne le fais toujours pas. Je pense à demander l'ajout d'un nouveau champ (quelque chose comme "Risque") afin que nous puissions demander un devis avant d'attribuer le travail à quelqu'un.

Quelqu'un a-t-il déjà traité ce genre de choses?

L'un des échecs de la plupart des approches de suivi des bogues est qu'elles ne concernent qu'un seul côté de l'équation - la vue de l'utilisateur final sur le système. Il s'agit d'un bogue critique à corriger qui peut attendre une semaine (priorité), ce bogue est douloureux car il s'agit d' sun problème de pluralisation (gravité).

Un article de blog décrivant le suivi de bogues multidimensionnel examine la manière de résoudre ce problème, notamment la vue développeur: PEF et REV.

Les valeurs PEF sont la vue de l'utilisateur:

• P ‍ain - à quel point le bug est-il douloureux lorsqu'il est rencontré?
• E ‍ffort - combien d'efforts faut-il pour contourner?
• F ‍ fréquence - à quelle fréquence le bogue se produit-il?

Le côté REV est du point de vue du développeur:

• R ‍isk - quel est le risque de la solution?
• E ‍ffort - combien d'efforts faudra-t-il pour réparer?
• V ‍ vérifiabilité - est-il facile de vérifier que le bogue est corrigé?

Chacun d'eux est mesuré sur une échelle de 1 à 9, 1 étant faible / facile et 9 étant élevé / difficile. Les nombres sont additionnés pour donner un score pour PEF et REV.

La partie qui aborde les bits décrits:

• Comme c'est clair / simple. Par exemple, que ce soit quelque chose qui nécessitera beaucoup de travail de conception ou simplement une simple correction de bogue dans l'interface utilisateur.
• La maintenabilité de la zone affectée du code. Est-ce une zone bien conçue ou une grosse boule de boue.
• Quelle proportion du programme, je pense, sera affectée par le changement requis.

Ces facteurs entrent dans l'effort et les risques décrits dans REV.

Oui, c'est quelque chose qui a été combattu auparavant. J'ai (dans le passé) utilisé ce modèle pour des champs personnalisés dans Redmine et il a été raisonnablement réussi.

Le gros avantage de cela vient lorsque vous comparez les scores PEF et REV. Si vous avez un PEF de 21 et un REV de 7, c'est quelque chose qui peut être une grosse victoire. Bien qu'un PEF de 7 et un REV de 21 soient quelque chose qui devrait être évité pendant un certain temps parce que le côté risque et effort l'emporte probablement sur l'avantage qui le fixe.

On peut alors regarder le score REV et attribuer des choses à faible risque aux développeurs moins expérimentés (faible risque, effort élevé sont souvent idéaux pour cette situation).

Je dirais que ce à quoi vous faites référence ici pourrait mieux être appelé «complexité». Bien sûr, plus un changement est complexe, plus le «risque» est élevé, car un nouveau bug peut être introduit par un programmeur inexpérimenté. Ce n'est pas une mauvaise idée d'introduire un tel champ si c'est un vrai problème.

Cependant, à en juger par ce que vous avez écrit, vous semblez avoir deux problèmes:

1. Vous avez affaire à des programmeurs nouveaux ou inexpérimentés.
2. La qualité de (beaucoup / certains) de votre code semble être discutable.

En plus d'introduire quelque chose comme un champ de «complexité» (qui aiderait à gérer et à hiérarchiser votre travail), je vous suggère de vous concentrer sur l'atténuation du risque des deux problèmes ci-dessus.

Pour résoudre le premier problème, je créerais un processus par lequel les nouveaux programmeurs discuteraient d'abord de tous les nouveaux bogues avec un programmeur plus expérimenté avant de travailler sur le bogue. De plus, je vais certainement introduire des révisions de code pour à la fois réduire le risque d'introduction de nouveaux bogues et utiliser comme opportunité de coaching pour que les nouveaux programmeurs se mettent au courant plus rapidement.

En ce qui concerne la qualité du code, je ferais deux choses. Tout d'abord, arrêtez le processus de pourriture: convenez de normes et de pratiques de codage qui empêcheraient l'introduction de tout nouveau code inférieur. Les révisions de code suggérées pourraient également aider ici. Deuxièmement, j'identifierais les pires parties de votre code et commencerais à les refactoriser et à les nettoyer.

Oui, c'est une bonne idée de ne pas donner aux développeurs inexpérimentés des problèmes trop complexes. Mais le revers de la médaille est que si vous ne les laissez faire que les choses faciles, ils n'apprendront pas.

Je suggère qu'une autre stratégie consiste à instituer un régime d'examen des codes. Laissez les débutants travailler sur les choses délicates (dans des limites raisonnables), mais examinez soigneusement leur travail.

À court terme, c'est plus de travail pour tout le monde. À plus long terme, vous vous retrouverez avec toute une équipe de développeurs qui peuvent gérer les choses complexes, ET sont "sur la même page" en ce qui concerne la qualité du code.