Lorsque les leaders ingénierie peuvent clairement visualiser les progrès, identifier les points bloquants et observer les tendances au sein de plusieurs équipes, ils sont à même de remarquer si quelque chose dérape avant qu’il ne soit trop tard. Ils peuvent expérimenter la structure et le calendrier des réunions, fournir un feedback exploitable et ignorer les détails qu’il convient de traiter à d’autres niveaux. Ils peuvent ensuite mesurer l’impact de ces décisions.

Le code churn fait partie des métriques à disposition des responsables pour comprendre la progression d’une équipe. Le code churn, c’est lorsqu’un développeur réécrit son propre code peu après l’avoir enregistré (généralement dans un délai de trois semaines). C’est une étape naturelle dans le flux de travail d’un ingénieur qui explore, teste et affine. Mais des niveaux exceptionnellement élevés de code churn ou des fluctuations inattendues de cette statistique peuvent venir signaler que quelque chose ne va pas.

En observant les tendances du code churn, les responsables peuvent identifier qu’un délai risque de ne pas être tenu, qu’un ingénieur est bloqué ou en difficulté, ou que des problèmes concernent des acteurs externes.

Dans ce guide, nous allons vous expliquer ce qu’est le code churn, ce qu’il n’est pas, et ce qu’il faut faire lorsque vous observez un pic inattendu de cette statistique.

Le code churn, du code réécrit ou supprimé peu de temps après avoir été écrit, est une étape normale du processus de développement. Les ingénieurs testent, re travaillent et explorent souvent différentes solutions à un problème, en particulier au début d’un projet lorsque le problème n’a pas encore de solution claire.

Les niveaux de code churn varient selon les équipes, les personnes, les types de projets et leur état d’avancement dans le cycle de développement.  Chaque personne, chaque équipe aura un niveau « normal » différent en fonction des flux de travail et des types de projets (par ex. nouveau problème, problème récurrent, solution rapide, etc.). Pour les responsables, il est donc utile d’avoir une idée de ce qui est « normal » dans le contexte de chaque équipe afin de pouvoir éventuellement détecter ce qui ne va pas.

Il y a lieu de s’inquiéter uniquement lorsque le code churn augmente ou diminue soudainement par rapport au niveau « normal »" de la personne ou de l’équipe. Il est particulièrement important de pouvoir identifier cela lorsqu’un projet approche de son échéance, car des risques peuvent exister.

Le code churn est un concept qui paraît simple mais qui est généralement mal compris. Nous pensons souvent, à tort, que les équipes devraient optimiser leur travail et viser un code churn réduit ou bien que c’est le signal d’un flux de travail mal équilibré. Aucune de ces deux possibilités n’est vraie. Cette statistique étant un signal particulièrement utile pour les responsables ingénierie et présentant des avantages pour toute l’équipe, il est intéressant de s’y pencher d’un peu plus près.

Les tests et le travail de réécriture constituent des étapes naturelles du processus de développement logiciel et on observe une variation des niveaux de code churn selon les personnes et les équipes. Un certain code churn est normal, surtout au début d’un projet ou lorsque les problèmes à résoudre sont nouveaux et complexes.

Mais c’est lorsque ces niveaux s’éloignent considérablement des normes attendues, aussi bien à la hausse qu’à la baisse, et en particulier au cours des dernières étapes d’un sprint ou lorsque le projet approche d’une échéance, qu’ils peuvent annoncer la perspective d’une situation cauchemardesque.

Après avoir comparé les schémas de contribution au code de plus de 85 000 ingénieurs logiciel, l’équipe data science de GitPrime a constaté que les niveaux de code churn se situaient fréquemment entre 13 et 30 % de l’ensemble des codes commits (soit une efficacité de 70 à 87 %), tandis qu’une équipe classique peut espérer atteindre environ 25 % de code churn (efficacité de 75 %). Il est conseillé de prendre un certain niveau pour référence, car des niveaux exceptionnellement bas peuvent indiquer qu’un ingénieur sacrifie la vitesse à la précision.

Chaque équipe ayant son propre niveau moyen de code churn, il peut être utile de se familiariser avec le mode de travail normal de l’équipe pour pouvoir détecter si quelqu’un est bloqué ou a besoin d’aide, ou pour laisser faire si le flux de travail est sain.

