Notre expérience de l’utilisation des Métriques Agiles les plus courantes

Notre expérience de l’utilisation des Métriques Agiles les plus courantes

L’utilisation des métriques Agiles pour mesurer la productivité de l’équipe est l’élément clé de la philosophie Agile. Les responsables d’équipe et tous les membres doivent voir les conséquences de leur travail et utiliser ces données pour améliorer le flux de travail et augmenter l’efficacité.

Les utilisateurs finaux et les clients peuvent également bénéficier de l’utilisation de métriques de projet agiles qui se concentrent sur l’évaluation du résultat du produit. Les métriques permettent aux scrum masters, aux développeurs, aux concepteurs et aux testeurs de mesurer les performances de l’application et de déterminer si les tâches actuelles et précédentes améliorent le produit.

Dans cet article, nous passerons en revue les métriques Agiles qui comptent et partagerons notre expérience de l’application de ce tableau de bord de métriques Agiles à un projet réel. Il s’avère que pour diriger une équipe avec succès et obtenir des résultats, vous devez non seulement savoir quelles mesures appliquer, mais comment le faire — nous vous expliquerons comment nous l’avons compris.

Types de métriques Agiles courantes

La classification des métriques Agiles n’est pas gravée dans le marbre — elle change et se restructure constamment. Pourtant, au fil des ans, nous avons vu la montée en puissance de trois principaux types de métriques Agiles dans divers cadres Agiles.

1. Métriques Kanban — ces métriques sont basées sur la mesure du temps investi (temps de cycle) et des résultats fournis (débit), ainsi que de leur ratio.
2. Métriques Scrum — métriques, qui sont axées sur la planification et la compréhension du flux de travail et la démonstration de la quantité de travail effectuée au cours d’une période donnée;
3. métriques Lean — la mesure continue de l’efficacité de la production et de la qualité des produits avec une évaluation technique en testant les fonctionnalités, en vérifiant les erreurs possibles et en prévoyant les effets négatifs.

Nous utilisons les trois types de métriques pour évaluer les principaux aspects du processus de développement logiciel et les résultats: qualité du produit, productivité de l’équipe et santé.

Métriques de qualité agile

Avant de commencer à mesurer la vitesse et l’efficacité de l’équipe, vous devez savoir si vous vous déplacez généralement dans la bonne direction. À quoi sert la livraison rapide de toutes les tâches de développement, si les tâches elles-mêmes sont formées dans le mauvais sens? La priorité de chaque équipe de développement logiciel et de chaque responsable est de s’assurer que toutes les activités sont liées à l’amélioration du produit — cela se fait en mesurant sa qualité et en détectant les tendances négatives.

Défauts échappés

Chaque projet Agile a des sprints ou des cycles de travail, à la fin desquels une certaine tâche est livrée. Une fois le travail terminé, le responsable de l’équipe doit évaluer la qualité des résultats obtenus. Tous les changements, modifications et bogues non corrigés sont des défauts échappés — des problèmes que les développeurs auraient pu corriger mais qui ne l’ont pas été. Enregistrez leur nombre et leur nature précis pour savoir quelles erreurs échappent généralement aux yeux des développeurs.

Après avoir fait un rapport sur les défauts échappés et collecté des statistiques tangibles, vous devez discuter des résultats avec votre équipe. Assurez-vous que chaque membre de l’équipe sait quels types d’erreurs l’équipe manque généralement. Si vous avez des suggestions individuelles, discutez-en avec les membres de l’équipe en tête-à-tête.

Déploiements ayant échoué

Si le produit a été déployé mais n’a pas été publié ou n’a pas réussi à attirer les utilisateurs, cela est enregistré comme un déploiement ayant échoué. Parfois, un déploiement raté arrive aux décisions de l’une des parties prenantes, ou le modèle économique s’avère peu fiable. Quelle que soit la cause du problème, vous devez enregistrer tous les déploiements ayant échoué ainsi que les raisons de leur échec.

Avant de lancer un nouveau déploiement, l’équipe peut toujours consulter la liste des déploiements ayant déjà échoué et examiner si celui-ci ne peut pas subir le même processus. L’analyse des raisons de l’échec des versions précédentes permet d’éviter les problèmes futurs.

Release Net Promoter Score (NPS)

