Prévisions Monte Carlo pour la planification de livraison Azure DevOps
Les responsables de livraison qui recherchent des prévisions Monte Carlo pour Azure DevOps ont généralement une question urgente : quand allons-nous probablement terminer ? Agile Analytics exécute une simulation bootstrap de 10 000 essais à partir du débit de vos sprints terminés, directement dans Azure DevOps, et renvoie une plage de probabilité plutôt qu'une simple estimation.
Pourquoi les estimations de livraison à date unique perdent leur crédibilité
- Les parties prenantes veulent une date de livraison, mais une estimation ponctuelle ne survit que jusqu'à la première erreur
- La planification basée sur la vélocité moyenne gomme la variation entre sprints qui détermine pourtant si une date va glisser
- Prévoir signifie généralement exporter l'historique de débit vers une feuille de calcul ou un outil BI séparé avant de pouvoir voir une plage
Ce que les prévisions Monte Carlo dans Azure DevOps vous apportent
- Exécutez une simulation bootstrap de 10 000 essais à partir du débit de vos propres sprints terminés, directement là où vit déjà votre backlog
- Lisez P50, P70, P85 et P95 comme une plage honnête plutôt qu'une seule date promise
- Posez l'une ou l'autre des questions que l'entreprise se pose vraiment : combien d'éléments seront terminés à cette date, ou quand ces N éléments seront-ils terminés
Comment fonctionne réellement la simulation Monte Carlo
Il s'agit d'un rééchantillonnage bootstrap de votre propre historique, pas d'un ajustement de courbe statistique. Pour chacun des 10 000 essais, la simulation avance pas à pas dans la fenêtre de prévision et, à chaque étape, tire au hasard (avec remise) un des sprints terminés de votre équipe, puis ajoute le nombre d'éléments terminés de ce sprint au total cumulé. Répétez cette opération 10 000 fois et la dispersion des résultats devient la prévision. Elle s'appuie sur l'historique Azure DevOps que l'extension lit déjà, sans exporter vos données vers une autre plateforme, sans jeton d'accès personnel à configurer, et sans backend analytique hébergé par l'éditeur entre les deux. La simulation est aussi déterministe : les tirages aléatoires sont initialisés à partir de votre historique de sprints, de la fenêtre de prévision et du nombre d'essais, si bien que l'exécuter deux fois avec les mêmes entrées renvoie la même plage P50/P70/P85/P95 les deux fois. La plage ne bouge que lorsque votre débit sous-jacent change. Si la dernière portion de la fenêtre de prévision ne correspond pas exactement à une limite de sprint, cette période partielle finale est proratisée plutôt que comptée comme un sprint complet, afin que le modèle ne surestime pas les bords.
Lire les prévisions par percentile, et pourquoi une plage vaut mieux qu'une date unique
Chaque prévision renvoie quatre niveaux de confiance lus sur les mêmes 10 000 simulations, chacun signifiant « au moins ce nombre d'éléments, au moins aussi souvent » :
- P95, Très probable : le nombre que vous avez 95 % de chances d'atteindre ou de dépasser. Généralement l'engagement le plus prudent de la plage.
- P85, Probable : le niveau que la plupart des équipes utilisent pour une date qu'elles sont prêtes à présenter à une partie prenante.
- P70, Plausible : un compromis raisonnable, juste plus souvent qu'à l'inverse, mais pas une promesse sûre.
- P50, Pile ou face : le nombre atteint par la moitié des simulations, et non atteint par l'autre moitié. Utile comme objectif ambitieux, risqué comme engagement.
Combien d'ici une date, contre quand N éléments seront terminés
Ce sont deux questions différentes, et la simulation exécute un mode distinct pour chacune. « Combien ? » prend une date cible (30 jours par défaut) et indique combien d'éléments du backlog vous êtes susceptible de terminer d'ici là, à chaque niveau de confiance ; utilisez ce mode quand la date est fixée et que la question ouverte porte sur le périmètre, par exemple une date de sortie ou un jalon contractuel. « Quand sera-ce terminé ? » prend une taille de backlog, comme les éléments restants d'un epic, et renvoie une plage de dates ; utilisez ce mode quand le périmètre est fixé et que la question ouverte porte sur la date. Comme le sens de la question s'inverse, celui du percentile s'inverse aussi : pour « quand sera-ce terminé ? », P50 est la date la plus tôt, la plus optimiste, et P95 la plus tardive, la plus prudente. Quand un backlog est assez grand pour que certaines des 10 000 simulations n'atteignent pas le nombre cible dans l'horizon de prévision, l'outil indique le pourcentage qui n'a pas terminé plutôt que de supposer silencieusement que toutes les simulations sont arrivées au bout, afin qu'une large plage de dates ne soit pas masquée par un chiffre faussement rassurant.
Ce dont la prévision a besoin avant que les chiffres aient un sens
Une prévision Monte Carlo n'est fiable qu'à hauteur de l'historique de sprints terminés sur lequel elle se rééchantillonne. Quand vous ouvrez la prévision pour une équipe, le sélecteur de sprints liste vos dix sprints terminés les plus récents et sélectionne par défaut les six plus récents pour exécuter la première prévision ; vous pouvez choisir un ensemble différent à la main, ce qui compte si l'un de ces sprints était un cas atypique, une semaine de congés ou une réorganisation, que vous voulez exclure du rééchantillonnage. Le sprint actuellement en cours est automatiquement exclu de cette sélection par défaut : rééchantillonner à partir d'un sprint partiel, encore ouvert, tirerait toute la prévision vers le bas avec un chiffre de débit qui n'a pas fini d'être compté. Si un sprint que vous avez sélectionné ne se charge pas, la vue le signale (« seulement X sprints sur Y demandés ont été chargés ») plutôt que de prévoir silencieusement sur un échantillon plus petit en le présentant comme complet. Une équipe avec seulement un ou deux sprints terminés obtiendra une prévision, mais la plage restera large jusqu'à ce que davantage d'historique s'accumule ; la simulation ne peut pas fabriquer une certitude que votre équipe n'a pas encore gagnée.
Voir les fonctionnalités de prévision
Comment fonctionne la simulation Monte Carlo à 10 000 essais, quelles données elle nécessite, et comment lire les dates P50/P85/P95 avec les parties prenantes.
Ouvrir la page →Lire le guide Monte Carlo
Une explication simple de pourquoi les prévisions probabilistes surpassent les estimations ponctuelles, et comment les présenter à l'entreprise.
Ouvrir la page →Voir les analyses de cycle time
La prévision ne vaut que ce que vaut l'historique de débit derrière elle. Le cycle time par percentile montre si votre rythme de livraison est assez stable pour servir de base à une prévision.
Ouvrir la page →Comparer avec ActionableAgile
Vous évaluez ActionableAgile pour Azure DevOps ? En quoi les deux approches des prévisions Monte Carlo, des métriques de flow et du traitement des données diffèrent, et laquelle convient à quelle équipe.
Ouvrir la page →Questions sur les prévisions Monte Carlo
À qui les prévisions Monte Carlo sont-elles le plus utiles ?
Aux responsables d'ingénierie, aux responsables PMO, aux program managers et aux responsables de livraison qui doivent communiquer un niveau de confiance sur les dates plutôt qu'une seule prévision optimiste.
Pourquoi est-ce plus fiable que la planification par vélocité moyenne ?
La vélocité moyenne masque la variabilité derrière un seul chiffre. La simulation conserve toute la dispersion du débit de vos sprints terminés et indique « au moins ce nombre, avec cette fréquence » à quatre niveaux de confiance, ce qui améliore les échanges avec les parties prenantes et réduit les promesses fragiles.
La prévision change-t-elle à chaque exécution ?
Non. La simulation est initialisée à partir de votre historique de sprints, de la fenêtre de prévision et du nombre d'essais, si bien que l'exécuter deux fois avec les mêmes entrées renvoie la même plage P50/P70/P85/P95 les deux fois. Une prévision qui change à chaque clic est difficile à défendre devant une partie prenante ; celle-ci reste stable jusqu'à ce que vos données de sprint sous-jacentes changent.
De combien d'historique de sprints a-t-elle besoin ?
La simulation rééchantillonne à partir des sprints terminés de votre équipe : plus il y a de sprints achevés, plus la plage est resserrée. Elle exclut automatiquement le sprint en cours de la sélection par défaut, car un sprint partiel tirerait la prévision vers le bas, et vous pouvez choisir à la main quels sprints terminés inclure si l'un d'eux était un cas atypique.
Que se passe-t-il si mon backlog est trop grand pour être prévu avec confiance ?
Dans la vue « quand sera-ce terminé ? », si certaines des 10 000 simulations n'atteignent pas le nombre cible dans l'horizon de prévision, l'outil indique le pourcentage qui n'a pas terminé plutôt que de supposer que toutes les simulations sont arrivées au bout. Cela vous indique que les dates les plus tardives de la plage sont un plancher, pas une promesse.