Dans cet article de blog, je vais vous montrer qu’il est tout à fait possible d’utiliser une représentation graphique sous forme de diagramme Gantt lorsque l’on travaille en mode Agile (dans sa variante Scrum) sans que cela compromette les pratiques agiles. Dis comme ça, on y croirait presque pas. Au sein des communautés agiles, il existe depuis longtemps un vrai débat (voire combat) contre les diagrammes de Gantt. Considéré comme vieux jeu même par les moins agiles d’entre nous, comme le véritable totem du cycle en V, Gantt s’est vite révélé être le premier évincé à l’ère de l’Agilité. Vu comme ça, le diagramme Gantt ne pourrait donc jamais être considéré comme agile, pas vrai ? Eh bien, laissez-moi vous dire que ce n’est pas totalement vrai. Je vous explique.
Les arguments contre les digrammes Gantt
Soyons honnêtes, c’est plutôt la façon dont les chefs de projet utilisent ce diagramme qui rend Gantt plus ou moins agile. En fait, la pire erreur qu’on puisse faire est de prétendre que Gantt reflète une représentation fidèle de la réalité. Encore une fois, ici ce n’est pas la faute du diagramme lui-même, ni du chef de projet. C’est plutôt la faute des personnes qui se servent du diagramme, car en regardant cette représentation simplifiée des choses, elles se disent que c’est ce qui se passe vraiment. Mais qui sont ces lecteurs du diagramme Gantt ? Les directeurs et les clients, par exemple… les personnes le moins au courant de tous les détails du projet.
Rien ne va avec le diagramme Gantt
C’est tout simplement faux. Les choses commencent toujours un peu plus tôt, ou se terminent un peu plus tard ; l’état d’avancement d’un Gantt est en fait un peu comme la barre de progression Windows. Autrement dit, les équipes ne font que mettre à jour les moindres détails du projet, les dépendances et les tâches…
Et ce n’est pas la pire des choses ! Non seulement la représentation de l’état d’avancement est erronée et génère donc une charge bureaucratique démesurée, mais la partie de la Roadmap liée à la projection est problématique aussi. La raison ?
Cela est essentiellement dû au principe même de fonctionnement du diagramme Gantt. Il faut définir une date de début et de fin bien précises. Et pour établir une date de fin, il faut nécessairement faire une estimation de la charge de travail mais, étant donnée que ce type d’estimation n’est jamais exacte, la date de fin ne peut être qu’erronée aussi. Et malgré ça, le diagramme Gantt impose dans tous les cas de s’engager par rapport à une date bien définie dans tous les cas.
L’essor de l’Agilité
Devinez quoi ? Les méthodes agiles ont progressivement vu le jour en partie pour aller à l’encontre de cette micro-gestion bureaucratique du développement des produits et se concentrer plutôt sur la valeur livrée :
- Faire des estimations approximatives (i.e. méthode T-shirt sizing ou technique d’estimation de projet, Fibonacci ou alors aucune estimation) pour arrêter les discussions infinies pour savoir si une tâche qui aura lieu dans 6 mois va vraiment prendre une ou deux heures.
- Se focaliser sur les user stories (et non sur les tâches) pour livrer une brique logicielle entièrement opérationnelle.
- Suivre des métriques qui mettent l’accent sur la valeur apportée au client au lieu de se concentrer sur les tâches accomplies, comme le cas du burn-up chart des user stories.
Ce qui en résulte est un backlog Agile, organisé en fonction de la valeur fonctionnelle avec une estimation de haut niveau (ou pas d’estimation du tout). Les clients sont satisfaits, car les éléments les plus importants sont livrés en priorité. L’équipe Produit est satisfaite, car elle n’aura plus à garder et suivre des indicateurs qui n’ont aucune vraie valeur. Et enfin, l’équipe Management Produit est également satisfaite étant donné que les nouveaux indicateurs se centrent sur ce qui compte vraiment : la capacité opérationnelle de l’équipe (burn-down chart, vélocité) et ce qui est livré aux clients (burn-up chart).
Donc tout le monde est content, n’est ce pas ?
Et bien, non ! Le top management ne l’est pas car cela signifierait perdre un cher outil que les managers comprenaient bien (même si l’outil était défaillant). En fait, ils ont du mal à appréhender tous ces nouveaux outils agiles et d’ailleurs ils ne sont plus en capacité de faire des prévisions « par eux-mêmes ».
Comment satisfaire tout le monde alors ?
Dans ce genre d’article, c’est le moment où l’auteur va tenter de justifier ce fardeau que sont les « user stories avec une date de début et de fin », « l’estimation de la durée des tâches en heures », car le top management – la direction – en a besoin.
Prêt à entendre quelque chose de différent ?
Réfléchissez à ce que les gens (les clients, la direction, etc.) recherchent sur un diagramme de Gantt…
- Où veut aller l’équipe ?
- Où on en est en ce moment ?
- Y a-t-il des obstacles ?
Qu’est-ce qu’il faut pour créer une Roadmap agile ?
La bonne nouvelle est qu’il est possible d’illustrer toutes ces informations sous forme d’un diagramme Gantt sans aller compromettre les valeurs et pratiques agiles. Voici un rappel de ce dont on a besoin pour créer un diagramme Gantt :
- Tout d’abord, des dates : une date de début et de fin pour tracer des barres ;
- Ensuite, un sentiment de progression : une barre interne pour indiquer l’état d’avancement et d’achèvement ;
- Et, éventuellement, des dépendances (voir s’il y a un ordre de priorité entre les différentes tâches) et des enfants (la manière de décomposer un projet en plusieurs morceaux)
Où retrouver l’information ?
Sans surprise, on retrouve bien tout ce qu’il faut dans notre backlog Agile habituel !
- Les dates : chaque user story n’a pas de date en soi, mais elle est planifiée pour un sprint ou une release. Et vu que ces mêmes sprints ou releases ont une date, cette information est réutilisée pour en créer !
- La progression : selon le fonctionnement et les pratiques de l’équipe, il existe déjà une notion de progression. Par exemple, des équipes suivent l’évolution de l’« effort restant » pour compléter le développement de chaque story. C’est d’ailleurs l’indicateur utilisé pour créer un burn-down chart. Si l’on met en relief l’effort restant et l’effort initial, on obtient le pourcentage de progression. Sinon, si une équipe n’a pas fait d’estimations des stories, on peut toujours calculer ce ratio en faisant une comparaison entre le nombre de tâches fermées et le nombre total des tâches.
- Les dépendances : elles peuvent être établies en reliant deux stories. À noter que dans l’univers Agile on a plutôt tendance à classer tout élément en fonction des priorités (faire en premier ce qui compte le plus).
[ Pour aller plus loin, voici un article entièrement dédié à la création d’une roadmap agile dans votre projet. ]
En bref, les epics sont programmés pour les Releases et les stories pour les Sprints. Comme on peut le voir sur l’image ci-dessus, les dates des epics correspondent à toute la durée de la release. De même pour les stories, il n’y a pas de date exacte marquant le début et la fin du processus, mais ce n’est pas grave. Ce qui est important est de savoir que la story a été développée (ou pas) à la fin du sprint.
Dernier point important, il faut être conscient que la représentation des tâches est la source de tout problèmes dans un diagramme Gantt traditionnel. En fait, ce qui marche assez bien avec Gantt (bien qu’il soit trop rigide) est la possibilité d’avoir une vision d’ensemble sur le projet, par contre les choses se compliquent quand on commence à se focaliser sur les moindres détails (i.e. la durée et affectation des tâches), en passant automatiquement à une micro-gestion. Cela veut dire qu’au lieu de se focaliser sur la valeur livrée, le management sera concentré sur « pourquoi John a mis 2 heures pour accomplir cette tâche en mai ? », ou pire encore, « on est vraiment sûr que tous les ingénieurs sont occupés à 125 % ? »
Le mot de la fin…
Finalement, un diagramme de Gantt peut-il être agile ? Et la réponse est évidemment que oui, tant que sa représentation ne conditionne pas la méthode de travail d’une équipe Agile. Mais la ligne est fine, c’est pourquoi l’adoption d’outils adaptés peut vraiment aider les équipes dans ce cas de figure. Avec Tuleap, cette frontière est bien définie grâce à l’outil Roadmap qui affiche ce qu’il y a dans le backlog du produit. Les équipes continuent donc à travailler en Agile, selon leurs méthodes, alors que le management dispose d’une représentation graphique plus claire et intelligible, tout en évitant de tomber dans le piège de la micro-gestion. C’est ce qu’on appelle profiter du meilleur des deux mondes !