Temps de travail des programmeurs et score de qualité des logiciels. Totalement décorrélé !
En fait, les feuilles de temps sont pire que nulles :
* ils démotivent les développeurs
* 10-15% la perte de productivité est le minimum
* les développeurs doivent prendre le temps de les remplir correctement
* des données erronées sont utilisées pour l'établissement des rapports et la direction prend de mauvaises décisions
* les clients sont trompés
* ils n'ont rien à voir avec la production de codes de qualité
* ils concentrent l'ensemble de l'organisation sur des données fictives plutôt que sur la production
Néanmoins, cela ne suffit pas à de nombreux managers pour abandonner les feuilles de temps. Tout comme pour le processus de la cascade, il existe une dépendance psychologique si forte que l'on a l'impression qu'ils sont drogués.
Cependant, la situation est encore pire. La plupart des cadres ont en tête des informations totalement erronées et prennent donc continuellement de mauvaises décisions. L'un de mes étudiants m'a récemment dit : "Vous voulez dire que tout ce que mon directeur m'a dit est faux !".
Oui, José, tout ce que ton manager t'a dit est faux :
* il n'y a pas de corrélation entre le temps passé par les développeurs et la production de logiciels
* il n'y a pas de corrélation entre le temps passé et la qualité du code
* il n'y a pas de relation entre les "personnes de qualité" et la production de code
La seule corrélation entre le temps du développeur et la qualité du code de production est la qualité des points de récit mesurés en tant que produit livrable pour une équipe spécifique.
Des recherches menées depuis de nombreuses années à l'université de Yale fournissent certaines des meilleures données sur ce sujet. Joel sur les logiciels:
* Pour un projet unique, les temps de codage les plus courts et les plus longs sont de 1/10.
* dans de nombreux projets, les meilleurs et les pires temps de codage sont de 1/25
* les ratios ci-dessus sont les mêmes pour les meilleurs et les pires étudiants de Yale
* la qualité du code produit est totalement indépendante du temps passé
Pour une raison ou pour une autre, de nombreux responsables du développement prennent des décisions sans disposer de la moindre donnée sur cette question et leurs hypothèses sont complètement décalées par rapport à la réalité.
Tom Poppendieck m'a raconté récemment qu'un manager compétent avait fait des recherches sur ses équipes XP pour déterminer quel nombre d'heures par semaine produisait le maximum de code de production de qualité. Après avoir essayé des semaines plus courtes et des semaines d'heures supplémentaires, le meilleur nombre d'heures pour que les équipes produisent le plus de code de qualité était une semaine de travail de 16 heures !
Croyez-moi, vous devez vous débarrasser de ces feuilles de temps boiteuses et vous concentrer sur la production de logiciels réels avant qu'un concurrent Agile ne vous mette sur la paille !