Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Les diagrammes de flux cumulatifs (CFD) vous aident à surveiller votre processus de travail en visualisant le flux de travail via votre système. Cet article explique comment utiliser des CFD, des temps de cycle et des délais pour identifier les problèmes et améliorer l’efficacité du flux de travail.
- Pour configurer ou afficher un CFD, consultez Afficher et configurer un diagramme de flux cumulatif.
- 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.
- Pour configurer ou afficher un CFD, consultez Afficher et configurer un diagramme de flux cumulatif.
- 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.
Le CFD de flux continu est le graphique que la plupart des équipes qui suivent un processus lean préfèrent.
Mais de nombreuses équipes combinent des pratiques Lean avec Scrum ou d’autres méthodes. Ils utilisent des pratiques allégées pendant une itération ou un sprint. Dans ce cas, le diagramme semble un peu différent. Il montre deux éléments supplémentaires, la CFD de flux continu est le graphique préféré par la plupart des équipes qui suivent un processus Lean.
Mais de nombreuses équipes combinent des pratiques Lean avec Scrum ou d’autres méthodes. Ils utilisent des pratiques allégées pendant une itération ou un sprint. Dans ce cas, le diagramme semble un peu différent. Il montre deux informations supplémentaires et précieuses, comme indiqué dans le graphique suivant, la CFD de période fixe.
CFD à flux continu
Cette CFD à période fixe montre un sprint achevé.
La ligne supérieure montre le périmètre défini pour le sprint. Étant donné que le travail doit se terminer le dernier jour, la pente de l’état Fermé indique si une équipe est en piste. Considérez cette vue comme un graphique de burnup.
Dans le graphique, la première étape du processus se trouve dans la zone supérieure gauche. La dernière étape se trouve dans la zone inférieure droite.
CFD à durée déterminée pour un sprint terminé
Indicateurs de performance du graphique
Les CFD indiquent le nombre d’éléments de travail regroupés par état ou colonne au fil du temps. Les deux métriques principales pour le suivi sont le temps de cycle et le délai d’exécution. Vous extrayez ces métriques 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. Mesurez la longueur entre le début d’un processus et le début du processus suivant.
Délai de livraison1
Pour un processus de flux continu : heure à partir de laquelle une demande est effectuée (comme l’ajout d’un récit utilisateur proposé) jusqu’à ce que cette demande soit terminée (fermée).
*Pour un sprint ou une fi pour un processus de flux continu : heure à partir de laquelle une demande est effectuée (comme l’ajout d’un récit utilisateur proposé) jusqu’à ce que cette demande soit 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 en cours.
Portée
Quantité de travail engagée pour la période 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 claire entre le délai de production ou le temps de cycle et l'EPT. Plus de WIP entraîne des temps de cycle plus longs et des délais plus longs. L’inverse est également vrai : moins de WIP conduit à un cycle plus court 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 une raison clé pour définir des limites WIP sur la carte 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 une période déterminée de CFD, une modification de ce nombre signifie un changement d’étendue pour cette période. Dans un flux continu, la fonction CFD indique la quantité totale de travail qui se trouve dans la file d’attente et terminée pour une journée donnée.
La catégorisation du travail dans des colonnes de tableau spécifiques indique la quantité de travail dans chaque zone du processus. Cette vue donne un aperçu de l’endroit où le travail se déplace sans problème, où il y a des blocages et où aucun travail n’est effectué. Il est difficile de comprendre une vue tabulaire des données, mais le visual CFD vous aide à voir ce qui se passe dans votre processus de travail et pourquoi.
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 doublure plate systémique peut se produire dans une caractéristique CFD. Le travail des fonctionnalités peut prendre plus de temps que de travailler sur des récits utilisateur, car les fonctionnalités sont composées de plusieurs récits. 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ée. 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 peut se produire, car le test prend plus de temps que d’écrire du 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. La maintenance d’un deuxième élément de travail offre une flexibilité opérationnelle pendant des retards inattendus. 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 d'exécution et le temps de cycle diffèrent. 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é. L’heure du cycle commence lorsqu’un élément de travail entre une catégorie d’état en cours ou résolu et se termine lorsqu’il entre une catégorie d’état Terminé.
Si votre équipe utilise un tableau pour suivre et gérer le travail, comprendre comment vos colonnes mappent aux états de flux de travail vous aide à gérer le travail plus efficacement. Pour savoir comment configurer votre carte, consultez Gérer les colonnes de votre carte.
Pour savoir comment le système utilise les catégories d’état proposées, en cours, résolues et terminées, consultez À propos des états de flux de travail dans les backlogs et les tableaux.
Comment le temps de cycle gère les éléments de travail réactivés
Pour les éléments de travail qui sont réactivés (déplacés d’un état Terminé vers un état En cours ), l’heure du cycle commence à partir de la première fois que l’élément de travail entre une catégorie d’état en cours ou résolu et termine la dernière fois qu’il entre une catégorie d’état Terminé . Le temps de cycle inclut l’ensemble de la période de travail active, y compris à tout moment après la réactivation.
Exemple de scénario :
- Nouveau → Active → Résolu → Fermé → Nouveau → Active → Fermé
- Calcul du temps de cycle : De la première transition vers Actif vers la transition finale vers Fermé
- Durée totale du cycle : Inclut les périodes de travail actives et l’heure dans l’état Fermé avant la réactivation
Cette méthode de calcul fournit une image complète du temps total nécessaire pour terminer l’élément de travail, y compris toute réanalyse ou effort supplémentaire après la réactivation. Le calcul du temps de début suit le même principe : il couvre toute la période de création d’élément de travail jusqu’à la fin finale, quel que soit l’état terminé intermédiaire.
Estimez les délais de livraison en fonction des délais et des temps de cycle
Utilisez vos délais moyens et vos temps de cycle, ainsi que vos écarts types, pour estimer les délais de livraison.
Lorsque vous créez un élément de travail, utilisez le délai moyen de votre équipe pour estimer la date d’achèvement. L’écart type de l’équipe indique la variabilité de l’estimation. De même, utilisez votre temps de cycle et son écart type pour estimer quand un élément de travail se termine 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 et l’écart type est de six jours. Avec ces données, estimez que l’équipe termine les futurs récits utilisateur d’environ 2 à 14 jours après le début du travail. Un écart type plus étroit rend vos estimations plus prévisibles.
Identifier les problèmes de processus
Les valeurs hors norme signifient souvent qu’il existe un problème de processus sous-jacent. Par exemple, attendre trop longtemps pour passer en revue les pull requests ou ne pas résoudre rapidement une dépendance externe. Consultez le graphique de contrôle de votre équipe pour identifier les valeurs aberrantes.
Exemple de widget de temps de cycle montrant plusieurs valeurs hors norme
Le graphique suivant présente plusieurs valeurs aberrantes, car certains bogues ont nécessité plus de temps que la moyenne pour être résolus. La vérification de la raison pour laquelle ces bogues ont pris plus de temps peut vous aider à trouver des problèmes de processus. La résolution des problèmes de processus permet de réduire l’écart type de votre équipe et d’améliorer la prévisibilité de votre équipe.
Vous voyez également comment les changements de processus affectent vos délais de traitement et de cycle. Par exemple, le 15 mai, l'équipe a travaillé pour limiter le travail en cours et résoudre les bogues obsolètes. L’écart type se limite après cette date, ce qui montre une meilleure prévisibilité.