Le problème des indicateurs c'est que lorsqu'on les met en place, on ne cherche plus à satisfaire les clients, mais les indicateurs.
écart temps réalisé, temps estimé ? => on triple tous les temps et on fait la révolution digitale (ie en bon français, se tourner les doigts)
Nombre de ligne de code ? => pas de factorisation et duplication de code
le rapport entre nombre de tickets traités et temps pour élaborer une version multiplication des tickets pour la moindre modif, correction de modif, analyse... on favorise les évolutions courte et simples
le rapport entre nombre de fonctionnalités testées et temps pour exécuter une campagne de test automatique, pareil on favorise certains types d'évols simple a faire/tester
le nombre de versions par an : une version par commit ?
le nombre de commits par mois : multiplication des commits avant test, puis commit de correction, puis commit post relecture, puis commit de correction post relecture, puis commit de merge/rebase parce qu'avec tout ce temps un collègue à pu faire passer son ticket du mois d'avant ;)
le nombre d’œufs de Pâques (easter eggs) dissimulés : perte de temps à développer des trucs inutile.
Bref certains de ces indicateurs peuvent donner une idée, mais à partir du moment où ils deviennent des unités de mesures, ils deviennent un handicap.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Aucun
Posté par fearan . En réponse au sondage Quel indicateur de performance pour le développement de logiciel ?. Évalué à 10.
Le problème des indicateurs c'est que lorsqu'on les met en place, on ne cherche plus à satisfaire les clients, mais les indicateurs.
Bref certains de ces indicateurs peuvent donner une idée, mais à partir du moment où ils deviennent des unités de mesures, ils deviennent un handicap.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent