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.
Prenons un trajet de la ville A vers la ville B en exemple : même si nous faisons ce trajet des centaines de fois, nous n'aurons pas le même résultat à chaque fois. Comme ce n'est pas déterministe, cela veut donc dire que nous devons être probabilistes. C'est un peu comme les prévisions météo: quelles sont les probabilités de pluie pour mercredi?
Une projection est constituée de deux éléments fondamentaux :
- une probabilité
- une période (de dates)
Pour savoir quand on va livrer, peut-on simplement faire une projection linéaire?
Pour les équipes capables de maintenir un travail en cours (WIP) stable, qui ne violent presque jamais les assomptions de la loi de Little et qui ne classifient pas les tâches par niveau d'urgence (Classes of Services), ça peut être satisfaisant. Pour les autres, c'est-à-dire la majorité des équipes, nous allons utiliser une simulation à la Monte-Carlo.
Monte-Carlo?
Imaginez que vous travaillez sur un projet qui a démarré il y a déjà un certain temps. 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.
Imaginez plutôt qu'armée de 1 000 analystes produit différents scénarios pour vous :
- Qu'arrivera-t-il si nous travaillons plus lentement?
- Et si nous travaillons plus rapidement?
- Si finalement nous découvrons en cours de route qu'il y a plus d'items à faire?
- Ou qu'il y a moins d'items à faire?
Ces 1 000 analystes étudient les chances que les différents scénarios se réalisent et choisissent ensuite le scénario désiré (ou 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 la simulation de Monte-Carlo permet de faire.
Cette technique est meilleure que votre intuition et les modèles de régression simples.
Avec cette technique, vous pouvez désormais effectuer vos projections de deux façons :
- Quelle est la probabilité de terminer tous ces items pour le X (ex. : 3 mai 2022)? → Réponse possible : Vous avez 42% de chance de livrer à cette date.
- Quand allons-nous livrer X (ex. : 10 items) ? → Réponse possible : Vous 85% de chance de livrer 10 items entre le 10 avril 2022 et le 30 avril 2022
J'utilise déjà Jira. Qu'est-ce qu'Axify propose de plus?
La force de Jira est sa gestion de projet Agile. Bien que celui-ci a déjà des graphiques comme le Burndown/Burn-up Chart, le Cumulative Flow Diagram et le Control Chart, ceux-ci ne sont pas parfaitement adaptés pour stabiliser l'équipe.
- Burndown/Burn-up Charts : Le défaut de ces graphiques est qu'on vient à se fier à la tendance et à la moyenne. La performance passée ne garantit pas la performance future. Ces graphiques sont également utilisés pour faire des projections. Ces projections sont souvent linéaires (scénario pessimiste et scénario optimiste). Ceux-ci ne répondent pas à la définition d'une estimation et sont moins pertinents qu'une simulation de Monte-Carlo.
- Control Chart : Le Control Chart est 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 qu'elle est pertinente, les données aberrantes ont un impact assez significatif sur le résultat de ces formules.
- Axify utilise plutôt des graphiques basés sur les percentiles. Les données aberrantes arrivent réellement une fois de temps en temps, et il ne faut pas les retirer dans nos analyses. Par contre, si elles ne sont pas fréquentes, elles ne doivent pas avoir un impact aussi significatif étant donné qu'elles ne sont pas assez représentatives de la réalité. C'est pourquoi les graphiques basés sur les moyennes sont significativement affectés par les données aberrantes, ce qui n'aide pas vraiment l'équipe à se stabiliser.
- Axify utilise plutôt des graphiques basés sur les percentiles. Les données aberrantes arrivent réellement une fois de temps en temps, et il ne faut pas les retirer dans nos analyses. Par contre, si elles ne sont pas fréquentes, elles ne doivent pas avoir un impact aussi significatif étant donné qu'elles ne sont pas assez représentatives de la réalité. C'est pourquoi les graphiques basés sur les moyennes sont significativement affectés par les données aberrantes, ce qui n'aide pas vraiment l'équipe à se stabiliser.
- Cumulative Flow Diagram : Le Cumulative Flow Diagram est un des graphiques les plus avancés pour analyser le flux Lean d'une équipe. Il est généralement utilisé pour détecter des tendances. Il n'est pas nécessairement efficace pour prédire le futur et se limiterait à une projection linéaire. De plus, celui-ci peut ne pas être assez représentatif lorsque nous n'avons pas assez de données.