Le Net Promoter Score est la mesure qui consiste à évaluer les réactions des utilisateurs en termes quantitatifs (chiffres, statistiques, notes moyennes) et qualitatifs (avis, commentaires directs, messages, e-mails, appels). Une fois que l’équipe a recueilli et analysé les commentaires, chaque membre de l’équipe suggère un score qui évalue dans quelle mesure l’utilisateur est susceptible de recommander le produit (généralement, les scores sont fixés dans des limites de 1 à 10).

Métriques de gestion de projet agile

Une fois que vous avez un historique complet des échecs et des succès précédents, vous pouvez analyser la direction prise pour tous les projets incomplets en cours et donner des tâches pertinentes, en vous appuyant sur les expériences précédentes. Une fois que vous avez défini la direction du développement — le « que faire » du produit, « vous devez évaluer l’efficacité de l’équipe — c’est le facteur « comment allons-nous ». Vous pouvez utiliser des métriques de projet Agiles pour savoir si les membres de l’équipe répondent à vos attentes, comprennent leurs tâches, gèrent les délais et si tous les processus sont coordonnés et synchronisés.

Délai d’exécution

Le délai d’exécution est une mesure qui permet aux équipes de vérifier combien il a fallu pour que l’entrée de l’arriéré de produits arrive à la fin du sprint. Il peut être utilisé pour suivre les produits à n’importe quel stade de développement, tâche par tâche, ou évaluer les dépenses de temps globales, de l’idéation à la sortie. Il s’agit de mesures à long terme que les développeurs peuvent utiliser lors de la planification de leurs travaux futurs et de l’estimation des prix.

Assurez-vous d’enregistrer le délai d’exécution pour chacun de vos projets. Il est préférable de conserver à la fois des statistiques globales couvrant l’ensemble du projet et des métriques de sprint organisées, afin que vous puissiez examiner chaque étape séparément.

Temps de cycle

Si le délai d’exécution fait partie des mesures de performance à long terme de l’équipe, le temps de cycle se concentre sur les tâches individuelles. Cette mesure évalue la durée d’un cycle unique, où un cycle est pris par une tâche, calcule le nombre de cycles par projet et mesure les résultats obtenus pour l’utilisateur final si le produit est déjà testé en version bêta ou publié.

Avec le temps de cycle, les équipes peuvent immédiatement voir si une tâche prend trop de temps ou si certains membres de l’équipe ne parviennent pas à leurs fins. Cette mesure à court terme rend la gestion de projet beaucoup plus facile et aide à identifier rapidement les problèmes à mesure qu’ils surviennent.

Burndown de sprint

Cette métrique est appliquée à court terme et à long terme. Les managers peuvent créer des rapports Scrum de burndown Sprint en temps réel pour suivre les progrès de leur équipe sur le projet en cours — pour cela, ils doivent estimer le nombre total de sprints et prévoir les dépenses de temps probables. Il peut également être utilisé à long terme — les gestionnaires peuvent analyser les rapports sur les projets précédents, identifier les étapes qui ont échoué dans les délais prévus et analyser les causes des retards.

Plus important encore, sprint burndown permet de suivre la dynamique du flux de travail des équipes. Certains membres ont tendance à travailler plus lentement au début, tandis que d’autres s’épuisent vers la fin du projet. Avec les burndowns de sprint, les chefs d’équipe peuvent détecter ces tendances, déterminer leurs causes et aider les membres à répartir le travail et à gérer le temps.

Epic & Burndown de version

Cette mesure est similaire à Sprint Burndown — la seule différence clé est qu’elle se concentre sur la productivité de l’équipe avant et après la sortie. Les gestionnaires peuvent ajouter de nouvelles exigences et intégrer des tâches basées sur les commentaires des utilisateurs finaux. C’est une version améliorée de sprint burndown, car elle intègre également les tâches données après la sortie du projet.

Velocity

Cette métrique évalue le nombre de points d’histoire terminés sur une période donnée. En fonction de votre historique, vous pouvez prévoir les dépenses de temps pour les points d’histoire futurs. La diminution de la vitesse de l’équipe sur des sprints particuliers peut indiquer un malentendu entre les membres de l’équipe ou des tâches indiquées plus difficiles que prévu.

Métriques agiles supplémentaires

Les métriques agiles aident l’équipe à mieux connaître son projet et à suivre de nombreux aspects importants du développement de produits. Il existe également des mesures Agiles pour les cadres supérieurs qui permettent de voir une image plus globale du développement et du bien-être de l’équipe. Selon notre expérience, ces mesures supplémentaires permettent de mesurer n’importe quel aspect de votre travail. Pourtant, nous avons défini les caractéristiques clés qui en disent le plus sur le produit final et aident à fournir un résultat entièrement complet.

