Comment mesurer la productivité ?

Depuis toujours, dans le monde du logiciel, on entend « Il faut augmenter la productivité des développements ». Il ne suffit pas d’en parler pour améliorer la productivité. Comment passer d’un slogan très abstrait à des actions concrètes et des résultats tangibles ?

On ne peut améliorer que ce que l’on mesure. Il est donc impératif de trouver un indicateur permettant de vérifier l’amélioration recherchée. Les mesures comme le nombre de lignes de code ou le nombre de points de fonctions, encore utilisées aujourd’hui, sont trop éloignées de la valeur produite pour être intéressantes. Un indicateur beaucoup plus proche de la satisfaction client, et donc plus pertinent, est « le nombre de fonctionnalités sans erreur ajoutées à un logiciel durant un période donnée », ce que l’on pourrait appeler le débit de fonctionnalités.

  • Nombre de fonctionnalités ajoutées à un logiciel

Plus ce nombre est important, plus la productivité est grande. Si ce chiffre est égal à zéro, la productivité est alors nulle. On peut améliorer cet indicateur en pondérant chaque fonctionnalité par sa complexité. Par exemple, « écran de facturation » aura une complexité de 1, alors que « payer en 10 fois » aura une complexité de 9.

  • Sans erreur

Une fonctionnalité qui ne marche pas ne peut exister. Evitons aussi de compter une fonctionnalité comportant une erreur non-bloquante ou introduisant une régression comme l’ajout du paiement en 10 fois a engendré un bug dans la consolidation des portefeuilles. En effet, ceci aura très certainement un impact négatif sur notre productivité future. Lorsque nous passons 20% du temps à corriger des erreurs, c’est 20% du temps perdu.

  • Durant une période donnée

Sur un projet en cascade, découpé en 3 lots de 6 mois, nous n’avons que très peu de mesures. De plus, entre deux lots, beaucoup de paramètres ont changé c’était le lancement, l’équipe a intégré de nouvelles personnes, on a modifié une partie de l’architecture logicielle, sans compter la dérive temporelle qui rajoute une variable supplémentaire. Bref, toute comparaison est impossible entre lots et notre indicateur devient inexploitable. Afin qu’une comparaison entre deux mesures puisse avoir un sens et permette de juger les améliorations, cette période doit être courte : entre une semaine et un mois maximum. Cela permet aussi d’avoir des mesures fréquentes et autant de possibilités d’amélioration.

Lorsque l’on met en place cet indicateur, nous observons ce type de tendances :

Profils observés

Malgré les différences de technologies, les deux tendances (1) et (2) ont une caractéristique commune : après un certain temps, le débit de fonctionnalités chute. Le profil 3 montre les équipes arrivant à conserver une augmentation de leur productivité. Quelle caractéristique magique ont-elles ? Une technologie spécifique ? Non. Une architecture spéciale ? Non. Elles observent simplement deux disciplines : le test automatisé et le remaniement permanent du code. Les équipes ayant un profil 1 ou 2 ne font pas de tests automatisés. Ceci les amène inexorablement à avoir un code qu’elles ne peuvent plus modifier rapidement sans risques de régression, et une modification qui semble triviale devient véritablement complexe Si on rajoute ce champs, il faudra vérifier que tout marche bien, cela va prendre assez longtemps, disons 1 semaine pour tout vérifier. Tandis qu’une équipe disposant d’un ensemble de tests automatisés va effectuer sa modification et vérifier le fonctionnement de l’ensemble Je rajoute ce champs. OK, je lance mes tests. tiens, ici ça ne passe plus. Ha oui ! Il faut que je modifie aussi ce bout de code. C’est fait. Je relance mes tests. Tout passe. OK, cette fois c’est fini.. Une modification triviale reste triviale.

Mais les tests ne font pas tout ! Certaines équipes ne remanient pas assez leur code. Ce non-remaniement engendre une croissance exponentielle de la complexité du code et on se retrouve dans une situation où, une fois encore, ajouter une fonctionnalité simple est devenu trop complexe Ajouter la possibilité de paiement différé ? Impossible, il faudrait modifier une centaine de classes et encore plus de tests. En remaniant régulièrement le code, et le code de tests, les équipes s’obligent à conserver la modularité de leur code, facilitant les évolutions futures.

D’un coté, nous avons un indicateur qui nous informe sur notre productivité et qui nous permet de vérifier l’efficacité des améliorations apportées au produit comme au processus de développement. D’un autre coté nous avons deux caractéristiques du processus qui nous permettent de réaliser ces promesses de productivité.

