Nouvelles

May 22, 2023

Pourquoi les développeurs de logiciels préfèrent les métriques DORA

Par Dylan Etkin, InfoWorld | Les technologies émergentes décortiquées par les technologues Depuis des années, les équipes d'ingénierie logicielle recherchent un moyen de mesurer leur efficacité avec des mesures concrètes qui les aident réellement.

Par Dylan Etkin, InfoWorld |

Les technologies émergentes décortiquées par des technologues

Depuis des années, les équipes d'ingénierie logicielle recherchent un moyen de mesurer leur efficacité avec des mesures concrètes qui les aident réellement à s'améliorer, sans que les développeurs se sentent espionnés. Enfin, nous arrivons à quelque chose.

Tout développeur connaît la douleur ou la douleur potentielle d'être mesuré par rapport à des mesures douteuses telles que des lignes de code écrites ou le nombre de demandes d'extraction fusionnées pour lesquelles notre industrie est historiquement connue. Et tout responsable de l’ingénierie connaît les réactions négatives et la méfiance que de telles mesures peuvent susciter au sein de son équipe.

Mais lorsque les conseils d'administration, les responsables de l'ingénierie et les développeurs veulent tous savoir si un processus fonctionne, si l'équipe est efficace et comment s'améliorer, nous avons besoin d'un moyen de mesurer le travail effectué.

Plusieurs ensembles de mesures, de cadres et de meilleures pratiques ont vu le jour pour y parvenir. Inévitablement, certains le font mieux que d’autres. Le Saint Graal consiste à mesurer le travail avec les outils et les systèmes avec lesquels les développeurs travaillent déjà quotidiennement. Les métriques DORA peuvent le faire, et c'est en partie pourquoi elles deviennent la norme de l'industrie.

Nous y reviendrons davantage, mais commençons par comprendre les autres types de mesures disponibles.

Les mesures d'activité peuvent être considérées comme mesurant le temps de flux dont dispose un développeur. Si votre flux est interrompu deux ou trois fois par jour, vous savez qu’il est presque impossible de faire avancer les choses.

Dans le but de gagner du temps pour les développeurs, toute une catégorie d'outils d'efficacité technique ont été développés et se connectent aux systèmes et calendriers RH. Ils essaient d'évaluer si un développeur a trop de changements de contexte, de réunions et de processus chronophages à suivre.

En fin de compte, ces métriques tentent de prévenir l'épuisement professionnel en examinant le côté humain du codage, ce qui est certes important, mais ces métriques ne sont pas très exploitables.

Si vous savez que les développeurs participent à trop de réunions, comment structurer un environnement où les réunions nécessaires ont lieu mais où le flux est également plus efficace ? Les mesures d'activité ne sont pas accompagnées d'un ensemble d'améliorations potentielles pour vous guider.

Nicole Forsgren, l'une des fondatrices de DORA (DevOps Research Assessment), a développé ce framework, qui vise à comprendre la productivité des développeurs. Mais plutôt que des mesures concrètes, le cadre SPACE se concentre sur l'état d'esprit et le bien-être physique des développeurs, qui sont sans aucun doute des facteurs importants dans le plaisir global des développeurs à l'égard de leur travail et dans les performances techniques d'une équipe.

Le cadre SPACE évalue cinq dimensions de la productivité des développeurs :

À l'instar des métriques Busyness, le framework SPACE capture des informations valides, mais il est difficile d'agir dessus. Considérez-le principalement comme des meilleures pratiques difficiles à mesurer à partir du travail effectué. Il manque de concision et de résultats axés sur les objectifs.

Il s'agit de mesures difficiles, faciles à mettre en œuvre et qui ne capturent pas les efforts réels des développeurs : des éléments tels que les lignes de code écrites, le nombre de demandes d'extraction fusionnées, le nombre d'heures passées à coder. Ces mesures sont issues de l'époque de la programmation par cartes perforées, où le développeur qui accomplissait la tâche avec le moins d'instructions était le leader.

Mais les développeurs savent qu’ils ne mesurent rien d’important. Je peux écrire les cinq lignes de code les plus importantes de l'application qui sont si complexes qu'il me faudrait deux semaines pour m'assurer qu'il s'agit des cinq bonnes lignes de code. Ou bien, je pourrais écrire cinq millions de lignes de code qui ne sont pas très utiles. C'est la même chose pour mesurer le nombre de demandes d'extraction fusionnées. Cela peut vous en dire un peu plus sur la taille globale de votre lot, mais ce n'est pas incroyablement instructif ni utile pour aider une équipe à s'améliorer.

Si vous jugez les développeurs par rapport à ces mesures, ils sauront que vous ne les comprenez pas, ni leur travail. De plus, mesurer ces choses à une échelle individuelle est toxique. Les développeurs se sentiront espionnés et jugés, et ils s’entêteront.