Flux cumulatif

Le nom de la métrique communique clairement son objectif — accumuler tous les flux de projet et les évaluer dans un seul diagramme. Avoir un tel graphique vous fournira une vue à grande échelle — il peut être envoyé aux parties prenantes du projet qui n’ont pas le temps d’analyser des rapports Agiles plus détaillés.

Le diagramme décrit généralement les processus suivants:

• Tâches dans l’arriéré : combien de tâches dans l’arriéré les membres de l’équipe ont sur la période donnée;
• Travail approuvé: combien de tâches parmi celles planifiées ont été accomplies — le chef d’équipe voit immédiatement les différences entre les activités planifiées et finalisées;
• Tâches de tampon: tous les travaux en attente d’approbation sont définis comme se trouvant dans une zone tampon;
• En cours: vous devez évaluer la charge de travail actuelle.

Taux de désabonnement du code

Cette mesure montre les tendances des changements de base de code avant la publication. Les diagrammes de désabonnement montrent la quantité de code ajoutée, supprimée ou modifiée une fois à la fois. Lors des premiers sprints, il y aura de nombreux pics et chutes sur le graphique, car le code est toujours instable, mais à mesure que le projet progresse, le graphique de désabonnement du code devrait devenir stable, sans hauts et bas drastiques.

Avant la sortie, le désabonnement devrait être diminué — l’ajout ou la modification de code avant la sortie même signifie qu’il ne subira pas de tests suffisants. Dans l’ensemble, chaque fois qu’il y a une irrégularité sur les graphiques Agiles, étudiez les raisons.

Tableau de contrôle

Un tableau de contrôle est un tableau où l’équipe peut voir des informations sur la durée de ses temps de cycle. Le résultat idéal serait que la ligne du graphique diminue régulièrement avec le temps — cela signifierait l’augmentation de la vitesse de l’équipe — moins de temps est nécessaire par cycle unique. Un autre aspect important est la cohérence — les temps de cycle doivent rester même quel que soit le type de tâche — cela signifie que vous avez une répartition correcte du travail.

Indicateurs de santé

Les équipes de développement de logiciels doivent se concentrer sur des priorités à long terme, telles que la fluidité de la communication entre les membres et la vérification de la satisfaction de tous. Agile est une méthodologie flexible, ce qui signifie qu’elle peut s’adapter aux intérêts des différents membres, dès que les managers savent à quoi prêter attention. Voici comment nous découvrons si tous les membres de notre équipe sont satisfaits du flux de travail.

Bonheur

Si vous avez des relations informelles de confiance dans votre équipe, il est plus facile de commencer par un dialogue ouvert avec chaque membre. Demandez à chacun d’évaluer son expérience dans l’entreprise de 1 à 5. Vous pouvez poser des questions d’assistance — quels sont les meilleurs et les pires aspects de leur travail, qu’est-ce qui pourrait être amélioré et qu’est-ce qui pourrait augmenter le bonheur? Si l’équipe n’a pas d’habitudes de communication amicales, l’utilisation d’enquêtes anonymes peut conduire à des résultats plus objectifs.

Moral de l’équipe

Le moral de l’équipe et le bonheur ne sont pas les mêmes choses. Le bonheur a plus à voir avec le confort, alors que le moral de l’équipe est lié à la productivité, à l’estime de soi, à l’évaluation de ses propres qualités professionnelles. Encore une fois, vous pouvez demander aux employés d’évaluer leur moral de 1 à 5 et de poser les questions suivantes;

• Travailler dans l’entreprise vous a-t-il aidé à améliorer vos compétences ?
• Dans quelle mesure votre plein potentiel est-il exploré avec la charge de travail actuelle?
• Aimez-vous votre travail?
• Voyez-vous les résultats clairs de votre travail?
• Êtes-vous enthousiaste à l’idée de nouveaux projets ?

L’objectif ici est de comprendre que le courant de développement de l’équipe va dans la bonne direction. Parfois, le responsable de l’équipe de développement de logiciels prend des tâches rentables mais ennuyeuses, ignorant les intérêts des membres. Ce sondage vous aidera à voir si les employés sont excités et mis au défi par leur travail.

Roulement des membres de l’équipe