Le débit de fonctionnalité reste une simple mesure et non l’objectif en soi. Poursuivre un objectif chiffré comme augmentons notre productivité de 30 points de complexité par semaine aurait pour conséquence de polariser l’équipe sur l’augmentation d’un indicateur (auquel est associée leur prime !) plutôt que l’augmentation de la productivité elle-même. Par exemple, la fonctionnalité « écran de facturation » sera rapidement évaluée à 30 points de complexité plutôt qu’à 5. D’autres indicateurs comme la qualité du code, la couverture de tests ou encore l’adhésion à la finalité du projet, nous permettront de détecter d’autres axes de progression. Associé aux pratiques de tests et de remaniement permanent du code, cet ensemble nous permettra d’amorcer une démarche d’amélioration continue qui est la seule vraie réponse à la question « Comment améliorer durablement la productivité ».

Benoit Lafontaine
Extrait du White paper OCTO Technology : “Java Productivity Prime, twelve guidelines to boost your productivity with a software factory” disponible sur www.octo.com

3 commentaires pour “Comment mesurer la productivité ?”

  1. Nous avons là une bonne définition de la productivité. Cependant, plusieurs points passent sous silence:
    – la satisfaction du programmeur;
    – les outils de travail;
    – la formation au ‘génie logiciel’;
    – la non-régression (quoi ce cela rejoigne les tests automatiques).

    Ces trois thèmes sont essentiels à l’amélioration du code même si du point de vue managérial, ils ne sont que difficilement chiffrable.

    1) la formation au ‘génie logiciel’. Avec l’embauche de nombreux prestataires par des sociétés de services, la formation au ‘bon code’ (celui qui va améliorer la qualité du logiciel) n’est plus assurée correctement et bon nombre de programmeurs se satisfont d’un malheureux copier/coller. Combien de codes en sont truffés? Y compris en Java. Seules les équipes qui savent gèrer la qualité du code peuvent en améliorer la productivité.

    2) la non-régression. Lorsque les tests automatiques n’étaient pas encore à la mode, on parlait de non-régression. En général, pour obtenir une bonne qualité de non régression, les tests ne suffisent pas (à moins qu’ils puissent tout couvrir), c’est pourquoi je pense intimement que la qualité du code influe directement sur la réussite des tests automatiques. Et même si vous désirez garder cet indicateur sur les tests, vous devriez passer les tests avec succès du premier coup. N’oublions pas qu’il s’agit de productivité: le but étant de coder rapidement sans créer de régression ni de bug.

    3) La satisfaction du programmeur: avec un code lisible, facile à maintenir et des tests de non-régression; le programmeur peut passer plus de temps à la machine à café. Et c’est vrai. Pour cela, il faut remanier le code et beaucoup de programmeurs préférent bidouiller un truc pour aller plus vite plutôt que de tout ré-écrire correctement (y compris des bouts de code sans rapport direct avec la fonctionnalité). Cette politique a deux inconvénients: déception du programmeur qui doit bidouiller et mauvaise maintenabilité donc perte de temps dans un avenir plus ou moins proche (souvent lors de la recette du produit).

    4) les outils de travail. Combien de programmeurs écrivent ou effectuent les mêmes travaux répétitifs alors qu’ils pourraient écrire un outil (une macro, un script) qui leur simplifierait la vie? Sur presque tous les projets, j’ai du écrire mes propres outils (du plus simple au plus compliqué). Une fois ces outils en place la productivité a également augmenté.

    Enfin, il faut savoir investir: la productivité se paye en investissement. Vous devez investir pour produire mieux: outils, création de tests de automatiques, formation, règles de codage, gestionnaire de sources, etc. Tout cela a un coût qu’il faut savoir payer pour gagner du temps ensuite, un temps précieux. De plus en plus précieux alors que les échéances de mise en production approchent…

  2. William,

    Je vois que nos points de vue se rejoignent :)

    Pour moi les points ‘non-régression’ et ‘qualité logicielle’ vont être matérialisé par la mesure que j’ai proposé : en la mettant en place, on va pouvoir valider cette assertion ‘le code de bonne qualité permet d’être plus productif’, l’intérêt d’une mesure est que cela evite les guerres de chapelle et on peut se baser sur du concret.
    De même, on va pouvoir introduire des outils et mesurer leur efficacité.

    Et n’oublions pas un autre point important : introduire d’autres mesures et ne pas se focaliser sur une une seule. La satisfaction des développeurs est évidemment une mesure très pertinente qu’il faut aussi prendre en compte, tout comme la confiance des programmeurs dans le code produit et bien d’autres, à nous de trouver les plus pertinents pour avoir une vue d’ensemble.

    Merci William pour ces précisions.

    Benoit

  3. Tout à fait d’accord avec cette analyse mais vous oubliez un point crucial qui est la traçabilité de exigences fonctionnelles. Vous pourrez avoir tous les points que vous mentionnez (tests automatisés, remaniement permanent du code, bons outils de travail, etc) et ne pas avoir une bonne productivité parce que votre client vous aura demandé une brouette à deux roues et vous aurez programmé une brouette à une roue… et il faudra recommencé.
    C’est le point le plus dur et le plus fastidieux à mettre en place.