Les niveaux de code churn peuvent varier au cours de la durée de vie d’un projet. Pour un projet sain, il peut être élevé au démarrage (parfois appelé le churn « exploratoire », lorsqu’un ingénieur explore différentes solutions à un problème) et plus faible vers la fin, lorsqu’une solution a été identifiée puis affinée.

Lorsque vous remarquez que le code churn change de façon inattendue, en particulier à l’approche d’une échéance, considérez qu’il s’agit d’un signal et allez voir plus loin. Voyez-vous un pic dans les niveaux de code churn à la fin du sprint, sprint après sprint, avec la même équipe ? Peut-être que le propriétaire du produit sur lequel travaille cette équipe fournit des instructions peu claires. Ou bien est-ce un ingénieur qui cherche constamment à perfectionner son travail au-delà de ce que l’entreprise considère comme suffisant ? Réfléchissez à la façon dont vous pouvez l’aider à définir ce qui est « suffisant » ou invitez-le à examiner le travail d’un autre développeur et soulignez les comportements que vous aimeriez observer.

Des niveaux de code churn anormalement élevés indiquent souvent des facteurs contributifs extérieurs au processus de développement normal. La prise en compte de ces facteurs permettra d’éliminer les frictions dans le processus de développement et l’équipe pourra passer moins de temps à attendre les autres ou à gérer des spécifications ambiguës et plus de temps à travailler sur les problèmes de fond.

Voici quelques flux de travail et quelques dynamiques courantes qui peuvent être à l’origine d’un code churn anormalement élevé et ce qu’il convient de faire lorsque vous l’identifiez.

Il est normal que le code churn soit élevé lorsqu’un ingénieur crée une nouvelle fonctionnalité et qu’il explore et teste plusieurs solutions à un problème. On considère souvent que le prototypage se trouve au début d’un projet, en particulier lorsqu’il s’agit d’un projet nouveau ou peu familier. (En réalité, un niveau exceptionnellement bas au début d’un projet pourrait précocement indiquer qu’il ne progresse pas comme prévu.)

Lorsqu’un développeur est accaparé par des projets exploratoires, il fait souvent des compromis au détriment des normes établies afin d’accélérer la preuve de concept, dans l’idée de revenir affiner après avoir identifié la bonne solution. Même si cela génère à court terme un code churn plus élevé, ce schéma de travail est productif car l’ingénieur peut valider plus rapidement de nouvelles idées. Qu’il s’agisse de changements de conception, de prototypes ou de preuves de concept, voici des exemples de cas dans lesquels il est fort probable que de gros morceaux de code soient réécrits.

Si vous voyez un ingénieur en train de travailler sur un prototype, ne l’interrompez pas. S’il a une réunion planifiée qui n’est pas strictement nécessaire, n’hésitez pas à la remettre à plus tard ou informez-le que vous êtes conscient de son travail en cours sur le projet et qu’il n’est pas obligé de participer.

En revanche, si le temps et le travail dédiés au prototypage excèdent de loin sa « quantité normale » ou ce que vous aviez prévu pour la tâche concernée, il peut être utile de vérifier ce qui se passe pour mieux comprendre le mode opératoire de l’ingénieur. Peut-être s’agit-il d’un problème plus complexe que la plupart de ceux qu’il a déjà rencontrés. Il admettra peut-être qu’il ne comprend pas entièrement certains aspects du problème. Si tout se passe bien, c’est peut-être aussi qu’il en fait trop par rapport aux attentes.

Le prototypage est un schéma sain et courant. La clé, c’est de comprendre à quel moment le temps qui y est consacré est anormalement long ou quand il dépasse les attentes. Veillez à ce que le temps consacré au prototypage corresponde au niveau approprié de risque pour l’entreprise et à la valeur ajoutée que vous attendez de la fonctionnalité concernée.

Le perfectionnisme apparaît lorsque l’ingénieur et l’entreprise n’ont pas la même jauge de « travail suffisant ». À trop souvent revenir affiner ou réécrire le code sans rien ajouter en termes de fonctionnalité ou de valeur au code existant, le résultat n’en vaut pas forcément la chandelle. Habituellement, l’ingénieur a tout intérêt à passer du temps sur autre chose.