Si les chefs d’équipe remplacent fréquemment les membres de l’équipe, cela signifie que l’environnement de travail est probablement malsain. Un certain taux de roulement au fil du temps est sain — en fait, vous ne voulez pas avoir d’ajout de personnes pendant des années, car cela signifierait une stagnation. Cependant, vous devez faire attention aux pics soudains d’activité — des mois où plusieurs personnes ont quitté l’équipe ou de nombreuses personnes l’ont rejointe. Si vous avez un ajout soudain de nombreux nouveaux participants, vous devez faire attention au processus d’intégration avant de passer directement au travail lié au projet.

Mesure des avantages pour les utilisateurs finaux

Les équipes Agiles doivent savoir dans quelle mesure le produit répond aux besoins d’un utilisateur final et d’un propriétaire d’entreprise. Cela se fait avec une analyse complète du code qui détermine la qualité du code et sa convivialité pour un utilisateur final, ainsi que les complications possibles de maintenance.

Analyse de code statique

C’est le type simple d’analyse de code lorsque le logiciel est inactif. En surveillant automatiquement le code avec des outils open source, vous pouvez identifier les problèmes de sécurité, détecter les dettes techniques et les bogues et envoyer des fragments de code problématiques au garbage collector.

Analyse de code dynamique

L’analyse de code dynamique nécessite que votre équipe exécute un logiciel pour évaluer l’expérience reçue par les utilisateurs finaux. Nous encourageons nos développeurs et testeurs à toujours se mettre à la place des utilisateurs, en explorant les scénarios les plus courants. Par exemple, ils peuvent présenter la solution à leurs collègues et aux membres de leur famille, en demandant des commentaires — sauf si cela n’est pas interdit par l’accord. Plus important encore, nous avons une équipe de professionnels de l’assurance qualité qui sont entièrement responsables de l’analyse dynamique du code — bien que nous croyions que plus les gens contribuent à tester les métriques dans Agile, meilleure est la qualité du produit final.

Comment appliquer les meilleures métriques Agiles

Parmi toute la variété de métriques Agiles disponibles, vous devez sélectionner celles qui seront pertinentes pour votre équipe et vos projets à long terme. Garder une trace de ces caractéristiques clés devrait être une habitude, alors que cela ne devrait pas vous distraire d’un travail plus urgent. Voici comment nous avons intégré de manière transparente des métriques Agiles à notre flux de travail.

Concentrez-vous sur la performance, le budget et la qualité

Vous devez vous assurer qu’après avoir sélectionné toutes les mesures, vous pourrez avoir une image claire de la qualité, de la charge, des dépenses en temps et du budget de votre travail. Tout d’abord, nous mettons en place des métriques à court terme liées à nos projets actifs : temps de cycle et vitesse pour l’évaluation des performances Agiles, analyse de code pour l’évaluation de la qualité du code et flux cumulatif pour suivre tous les processus de développement et leurs coûts.

Lors du premier sprint, nous nous assurons de faire ce qui suit:

• Définir le nombre de sprints et de cycles du projet;
• Estimer les dépenses de temps pour l’ensemble du projet, en tenant compte des besoins du client;
• Évaluer des solutions compétitives pour comprendre le niveau de complexité du produit final;
• Recueillir les commentaires des membres de notre équipe sur leurs attentes sur les aspects les plus passionnants, difficiles et difficiles du projet.

De cette façon, nous pouvons savoir combien de temps nous allons consacrer à la réalisation du projet, définir des normes de qualité basées sur des solutions similaires et si notre équipe est motivée à travailler sur les tâches ou non (cela a un impact énorme sur la productivité).

Métriques après le premier sprint

Ici, nous nous concentrons sur l’obtention des commentaires du client et de tous les membres de l’équipe. Après le premier sprint, nous voulons savoir que toutes les parties impliquées dans le flux de travail comprennent le processus et se sentent à l’aise. De plus, nous mettons l’accent sur l’évaluation de la qualité du code — nous prévoyons même l’analyse du code et l’évaluation de la dette technique dans le cadre de chacun de nos prochains sprints. Dès que les premières lignes de code ont été écrites, le maintien de sa qualité est notre priorité.

La vitesse vient après

La vitesse est l’une des mesures les plus importantes de nos projets, mais pas la clé. Nous nous abstenons de baser notre jugement sur les nombres de vitesse aux étapes initiales. La stratégie consistant à franchir rapidement les premières étapes est un désastre qui attend de se produire — l’équipe peut sauter la planification ou oublier de poser plusieurs questions cruciales à un client. Nous ne précipitons pas les premières étapes du produit, laissant les clients et les membres de l’équipe trouver leur rythme.

