Pratiques, exceptions et métriques

Ce processus type est appliqué dans la majorité des cas, mais des exceptions arrivent, par exemple :

L’existence de ces exceptions ne signifie pas que le processus pose problème car il est prévu pour gérer les cas standards. Le fait que des cas non-standard demandent des adaptations ne remet pas le cas standard en cause.

Je préfère un processus simple et suffisamment malléable pour que ces exceptions ne soient pas une gène plutôt qu’un processus qui tenterait de couvrir tous les cas possibles.

Le pilotage de ces exceptions se fait au fil de l’eau.

Il s’agit de maintenir un mélange satisfaisant entre :

Ce type d’approche est acceptable dans une équipe où la relation PO — personnes qui développent fonctionne bien, par exemple il ne faut pas qu’une personne ne tente de tirer profit des exceptions en lésant les autres.

Actuellement nous utilisons peu de métriques pour suivre l’avancée des sujets.

Quand on parle de métrique de développements, le risque que je vois le plus souvent cité est la loi de Campbell, indiquant le risque de se concentrer sur ces métriques elles-mêmes.

Dans un projet avec des pratiques informelles, comme celui dont je vous parle, il existe deux autres risques.

Le premier est celui rigidifier la manière de travailler.

En effet une métrique projet matérialise un certain type de processus.

Par exemple une métrique mesurant le nombre de bugs implique que certaines demandes d’évolutions soient classifiés comme des bugs. Dans les projets sur lesquels j’ai travaillé, les bugs peuvent être traités différemment des autres évolutions, par exemple avec un processus plus court afin d’accélérer la correction. Dire qu’une demande d’évolution est un bug signifie qu’on va lui appliquer ce processus particulier.

Si le nombre de bugs n’est pas mesuré, on peut se permettre sans effet secondaire de parfois identifier comme bug des demandes d’évolutions qui ne sont pas des bugs (dans le sens de “comportement fautif”), mais dont on veut qu’elles suivent le processus plus court.

Le processus “gestion d’un bug” est alors un outil, dont on peut choisir d’adapter l’utilisation pour y faire rentrer des exception quand cela est utile, tant que cela ne dénature pas le fonctionnement général.

Mais si le nombre de bug est mesuré, l’utiliser pour quelque chose qui n’est pas un bug vient fausser cette mesure. Car en mesurant quelque chose qui s’appelle “le nombre de bugs”, il y a pas mal de chance qu’on veuille mesurer les bugs (dans le sens de “comportement fautif”), pas le nombre de fois où on a appliqué le processus plus courts de traitement de bugs.

Même si l’objectif n’est pas directement de réduire le nombre de bugs mesurés, utiliser le processus plus court pour autre chose qu’un bug va alors fausser cette mesure. Cela peut ne pas poser problème tant que la proportion d’exceptions reste faible par rapport au nombres de cas standards, mais cela signifie qu’il faut maintenant surveiller cela pour faire en sorte que la métrique reste pertinente^[1].

Par ailleurs si on veut faire évoluer un processus qui fait l’objet d’une métrique, l’historique de la métrique risque d’être perdu, cela peut ne pas être grave, mais cela signifie qu’il faut se poser la question, ou alors risquer de passer du temps plus tard à investiguer pourquoi les valeurs mesurées ont changé à un certain moment.

Le processus court n’est plus un outil qu’on peut utiliser et adapter librement. Cela ne signifie pas que la métrique l’a rendu impossible à modifier, mais qu’elle a tendance à le rigidifier.

L’autre risque est celui de la décontextualisation.

En effet une métrique peut voyager seule, sans le contexte qui peut être nécessaire à la comprendre.

Imaginez que vous mesurez le nombre d’évolutions identifiées comme des bugs, et que dans l’équipe vous prenez soin d’utiliser cette métrique dans son contexte, par exemple vous savez qu’elle n’est pas tout à fait juste, et qu’en particulier pour certaines itérations vous avez fait des exceptions qui la rendent inexploitable, et qu’à un moment vous avez modifié cette métrique.

En interne vous n’avez pas forcément formalisé tout ce contexte, et même si vous l’avez fait la métrique peut être disponible sans son contexte, ou les personnes qui accèdent à la métrique peuvent ignorer le contexte (surtout pour les métriques qui semblent ne pas avoir besoin de contexte, comme le nombre de bugs).

Cela signifie que lorsque vous communiquez une métrique, et même dès qu’elle devient disponible, il faut prendre en compte qu’elle soit interprétée sans son contexte.

Mon expérience est que quand une personne a lu une métrique est qu’elle en a tiré une conclusion fausse par rapport à ce qu’elle a cru comprendre, il peut être difficile de rattraper le coup. Par exemple un N+2 ou +3 qui a parcouru en diagonale les slides d’un comité de suivi qu’on lui a fait suivre.

Cela ne signifie pas que cela soit forcément grave, mais qu’il faut le prendre en compte^[2].

Je pense qu’il n’est pas possible d’empêcher toute mauvaise interprétation, mais il est possible d’essayer de diminuer le risque, par exemple :

Si l’article est plutôt à charge contre les métriques, je ne veux pas dire que les métriques sont obligatoirement une mauvaise choses.

Certaines métriques peuvent être utiles, voire nécessaires au fonctionnement d’une équipe.

Mais cela ne signifie pas qu’elles n’ont pas d’effets secondaires.

Mon message n’est donc pas “non aux métriques” mais “portez attention aux effets des métriques”, et surtout de celles qui portent sur les pratiques des équipes^[3].

Mon conseil final est de faire attention à l’envie de mesurer des choses à priori, par exemple car le coût de la mesure est faible, sans se poser de question. Je préfère prendre le risque de perdre du temps si une métrique n’est pas disponible au moment même où on en a besoin, plutôt que celui d’une mauvaise interprétation.

Post-scriptum : L’idée de cet article m’est venue en lisant la première partie de Seeing Like a State qui illustre plusieurs manières dont des États ont mis en place des règles pour rendre mesurables les personnes qu’ils gouvernent, et leurs effets sur les vies de ces personnes.