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:
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.
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
Enregistrer un commentaire