Être agile ne signifie pas ne pas savoir où l’on va. Être agile signifie plutôt être flexible tout au long du processus à entreprendre. D’un côté les approches agiles promeuvent plus de transparence, de l’autre côté les roadmaps des produits créent cette transparence. Avec la complexification des projets, embarquant des dizaines, voire des centaines de personnes comme dans le cas de l’agilité à l’échelle, il est crucial de synchroniser les équipes et presque inévitable de passer par une planification long terme. Tuleap offre une solution pour partager la vision globale du projet au fil du temps. Voyons ensemble comment créer une Roadmap Agile dans Tuleap.


dashboard roadmap

Roadmap Agile, de quoi parle-t-on ?

Une roadmap est à la fois une vision produit et un plan

Une roadmap (feuille de route en français) représente un plan stratégique de haut niveau qui sert à illustrer le développement escompté d’un produit au fil du temps. Les Product Owners (PO) et les Product Managers utilisent des roadmaps pour mettre en avant les nouvelles fonctionnalités à développer et le moment où elles seront livrées. La roadmap est un véritable outil de travail dans le quotidien d’une équipe car elle prédéfinit l’évolution du produit en question. Dans un contexte agile (et par ailleurs dans tout processus de développement produit), elle se révèle très utile pour partager la vision produit.

Une fois la roadmap établie, il est opportun de la partager avec l’ensemble de l’équipe produit pour que chacun des membres comprenne la direction et vision produit. C’est une pratique très récurrente des méthodes d’agilité à l’échelle, que l’on retrouve notamment dans SAFe, où plusieurs équipes différentes préfèrent partager entre elles une seule et unique roadmap produit. 

kanban outil agile

Les roadmaps produit dans l’univers agile

Dans l’univers agile, une roadmap est tout d’abord une déclaration d’intention. Elle ne peut donc pas être une roadmap figée ou l’addition de délais stricts à respecter. Elle devrait plutôt représenter un plan incrémental ouvert au changement. Et une roadmap qui ressemble presque à un diagramme Gantt, peut-elle être agile ? Pour y répondre, lisez l’article de notre CTO Manuel « Comment utiliser un diagramme de Gantt pour la Gestion de Projet Agile ? » .
Car, oui, les plans sont amenés à changer, tout comme votre roadmap.
Une roadmap agile peut prendre la forme de :

  • Une roadmap basée sur des thèmes ou des epics : ce type de représentation est très utile pour la visualisation de longues plages de travail sur plusieurs itérations. Dans Tuleap, si vous souhaitez aller plus loin par rapport à un seul epic, vous pouvez explorer ses fonctionnalités enfant.
  • Une roadmap basée sur de grandes étapes (« milestones ») à franchir : créez votre roadmap produit par itérations ou sprints, sans forcément associer ces sprints à des dates précises. 
  • Une roadmap basée sur un mix de plusieurs méthodes : si votre projet intègre encore des modules en waterfall (cycle en V), votre roadmap produit peut aussi afficher des dates en fonction des semaines.

Renforcer la transparence de la roadmap

Il arrive encore assez souvent que les Product Owner (PO) créent leurs roadmaps dans des vieux (et terribles) documents Excel ou PowerPoint. Mais ils peuvent faire mieux. Ils peuvent améliorer la manière dont ils conçoivent et partagent une roadmap stratégique. Ils peuvent élaborer une roadmap produit beaucoup plus réaliste, qui corresponde mieux au phases de développement dans la vraie vie.

La roadmap Tuleap est configurée et affichée directement dans l’espace de travail d’une équipe, non pas dans d’autres feuilles de calcul. Finalement, cela encourage la participation et responsabilisation de toute personne engagée dans le projet et permet également d’avoir un diagramme plus proche des réalités du terrain. 

Les outils Tuleap pour créer sa roadmap

Pour créer une roadmap dans Tuleap, vous aurez besoin de 2 choses :

  • activer le widget « Agile Dashboard » dans votre projet et le configurer pour Scrum,
  • le widget « Roadmap