Augmenter la vélocité de notre équipe devient l’une de nos priorités lorsque nous sommes au point d’exécution. Dès que toutes les caractéristiques et le design sont disposés, nous nous efforçons de minimiser les dépenses de temps et d’effectuer toutes les tâches le plus rapidement possible.

Métriques individuelles

Chacune des métriques utilisées doit être disponible pour l’ensemble de l’équipe et les membres individuels. Les développeurs, les testeurs, les concepteurs devraient pouvoir voir le rythme et les résultats de leur travail, pas seulement une équipe dans son ensemble. Pour y arriver, nous utilisons des outils de productivité et des trackers de temps, comme Jira et Hubstaff. Tous les rapports généraux sont synchronisés avec les rapports individuels — les membres peuvent voir le pourcentage du temps de production global de leurs heures.

Foire aux questions

Qu’est-ce que le KPI dans Agile ?

Les indicateurs de performance clés en Agile sont des valeurs mesurables qui montrent l’efficacité de l’équipe dans la réalisation des objectifs commerciaux. Les KPI de haut niveau se concentrent sur des résultats à long terme qui dépendent de nombreux facteurs – le nombre d’utilisateurs attirés par le produit final, les taux de conversion, la qualité des commentaires. Les KPI de bas niveau sont des valeurs à court terme qui ne sont pas influencées par de nombreux facteurs liés — temps passé sur le projet (généralement calculé en heures), budget du projet (investissement par tâche), etc.

Agile est une méthodologie de développement basée sur l’amélioration continue — le développement logiciel analyse les données et s’y adapte. L’équipe analyse les KPI Agiles sur leurs performances et leur qualité de travail, et met en œuvre les changements immédiatement, lors du prochain sprint.

Que sont les métriques de sprint ?

Les métriques de sprint sont des métriques qui évaluent les livrables de l’équipe de développement logiciel, vérifiant la valeur fournie au client final à la fin de chaque sprint. Cette valeur peut être mesurée avec une nouvelle fonctionnalité, des améliorations de conception ou la suppression de bogues.

Le prochain objectif de sprint metrics est de mesurer l’efficacité de l’équipe en termes commerciaux — la rapidité avec laquelle la solution a été livrée sur le marché, les commentaires du client et les niveaux de conversion. Enfin, les métriques doivent montrer la satisfaction des développeurs vis-à-vis de leur projet et de la direction prise par l’équipe en général.

Pourquoi les métriques sont-elles importantes pour les projets Agiles ?

Tout l’intérêt de la méthodologie Agile est que les développeurs peuvent toujours apporter des corrections dans le processus après chaque sprint. Disposer de données, de statistiques et de graphiques tangibles permet aux développeurs de comprendre les changements à apporter pour le prochain sprint, et permet d’évaluer la qualité du produit final — sinon, il serait facile de se plonger dans les détails techniques et organisationnels.

Qu’est-ce qu’un sprint en Agile ?

Un sprint est une période clairement définie avec la date de départ et d’arrivée où l’équipe est prête à accomplir un certain nombre de tâches. Les sprints sont à la base de Scrum, Agile et DevOps — les équipes divisent leur charge de travail en petits morceaux gérables et suivent les résultats de chaque sprint. Chacune de ces périodes est traitée comme un mini-projet avec une planification préalable, une évaluation des risques, des attributions de responsabilités et une analyse post-sprint.

Chaque projet est composé d’une série de sprints. Étant donné que chaque sprint est évalué, il est facile de repérer les problèmes dès le début et de les supprimer lors du sprint suivant — le flux de travail est donc constamment optimisé.

Quelles sont les métriques pour le développement de logiciels?

Les métriques de développement logiciel sont des valeurs quantitatives qui permettent de mesurer la qualité, les performances et la santé du projet de développement logiciel. Ils aident à améliorer le processus de développement au fur et à mesure que le projet avance et peuvent être utilisés pour le travail futur de l’équipe afin d’améliorer l’organisation et la planification.

Il existe six principaux types de métriques de développement logiciel:

