À travers cet article, nous souhaitons vous montrer qu’il est possible de travailler de manière agile et d’utiliser le diagramme de Gantt comme outil (dans sa variante Scrum), sans pour autant mettre en péril votre agilité. Cela vous semble impossible ? Il est vrai que le diagramme de Gantt est considéré comme « vieux jeu » au sein des communautés Agiles et le fameux modèle en cascade perçu comme la première chose à éliminer lorsque l’on parle d’Agilité. Mais tout ceci n’est pas entièrement vrai !
Le problème des diagrammes de Gantt dans la gestion de projet
Pour être honnête, c’est principalement la manière dont les Managers de Projet utilisent le Gantt qui rend cet outil non agile. La pire erreur concernant un diagramme de Gantt serait de penser que c’est une exacte représentation de la réalité. Encore une fois, ce n’est pas la faute de l’outil en lui même ni même celle des chefs de projet. L’erreur est en fait commise par les personnes qui lisent le diagramme et pensent, souvent parce que le Gantt arbrore une représentation simple, que les choses se déroulent exactement ainsi. Et qui sont les lecteurs du diagramme de Gantt ? Le management, les clients, etc… les personnes qui sont finalement le moins au fait des détails du travail.
Pourquoi le diagramme de Gantt est faussé
Certes, les choses commencent toujours avant la date fixée, se terminent toujours après et la mise à jour des progrès est aussi folle que la barre de progression Windows. Cependant, cette représentation est simple à comprendre : les équipes sont condamnées à mettre à jour le moindre détail, la moindre dépendance ou tâche.
Et ce n’est le pire. Non seulement la représentation de l’état d’avancement du travail est erronée et génère une quantité folle de paperasse, mais la partie projection et roadmap, est également mauvaise. Pourquoi cela ?
Principalement en raison de la manière dont fonctionne le diagramme de Gantt. Pour chaque élément, vous avez besoin de déterminer une date de début et une date de fin de manière précise (au jour près). Pour cela, vous devez avoir une estimation du volume de travail. Mais puisque les estimations sont presque toujours biaisées, cela signifie que les dates de fin déterminées à l’avance sont également faussées. Et malgré cela, le diagramme de Gantt demande tout de même de s’engager sur un jour précis.
L’essor de l’Agilité
Les méthodologies de gestion de projet Agiles sont justement apparues en partie pour combattre la bureaucratie et le micro-management du développement de produit, mais aussi afin de se focaliser sur la valeur livrée :
- Une estimation approximative de la durée des tâches est faite, afin de mettre fin aux discussions interminables pour savoir si la tâche que vous allez réaliser dans 6 mois nécessitera vraiment une heure ou deux.
- L’accent est mis sur les User Stories (et non sur les tâches) pour livrer un logiciel complètement fonctionnel.
- Un suivi des métriques est réalisé, ce qui permet de se concentrer sur la valeur livrée au client plutôt que sur la simple complétion des tâches. (Comme les graphiques Burn-up des User Stories)
C’est pourquoi désormais, nous avons un backlog Agile, organisé autour de la valeur livrée, avec un haut niveau d’estimation (ou pas d’estimation du tout). Les clients sont contents parce que ce qui est important est livré en priorité. L’équipe produit est satisfaite car elle n’est plus obligée de maintenir des indicateurs qui n’ont aucune valeur pour elle. Enfin, le manager de produit est content également parce que les nouveaux indicateurs se concentre sur ce qui compte vraiment : la capacité des équipes à exécuter (graphiques burn-down, diagramme de vélocité) et ce qui est livré au client (graphiques burn-up).
Est ce que tout le monde est content ?
Non ! Le top management ne l’est pas. Parce qu’ils perdent un précieux outil, envers lequel ils pouvaient se montrer compréhensifs (même si celui-ci était un peu cassé). Ils ne comprennent pas ces nouveaux outils et ils ont perdu leur capacité à prévoir « par eux même ».
Peut on rendre les gens heureux ?
C’est dans ce type d’article que l’auteur tente généralement de justifier le poids des « User Stories avec date de début et date de fin » et des « tâches estimées en heures », en disant que la direction en a besoin.
Est ce que vous êtes prêts pour quelque chose de différent ?
Pensez à ce que les gens (clients, management, etc) recherchent à travers le graphique de Gantt :
- dans quelle direction va l’équipe ?
- où est ce que nous en sommes à l’instant T ?
- y a-t-il des obstacles ?
Qu’en est-il de la roadmap Agile ?
La bonne nouvelle est que vous pouvez réunir toutes ces informations sous la forme d’un graphique de Gantt, sans compromettre vos valeurs et pratiques Agiles. Résumons ce que vous pouvez faire avec Tuleap pour rendre un diagramme de Gantt agile :
- Premièrement, les dates : une date de début et une date de fin, afin de pouvoir dessiner les barres,
- Ensuite, une idée de la progression: la barre intérieure pour indiquer la complétion des tâches,
- En enfin, en option, les dépendances (est ce quelque chose doit être faite impérativement avant une autre ?) et les enfants (la manière dont les choses doivent être décomposées).
Comment créer un diagramme de Gantt pour la gestion de projet Agile ?
Devinez quoi ? Nous avons déjà tout ce qu’il faut dans notre backlog agile habituel !
- Les dates : une User Story n’a pas de date en soi, mais elle est planifiée dans un Sprint ou dans une Release, qui eux possèdent une date. Récupérons donc cette information pour dessiner les barres.
- Progression : en fonction des habitudes de l’équipe, vous avez déjà une idée des progrès réalisés. Par exemple, certaines équipes suivent l’évolution de « l’effort restant ». C’est ce qui est utilisé pour dessiner les graphiques burn-down. Si l’effort restant est comparé à l’effort initial, il est possible d’en déduire un pourcentage de progrès. Par ailleurs, si l’équipe n’a pas fait d’estimation initiale pour les Stories, il est toujours possible d’obtenir un ratio en comparant le nombre de tâches accomplies sur le nombre de tâches total.
- Dépendances : elles peuvent être signalées par un lien entre deux Stories. Mais dans le monde agile, nous essayons de classer les éléments par ordre de priorité (ce qui est prioritaire est fait en premier).
Il existe un article dédié si vous souhaité apprendre comment construire une roadmap agile pour vos projet.
Pour résumer, les Epics sont planifiés pour les Releases et les Stories pour les Sprints. Vous pouvez voir sur l’image que les dates des Epics correspondent à l’ensemble des Releases. Il en est de même pour les Stories, pour lesquelles vous n’avez pas les détails sur le moment exacte où le travail commencera et se terminera mais ceci est sans importance. Ce qui compte c’est que la Story soit terminée ou non à la fin du Sprint.
Le dernier point est important pour comprendre que la répartition des tâches est à l’origine de toutes les erreurs dans le Gantt traditionnel. Le Gantt est en réalité un très bon outil pour avoir une vue d’ensemble des choses (bien que sa version traditionnelle soit rigide). Dès lors que vous commencez à aller dans les détails (durée des tâches, attribution), cela conduit naturellement à du micro-management. Au lieu d’avoir un management focalisé sur la valeur à livrer, la direction se demandera alors « Pourquoi John a-t-il mis deux heures à accomplir cette tâche en mai ? » ou, pire encore, « Sommes-nous vraiment sûrs que tous les ingénieurs salariés sont facturés à 125% ? ».
Alors est ce qu’un diagramme de Gantt peut être agile ?
La réponse est bien sûr oui, tant que sa représentation n’influence pas la façon dont l’équipe agile travaille. La frontière est mince et c’est là que les outils peuvent vraiment protéger l’équipe. Avec Tuleap, cette frontière est tracée avec l’outil Roadmap qui est une représentation de ce qui se passe dans le backlog du produit. Les équipes continuent à travailler en suivant les pratiques agiles, leur management peut avoir une représentation qu’il comprend mais sans la tentation du micro-management. Le meilleur des deux mondes réuni !