Effectivement, et je ne cmprends pas qu'on se base encore sur ce genre de méthodologie aujourd'hui pour estimer la productiité des ingénieurs logiciels.
Pour l'avoir déjà vu ailleurs (des journalistes qui extrapolent des études au point de leur faire dire autre chose que ce qu'elles souhaitent communiquer), je ne suis pas sûr que la description de l'article corresponde à la réalité de l'étude. Ils disent d'ailleurs
Traditional metrics, such as LOC, story points, and function points, have been shown to incentivize practices that may not align with high-quality software development, such as prioritizing code quantity over quality or ignoring the true complexity of the development process [12] [13].
Après, franchement 10% ce n'est pas beaucoup; que 10% des salariés d'une grande boîte (ingés ou pas) ne soient pas productifs je ne trouve pas ça choquant. Si on écoute Pareto, il y en aurait même 20% qui ne produisent rien de concret (pas qu'ils ne font rien, mais que leur travail n'est pas productif).
Il y a aussi des gens avec profil d'ingénieur qui ne "produisent" rien ou peu de choses mesurable, mais qui sont plutôt des "facilitateurs" qui vont aider les autres à produire dans une équipe. Je ne sais pas combien il y en a dans les 10% en question, mais je pense que ce n'est pas négligeable.
mais qui sont plutôt des "facilitateurs" qui vont aider les autres à produire dans une équipe.
Mais donc ça sera mesurable. Dans le sens où si cette personne n'est plus là, l'équipe va livrer plus tard, moins propre. Enfin le moins propre ça peut n'être un problème le jour où il va falloir faire évoluer le code.
Après, il s’agit d’une tendance moderne (la merdification bureaucratique) : on rajoute des couche (avec les micro-managers qui vont bien) et on défini des métriques numériques (puisque les nombres c’est mathématique) …qui deviennent des objectifs à atteindre ;(
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
C’est très clair : Il(s) mesure(nt) les commits mais il(s) ne mesurent pas les commits…
Dans un thread sur X.com, il explique disposer de données sur les performances de plus de 50 000 ingénieurs dans des centaines d'entreprises ayant accepté de partager leurs dépôts Git privés avec son équipe, […]
Quoi qu’il en soit, son équipe travaille sur un modèle qui quantifie la productivité en analysant le code source de dépôts Git, et en simulant un panel de 10 experts évaluant chaque livraison à travers de multiples dimensions.
[…]
Il précise aussi que les commits ne leur servent pas de mesure de la productivité, et renvoie à un article de recherche publié en septembre dernier détaillant leur méthodologie, en vue de « Prédire les évaluations des experts dans les revues de code logiciel ».
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
C'est normal, c'est du trop haut niveau pour des gens "ordinaires". Il faut faire partie de l'élite pour comprendre (et aparamment je n'en fais pas partie non plus ).
TL;DR dans la vie, il y a deux catégories de personnes, celles qui font des comités et celles qui dont des commits. L'une se plaint que l'autre en fait trop, l'autre que les premiers n'en font pas assez. Et chacune des deux catégories se commitent pour faire plus de ce qu'elle fait le mieux. Simple, basique.
Il y a le bon commit et le mauvais commit. Le bon commit est commité au commit, alors que le mauvais, il est commit à commiter mais … c'est un mauvais commit. Commité. Je sais plus.
On peut commiter mille fois un commit, mais on ne peut pas commit… Si, on peut commiter une fois une… Euh… Non, on ne peut pas commiter mille fois un commit mais on peut commiter une fois mille commit !
C'est embêtant ça, un ingénieur qui qui ne passe pas son temps à saisir du code, mais qui fait, peut être, de la relecture de code de ces collègues, de la documentation/spécification, de l'analyse du besoin, du débogage, de la gestion d'équipe, c'est forcement un mauvais ingénieur logiciel.
# Ça ne fait aucun doute ! (je sors)
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 7 (+4/-0).
Apparemment la méthodologie est curieuse et est de même nature que le "publish ou perish" en recherche scientifique.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par totof2000 . Évalué à 3 (+1/-0).
Effectivement, et je ne cmprends pas qu'on se base encore sur ce genre de méthodologie aujourd'hui pour estimer la productiité des ingénieurs logiciels.
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par Faya . Évalué à 3 (+1/-0).
Pour l'avoir déjà vu ailleurs (des journalistes qui extrapolent des études au point de leur faire dire autre chose que ce qu'elles souhaitent communiquer), je ne suis pas sûr que la description de l'article corresponde à la réalité de l'étude. Ils disent d'ailleurs
Après, franchement 10% ce n'est pas beaucoup; que 10% des salariés d'une grande boîte (ingés ou pas) ne soient pas productifs je ne trouve pas ça choquant. Si on écoute Pareto, il y en aurait même 20% qui ne produisent rien de concret (pas qu'ils ne font rien, mais que leur travail n'est pas productif).
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par totof2000 . Évalué à 3 (+1/-0).
Il y a aussi des gens avec profil d'ingénieur qui ne "produisent" rien ou peu de choses mesurable, mais qui sont plutôt des "facilitateurs" qui vont aider les autres à produire dans une équipe. Je ne sais pas combien il y en a dans les 10% en question, mais je pense que ce n'est pas négligeable.
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par Faya . Évalué à 2 (+0/-0).
Mais donc ça sera mesurable. Dans le sens où si cette personne n'est plus là, l'équipe va livrer plus tard, moins propre. Enfin le moins propre ça peut n'être un problème le jour où il va falloir faire évoluer le code.
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par totof2000 . Évalué à 3 (+1/-0).
Comment le mesurer concretement, autre qu'à postériori, par l'absence de la personne en question ?
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
C'est tout le problème de ce genre de choses et cette volonté de tout mesurer sur des critères "objectifs" parce que ce sont des chiffres.
Par exemple, on pourrait définir le terme "productif" et, probablement, ne pas le réduire forcément à l'individu.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Après, il s’agit d’une tendance moderne (la merdification bureaucratique) : on rajoute des couche (avec les micro-managers qui vont bien) et on défini des métriques numériques (puisque les nombres c’est mathématique) …qui deviennent des objectifs à atteindre ;(
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
La/le facilitatrice/facilitateur est, selon ce genre de métriques, le/la pire (i.e. moins productive/productif quand on mesure les commits ou lignes écrites)
https://linuxfr.org/users/gilcot/liens/the-worst-programmer-i-know
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5 (+4/-1).
C’est très clair : Il(s) mesure(nt) les commits mais il(s) ne mesurent pas les commits…
[…]
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 8 (+5/-0).
J'ai rien compris :-)
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par totof2000 . Évalué à 5 (+3/-0).
C'est normal, c'est du trop haut niveau pour des gens "ordinaires". Il faut faire partie de l'élite pour comprendre (et aparamment je n'en fais pas partie non plus ).
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par Benoît Sibaud (site web personnel) . Évalué à 9 (+6/-0).
TL;DR dans la vie, il y a deux catégories de personnes, celles qui font des comités et celles qui dont des commits. L'une se plaint que l'autre en fait trop, l'autre que les premiers n'en font pas assez. Et chacune des deux catégories se commitent pour faire plus de ce qu'elle fait le mieux. Simple, basique.
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par Thomas Douillard . Évalué à 7 (+5/-1).
Il y a le bon commit et le mauvais commit. Le bon commit est commité au commit, alors que le mauvais, il est commit à commiter mais … c'est un mauvais commit. Commité. Je sais plus.
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par Lutin . Évalué à 4 (+2/-0).
On peut commiter mille fois un commit, mais on ne peut pas commit… Si, on peut commiter une fois une… Euh… Non, on ne peut pas commiter mille fois un commit mais on peut commiter une fois mille commit !
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par cg . Évalué à 6 (+4/-0).
Le commit de répétition permet-il de faire croire qu'on commit alors qu'on rebase ?
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+2/-0).
Au jeu des diff, blame le dév qui commite vers l'Allemagne. Je reste bissecté sur la question.
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par YBoy360 (site web personnel) . Évalué à 5 (+3/-0).
Il y a les concomitant aussi, une 5ème catégorie.
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par totof2000 . Évalué à 2 (+0/-0).
ce sont ceux qui ne croient qu'au mythe du nombre de commits pour mesurer leur productivité ?
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par totof2000 . Évalué à 2 (+0/-0).
j'aurais plutôt dit "C'est pas faux !!!"
# Il n'y a pas que le code dans la vie
Posté par vitanix . Évalué à 6 (+5/-0).
C'est embêtant ça, un ingénieur qui qui ne passe pas son temps à saisir du code, mais qui fait, peut être, de la relecture de code de ces collègues, de la documentation/spécification, de l'analyse du besoin, du débogage, de la gestion d'équipe, c'est forcement un mauvais ingénieur logiciel.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.