À noter : dans Tuleap, une roadmap est un widget affiché dans un tableau de bord projet et ne peut pas être affiché sur un tableau de bord personnel.

Du côté agile, rien à faire. Ni en termes de configuration, ni en termes de pratiques, de nouvelles méthodes pour les équipes. C’est 100% transparent pour l’équipe, qu’il y est un Gantt affiché en haut du tableau de bord ou non. Et c’est plutôt bon signe que l’on ne compromette pas les valeurs agiles à ce niveau-là, pas vrai ? Toute la magie a lieu dans la configuration de Tuleap Trackers, et plus précisément de la sémantique utilisée.

Configurer sa roadmap produit

Tout est une question de sémantique

Vous pouvez zapper ce paragraphe si vous parlez couramment le Tuleap et connaissez par cœur toutes les étapes de configuration.

La fonctionnalité Tuleap Trackers a une structure plutôt générique : ce n’est pas un outil de suivi des bugs ou des user stories, en fait, c’est plutôt un moyen de structurer des données en « trackant » tout type de tickets, de bugs, de tâches… (vous pouvez jeter un œil à cet article pour mieux comprendre le concept de Tuleap Trackers).

Parfois, Tuleap a besoin d’identifier les éléments clés de cet amas de données. Par exemple, s’il y a 3 champs de texte dans un « bug tracker », comment savoir lequel représente le résumé de mon bug ? C’est là qu’entre en jeu le « Titre sémantique ». Les administrateurs peuvent définir quels champs représentent le « Titre », lesquels sont la « Description » etc.

Pour afficher l’information dans la roadmap, l’administrateur va devoir définir :

  • la sémantique liée au « timeframe » (Timeframe semantic)
  • la sémantique liée au « progrés » (Progress semantic)

La « Roadmap Timeframe »

La sémantique Timeframe existe depuis un petit moment et permet de définir une période de temps avec soit :

  • une date de début et une date de fin,
  • une date de début et une durée (en jours)

Depuis la sortie de Tuleap 12.10, « timeframe » évolue et permet désormais une 3ème définition : inherited timeframe. Au lieu d’avoir une date définie, l’artefact va littéralement « hériter » d’un autre artefact. Un peu trop compliqué ? Ok, voyons l’exemple suivant :
Disons qu’un tracker rattaché à une user story hérite de la « timeframe » d’un tracker rattaché à un sprint. Dans ce cas-là, nous avons une user story décrite comme suit : « À la première connexion, l’utilisateur devrait voir un gif d’un alpaga ». Cette story est reliée au sprint n°12, qui démarre le 21 juin et dure 10 jours. Le timeframe de cette story (« À la première connexion, l’utilisateur devrait voir un gif d’un alpaga ») sera donc du lundi 21 juin au 2 juillet. Tout simplement !

La « Roadmap Progress »

La sémantique Progress est la plus récente des sémantiques. Lorsque vous la définissez, Tuleap se charge de reporter le pourcentage de complétion des artefacts. En d’autres termes, vous avez 2 façons de faire :

  • soit en faisant le ratio entre l’effort restant (remaining effort) et l’effort total (total effort),
  • ou en comptant les artefacts liés : le nombre d’artefacts fermés par rapport au nombre total d’entre eux.

Afficher les jalons dans la frise chronologique

En termes de concepts, évidemment qu’il existe une différence notable entre ce que l’on attend des méthodes/outils Agiles d’un diagramme de Gantt. Les jalons (milestones) par exemple. Dans un Gantt en cycle en V, un jalon représente littéralement un point précis à atteindre. Soit vous l’atteignez et vous avez réussi, soit vous n’y arrivez pas, et c’est un échec. Pour les méthodes agiles, ce n’est pas tout à fait pareil, voire complètement l’opposé. L’approche agile est par essence dans la continuité : il y a donc beaucoup plus de jalons (releases, itérations…) mais ils représentent une durée, une période d’accomplissement, un chemin à parcourir et non un point d’arrivée.

Avec le widget Roadmap, cette information contextuelle peut être affichée tout en haut de la frise, dans le ruban qui correspond à la périodicité :

agile roadmap timeline
Ruban chronologique de la Roadmap avec les Releases et les Sprints du projet

