Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Vous pouvez utiliser des diagrammes de flux cumulatifs (CFD) pour surveiller le flux de travail dans un système. Le temps de cycle et le délai d’exécution sont les deux principales mesures utilisées pour le suivi. Vous pouvez extraire ces métriques d’un CFD.
Cet article vous montre comment utiliser les CFD, les temps de cycle et les délais pour identifier les problèmes dans votre processus de travail et vous aider à faire avancer le travail dans votre système.
- Pour configurer ou afficher un CFD, consultez Afficher et configurer un diagramme de flux cumulé.
- Pour ajouter une carte de contrôle du délai ou du temps de cycle à un tableau de bord, consultez les widgets Temps d’exécution et Temps de cycle.
Exemples de graphiques et métriques principales
Le CFD à flux continu fournit le graphique le plus apprécié par les équipes qui suivent un processus Lean.
Cependant, de nombreuses équipes combinent les pratiques Lean avec Scrum ou d’autres méthodologies. Par conséquent, ils utilisent des pratiques Lean dans le cadre d’une itération ou d’un sprint. Dans cette situation, le diagramme prend un aspect légèrement différent. Il fournit deux informations supplémentaires très précieuses, comme le montre le graphique suivant, le CFD à période fixe.
CFD à flux continu
Ce CFD à durée déterminée concerne un sprint terminé.
La ligne supérieure représente l’étendue définie pour le sprint. Étant donné que le travail doit être terminé avant le dernier jour du sprint, la pente de l’état Fermé indique si une équipe est sur la bonne voie pour terminer le sprint. Le moyen le plus simple de considérer cette vue est un graphique de burnup.
Dans le graphique, la première étape du processus est représentée par la zone supérieure gauche. La dernière étape du processus est représentée par la zone en bas à droite.
CFD à durée déterminée pour un sprint terminé
Indicateurs de performance du graphique
Les CFD affichent le nombre d’éléments de travail regroupés par état ou par colonne au fil du temps. Les deux principales mesures utilisées pour le suivi sont le temps de cycle et le délai d’exécution. Vous pouvez extraire ces mesures du graphique.
Mesure
Définition
Temps de cycle1
Temps nécessaire pour faire passer le travail d’un processus ou d’un état de flux de travail unique. La longueur est mesurée du début d’un processus au début du processus suivant.
Délai de livraison1
Pour un processus à flux continu : le temps écoulé entre le moment où une demande est effectuée (par exemple, l’ajout d’un récit utilisateur proposé) et le moment où cette demande est terminée (fermée).
Pour un processus de sprint ou à période fixe : temps écoulé entre le début du travail sur une demande et la fin du travail (par exemple, le temps entre l’état Actif et l’état Fermé).
Travaux en cours (WIP)
Quantité de travail ou nombre d’éléments de travail sur lesquels on travaille activement.
Portée
La quantité de travail engagée pour la période de temps donnée. Cette mesure ne s’applique qu’aux processus à période fixe.
1 Le widget CFD qui utilise les données Analytics et le CFD intégré que vous pouvez afficher à partir d’un backlog ou d’un tableau d’équipe ne fournissent pas de valeurs distinctes de délai et de temps de cycle. Toutefois, les widgets Délai et Temps de cycle fournissent ces valeurs.
Il existe une corrélation bien définie entre le délai d’exécution ou le temps de cycle et les en-cours. Plus d’en-cours entraîne des temps de cycle plus longs, ce qui entraîne des délais de livraison plus longs. L’inverse est également vrai : moins d’en-cours se traduit par des cycles et des délais plus courts. Lorsque l’équipe de développement se concentre sur moins d’éléments, elles réduisent le cycle et les délais de développement. Cette corrélation est l’une des principales raisons pour lesquelles vous devez définir des limites d’encours sur le tableau que vous utilisez pour suivre et gérer le travail.
Le nombre d’éléments de travail indique la quantité totale de travail d’un jour donné. Dans un CFD à période fixe, une variation de ce nombre indique un changement de portée pour une période donnée. Dans un CFD à flux continu, il indique la quantité totale de travail qui se trouve dans la file d’attente et qui est terminée pour une journée donnée.
La catégorisation du travail dans des colonnes spécifiques du tableau vous indique la quantité de travail dans chaque domaine du processus. Cette vue fournit des informations sur les endroits où le travail se déroule sans problème, où il y a des blocages et où aucun travail n’est effectué. Il est difficile de déchiffrer une vue tabulaire des données. Cependant, la CFD visuelle vous aide à comprendre ce qui se passe dans votre processus de travail et pourquoi cela se produit.
Identifier les problèmes et prendre les mesures appropriées
La CFD apporte des réponses aux questions suivantes. En fonction des réponses, vous pouvez ajuster le processus pour déplacer le travail dans le système.
L’équipe va-t-elle travailler à temps ?
Cette question ne s’applique qu’aux CFD à durée déterminée. Vous pouvez vous y prendre en compte en regardant la courbe (ou la progression) du travail dans la dernière colonne du tableau.
Dans ce scénario, vous pouvez envisager de réduire l’étendue du travail dans l’itération. Cette action est appropriée s’il est clair que le travail n’est pas terminé assez rapidement, en supposant qu’il se poursuit à un rythme régulier. Ce scénario peut indiquer que le travail a été sous-estimé et doit être pris en compte dans la planification du prochain sprint.
Cependant, il peut y avoir d’autres raisons pour lesquelles le travail n’est pas terminé assez rapidement. Vous pouvez déterminer ces raisons en examinant d’autres données sur le graphique.
Comment le flux de travail progresse-t-il ?
L’équipe termine-t-elle le travail à un rythme régulier ? Une façon de le savoir est de regarder l’espacement entre les différentes colonnes du graphique. Est-ce qu’ils sont d’une distance similaire ou uniforme entre eux du début à la fin ? Y a-t-il des colonnes qui semblent stagner sur une période de plusieurs jours ? Ou y en a-t-il qui semblent gonfler ?
Mura, ou irrégularité, est le terme maigre pour les lignes plates et les renflements. Mura indique une forme de déchet (Muda) dans le système. Toute irrégularité dans le système provoque l’apparition de renflements dans le CFD.
La surveillance de la CFD pour les lignes plates et les boulgères prend en charge une partie clé du processus de gestion de projet Théorie des contraintes. La protection de la zone la plus lente du système est appelée processus tambour-tampon-câble et fait partie de la planification des travaux.
Deux problèmes apparaissent visuellement comme des lignes plates et comme des boulons.
Les lignes plates apparaissent lorsque l’équipe ne met pas à jour le statut de ses éléments de travail avec une cadence régulière. Le tableau que vous utilisez pour suivre et gérer le travail constitue le moyen le plus rapide de passer du travail d’une colonne à une autre.
Les lignes plates peuvent également apparaître lorsque le travail sur un ou plusieurs processus prend plus de temps que prévu. Des lignes plates apparaissent dans de nombreuses parties du système, car si seulement une ou deux parties ont des problèmes, vous voyez un renflement.
Lignes plates
Les renflements se produisent lorsque le travail s’accumule dans une partie du système et ne progresse pas dans un processus.
Par exemple, un renflement peut se produire lorsque les tests prennent beaucoup de temps, mais que le développement prend moins de temps. Le résultat est que le travail s’accumule dans l’état de développement. Les renflements indiquent qu’une étape suivante a un problème, pas nécessairement l’étape dans laquelle le renflement se produit.
Renflements
Comment résoudre les problèmes de flux ?
Vous pouvez résoudre le problème du manque de mises à jour en temps opportun en prenant les mesures suivantes :
- Tenir des stand-ups quotidiens
- Tenir d’autres réunions régulières
- Planification d’un e-mail de rappel quotidien pour l’équipe
Les problèmes systémiques de ligne plate indiquent un problème plus difficile, bien que ces problèmes soient rares. Les lignes plates indiquent que le travail dans l’ensemble du système est arrêté. Les causes sous-jacentes peuvent inclure les problèmes suivants :
- Blocages à l’échelle du processus
- Des processus qui prennent beaucoup de temps
- Transfert du travail vers d’autres opportunités qui ne sont pas saisies sur le tableau
Un exemple de stagnation systémique peut se produire dans un CFD de fonctionnalités. Le travail sur les fonctionnalités peut prendre beaucoup plus de temps que le travail sur les user stories, car les fonctionnalités sont composées de plusieurs stories. Dans ces situations, soit la pente est attendue (comme dans un exemple précédent), soit le problème est bien connu et l’équipe l’a déjà soulevé. S’il s’agit d’un problème connu, la résolution du problème est en dehors de l’étendue de cet article.
Teams peut résoudre de manière proactive les problèmes qui apparaissent comme des boulons DEF. La solution appropriée peut dépendre de l’endroit où le renflement se produit. À titre d’exemple, supposons que le renflement se produise dans le processus de développement. Le gonflement se produit peut-être parce que les tests prennent beaucoup plus de temps que l’écriture de code. Les testeurs peuvent également trouver un grand nombre de bogues. Lorsqu’ils transfèrent continuellement le travail aux développeurs, les développeurs héritent d’une liste croissante de travail actif.
Il existe deux façons potentiellement simples de résoudre ce problème :
- Faites passer les développeurs du processus de développement au processus de test jusqu’à ce que le renflement soit éliminé.
- Modifiez l’ordre des travaux. Plus précisément, entremêlez le travail qui peut être fait rapidement avec le travail qui prend plus de temps.
Recherchez des solutions de base pour éliminer les renflements.
Remarque
Étant donné que divers scénarios peuvent se produire et entraîner un déroulement inégal du travail, il est essentiel que vous effectuiez une analyse réelle du problème. Le CFD peut vous dire qu’il y a un problème. Il peut également vous indiquer approximativement où se trouve le problème, mais vous devez enquêter pour en identifier les causes profondes. Ces conseils fournissent des actions recommandées qui résolvent des problèmes spécifiques, mais les solutions peuvent ne pas s’appliquer à votre situation.
L’étendue a-t-elle changé ?
Les modifications du champ d’application ne s’appliquent qu’aux CFD à durée déterminée. La ligne supérieure du graphique indique l’étendue du travail. Un sprint est préchargé avec le travail à effectuer le premier jour. Les modifications apportées à la ligne supérieure indiquent l’ajout ou la suppression de travaux.
Dans un scénario particulier, vous ne pouvez pas suivre les modifications de portée avec un CFD. Ce scénario se produit lorsque le même nombre d’éléments de travail sont ajoutés et supprimés le même jour. La ligne reste plate dans ce cas.
Pour suivre les modifications de l’étendue dans ce cas, effectuez les actions suivantes :
- Comparez plusieurs graphiques entre eux.
- Surveillez des problèmes spécifiques.
- Utilisez l’avancement du sprint pour surveiller les modifications de portée.
Y a-t-il trop de WIP ?
Vous pouvez facilement surveiller le tableau pour déterminer si les limites d’en-cours sont dépassées. Vous pouvez également surveiller les niveaux d’en-cours à l’aide de la CFD.
Une grande quantité de WIP apparaît généralement comme un boulgène vertical. Plus il y a une grande quantité d’en-cours longtemps, plus le renflement s’étend en une forme ovale. Ce comportement indique que le WIP affecte négativement le cycle et le délai.
Voici une bonne règle de base pour les travaux en cours : il ne doit pas y avoir plus de deux éléments en cours par membre de l’équipe à un moment donné. La principale raison de l’utilisation d’une limite de deux éléments, et non d’une limite plus stricte, est que la réalité s’immisce fréquemment dans le processus de développement de logiciels.
Parfois, il faut du temps pour obtenir des informations d’une partie prenante ou pour acquérir les logiciels nécessaires. Il existe un certain nombre de raisons pour lesquelles les travaux peuvent être interrompus. Le fait de disposer d’un deuxième élément de travail vers lequel pivoter peut offrir une certaine marge de manœuvre. Si les deux éléments sont bloqués, il est temps de déclencher un indicateur rouge pour obtenir quelque chose de déblocé, pas simplement basculer vers un autre élément. Dès qu’il y a un grand nombre d’éléments en cours, la personne qui travaille sur ces éléments peut avoir des difficultés à changer de contexte. Il est probable qu’ils oublient ce qu’ils faisaient, ce qui peut entraîner des erreurs.
Temps de prospect et durée de cycle
Le diagramme suivant montre comment le temps de prospect diffère de l’heure du cycle. Le délai commence lorsqu’un élément de travail est créé et se termine lorsque l’élément de travail entre dans une catégorie d’état Terminé. La durée du cycle commence lorsqu’un élément de travail entre pour la première fois dans une catégorie d’état En cours ou Résolu. Le temps de cycle se termine lorsque l’élément de travail passe dans une catégorie d’état Terminé.
Si un élément de travail entre dans une catégorie d’état Terminé, puis est réactivé, ses délais et ses temps de cycle sont affectés. Tout temps supplémentaire qu’il passe dans une catégorie d’état Proposé, En cours ou Résolu contribue à ses délais et à ses temps de cycle.
Si votre équipe utilise un tableau pour suivre et gérer le travail, il est utile de comprendre comment vos colonnes sont mappées aux états du flux de travail. Pour plus d’informations sur la configuration de votre tableau, consultez Gérer les colonnes de votre tableau.
Pour plus d’informations sur la façon dont le système utilise les catégories d’état (Proposé, En cours, Résolu et Terminé), consultez À propos des états de flux de travail dans les backlogs et les tableaux.
Estimez les délais de livraison en fonction des délais et des temps de cycle
Vous pouvez utiliser vos délais moyens de livraison et de cycle et vos écarts-types pour estimer les délais de livraison.
Lorsque vous créez un élément de travail, vous pouvez utiliser le délai moyen de votre équipe pour estimer la date d’achèvement de cet élément de travail. L’écart type de votre équipe vous indique la variabilité de l’estimation. De même, vous pouvez utiliser votre temps de cycle et son écart-type pour estimer l’achèvement d’un élément de travail après le début du travail.
Exemple de widget Temps de cycle
Dans le graphique suivant, la durée moyenne du cycle est de huit jours. L’écart-type est de six jours. À l’aide de ces données, vous pouvez estimer que l’équipe termine les futures user stories environ 2 à 14 jours après avoir commencé à travailler. Plus l’écart type est réduit, plus vos estimations sont prévisibles.
Identifier les problèmes de processus
Les valeurs hors norme représentent souvent un problème de processus sous-jacent. Par exemple, attendre trop longtemps pour examiner les demandes de tirage ou ne pas résoudre rapidement une dépendance externe. Passez en revue le graphique de contrôle de votre équipe pour connaître les valeurs hors norme.
Exemple de widget Durée du cycle montrant plusieurs valeurs hors norme
Le graphique suivant montre plusieurs valeurs aberrantes, car plusieurs bogues ont pris plus de temps que la moyenne à résoudre. Enquêter sur les raisons pour lesquelles ces bogues ont pris plus de temps peut aider à découvrir les problèmes de processus. La résolution des problèmes de processus peut aider à réduire l’écart-type de votre équipe et à améliorer la prévisibilité de votre équipe.
Vous pouvez également voir comment les modifications de processus affectent vos délais et vos temps de cycle. Par exemple, le 15 mai, l’équipe a fait un effort concerté pour limiter le WIP et corriger les bogues obsolètes. Vous pouvez voir que l’écart type se limite après cette date, montrant une meilleure prévisibilité.