Le perfectionnisme se caractérise par un code churn élevé en milieu ou en fin de sprint ou de projet, une fois le travail déjà prêt à partir en production. L’ingénieur réécrit des sections conséquentes sans ajouter de fonctionnalité ni de valeur importantes au code initial. Souvent, un ingénieur va reproduire ce schéma sprint après sprint. Autrement dit, si vous pensez voir du perfectionnisme dans les données, observez leur tendance historique pour vérifier qu’il ne s’agit pas tout simplement d’une situation exceptionnelle.

Le « fignolage » (lors des étapes finales, avant et après une version, un ingénieur résout les problèmes qui restent, parfois décelés lors du processus de révision, et met à jour les fréquents petits code commits avec churn élevé) peut parfois virer au perfectionnisme. Il faut réussir à distinguer si l’on apporte des améliorations parfaitement superflues pour l’entreprise sans y ajouter une réelle valeur ajoutée.

Que faire ?

●       Faire une distinction : le travail correspondait-il aux normes de l’équipe lorsqu’il a été enregistré la première fois ? Ce travail supplémentaire résulte-t-il d’un feedback du processus de révision ou présente-il des avantages importants pour le code initial ? (Formidable si tel est le cas ! Félicitons à ceux qui prennent systématiquement en compte le feedback du processus de révision et améliorent le code).

●       Soyez clair sur ce que signifie « être fait ». Montrez le delta entre les exigences de départ et ce qui a été livré. Si un ingénieur commence à retravailler ou réécrire du code sur une période prolongée, ou dans des proportions bien supérieures à ce qui est nécessaire pour l’exécution du projet, envisagez de demander à un ingénieur plus chevronné d’évaluer ce qui est « suffisant » dans le contexte de ce projet.

●       Un code churn très élevé met en péril la sortie d’une version. La réécriture excessive du code juste avant une échéance peut alerter sur le fait que la version nécessite peut-être un délai supplémentaire.

On observe fréquemment un code churn anormalement élevé lorsque les acteurs sont peu clairs ou indécis. Cela peut sembler anecdotique, mais un membre qui hésite au sein d’une équipe peut causer de réels préjudices, tant au niveau du moral que de la progression, et peut, à terme, générer de la frustration.

S’il manque des fonctionnalités ou des composants suite à un malentendu entre ce qui a été livré et ce qui devait l’être, on remarquera probablement une amélioration des nouvelles tâches après application des nouvelles exigences. Si le code doit être retravaillé suite au malentendu, on remarquera une forte augmentation du code churn. Dans les deux cas, il convient de considérer qu’une forte augmentation de l’activité dans le dernier tiers d’un sprint (non causée par la révision du code) est un signal indiquant que l’échéance ne sera peut-être pas respectée.

Lorsque ce schéma se répète d’un sprint à l’autre au sein de la même équipe, il est judicieux de vérifier si cela est dû à des demandes tardives.

En règle générale, le problème qu’une équipe est en train de résoudre doit disparaître au fil du temps lorsque des solutions sont identifiées, construites et affinées. Un pic soudain d’activité, en particulier dans les dernières étapes d’un projet, tend à indiquer que quelque chose de nouveau s’est produit.

Que faire ?

• Si un acteur change fréquemment d’avis une fois la phase de développement commencée, montrez-lui le pourcentage de travail d’ingénierie consacré à la recréation (en incluant si possible les durées et les sommes permettant de souligner l’impact de ce comportement).
• Il faut comprendre que les exigences fluctuantes d’un propriétaire de produit peuvent signaler qu’il se disperse, que la somme de travail est trop importante et donc qu’il accorde seulement toute son attention aux choses lorsqu’il est trop tard. Il est donc utile de faire preuve d’empathie et d’avoir une discussion avec son responsable. Inclure des données dans la discussion permet de couper court au scepticisme ambiant et d’aboutir directement à une discussion sur la façon d’appréhender la situation à venir.

