Métriques de développement logiciel : pour vous fier à vos projections

Vous est-il déjà arrivé de manquer des délais de livraison? La réponse est probablement oui! Le développement logiciel peut ressembler à une boîte noire : il est difficile de savoir comment va réellement un projet technologique. Dans cet article de blogue, découvrez pourquoi il est important de mesurer certains aspects de votre équipe de développement logiciel et de stabiliser son flux de travail, en plus de pistes de solutions pour y arriver.

Lorsque nous observons un projet de développement à haut niveau, nous pouvons avoir l’impression que son déroulement est comme un long fleuve tranquille. Par exemple, nous pourrions regarder le type d’items livrés et constater qu’il y a peu de bogues, ce qui est une bonne chose. Nous pourrions également entendre des membres de l’équipe dire que «tout va bien».

Cependant, la réalité peut être toute autre. L’équipe peut répondre que «tout va bien» parce que nous avons posé la question à un bon moment. Ou peut-être que notre temps de cycle augmente progressivement, mais nous ne sommes pas en mesure d’en identifier la cause. Bref, il est extrêmement difficile d’avoir de la visibilité en continu sur un projet technologique. Alors, comment remédier à la situation?

Se mesurer, se stabiliser et se projeter

Utiliser un outil de suivi peut vous permettre d’avoir de la visibilité en continu sur différents éléments d’un projet logiciel. Dans le cas d’Axify, il s’agit de vos processus d'ingénierie logicielle, vos activités de développement, la collaboration sur les items ainsi que le moral de votre équipe. Pourquoi ces éléments? Divers cadres de références constituent la base de la plateforme, dont le cadre d’application SPACE, qui nomme ces éléments parmi ceux favorisant une meilleure performance de livraison de logiciels, donc une meilleure performance organisationnelle.

Mesurer les éléments qui ont un impact sur votre flux de travail vous permettra d’analyser votre stratégie de livraison pour travailler sur votre stabilité. Une équipe stable priorise les tâches en cours (WIP) pour diminuer le nombre de tâches concurrentes. Cela a pour effet d’augmenter et améliorer la collaboration active sur ces tâches, réduisant ainsi les délais d’attente à chaque étape. De plus, observer les bons indicateurs permet de déceler rapidement les goulots d’étranglement pour livrer plus de valeur à vos clients. Le résultat? Un flot de livraison fluide et en continu.

"Cette constance élimine l’aspect aléatoire de la livraison logicielle : votre équipe est alors prédictible! Si 95% du temps vous êtes en mesure de livrer un item en cinq jours ou moins, vous pouvez avoir confiance en votre capacité à répéter la même expérience à nouveau."

Se mesurer

Les indicateurs de performance présentés par Axify sont agnostiques d’un cadre de travail (ex. : Scrum, Kanban, XP, Waterfall, etc.). Cette approche a l’avantage de refléter les résultats de votre méthodologie de travail. Pour reprendre les mots de Peter Drucker, que l’on décrit comme le fondateur du management moderne, «ce qui peut être mesuré peut être géré». En date du 17 mars 2023 (parce que nous travaillons toujours à faire évoluer notre produit!), diverses métriques dont les suivantes sont analysées par Axify pour donner plus de visibilité sur la qualité du flux de travail d’une équipe.

• Le temps de cycle
• Le débit
• Le travail en cours (WIP)
• Métriques DORA (la fréquence de déploiement et le délai nécessaire aux changements)
  
  

Pourquoi ces indicateurs de performance?

Ces indicateurs de performance sont simples à comprendre pour tous, offrent la capacité d’interpréter la théorie des files d’attente et ils permettent de prendre des actions concrètes afin d’améliorer les séquences du processus. Ils font d’ailleurs partie des métriques que notre VP Ingénierie recommande de suivre pour améliorer la performance de votre équipe.

Ceci étant dit, il est important de comprendre que ces indicateurs de performance sont interdépendants. Par exemple, imaginons que vous désirez livrer plus rapidement (réduire votre temps de cycle) et augmenter le nombre d’items livrés (débit) pour une période donnée. Immanquablement, modifier ces deux variables affectera votre travail en cours (WIP), ce qui peut avoir un impact négatif sur la qualité du travail effectué. Avoir plus de tâches en cours peut amener l’équipe à travailler en silos, augmentant le risque d’erreurs (donc d’introduction de bogues), ce qui impliquerait du temps de correction et une diminution de la valeur livrée. C’est pourquoi il est si important de prendre le temps d’inspecter votre processus afin de prendre la décision la plus adaptée à votre réalité.

"En effet, la plupart des équipes cherchent à améliorer seulement certaines dimensions de la performance et peuvent oublier que tout changement aura des répercussions sur les autres dimensions. Chaque décision que l’on prend aujourd’hui aura un impact sur la prédictibilité de l’équipe demain. C’est pourquoi la stabilité est la clé!"

Se stabiliser

En réalité, les équipes recherchent la stabilité, c’est-à-dire être en mesure de maintenir un rythme de livraison, sans profondes variations, pendant un temps assez long. Plus une équipe est stable, plus elle est performante : elle livre plus d’items, plus vite, avec plus de qualité et le fait continuellement. Et plus une équipe est prédictive, plus elle peut répondre précisément et avec confiance à la question «Quand est-ce qu’on va livrer?».

Le travail en cours, le temps de cycle et le débit sont interdépendants et vont toujours affecter la livraison. Au niveau du processus, on vise à limiter le WIP pour avoir une visibilité sur ces métriques et les rendre accessibles à l’ensemble de l’équipe et de l’organisation. La qualité de la communication et la transparence sont la clé pour augmenter la performance.

