A la recherche de nouveaux vaccins

Il y a peu, je participais à une réunion de travail impliquant une trentaine de personnes et j’ai fait une observation qui m’a intrigué. Avez-vous remarqué ce qui se produit lorsqu’un téléphone portable sonne au cours d’une réunion ?

  • La personne propriétaire du portable l’éteint rapidement
  • Tous ceux qui ne l’avaient pas encore fait vérifient leur portable et activent discrètement le mode silence.

Voilà un exemple de mesure préventive particulièrement efficace! Dans les entreprises où l’on respecte un certain standard de réunion, l’exception que constitue la sonnerie d’un portable ne se produit qu’une seule fois, pas deux. La première “infraction” protège le groupe de toute nouvelle occurrence. Elle agit en quelque sorte comme un “vaccin” sur le fonctionnement du groupe en réunion.

Quelles conditions faut-il réunir afin de créer d’autre vaccins de ce type au sein d’une équipe ? J’en vois au moins trois :

  • Qu’il existe un standard explicite ou implicite pour le groupe
  • Que l’écart au standard soit détectable rapidement par tous les membres du groupe
  • Qu’une prévention des futurs écarts soit possible sans confrontation supplémentaire

Y a t’il des activités de groupe — autres que les réunions — dans lesquelles un vaccin de ce type pourrait fonctionner ? Bien sûr ! Par exemple, certaines équipes de développement utilisent un lapin Nabaztag qui “écoute” en permanence les résultats du serveur de build continu. Ici le standard est que le code déposé par chacun sur le serveur doit passer tous les tests. Lorsque ce n’est pas le cas, le lapin remue les oreilles et dénonce immédiatement l’auteur de l’infraction. Cet évènement incite ledit auteur à réparer le build, et les autres développeurs à toujours mieux vérifier le passage des tests sur leur code avant de le déposer.

Il existe d’autres moyens que le test pour détecter les défauts d’un système en cours de développement. D’après Wikipedia, une analyse faite par Capers Jones sur 12000 projets de développement à montré que le taux de découverte des défauts latents par des inspections formelles se situe entre 60% et 65%. Pour les inspections informelles, le chiffre est inférieur à 50%. Pour les tests en général, le taux de découverte des défauts latents est d’à peu près 30%.

L’inspection formelle, également appelée “revue de code” constitue une mesure de prévention particulièrement puissante pour améliorer en continu la qualité de vos développements. C’est une amélioration générique, qui fonctionne donc également comme un “vaccin” :

  • Il existe un standard (correction du code, règles de codage, de lisibilité, de modularité, d’architecture, de couverture par les tests etc).
  • L’écart au standard (erreur de logique ou infraction au standard) est détecté rapidement par tous les membres de la revue (le code étant rétroprojeté).
  • Après la revue les autres participants peuvent rechercher et corriger rapidement des écarts similaires sur leur code, sans confrontation supplémentaire.

A court terme, la revue permet aux participants — même les plus novices — d’apprendre de nouvelles choses (sans avoir à poser des questions embarrassantes). A moyen terme, son usage régulier réduit significativement le nombre de défauts du système. A long terme la revue de code contribue à créer une culture de la qualité logicielle dans votre entreprise.

Comme dans le cas des vrais vaccins, ce type d’amélioration générique ne va pas sans quelques inconvénients ni réticences. Lorsque vous mettrez en place une stratégie de revue de code, vous rencontrerez très certainement des objections:

- “Mobiliser chaque semaine tous les développeurs va coûter cher et mettre le projet très en retard !”
- “Ici, il n’y a pas de standard de qualité du code !”
- “Ici dès qu’on échange sur le code ou le design cela finit par des débats houleux !”
- “On a déjà essayé de faire des revues et c’était vécu comme du flicage !”

Ces obstacles peuvent être surmontés. Apprenez à mener des revues de code. Mesurez le coût de la non-qualité sur votre projet; essayez des revues de code régulières pour une période de trois mois, puis mesurez le à nouveau. Si votre équipe respecte déjà le standard “pas de sonnerie intempestive en réunion” qu’est-ce qui l’empêche de respecter des standards encore plus cruciaux pour votre entreprise ?

2 commentaires pour “A la recherche de nouveaux vaccins”

  1. Je suis tombé par hasard sur le blog en « wilf »ant … j’étais parti sur une recherche sur CMMI. Je dois avouer que le blog est super interessant (j’ai bookmarqué).
    Un commentaire (ou retour d’experience)sur le fait qu’il faut un standard explicite (on devrait connaître les regles et les avoir acceptées) et bien faire attention à la façon d’appliquer la méthode dans un environement culturel différent et que celle-ci peut prendre du temps. En effet en Chine un téléphone portable qui sonne en réunion semble ne pas être problématique (sauf pour un manager occidental); pointer du doigt la personne fautive lui ferait perdre la face (et il ne comprendrait pas). Ce fut difficile de faire accepter La ‘Code Review’ collective pour les mêmes raisons. L’exercice serait d’identifier l’erreur et non le fautif. Le Nabaztag qui dénonce aurait était interprété comme ‘fun’ dans mon acienne équipe de Paris alors que ce serait considéré comme ‘flicage’ dans l’équipe de Shanghai … cela evoluera avec le temps

    Merci pour tt ces posts !

    Gael

  2. Gaël,
    Merci pour ce partage d’expérience! En effet, les standards (implicites ou explicites) varient d’une culture à l’autre, d’une entreprise, et d’une équipe à l’autre. Dans le cas des revues, la constitution du standard demande à la fois de la rigueur, de la souplesse (car les standards évoluent) et un dialogue de qualité, la revue de code ne pouvant être efficace et perenne que si le blâme en est exclu.

Laissez un commentaire