Discussion :

[pmithrandir]

Bonjour,

Il y a 3 semaines un mois, mon chef m'a posé une colle.
Il veut que je lui fournisse une liste de données de références qui nous permettrait de tracer l'activité de development et d'identifier d'éventuels problèmes.

Étant moi même développeur, j'avoue que j'ai un respect limité pour les comptages bête et méchant de bug, de ticket ré ouvert, etc...(surtout, je n'aime pas les circuits parallèle que cela créé) Mais d'un autre coté, je n'ai pas grand chose d'autre à lui proposer...

Est-ce que vous auriez des idées qui pourrait m'aider à estimer honnêtement le travail de mon équipe et à détecter d'éventuels problèmes.
La période estimée est de 1 mois et l'équipe de 10 personnes. Je ne veux pas aller plus dans le détail.(j'ai d'autres moyens de les évaluer individuellement)

Voici mes premières idées :
Nombre de ligne de code affectée : J'entends par la ajoutée ou supprimée. Au premier abord, je trouvais ça pas top, mais si on ajoute les valeurs entière uniquement, ça démontre tout de même un minimum si les gens touchent au code ou pas.
Proportion de travail bug / nouvelle fonctionnalités : En essayant bien sur de diminuer ce nombre autant que possible, ce qui aurait tendance a montrer sur le long terme que la qualité était au rdv.
Résultat jenkins - proportion de build échoué dans le mois : Pour voir ce que les dev livre
Résultat jenkins - proportion de commit non associé a un build : Pour augmenter le nombre des projets suivi par jenkins
Jenkins - les habituels PMD - test coverage - checkstyle : l'idée étant de voir si les proportions augmentent ou pas.

Après, je ne vois pas trop quoi d'autre je pourrai évaluer mathématiquement.

Si vous avez des idées, ou des liens, je suis preneur.

Merci,
Pierre

[gangsoleil]

Bonjour,

C'est toujours delicat d'evaluer une equipe, sans tomber dans les travers courants que sont la somme des evaluations individuelles ou l'evaluation du chef.

[Edit]
Bon, j'ai relu, et il s'agit de tracer l'activite de developpement.

Donc effectivement, tout ce qui est taux de couverture de code (qui ne doit qu'augmenter) ainsi que tests automatiques est un bon debut.

Le taux de bug est toujours delicat a manipuler : un ratio bug / nombre de lignes de code, c'est bien, mais il ne faut surtout pas comparer des choses strictement identiques : un code C et un code C++ n'ont pas la meme verbosite, et donc le rapport sera forcement different.

Tu peux mesurer, toujours sans comparaison externe, le taux de commentaires, ou bien la quantite de doc produite.

Bref, pleins de pistes, qui sont presques toutes autant de batons pour se faire battre que de bons indicateurs...

[pmithrandir]

Bonjour,

Le taux de bug, je n'aime pas trop, comme je disais, a chaque fois ca finit par des équipe de test qui contacte directement l'équipe de dev pour limiter les tickets créés...(voir qui ne le font que pour leur potes).

Et, selon les mois, si on est en période de test ou pas, ca va varier sans que je puisse vraiment y faire quoi que ce soit.


En fait, le but est vraiment d'avoir une référence en nombres de l'activiét, pour voir si un des paramètres se casse la figure sans que l'on puisse l'expliquer.
Une sorte d'alerte a vant que ca ne dérape fortement...

Si d'autres perssonnes ont des sugggestions, je suis preneur... Par exemple, comment des developpeurs trouvarait juste d'être évalué.

Pierre

[LooserBoy]

Bonjour,

En ce qui concerne mon équipe, nous inscrivons nos temps passés sur chaque projet sur un outil comme PSNext.
Ca nous permet de savoir si on "glisse" sur les plannings et permet aussi de voir si on sur-facture ou sous-facture.

Est-ce que vous avez un système du genre?

[pmithrandir]

Bonjour

On suis la consommation, mais on a moins de projets, donc c'est en général par journée qu'on le fait.

Il n y a vraiment pas d'autres moyens dans tous les dévelopeurs de ce forum qui sont mis en place par leur chef, ou pour leur équipe ?

[Lung]

TFS sert pas à ça ?
(personnellement, je ne connais pas)

[el_slapper]

la productivité est difficille à mesurer.

Autre problème, toute mesure finit par être utilisée pour juger les gens, et toute mesure qui sert à juger les gens influe sur leur travail. Et pas en bien.

Many studies have shown that extrinsic rewards like grades and pay will, over time, destroy the intrinsic reward that comes from the work itself.

La seule métrique qui me parait utile, c'est la couverture de code(même si idéalement, il faudrait aussi mesurer la couverture des exigences). Parceque ça permet directement d'identifier là ou on peut améliorer le bousin. Tout le reste, c'est un bon moyen de taper sur les gens - et donc de les démotiver, voire, pire, de les voir tordre leur travail pour qu'il entre dans les cases plutôt que de le faire bien...

EDIT : un autre qui me plait bien :

If you give a manager a target, he will meet it, even if he has to destroy the organization to do so.

[pmithrandir]

Merci,

Pour TSF, si on parle de Team Foundation Server, je crois que ca ne m'apportera pas de réponses suffisantes.

Pour rebondir sur ton propos el slapper, mon but est bien d'avoir des outils d'alertes qui m'aident à me poser de questions, plutôt que des outils pour juger. Surtout individuellement, je ne vois pas l’intérêt, puisque comme tu dis, les gens vont faire tout pour rentrer dans les cases, au risque de négliger les choses importantes.

Je ne suis même pas sur que ca serra des données publiques, ou juste pour moi et mon responsable pour décider ensemble des choses à mettre en place pour l'équipe.

[Barsy]

Une technique qui marche pas trop mal, c'est le test croisé. C'est à dire qu'à chaque fois qu'un développeur "commite" une fonctionnalité, c'est un autre développeur de l'équipe qui doit la tester.
Ça permet de détecter plus de bugs en interne et en plus de partager les connaissances entre chaque développeurs, plutôt que d'avoir chacun qui développe sur sa partie dans son coin.

[pmithrandir]

Merci,

on a déjà ce genre de pratique en place.

Mais le but de mon post est plus de trouver des outils de suivi de qualité ou des barèmes justes et fiables que d'améliorer cette qualité. Le second point est déjà en place...

Là, on veut surtout savoir ce qu'il se passe, on est pas encore dans l'action.

[Katyucha]

Je rajouterai le temps de correction des bugs.
Un bug, ca peut arriver... On n'est jamais à l'abri, par contre, il ne faut pas que ca traine !

[rimram31]

...Étant moi même développeur, j'avoue que j'ai un respect limité pour les comptages bête et méchant de bug...

Tu peux le voir (et le présenter) comme un moyen efficace d'améliorer la qualité afin d'en tirer expérience et identifier quelques pistes pour mieux les éviter par la suite Mais ça demande un travail d'analyse important pour essayer d'être le plus objectif possible.

Pour les anomalies, il faut un minimum de rigueur dans la gestion des tickets: un seul ticket par incident, pas de "bla bla" et dérives associées qui rebondissentt sur d'autres anomalies, gestion des "root cause", tickets liés ... criticité, tickets invalides ... et un coût de résolution en temps passé. Le plus difficile ensuite c'est de faire le suivi, ça demande un travail périodique ainsi que des réunions, ça permet aussi de gérer tout ça "en équipe". Avec des gens censés, il ne peut qu'être bénéfique de prendre conscience des conséquences de son travail sur celui des autres.

J'ai aussi par le passé, généralisé les "tickets" a l'ensemble des activités, pas uniquement la production de code, ça permet avec les mêmes outils de suivre tous les process (démarche de type ITIL) mais c'est pas toujours facile a faire accepter, ça peut se faire par étapes et se poursuivre si l'équipe y trouve du sens pour elle-même. Tu peux comme ça aussi tracer les livraisons, la documentation ... et procéder comme tu le ferais pour une "anomalie" de code en généralisant a l'activité.

J'ai par contre toujours été attentif (une règle personnelle) a ne jamais individualiser les résultats hors de l'équipe, quitte a en "couvrir" certains. La seule information qui doit être communiquée en dehors, c'est la "performance" de l'équipe.

Il faut enfin ne jamais négliger les réunions de clôture de projet (ou jalon important) sans lesquelles tout ce travail n'a aucun intérêt car cela n'a de sens que pour capitaliser sur sa façon de travailler et d'analyser pourquoi on a réussi/raté parfois pour s'en servir pour la suite. Il n'est alors pas question d'analyser seulement le négatif mais aussi le positif (ce qui a marché!) et il faut savoir aussi affronter ses propres erreurs (en tant que manager!).