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 :

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