Le graphique d’avancement présente de nombreux avantages. C’est l’un des principaux outils de mesure dans Scrum pour plusieurs raisons. Il est facile à créer, à mettre à l’échelle et à lire. Cependant, il a aussi des inconvénients qui en font un outil non universel. Dans l’article d’aujourd’hui, nous abordons le sujet des inconvénients et des avantages du graphique d’avancement.
Nous avons écrit sur ce que c’est, comment créer et interpréter un graphique d’avancement dans des articles précédents. Aujourd’hui, nous allons nous concentrer sur les avantages et inconvénients du graphique d’avancement. Cependant, la plupart d’entre eux ne sont pas cachés dans le simple graphique lui-même. Ils sont plutôt liés aux façons d’utiliser le graphique d’avancement pour motiver l’équipe de développement, car ils décrivent les résultats de leur travail et renforcent l’auto-organisation.
Le graphique d’avancement vous permet de visualiser les progrès de votre projet. Sa lisibilité et sa simplicité en font un outil très populaire. C’est pourquoi il est judicieux que le graphique d’avancement ne soit pas seulement une mesure constamment mise à jour cachée dans un outil de gestion de projet numérique. Si possible, il vaut la peine d’en faire un point de référence pour l’équipe de développement visible dans le lieu de travail physique. Que ce soit sous la forme d’une visualisation à l’écran ou d’un croquis dessiné à la main.
La transparence du graphique d’avancement peut en faire un outil pour motiver l’équipe de développement à travailler efficacement. Atteindre le point “zéro” à chaque Sprint peut devenir un objectif ambitieux pour l’équipe, pour lequel des récompenses sont données – selon les principes de la gamification en entreprise.
La visibilité d’un graphique d’avancement à jour et entretenu de manière intéressante peut également renforcer l’esprit de coopération et d’auto-organisation. Après tout, la mesure est un indicateur du travail d’équipe. Elle ne montre pas exactement qui a terminé – ou n’a pas terminé – les tâches prévues, seulement les résultats obtenus.
Les développeurs décident combien de tâches ils réaliseront dans un Sprint donné. Plus l’équipe est expérimentée, plus elle devrait être capable de prédire ses actions avec précision. Et le graphique d’avancement reflète le véritable progrès du Sprint.
Ainsi, l’avantage du graphique d’avancement n’est pas tant de mesurer la quantité objective de travail effectué, mais le rapport entre les tâches planifiées et celles réalisées. Ainsi, les développeurs apprennent progressivement à les planifier et peuvent estimer leurs capacités de manière de plus en plus précise et éliminer les erreurs répétitives.
Un des avantages significatifs du graphique d’avancement concerne sa polyvalence à se combiner avec d’autres outils. Les outils suivants peuvent s’appliquer à :
Par exemple, dans ce dernier cas, l’utilisation du graphique d’avancement de la portée du projet permet une comparaison entre le budget prévu et le budget réel pour l’ensemble du projet.
Malgré tous les avantages du graphique d’avancement décrits ci-dessus, il peut devenir une source de confusion pour l’équipe de développement. Cependant, ce que nous appelons fréquemment les “défauts” du graphique d’avancement ne sont pas dus à des imperfections de l’outil lui-même. Les problèmes décrits ci-dessous concernent la manière de mettre en œuvre le graphique d’avancement plutôt que son design. Voici les défauts qui peuvent interférer avec la représentation des progrès de l’équipe de développement de cette manière.
Les graphiques ne peuvent pas être une mesure absolue des progrès d’une équipe. Ce ne sont que des outils à appliquer de manière plus ou moins habile. Nous pouvons considérer cela comme un inconvénient (ou un avantage) non seulement du graphique d’avancement mais aussi d’autres mesures de performance d’équipe.
Pour créer un graphique d’avancement, vous avez besoin d’autres personnes pour entrer des données. En d’autres termes, les développeurs notent le temps de réalisation des tâches sur le graphique. Ils pourraient l’avoir prolongé ou raccourci un peu – soit par inattention, soit pour améliorer les choses pour l’équipe. Les développeurs oublient parfois aussi de consigner leur temps. Ou laissent le chronomètre allumé. Cela fait que le temps de travail s’étend sur plusieurs heures. Et après avoir découvert l’erreur, il est difficile de reconstruire son véritable déroulement.
Le Sprint Backlog ne doit pas être modifié après le début d’un Sprint. Cependant, dans la pratique, de tels changements se produisent assez souvent. Ils résultent de l’évolution des exigences des parties prenantes. Ou de problèmes imprévus que rencontrent les développeurs.
Cela entraîne une mise à l’échelle du graphique d’avancement. Cela est dû au fait que le temps nécessaire pour accomplir les tâches reste le même. Cependant, l’échelle des tâches restantes augmente. Cela peut donner une impression trompeuse que l’équipe de développement a mal planifié le travail à réaliser dans un Sprint donné. Ou qu’elle travaille trop lentement.
Les modifications du Sprint Backlog peuvent également résulter de tâches qui ont été programmées pour être terminées trop rapidement. Dans une telle situation, l’équipe de développement décide généralement d’augmenter le nombre de tâches. Cela peut à son tour entraîner un non-respect des délais. De plus, des conflits peuvent surgir de la superposition des tâches restantes du Sprint précédent avec de nouvelles tâches programmées pour être terminées par les parties prenantes et les propriétaires de produit.
De grands changements dans le Product Backlog peuvent perturber la forme du graphique d’avancement. Et ainsi fausser fortement l’image des progrès du travail et de l’efficacité de l’équipe. Cela se produit lorsque de nouvelles User Stories apparaissent. Et celles qui sont proches de la phase de mise en œuvre sont souvent divisées en parties plus petites. Il arrive aussi que le client renonce à certaines fonctionnalités du produit.
Par conséquent, lors de l’interprétation du graphique d’avancement, il faut se guider par la connaissance et l’expérience dans l’évaluation de la performance de l’équipe. Et également prendre en compte la variabilité du Backlog. Si le graphique n’est pas la seule mesure utilisée pour évaluer la performance, les autres graphiques permettront de voir une image plus complète des progrès du travail.
Le graphique d’avancement peut contribuer de manière significative à la motivation de l’équipe de développement. Cela est dû au fait qu’il fournit une mesure du travail réel effectué sur le plan. De plus, sa combinaison avec d’autres outils de mesure peut être une source de connaissances précieuses sur le travail de l’équipe et la planification du produit.
En appliquant soigneusement les principes de Scrum, vous pouvez éviter les problèmes potentiels avec le graphique d’avancement. La chose la plus importante est d’adapter les outils de maintien du graphique en fonction du travail réel de l’équipe Scrum, ainsi que de minimiser les changements dans le Sprint et le Product Backlog, dont nous parlons plus en détail dans cet article.
Si vous aimez notre contenu, rejoignez notre communauté de travailleurs acharnés sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
En tant que chef de projet, Caroline est une experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous pression font d'elle la meilleure personne pour transformer des projets compliqués en réalité.
Les entreprises luttent pour gérer une vaste quantité de contenu publié en ligne, des publications…
À l'ère de la transformation numérique, les entreprises ont accès à une quantité sans précédent…
Saviez-vous que vous pouvez obtenir l'essence d'un enregistrement de plusieurs heures d'une réunion ou d'une…
Imaginez un monde où votre entreprise peut créer des vidéos engageantes et personnalisées pour n'importe…
Pour tirer pleinement parti du potentiel des grands modèles de langage (LLMs), les entreprises doivent…
En 2018, Unilever avait déjà entrepris un voyage conscient pour équilibrer les capacités d'automatisation et…