Face à un problème particulièrement complexe, on peut attendre un pourcentage plus élevé d’exploration et de marche arrière. Tout l’enjeu consiste à savoir si le problème perdure depuis trop longtemps.

Parfois, le code churn est exceptionnellement élevé si l’ingénieur pensait avoir correctement résolu le problème, et qu’il avait même peut-être déjà envoyé le projet pour révision, avant de constater qu’il fallait réécrire des sections importantes. Les spécifications laissait peut-être une grande marge d’interprétation ou bien l’ingénieur n’avait pas bien compris le problème ou la façon de le résoudre.

Que faire ?

●       Apprenez à reconnaître quand un problème perdure depuis trop longtemps et soyez proactif.

●       Il est généralement préférable d’être coaché par un collègue ingénieur ou un chef d’équipe plutôt que par un responsable. Demandez à un ingénieur plus expérimenté (qui a tendance à aider les autres ou qui aime le faire) de participer en binôme au programme.

●       En accord avec lui, essayez d’échanger à un moment qui ne perturbe pas son travail. Déterminez s’il dispose des ressources dont il a besoin et quelles ressources supplémentaires il souhaiterait que vous lui fournissiez.

Lorsqu’un ingénieur travaille à partir d’exigences plutôt vagues, il se fie à ce qu’il pense deviner pour interpréter et compléter. Certaines de ses hypothèses seront sans aucun doute incorrectes et feront augmenter le code churn. Si les spécifications sont mal rédigées ou incomplètes, il est même possible qu’il travaille sur quelque chose d’impossible à créer.

Que faire ?

●       Examinez les exigences pour déterminer s’il est nécessaire d’apporter davantage de clarification et si les cas limites ont été correctement traités.

●       Rencontrez l’équipe produit et montrez-lui le coût que peut représenter un manque de clarté. Si vous utilisez GitPrime, apportez un graphique du calendrier du projet pour illustrer le résultat d’une mise en œuvre effectuée proprement par comparaison avec un travail approximatif.

●       Donnez un exemple de ce que doivent être de bonnes exigences. Expliquez que les membres de l’équipe peuvent contribuer à l’accélération du processus en fournissant des spécifications claires.

Lorsqu’un ingénieur révèle un code churn élevé sans obtenir beaucoup de résultats sur une période prolongée, cela peut être un signe d’épuisement ou d’ennui. Parfois, cela résulte d’une méthode de travail appelée « Bit Twiddling » selon laquelle un ingénieur s’intéresse invariablement à une seule partie du code base pendant très longtemps, en n’y apportant que de légères modifications ici et là. C’est un peu comme faire un puzzle, se retrouver au point où toutes les pièces se ressemblent et rien n’avance ; cela se produit souvent parce que l’ingénieur ne comprend pas complètement le problème ou le contexte dans lequel il doit faire des modifications.

Recherchez le code churn élevé dans la même zone de code. La clé consiste à coupler la répétition et le réusinage avec l’ambivalence ou l’indifférence dans la revue de code, sur une longue période. Cela indique que l’ingénieur s’essouffle et perd sa motivation, ou que ce risque est probable.

Que faire ?

●       Faites en sorte de remotiver l’ingénieur avec un nouveau projet. Trouvez une piste, même légère, qui mènera à des zones nouvelles et intéressantes du code, même si cela se fait au détriment de la productivité de l’équipe à court terme.

En nous appuyant uniquement sur les données de résultats des équipes (métriques d’utilisation, taux de bug, produits et fonctionnalités pour expérience client), nous passons à côté de la possibilité de comprendre comment nos équipes travaillent, de l’idée à la production, lorsqu’elles créent ces résultats.

GitPrime fournit une série de rapports qui examinent le processus de développement, de l’idée à la production, afin que les leaders ingénierie puissent identifier les goulets d’étranglement, les problèmes causés par les acteurs externes et les ingénieurs qui travaillent énormément sur des éléments moins prépondérants. Ils utilisent GitPrime pour comprendre la dynamique, par exemple le code churn exceptionnellement élevé à la fin d’un sprint, qui aurait pu passer inaperçue ou causer des retards.

La mesure du code churn et d’autres indicateurs d’intégrité a pour objectif de fournir des données concrètes à votre moteur d’intuition.