Comme toujours dans Tuleap, la configuration est entre les mains de l’administrateur. Il peut décider d’afficher n’importe quel type d’information :

agile-Rodmap-widget-configuration
Configuration du widget Roadmap

Une Roadmap avec une vision long terme

Les diagrammes de Gantt peuvent tout à fait être utilisés pour représenter une vision long terme. Il est vrai que cela peut sembler un peu contradictoire avec l’approche traditionnelle Agile, pourtant, il y aura toujours un besoin sous-jacent de vision moyen-long terme. C’est bien connu, les équipes agiles donnent plus de valeur au fait d’être réactif face aux changements plutôt qu’à la planification à l’avance. Mais même si tout le monde sait qu’au final ce n’est pas forcément ce qu’il se passera de façon exacte, cela reste un moyen de guider l’équipe vers un but final : « voici ce vers quoi nous allons ». Selon la méthode SAFe par exemple, « La roadmap est un calendrier d’événements et de jalons qui communiquent les livrables de la solution planifiée sur un horizon de planification ».

Il est donc complètement possible de construire une roadmap avec une vision long terme dans Tuleap. Pour être honnête, c’est un peu « tricky » mais ça fait l’affaire 😉

Dessiner le futur avec les releases et les « pseudo releases »

Dans votre tableau de bord Agile, vous allez pouvoir créer des « pseudo jalons » qui représenteront le futur. Classiquement, vous pouvez choisir de parler en trimestre ou semestre.

milestones-for-agile-roadmap
« Pseudo jalons » pour préparer la Roadmap

Si vous suivez cette configuration, vous aurez une release actuelle « en cours » (par ex. « Release 4.0-Été ») en parallèle des autres « pseudo » releases (par ex. « 2021 Q3, Q4 »). Ces « pseudo » releases seront toujours là, planifiées, mais leurs noms et leurs dates changeront.
Par exemple, dès que les releases du troisième trimestre 2021 sont planifiées avec leur contenu réel (version 5.0 et 6.0), les pseudo releases se déplaceront automatiquement vers 2022 (S1 2022 a été scindé en Q1 2022 et Q2 2022).

jalons roadmap
Les releases de l’été sont réelles, les « pseudo releases » se déplaceront vers 2022 si nécessaire

Dans la Roadmap Tuleap, ces changements apparaîtront dans le ruban rouge :

pseudo releases de la roadmap
« Pseudo releases » dans la Roadmap

Contenu des « pseudo » releases

On peut donc créer des « pseudo releases » pour matérialiser le futur ; mais qu’en est-il du contenu de ces versions ? La plupart du temps, dans les versions réelles, nous planifions des user stories. Ces stories sont bien définies avec des critères d’acceptation. C’est une bonne pratique d’avoir des histoires d’à peu près la même complexité. Mais cela ne rentre pas dans les pseudo releases du trimestre/semestre. Cela impliquerait d’avoir des stories vraies et fausses dans notre backlog. Et bien que ce soit une solution pour les « pseudo releases », cela ne peut pas être fait avec des « pseudo stories » car il y en aurait trop.

La solution classique est de faire appel aux « Epics » (ou Thèmes, Fonctionnalités, etc.). Les « epics » servent à diviser un élément ; mais ils ne sont pas assez détaillés pour être une vraie user story. Comme vous l’avez probablement déjà compris, alors que les releases réelles continueront d’être remplies de user stories, nous utilisons donc les epics dans les « pseudo versions » pour façonner la roadmap.

Parce qu’il ne faudrait pas polluer le backlog avec tous ces epics, nous allons tout simplement les relier au niveau des artefacts, comme suit :

epics, pseudo releases et artefacts
Les Epics sont reliés aux pseudo releases au niveau de l’artefact

En termes de configuration, les epics vont hériter des timeframes des releases. Et le widget roadmap sera donc configuré pour afficher tant ces epics que les user stories. Tada !

roadmap agile avec Tuleap
Roadmap affichant ce qui est en cours et ce qui est planifié

Envie d’en savoir plus sur l’agilité ?