Productivité et développement informatique

Régulièrement, j’entends dire qu'il faut améliorer la productivité des informaticiens mais pouvons-nous parler de productivité pour le développement de logiciels ?
Pour pouvoir répondre à cette question, il est nécessaire de définir les notions de productivité et de développement logiciel.

La productivité du travail est un ratio calculé sur le nombre de réalisations produites par rapport au nombre d'unités de temps effectués pour ces réalisations.

Pour le développement logiciel, nous pourrions avoir :
  • le nombre de lignes de code développées en une heure
  • le nombre de fonctions développées en une journée
  • etc

Ces ratios peuvent en effet être intéressants mais ils restent assez limités car ils ne prennent pas en compte la notion de qualité ni celle de la valeur. Nous pouvons voir la valeur sous différents aspects comme la valeur de l'unité de temps (exemple extrême : coût d'un développeur en Inde par rapport un développeur à Paris) ou la valeur des fonctions développées pour l'utilisateur.

De plus, le développement ne se résume pas à écrire des lignes de codes. Un développeur devra réfléchir un minimum en termes de réutilisation, d'optimisation et de robustesse pour réaliser la fonction qui lui est demandé. Il devra également documenter son code (quelle est la norme?) et faire quelques tests pour s'assurer du bon fonctionnement de son code.

Si nous réfléchissons à ces tâches, nous pouvons constater que nous ne sommes pas dans un environnement vraiment adapté pour mesurer la productivité. Le développement logiciel est plus proche de l'artisanat que de la production de masse où la division du travail et la spécialisation sont reines.

C'est pour ces raisons que je préfère parler d'efficacité que de productivité pour l'informatique. Les éléments de mesure pour contrôler l'efficacité du développement sont la qualité, le coût et le délai.
Si l’objectif d’augmenter la productivité est d’améliorer les délais, je pense que pour le développement, il faut s’orienter vers d’autres voies.
Pour améliorer les délais de développement (et non la productivité), il existe quelques pistes :
  • éviter le multitâche : même si la génération Y (salariés nés entre 1982 et 2001) excelle dans ce domaine, le multitâche est une source de temps gaspillé. Le fait de passer d'un dossier à l'autre est une perte de temps. A chaque changement, il faut se remettre en mémoire où nous en étions.
  • éviter de multiplier les interactions entre les individus. Plus il y aura d'interactions entre les développeurs, plus il y aura de pertes de temps et d'incompréhensions. Les développeurs doivent être responsables de bout en bout de leurs développements.

    Ou utiliser les principes de la chaîne critique (voir : Comment respecter les délais sur un projet ?)

Et vous, quelles sont vos méthodes ?

"Le travail est si bien divisé que l'un travaille et que l'autre récolte." Lanza Del Vasto

2 commentaires:

Franck a dit…

Le problème posé par ta méthode est le partage de la connaissance du code. En effet, ta méthode nécessite d'avoir une forme de développement uniformisé. Or chacun sait que chaque développeur a sa propre méthode.

Nous savons aussi que la productivité augmente au fil du temps sur un projet donné. La mesure doit donc tenir compte de cela.

Ensuite, tu parles d'analyse, développement et test sans parler de documentation qui a elle-même un cout.

Je pratique le TDD depuis quelques années et cette manière de travailler permet non seulement d'uniformiser les formes de développement : l'équipe tend à développer de la même manière. Elle permet aussi de tester les applications en écrivant les tests avant le codage. De plus si les test sont bien écrits, ils peuvent permettre de documenter le code.

Enfin, l'interactivité est un échange qui peut parfois amener à de meilleures solutions techniques. Il ne faut pas voir le développeur comme un ouvrier des temps modernes, il ne doit pas produire du code à la chaine.

Fabrice Thomas a dit…

Le Test Driven Development (ou le Développement Dirigé par les Tests) est en effet une méthode intéressante pour améliorer la qualité du code et le coût (remplacement des spec par les tests) sur un projet.
Je suis également d'accord avec toi pour dire qu'au fil du temps, l'efficacité (pas la productivité) des développeurs augmente.

Je ne vois pas les développeurs comme des ouvriers des temps modernes mais comme des artisans.

Merci Franck pour ton commentaire

Une erreur est survenue dans ce gadget