[Lecture] Measu­ring the Health of Your Deve­lop­ment Team

Extrait de The Mana­ger’s Path

Frequency of Releases

Je trouve toujours ça très dur de mesu­rer la santé des équipes de déve­lop­pe­ment avec des indi­ca­teurs chif­frés. Il y a bien plus de moyen de mal inter­pré­ter et mal utili­ser ces indi­ca­teurs que de manière de bien le faire.

Je ne suis pas en train de promou­voir l’ab­sence de chiffre, mais mon indi­ca­teur premier reste le juge­ment subjec­tif du mana­ger qui travaille avec l’équipe. L’in­di­ca­teur n’est là qu’é­ven­tuel­le­ment pour l’aler­ter si jamais il n’a pas vu quelque chose.

La fréquence de déploie­ment me semble un bon indi­ca­teur à mesu­rer, car proche de l’uti­li­sa­teur final. Il reste que parfois ça peut augmen­ter et être mauvais signe (plein de correc­tifs) ou dimi­nuer et être bon signe.

Dans tous les cas, je propose de ne jamais lier ces indi­ca­teurs à un système de récom­pense ou d’éva­lua­tion. C’est le meilleur moyen de se retrou­ver à faire un effet cobra. De manière géné­rale, la fixa­tion d’objec­tifs par les indi­ca­teurs me parait assez nocive, parti­cu­liè­re­ment dans les métiers de réflexion.

Une façon de faire ça, c’est déjà de ne faire que des mesures collec­tives, pas de mesures indi­vi­duelles.

Frequency of Code Check-ins

J’ai plus de mal à voir cette mesure là. Si l’idée est d’être en déploie­ment continu, sur des chan­ge­ments les plus petits possibles, un déploie­ment et un check-in c’est quasi­ment la même chose.

Frequency of Inci­dents

Mesu­rer les inci­dents parait une évidence mais j’ai un nombre absolu bien trop faible pour en tirer quoi que ce soit. Si j’ai trois inci­dents cette semaine, est-ce un coup de pas de chance ? que j’ai plus d’in­gé­nieurs sur le pont ? qu’on a livré des choses majeures derniè­re­ment ? qu’ils s’at­tachent aux sujets de fond plutôt qu’à des travaux simples en surface ?

Ça se mesure, mais ça se décompte sur plusieurs mois donc ça n’est pas super utile pour réagir si la perfor­mance s’ef­fondre.