Toute équipe d’ingénierie logicielle productive garde la trace de ses améliorations grâce à un ensemble d’indicateurs choisis appelés métriques d’ingénierie KPI. Voici les 5 métriques de développement d’indicateurs clés de performance (KPI) les plus essentiels que vous devriez commencer à suivre dès aujourd’hui.

Avez-vous déjà travaillé avec une équipe d’ingénierie où aucune métrique KPI n’était mesurée ? Si c’est le cas, alors vous savez probablement à quel point il est difficile de dire si l’équipe est sur la bonne voie pour la libération ou non.

La vérité est que si vous voulez atteindre vos objectifs commerciaux, vous devez vous assurer que votre logiciel répond à toutes les exigences. Pour ce faire, vous devez mettre en œuvre des mesures d’ingénierie KPI dans les processus de développement.

En mettant en place des mesures d’ingénierie KPI pour votre équipe de développement logiciel, vous éviterez la mauvaise qualité et les délais non respectés. Ce que vous obtiendrez, c’est une équipe productive et un produit de haute qualité.

Voici cinq indicateurs de développement KPI essentiels que vous devriez suivre pour atteindre vos objectifs commerciaux.

Sprint Burndown

Qu’est-ce que le Sprint Burndown ?

Les équipes agiles organisent leur développement en sprints. Un sprint burndown mesure la quantité de travail effectuée par l’équipe au cours d’un sprint.

Quels sont les avantages?

• Un sprint burndown est excellent pour tenir l’équipe au courant des barrages routiers qui se produisent.
• En mesurant le sprint breakdown, vous pouvez vérifier si votre équipe respecte ses prévisions.
• En utilisant un tableau de ventilation de sprint, l’équipe peut gérer sa progression. Si l’équipe se rend compte qu’elle risque de ne pas atteindre l’objectif du sprint, les membres de l’équipe peuvent prendre les mesures appropriées pour rester sur la bonne voie.

Comment le mesurez-vous ?

Les équipes agiles utilisent des graphiques de décomposition de sprint pour visualiser leur flux de travail. Le graphique a un axe x qui représente le temps et un axe y qui représente la quantité de travail restant à accomplir. Vous pouvez mesurer le temps en heures ou en story points. Ou bien, vous pouvez imaginer vos propres statistiques. L’objectif principal ici est que tout le travail prévu soit terminé à la fin du sprint.

Un outil que vous pouvez utiliser est le tableau de répartition du sprint de Jira. Pour l’utiliser, vous devez créer un compte Jira Software, et un projet Scrum Jira Software.

Vous verrez un axe vertical qui représente les story points. L’axe horizontal représente le temps. La ligne rouge dans le graphique représente la quantité de travail restant dans le sprint. La ligne grise est la ligne de travail réelle. Si la ligne rouge est inférieure à la ligne grise, cela signifie que l’équipe est sur la bonne voie. En revanche, si la ligne rouge est au-dessus de la ligne grise, cela signifie que le projet est en retard.

Release Burndown

Qu’est-ce que le Release Burndown ?

Le Release Burndown offre un aperçu de la progression de la release. Il est similaire au Sprint burn down, mais sa portée est plus grande. Il aide les équipes à vérifier si elles parviendront à publier le produit à une date précise. Si elles se rendent compte qu’elles sont en retard sur le calendrier, elles peuvent en informer les utilisateurs et les parties prenantes. Ou, si ce n’est pas le cas, elles peuvent réduire l’étendue du travail pour libérer le produit à temps.

Quels sont les avantages ?

• Vous pouvez vérifier à quelle vitesse votre équipe travaille sur le backlog.
• Vous pouvez avoir un aperçu de la façon dont le travail ajouté et supprimé affecte la progression de votre équipe.
• Faites des prédictions sur le nombre de sprints qu’il faudra à votre équipe pour terminer le travail.

Comment le mesurez-vous ?

Le burndown de la version est mesuré à l’aide d’un tableau similaire au tableau de répartition des sprints. La différence est que maintenant, l’axe horizontal représente les sprints, et l’axe vertical représente le travail restant (jours, heures, ou story points).

Par exemple, regardons l’image ci-dessous. Il s’agit d’un graphique de burndown de version Jira. Vous pouvez voir que l’équipe a initialement défini quatre sprints et 43 story points. Au cours de ces quatre sprints, l’équipe a réduit le nombre d’histoires de 43 à 26. L’équipe a également prévu que la libération du produit prendra sept sprints supplémentaires, ce qui donne un total de 11.

Temps de cycle

Qu’est-ce que le temps de cycle ?

Le temps de cycle est une métrique de développement KPI qui mesure le temps que l’équipe passe à travailler sur une tâche. Les diagrammes de temps de cycle sont utilisés par les Scrum Masters et les Product Owners pour contrôler l’efficacité du processus de développement.

Quels sont les avantages ?

• Il fournit des informations sur la performance globale de l’équipe.
• Il permet d’estimer l’achèvement des tâches futures.
• Vous pouvez remarquer tout goulot d’étranglement et tout ralentissement dans le flux de travail.

Comment le mesurer?

Le temps de cycle est égal à la date de fin moins la date de début. Par exemple, si l’équipe commence à travailler le 1er décembre et termine le 10 décembre, la durée du cycle est de neuf jours.

