Flux cumulé, délai d’exécution et conseils sur le temps de cycle
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Vous utilisez des diagrammes de flux cumulatifs (CFD) pour surveiller le flux de travail via un système. Les deux métriques principales à suivre, au temps de cycle et au délai d’exécution peuvent être extraites du graphique. Pour configurer ou afficher des graphiques CFD, consultez Configurer un graphique de flux cumulé.
Vous pouvez également ajouter les graphiques de contrôle de temps de prospect et de cycle à vos tableaux de bord.
Exemples de graphiques et métriques principales
Le FLUX CONTINU CFD fournit le graphique le plus privilégié par les équipes qui suivent un processus de lean.
Toutefois, de nombreuses équipes ont commencé à combiner des pratiques maigres avec des méthodologies Scrum ou d’autres méthodologies, ce qui signifie qu’elles pratiquent l’inclinaison dans l’étendue d’une itération ou d’un sprint. Dans cette situation, le diagramme prend un aspect légèrement différent et fournit deux éléments d’information supplémentaires, et très précieux, comme indiqué dans le graphique suivant.
Flux continu
La durée fixe de la CFD indiquée ici concerne un sprint terminé.
La ligne supérieure représente l’étendue définie pour le sprint. Et, étant donné que le travail doit être effectué le dernier jour du sprint, la pente de l’état Fermé indique si une équipe est en piste pour terminer le sprint. Le moyen le plus simple de considérer cette vue est un graphique de burnup.
Les données sont toujours représentées avec la première étape du processus en haut à gauche et la dernière étape du processus en bas à droite.
Durée fixe DE LA CFD pour un sprint terminé
Indicateurs de performance du graphique
Les graphiques CFD affichent le nombre d’éléments de travail regroupés par état/colonne au fil du temps. Les deux métriques principales à suivre, au temps de cycle et au délai d’exécution peuvent être extraites du graphique.
Mesure
Definition
Durée du cycle 1
Mesure le temps nécessaire au déplacement d’un processus unique ou d’un état de flux de travail. Le calcul est du début d’un processus au début du processus suivant.
Délai d’exécution 1
Pour un processus de flux continu : mesure le temps nécessaire lorsqu’une demande est effectuée (par exemple, l’ajout d’un récit utilisateur proposé) jusqu’à ce que cette demande soit terminée (fermée).
Pour un processus de sprint ou de période fixe : mesure l’heure à laquelle le travail sur une demande commence jusqu’à ce que le travail soit terminé (c’est-à-dire l’heure entre Actif et Fermé).
Travail en cours
Mesure la quantité de travail ou le nombre d’éléments de travail en cours de travail.
Portée
Représente la quantité de travail validée pour la période donnée. S’applique uniquement aux processus de période fixe.
1 Le widget CFD (Analytics) et le graphique CFD intégré (magasin de données de suivi du travail) ne fournissent pas de nombres discrets sur le temps de prospect et le temps de cycle. Toutefois, les widgets Temps de prospect et Temps de cycle fournissent ces nombres .
Il existe une corrélation bien définie entre le temps de prospect/le temps de cycle et le travail en cours (WIP). Plus la fonctionnalité WIP est longue, plus le temps de cycle est long, ce qui entraîne également des délais plus longs. L’inverse est également vrai : moins wiP, plus le cycle et le temps de prospect sont 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 essentielle pour laquelle vous pouvez et devez définir les limites Work In Progress sur la carte.
Le nombre d’éléments de travail indique la quantité totale de travail d’un jour donné. Dans une période fixe, une modification de ce nombre indique le changement d’étendue pour une période donnée. Dans un flux continu, il indique la quantité totale de travail dans la file d’attente et terminée pour un jour donné.
La décomposition du travail en colonnes de tableau spécifiques fournit une vue dans laquelle le travail est en cours. Cette vue fournit des insights sur l’endroit où le travail se déplace sans problème, où il y a des blocages et où aucun travail n’est effectué du tout. Toutefois, il est difficile de déchiffrer une vue tabulaire des données, mais le graphique CFD visuel fournit des preuves que quelque chose se produit d’une manière donnée.
Identifier les problèmes, prendre les mesures appropriées
La CFD répond à plusieurs questions spécifiques et en fonction de la réponse, des actions peuvent être prises pour ajuster le processus de déplacement du travail au sein du système. Examinons chacune de ces questions ici.
L’équipe va-t-elle travailler à temps ?
Cette question s’applique uniquement aux CFD de période fixe. Vous obtenez une compréhension en examinant la courbe (ou la progression) du travail dans la dernière colonne du tableau.
Dans ce scénario, il peut être approprié de réduire l’étendue du travail dans l’itération s’il est clair que le travail, à un rythme stable, n’est pas assez rapide. Il peut indiquer que le travail a été sous-estimé et devrait être pris en compte dans la planification des sprints suivant.
Il peut toutefois y avoir d’autres raisons qui peuvent être déterminées 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 dire consiste à examiner 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 ? Une colonne apparaît-elle sur une ligne plate sur une période de plusieurs jours ? Ou, semble-t-il « boulgérer » ?
Mura, le terme maigre pour les lignes plates et les boulgères, signifie inégale et indique une forme de déchets (Muda) dans le système. Toute inégalité dans le système entraîne l’apparition de boulgères dans la 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 de batterie-tampon-corde et fait partie de la façon dont le travail est planifié.
Deux problèmes apparaissent visuellement comme des lignes plates et comme des boulons.
Les lignes plates apparaissent lorsque l’équipe ne met pas à jour son travail avec une cadence régulière. Le tableau offre le moyen le plus rapide de passer 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. Les lignes plates apparaissent sur de nombreuses parties du système, car si une seule partie du système ou deux parties d’un système ont des problèmes, vous verrez un gonflement.
Lignes plates
Les boulgères se produisent lorsque le travail s’accumule dans une partie du système et ne passe pas par un processus.
Par exemple, un gonflement peut se produire lorsque le test prend une longue période de temps pendant que le développement prend une période de temps plus courte, ce qui entraîne l’accumulation de travail dans l’état de développement (les boulgères indiquent qu’une étape réussie a un problème, pas nécessairement l’étape dans laquelle le boulgnage se produit).
Renflements
Comment résoudre les problèmes de flux ?
Vous pouvez résoudre le problème d’un manque de mises à jour en temps voulu via :
- Des stand-ups quotidiens.
- Autres réunions régulières.
- Planification d’un e-mail de rappel d’équipe quotidien.
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 sur le système s’est arrêté. Les causes sous-jacentes peuvent être les suivantes :
- Blocages à l’échelle du processus.
- Les processus prennent beaucoup de temps.
- Le travail passe à d’autres opportunités qui ne sont pas capturées sur le tableau.
Un exemple de ligne plate systémique peut se produire avec une fonction CFD. Le travail des fonctionnalités peut prendre beaucoup plus de temps que de travailler sur les récits utilisateur, car les fonctionnalités sont composées de plusieurs récits. Dans ces situations, la pente est attendue (comme dans l’exemple ci-dessus) ou le problème est bien connu et déjà soulevé par l’équipe en tant que problème. 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. Selon l’endroit où se produit le gonflement, le correctif peut être différent. Par exemple, supposons que le gonflement se produit dans le processus de développement. Le gonflement peut se produire, car l’exécution de tests prend 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.
Deux façons potentiellement faciles de résoudre ce problème sont : 1) Déplacer les développeurs du processus de développement vers le processus de test jusqu’à ce que le gonflement soit éliminé ou 2) modifier l’ordre du travail de sorte que le travail qui peut être effectué rapidement est entrelacé avec le travail qui prend plus de temps à faire. Recherchez des solutions simples pour éliminer les gonflements.
Remarque
Étant donné que de nombreux scénarios différents peuvent se produire de façon inégale, il est essentiel d’effectuer une analyse réelle du problème. La CFD vous indiquera qu’il y a un problème et à peu près là où il est, mais vous devez examiner pour obtenir la ou les causes racines. Les conseils fournis ici indiquent les actions recommandées qui résolvent des problèmes spécifiques, mais qui peuvent ne pas s’appliquer à votre situation.
L’étendue a-t-elle changé ?
Les modifications d’étendue s’appliquent uniquement aux CFD de période fixe. 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 que le travail a été ajouté ou supprimé.
Le scénario où vous ne pouvez pas suivre les modifications d’étendue avec un CFD se produit lorsque le même nombre d’éléments de travail est ajouté comme supprimé le même jour. La ligne continue d’être plate. Comparez plusieurs graphiques entre eux. Surveillez les problèmes spécifiques. Utilisez view/configure sprint burndown pour surveiller les modifications d’étendue.
Trop de WIP ?
Vous pouvez facilement surveiller si les limites WIP ont été dépassées à partir de la carte. Vous pouvez également le surveiller à partir 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é de WIP, plus le gonflement se développera pour devenir un ovale. Il s’agit d’une indication que le WIP affecte négativement le cycle et le délai d’exécution.
Voici une bonne règle de pouce 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 raison principale pour deux éléments par rapport aux limites plus strictes est que la réalité fréquemment intruse sur n’importe quel processus de développement logiciel.
Parfois, il faut du temps pour obtenir des informations d’une partie prenantes, ou il faut plus de temps pour acquérir des logiciels nécessaires. Il existe un certain nombre de raisons pour lesquelles le travail peut être arrêté. Avoir un deuxième élément de travail à pivoter pour fournir 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 travaillant sur ces éléments aura des difficultés à changer de contexte. Il est plus probable qu’ils oublient ce qu’ils faisaient, et des erreurs peuvent se produire.
Temps de prospect et durée de cycle
Le diagramme ci-dessous montre comment le temps de prospect diffère du temps de cycle. Le délai d’exécution est calculé à partir de la création d’éléments de travail pour entrer un état Terminé. Le temps de cycle est calculé à partir de la première entrée d’une catégorie d’état En cours ou Résolu à l’entrée d’une catégorie d’état Terminé .
Illustration du temps de prospect et du temps de cycle
Si un élément de travail entre dans un état Terminé, puis est réactivé, tout temps supplémentaire qu’il passe dans un état Proposé, En cours ou Résolu contribue à son temps de prospect/cycle lorsqu’il entre dans une catégorie d’état Terminé pour la deuxième fois.
Si votre équipe utilise le tableau, vous devez comprendre comment vos colonnes correspondent aux états du flux de travail. Pour plus d’informations sur la configuration de votre carte, consultez Ajouter des colonnes.
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 les états de flux de travail et les catégories d’état.
Planifier l’utilisation des délais de livraison estimés en fonction des délais de prospect/cycle
Vous pouvez utiliser les durées moyennes de prospect/cycle et les é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 quand votre équipe termine cet élément de travail. L’écart type de votre équipe vous indique la variabilité de l’estimation. De même, vous pouvez utiliser le temps de cycle et son écart type pour estimer l’achèvement d’un élément de travail une fois que le travail a commencé.
Dans le graphique suivant, la durée moyenne du cycle est de huit jours. L’écart type est +/- six jours. À l’aide de ces données, nous pouvons estimer que l’équipe terminera les futures histoires d’utilisateurs environ 2 à 14 jours après leur début de travail. Plus l’écart type est réduit, plus vos estimations sont prévisibles.
Exemple de widget Temps de cycle
Identifier les problèmes de processus
Passez en revue le graphique de contrôle de votre équipe pour connaître les valeurs hors norme. Les valeurs hors norme représentent souvent un problème de processus sous-jacent. Par exemple, attendre trop longtemps pour terminer les révisions de demande de tirage ou ne pas résoudre rapidement une dépendance externe.
Comme vous pouvez le voir dans le graphique suivant, qui montre plusieurs valeurs hors norme, plusieurs bogues ont pris plus de temps que la moyenne de l’équipe. L’examen de la raison pour laquelle ces bogues ont pris plus de temps peut aider à découvrir les problèmes de processus. Résoudre les problèmes de processus peut aider à réduire l’écart type de votre équipe et à améliorer la prévisibilité de votre équipe.
Exemple de widget Durée du cycle montrant plusieurs valeurs hors norme
Vous pouvez également voir comment les modifications de processus affectent votre prospect et votre temps de cycle. Par exemple, le 15 mai, l’équipe a fait un effort concerté pour limiter le WIP et résoudre les bogues obsolètes. Vous pouvez voir que l’écart type se limite après cette date, montrant une meilleure prévisibilité.