• Métriques de code formelles – ce sont des valeurs qualitatives objectives qui calculent la quantité de travail effectuée en déterminant le nombre de lignes de code (LOC), la Longueur du chemin d’instruction, etc.
• Indicateurs d’efficacité des développeurs : l’équipe peut calculer le code d’affectation, les jours actifs et le temps consacré à la tâche.
• Métriques de processus agiles – lorsque le projet est divisé en sprints, l’équipe peut mesurer l’efficacité de parties plus petites du projet – temps d’exécution (combien de temps a été consacré à une certaine étape de développement, qui peut contenir plusieurs sprints), temps de cycle (un sprint relève généralement d’un seul cycle) et vitesse (combien de tâches ont été effectuées dans un laps de temps particulier).
• Métriques opérationnelles — ces métriques vérifient les caractéristiques d’exécution du logiciel et déterminent l’efficacité du personnel de l’entreprise à maintenir l’outil sans l’aide de tiers. Temps moyen entre les pannes et Temps moyen de récupération (MTTR) vérifiez comment le logiciel fonctionnera dans des circonstances naturelles et dans quelle mesure l’équipe interne est-elle équipée pour gérer la charge.
• Métriques de test – ces métriques évaluent la couverture du code — la quantité de code testée, le nombre de bogues et le pourcentage de dette technique.
• Satisfaction du client — l’équipe obtient des informations sur les réactions des utilisateurs finaux au produit en mesurant le Score Net de Promoteur, le Score de Satisfaction du client et le Score d’Effort du client. Ces mesures évaluent, respectivement, si les utilisateurs recommandent le produit et s’ils sont satisfaits du résultat.

Les métriques agiles font partie des réseaux logiciels et peuvent comprendre d’autres catégories, comme vous pouvez le constater dans notre guide.

Que sont les métriques SDLC ?

Le SDLC est un cycle de vie de développement logiciel – un ensemble d’étapes qu’une technologie typique subit au cours de sa conception, de son exécution et de sa finalisation. Un SDLC moyen comprend les étapes suivantes:

• Évaluer les systèmes existants et définir leurs caractéristiques, avantages, problèmes;
• Définir les exigences pour la nouvelle fonctionnalité du projet, la conception, le public cible, etc.;
• Concevoir le système et décrire un chemin d’accès utilisateur typique ;
• Développer le logiciel, ce qui signifie écrire du code, préparer le matériel et créer des fonctionnalités;
• Tester les performances du logiciel, ses fonctionnalités, sa sécurité, son interface, etc.;
• Déployer le logiciel dans son environnement naturel, où la technologie fonctionnera à long terme;
• Maintenir le système en mettant à jour le code, en remplaçant ou en modifiant certains fragments et en supprimant les bogues.

Chaque étape de SLDC peut être mesurée par les caractéristiques suivantes.

• Exigences: l’équipe doit collecter toutes les exigences du projet et évaluer la mise en œuvre de chacune d’elles en termes de temps et d’argent;
• Qualité logicielle: toutes les métriques de qualité Agile peuvent être utilisées au stade du développement d’un SDLC;
• Cas de test: l’équipe doit calculer le nombre d’activités de test effectuées, sa vitesse et la couverture finale du code;
• Défauts: pour mesurer l’efficacité de leur travail, les développeurs et les testeurs doivent être conscients du nombre exact de problèmes qui surviennent pendant le développement;
• Tâches: mesurer le temps passé et l’argent gagné par tâche permet d’évaluer si tous les membres de l’équipe sont productifs ou non.

Toutes les métriques, décrites dans notre guide, peuvent être utilisées à différentes étapes du cycle de vie du développement logiciel. Le projet a le plus besoin d’une surveillance plus proche de la version car les problèmes peuvent s’accumuler et il est facile de manquer un défaut critique du produit.

Qu’est-ce que le débit dans les métriques Agiles ?

C’est la métrique qui calcule le nombre d’histoires terminées par sprint. En Mêlée, une métrique similaire est appelée Vitesse de sprint.

Conclusion

Les métriques agiles constituent une base solide pour prendre des décisions éclairées tout au long d’un projet de développement logiciel. Les développeurs peuvent utiliser ces informations pour augmenter leur efficacité lors des prochains sprints et améliorer constamment la qualité de leur produit. Cependant, il convient de noter que les métriques de développement ne devraient pas devenir une priorité absolue dans le projet de développement logiciel. Les développeurs doivent se fier avant tout aux besoins du projet et aux préférences du public.

Chez Jelvix, nous utilisons une approche personnalisée pour appliquer des métriques au projet. Tout d’abord, nous discutons du MVP du projet avec le client, recherchons le public cible, analysons les solutions concurrentielles, puis choisissons les mesures qui correspondent le mieux au projet. Nous ne nous efforçons pas d’appliquer tous les indicateurs clés de performance — nous sélectionnons plutôt ceux qui reflètent le plus les besoins du projet.