Si l’équipe commence le travail le 1er décembre et termine la tâche le même jour, alors votre temps de cycle ne sera pas de zéro mais de un. Pour les projets qui commencent et se terminent le même jour, la durée du cycle est égale à la date de fin moins la date de début +1.

Vous pouvez remplacer les jours par des semaines, des heures ou même des sprints.

Pensez à utiliser des diagrammes de temps de cycle pour visualiser votre flux de travail. Ces graphiques montrent combien de temps il a fallu pour terminer un problème par rapport au jour d’achèvement.

Par exemple, regardons le graphique ci-dessous. Sur l’axe des abscisses, vous pouvez voir la date à laquelle la tâche a été clôturée, et sur l’axe des ordonnées, vous pouvez voir le temps passé. Les cercles verts sont des tâches. Un cercle plein indique un groupe de problèmes, tandis qu’un cercle ouvert indique un seul problème. Si vous utilisez un outil comme Jira, vous pouvez voir la clé de la tâche, son code et le délai d’exécution en passant votre souris sur le cercle. La ligne rouge représente le temps de cycle moyen, et la ligne bleue représente le temps de cycle moyen glissant.

L’objectif final est que l’équipe ait des temps de cycle cohérents pour les éléments de travail qui ont des valeurs de story point similaires. Des valeurs inférieures signifient que l’équipe travaille efficacement, tandis que des valeurs supérieures peuvent indiquer des goulots d’étranglement dans le processus de travail.

Team Velocity

What is Team Velocity?

La vélocité est une autre métrique d’ingénierie KPI agile qui mesure la quantité de travail qu’une équipe complète pendant un sprint. La quantité de travail est généralement mesurée en story points ou en heures.

Les propriétaires de produits utilisent la vélocité pour calculer la vitesse à laquelle une équipe peut travailler sur le backlog. L’indice de vélocité est unique pour chaque équipe, et vous ne devriez pas comparer la vélocité entre les équipes.

Par exemple, disons que vous voulez compléter 300 story points dans le backlog. Vous savez que l’équipe de développement, en moyenne, complète environ 50 story points par itération. Avec cette information en main, vous pouvez prédire que l’équipe aura besoin de six itérations pour compléter le travail requis.

Quels sont les avantages ?

• C’est très utile pour les prévisions.
• Il peut aider à planifier les futurs sprints.
• Il peut vous aider à comprendre si l’équipe est bloquée ou si vos changements de processus fonctionnent.

Comment la mesurer?

Si vous avez une équipe stable en place, vous parviendrez à établir une vélocité moyenne en mesurant au moins 5 à 7 sprints. Si votre sprint habituel est hebdomadaire, et que l’équipe réalise 250 story points sur une période de cinq semaines, alors votre taux de vélocité moyen est de 50 story points par semaine.

Regardons le graphique de vélocité de Jira ci-dessous. Les barres bleues représentent l’engagement, et les vertes représentent le travail réel effectué. Dans le sprint numéro 1, l’équipe a planifié 16 story points et en a réalisé 16. Cela indique que leurs estimations étaient correctes. Cependant, dans le deuxième sprint, l’équipe a planifié 19 story points mais n’en a réalisé que 12. Cela suggère que la prochaine fois, ils devraient réduire leur plan.

Un flux incohérent est un indicateur que vous avez des problèmes dans le développement et que vous devez faire des changements.

Flux cumulé

Qu’est-ce que le flux cumulé ?

Le flux cumulé visualise le statut de vos tickets sur une période de temps. Il montre le passage de vos tickets d’un statut à un autre au fur et à mesure que votre projet progresse.

Quels sont les avantages ?

• Il est utile pour identifier les goulots d’étranglement.
• Il aide les équipes à s’assurer que le flux de travail est cohérent.
• Il vous montre la stabilité de votre flux de travail.
• Il vous aide à comprendre comment vous pouvez rendre votre processus plus prévisible.

Comment le mesurer ?

La façon la plus simple de mesurer le flux de travail cumulatif est d’utiliser des graphiques. Ils visualisent les trois plus importantes métriques d’ingénierie logicielle de votre flux, notamment le temps de cycle, le débit et les travaux en cours.

Regardons le graphique ci-dessous. L’axe x horizontal indique le temps, tandis que l’axe y vertical indique les éléments de travail. Les différentes couleurs représentent les différents états du flux de travail. Si les bandes progressent en parallèle, cela signifie que votre débit est stable. Cela indique que le nombre de nouvelles tâches qui entrent dans votre flux de travail est le même que le nombre de celles qui le quittent.

Si une bande se rétrécit rapidement, cela signifie que vous avez plus de capacité que nécessaire. Vous devriez relocaliser la capacité pour optimiser le flux.

Si une bande s’élargit rapidement, cela signifie qu’il y a plus de cartes qui entrent dans l’étape correspondante que d’affectations qui en sortent.

Summing Up

Le suivi des indicateurs de développement KPI décrits ci-dessus peut conduire à une issue positive du processus de développement du produit. Vous parviendrez finalement à ne plus remettre en question l’avancement de votre projet et à obtenir un aperçu détaillé de chaque étape du cycle de vie du développement.

Si vous voulez mettre fin au cercle vicieux des produits de mauvaise qualité, des délais non respectés et des échecs de code, commencez dès aujourd’hui à mettre en œuvre le développement des indicateurs de performance clés. Vous parviendrez à publier un produit de qualité supérieure sans les risques qui l’accompagnent.

.