Même si les compétences pratiques et la connaissance de langages de programmation, d'outils et de technologies spécifiques sont la clé pour décrocher un emploi à temps plein en tant que développeur de logiciels, il existe un autre indicateur précieux qui, à bien des égards, peut être considéré comme un présupposé pour réussir dans cette profession : productivité. La mesure de la productivité est quelque chose que tous les développeurs de logiciels professionnels doivent comprendre et prendre en compte, car les mesures de performance sont intrinsèquement importantes pour toute équipe de développement de logiciels dans l'environnement commercial actuel.
Pourquoi votre productivité en tant que développeur est-elle importante ?
À l'ère du développement Agile, du DevOps et de la réduction des cycles de publication des logiciels, lorsque les développeurs doivent livrer de nouvelles versions de produits le plus rapidement possible, les entreprises utilisent plusieurs mesures de productivité différentes pour évaluer les performances des programmeurs individuels et d'une équipe dans son ensemble. En regardant cela du point de vue d'un développeur, la mesure des performances peut servir un certain nombre d'objectifs précieux, vous aidant à suivre les progrès de vos compétences en programmation, ce qui vous permettrait d'atteindre une croissance professionnelle constante. Les codeurs très productifs sont ceux qui finissent par recevoir des offres salariales à couper le souffle et se mettent au travail sur les projets les plus excitants. Mais même si vous n'êtes pas vraiment très performant et que vous voulez juste n'importe quel travail dans le développement de logiciels et y réussir raisonnablement, vous devez toujours avoir au moins une compréhension de base des indicateurs de performance et de la manière dont ils sont utilisés pour mesurer la productivité de votre contribution au travail. C'est ce dont nous allons parler aujourd'hui.
Métriques de mesure de la productivité du développement logiciel
Que sont les indicateurs de productivité du développement logiciel ?
Les métriques de développement logiciel sont les domaines du travail de programmation où des mesures quantitatives peuvent être appliquées afin de suivre les performances, la qualité du travail et la productivité d'un développeur. Chaque métrique de productivité est basée sur la prise de données du processus de développement et son utilisation pour mesurer la productivité. Comme à peu près rien en ce qui concerne le développement de logiciels n'est simple et direct, on peut dire que la mesure de la productivité de la programmation est également assez incohérente et fragmentée dans l'industrie. Ou, tout simplement, différentes équipes et entreprises peuvent utiliser des indicateurs de performance complètement différents et aborder cette question sous plusieurs angles. Vous n'avez donc pas besoin de vous soucier d'apprendre chaque métrique pouvant être utilisée par les équipes de développement de logiciels.
Quels types de mesures de productivité du développement logiciel existe-t-il ?
Naturellement, il existe plusieurs mesures de productivité différentes qui abordent la mesure des performances à différents niveaux et angles. Voici les types les plus courants de ces mesures de productivité :
Métriques formelles axées sur la taille.
Ces métriques sont axées sur la mesure de la taille du résultat du travail d'un programmeur, telles que les lignes de code (LOC), la longueur des instructions de code, la complexité du code, etc. Ces métriques sont de plus en plus considérées comme obsolètes dans l'industrie du développement de logiciels d'aujourd'hui.
Mesures de productivité axées sur le temps et la fonction.
Il existe une sélection de mesures de productivité traditionnelles utilisées dans le développement de logiciels en cascade, telles que les jours actifs, l'étendue des fonctionnalités livrées dans une période de temps définie, les taux de désabonnement du code, le nombre de tâches assignées, etc.
Métriques du processus de développement agile.
Les métriques de processus de développement agile, telles que le rapport d'avancement de sprint, la vélocité, le délai d'exécution, le temps de cycle et autres, sont probablement les métriques les plus couramment utilisées par les équipes de développement de logiciels aujourd'hui. Nous parlerons des métriques Agiles plus en détail plus loin dans l'article.
Métriques d'analyse opérationnelle.
Cet ensemble de mesures est axé sur la mesure des performances du logiciel dans son environnement de production actuel. Le temps moyen entre les pannes (MTBF), le temps moyen de récupération (MTTR) et le taux de plantage des applications sont les mesures les plus utilisées ici.
Mesures de test.
Les tests de logiciels ont leur propre ensemble de mesures pour mesurer la qualité des tests du système, tels que le pourcentage de tests automatisés, la couverture du code, etc.
Indicateurs de satisfaction client.
Enfin, la métrique ultime pour tout logiciel est l'expérience client final, et il existe également tout un ensemble de métriques pour cela, telles que le score d'effort client (CES), le score de satisfaction client (CSAT), le score net du promoteur (NPS) et d'autres.
Métriques de développement de logiciels agiles
Comme vous pouvez le voir, il est assez facile de se perdre dans toutes les subtilités des métriques de productivité logicielle. Cependant, les seuls qu'un développeur de logiciels régulier devrait bien connaître sont les métriques Agiles, couramment utilisées par les équipes de développement de logiciels aujourd'hui comme normes de mesure de la productivité des équipes à travers les différentes parties du cycle de vie du développement de logiciels. Listons les métriques Agiles principales et les plus couramment utilisées.
1. Burndown de sprint.
Les rapports Sprint Burndown sont l'une des mesures clés pour les équipes de développement Agile Scrum. Comme dans Agile, le processus de développement est organisé en sprints limités dans le temps, Sprint Burndown est utilisé comme moyen de suivre l'achèvement des tâches pendant un sprint. Les heures ou les story points sont utilisés comme unité de mesure. L'objectif est de réaliser des progrès constants et de livrer un travail conforme aux prévisions initiales. Sprint Burndown aide les équipes à mesurer le rythme de travail et à l'ajuster si nécessaire.
2. Vélocité de l'équipe.
La vélocité est un autre indicateur clé, qui est également basé sur les heures ou les points d'histoire comme unité de mesure. Il mesure la quantité moyenne de travail qu'une équipe accomplit au cours d'un sprint et est utilisé pour l'estimation et la planification tout au long du projet. Le suivi de la vitesse est important pour s'assurer que l'équipe offre des performances constantes.
3. Points d'histoire.
Au niveau d'un membre individuel de l'équipe de développement, les points d'histoire sont une mesure précieuse, car la taille des histoires qu'un programmeur livre à chaque version est un indicateur de la productivité de ce codeur.
4. Tableau de contrôle du cycle.
Mesure le temps total à partir du moment où le travail sur une tâche ou un autre élément du backlog a commencé jusqu'à son achèvement. Permet de suivre et de contrôler les temps de cycle pour des résultats plus prévisibles.
5. Débit et valeur fournie.
Les chefs de projet analysent les tâches assignées aux développeurs et leur attribuent une valeur. Cette métrique est ensuite utilisée pour mesurer le débit de l'équipe ou, en d'autres termes, la quantité de travail à valeur ajoutée effectué.
6. Barattage de code.
L'attrition du code est une autre mesure qui mérite d'être mentionnée car elle est utilisée pour mesurer à la fois la productivité d'une équipe dans son ensemble et pour suivre les performances des programmeurs individuels. L'attrition du code mesure la fréquence à laquelle un développeur supprime ou modifie des lignes de code précédemment ajoutées, et quel pourcentage de code précédemment écrit finit par être modifié ou jeté.
Avis d'experts
Enfin, pour ajouter une certaine perspective, quelques citations sur le sujet par des professionnels expérimentés de l'industrie du développement de logiciels. "J'espère que vous ne cherchez pas à "comparer" vos mesures avec une sorte de norme ou même avec les performances d'une autre équipe dans une autre entreprise. Partout où j'ai travaillé, il y a eu des variations uniques dans leurs définitions des points d'histoire, de la vélocité, des estimations horaires, des tâches, etc. qui rendraient vraiment presque impossible de comparer les performances d'une équipe d'une entreprise directement avec celles d'une autre équipe d'une autre société », a déclaré Cliff Gilley, ancien responsable technique des produits et coach agile.. « Je me méfie un peu des mesures lorsqu'il s'agit de guider la performance de l'équipe. Une fois que vous faites attention à seulement une ou deux variables, il devient très facile de tomber dans le jeu (intentionnellement ou non) de la métrique et de vous faire croire que vous vous améliorez - alors que tout ce que vous faites est d'améliorer la métrique. Par exemple, les métriques basées sur la vitesse peuvent "s'améliorer" si l'équipe passe à des histoires plus petites (moins de travail par histoire - donc plus d'histoires terminées - donc la vitesse augmente). Cela peut être une bonne chose si les histoires sont des histoires d'utilisateurs utiles qui offrent de plus petits incréments de valeur commerciale. Cela pourrait être une mauvaise chose si les histoires deviennent des tâches plus petites et plus "techniques" qui n'apportent pas de valeur réelle par elles-mêmes », a déclaré Adrian Howard, un autre professionnel de l'industrie.. « Lorsque je travaille dans un système basé sur l'extraction, j'accorde de l'importance au débit et au temps de cycle. Le premier me donne des informations générales sur la capacité de notre équipe et, avec le temps, peut devenir une mesure prédictive très puissante. Le second est utile comme indicateur général de l'efficacité de nos pipelines. Si le temps de cycle est élevé, il est temps de commencer à examiner le pipeline, car il existe une contrainte que nous pouvons probablement travailler pour assouplir/exploiter. Mais les métriques ne sont que des outils. Ne vous y perdez pas et ne commencez certainement pas à planifier vers une métrique spécifique. Pensez à ce que vous faites en équipe et à la façon dont vous travaillez naturellement, puis construisez le système autour des gens. Les métriques devraient vous aider à voir comment votre système prend en charge le travail de chacun. Ou pas », a conclu Dave Cerra, un producteur de développement de jeux vidéo .
GO TO FULL VERSION