"Créer et maintenir un affichage visuel présentant des métriques de productivité et de qualité, en plus des statuts courants des bogues, le rendre disponible à l’équipe de développement et aux leaders, et aligner ces métriques avec des objectifs opérationnels peuvent contribuer à l’augmentation de la vélocité de livraison de logiciels."

De plus, utiliser les données de performance de l’application et de l’infrastructure pour prendre des décisions d’affaires sur une base quotidienne contribue à augmenter la qualité et la vitesse de livraison. En effet, le débit et le temps de cycle (combien d’items sont livrés en combien de temps) déterminent le niveau de service attendu, ou le SLE (Service Level Expectation), ce qui facilite la gestion des attentes des clients en présentant les données dans un langage commun.

Se projeter

Votre équipe de développement est stable? Parfait! Vous pouvez maintenant prédire avec plus de précision et de confiance vos livraisons futures. Mais attention à ne pas crier victoire trop rapidement. Le développement logiciel n’est pas déterministe, c’est-à-dire qu’il est impossible de répéter la même expérience et toujours obtenir le même résultat : nous devons donc être probabilistes.

Pour savoir quand on va livrer, peut-on simplement faire une projection linéaire? Pour savoir quand on va livrer, peut-on simplement faire une projection linéaire?

"Si votre équipe est parfaitement stable (c’est-à-dire que le travail en cours, le temps de cycle et le débit sont constamment réguliers) et que vous souhaitez estimer la date de livraison potentielle de façon simple et rapide pour votre propre intérêt, peut-être. Cependant (et nous le répétons), le monde du développement logiciel n’est pas déterministe! Le futur est toujours incertain et, lorsqu’il y a de l’incertitude, il est préférable d’utiliser une approche par probabilités, surtout lorsqu’il est question de créer des attentes envers les clients ou les parties prenantes. Il existe d’ailleurs un algorithme éprouvé permettant de faire ce genre de prédiction avec plus de facilité, tout en introduisant les notions de risque et de niveaux de confiance : la simulation de Monte-Carlo."

Imaginez que vous travaillez sur un projet qui a démarré il y a déjà un certain temps et vous voulez savoir quand une fonctionnalité sera livrée. Vous pourriez vous fier à votre intuition pour estimer la date de livraison ou extrapoler avec une projection linéaire, mais ces solutions ne considèrent pas des variables pouvant affecter la livraison. Maintenant, imaginez plutôt qu’une armée de 1 000 analystes produit différents scénarios pour vous :

• Qu’arrivera-t-il si nous travaillons plus lentement? Ou plus rapidement?
• Et si nous découvrons en cours de route qu’il y a plus d’items à faire? Ou moins d’items à livrer?

Ces 1 000 analystes étudient les chances que les différents scénarios se réalisent et choisissent ensuite le scénario le plus probable. Imaginez maintenant que vous n’avez pas besoin de payer ces 1 000 analystes et que vous pouvez obtenir la réponse dans l’immédiat? C’est ce que l’outil de prédiction d’Axify vous permet de faire. Cette technique est meilleure que votre intuition et les modèles de régression simples.

Quelques exemples

1. Quelle est la probabilité de terminer 20 items pour le 3 mai 2022? → Réponse possible : Vous avez 42% de chance de livrer à cette date.
2. Quand allons-nous livrer 10 items? → Réponse possible : Vous avez 85% de chance de livrer 10 items entre le 15 et le 30 avril 2022.
   
   

Exemple de prédiction dans Axify pour livrer 10 items avec une date de début au 11 mars. Axify prévoit une date de livraison au 25 mars avec 85% de confiance.

J’utilise déjà un outil comme Jira, Azure DevOps ou PowerBi pour sortir des données. Qu’est-ce qu’Axify propose de plus?

Il existe effectivement plusieurs outils de gestion de projets Agile permettant d’obtenir divers rapports. Certaines plateformes offrent également un haut niveau de personnalisation lors de la création de rapports personnalisés. Ceci étant dit, plusieurs de ces rapports ne sont pas adaptés pour appuyer les équipes dans la stabilisation de leurs processus. En voici quelques exemples :

• Burndown/Burnup Charts : Le défaut de ces graphiques est que l’on en vient à se fier à la tendance et à la moyenne. La performance passée ne garantit pas la performance future (encore une fois, le monde du développement logiciel est plein de surprises!). Ces graphiques sont également utilisés pour faire des projections, souvent linéaires (scénario pessimiste et scénario optimiste) qui ne répondent pas à la définition d’une estimation et sont moins pertinents qu’une simulation avec un algorithme éprouvé.
• Control Chart : Il s’agit d’un graphique qui démontre la tendance du temps de cycle à travers le temps. Le défaut d’un Control Chart est qu’il est souvent basé sur une moyenne ou sur la déviation standard (qui elle-même est basée sur la variance). Bien que pertinentes, les données aberrantes ont un impact assez significatif sur le résultat de ces formules. De son côté, Axify utilise plutôt des graphiques basés sur les percentiles. La définition d’une donnée aberrante est qu’elles n’arrivent qu’une fois de temps en temps. Ainsi, il ne faut pas nécessairement les retirer dans nos analyses. Par contre, puisqu’elles ne sont pas fréquentes, elles ne doivent pas avoir un impact significatif pour bien représenter la réalité. C’est pourquoi les graphiques basés sur les moyennes sont affectés par les données aberrantes, ce qui n’aide pas vraiment l’équipe à se stabiliser.
• Cumulative Flow Diagram : Ce graphique est l’un des plus avancés pour analyser le flux Lean d’une équipe. Il est généralement utilisé pour détecter des tendances, mais il n’est pas nécessairement efficace pour prédire le futur et se limiterait à une projection linéaire. De plus, celui-ci n’est pas représentatif lorsque nous n’avons pas assez de données.