Comment construire une roadmap

Aujourd’hui je souhaiterais vous parler de mon nouveau poste. Ayant changé d’entreprise, mon rôle dans ma nouvelle équipe est de suivre le développement d’un « logiciel » web. Pour ce faire, j’ai dû mettre en place une roadmap.

Les étapes pour construire une roadmap

Comment ai-je procédé ? Etant assez novice finalement dans ce domaine, si vous avez des remarques et des conseils, comme toujours, je suis preneur.

1/ Tout d’abord, j’ai étudié l’existant, de manière sommaire car mon manager était assez pressé.

2/ Il n’y avait pas de procédure de suivi des tickets et des commit (SVN, Git, etc.). J’ai donc écrit sur notre intranet la procédure à suivre quant au suivi des tickets. Mon but étant que tout travail doit être logué, tracké et donc faire l’objet d’un ticket. Nous utilisons un outil interne pour cela mais ma préférence dans les outils sur le marché vont vers Jira.
J’ai naturellement agrémenté mes procédures de schéma. Un apport visuel est toujours intéressant.

3/ J’ai ensuite réfléchi au cycle de développement de l’application. Entre la correction de bugs, les demandes d’amélioration prioritaires et rapides (hors roadmap) et les nouveautés liées à la roadmap, j’ai donc mis en place un cycle d’1 mois. Durant ce mois, les nouveautés liées à la roadmap ne pourront pas (ou peu) changer. Pourquoi 1 mois alors que les méthodes AGILE préconisent 2 semaines ? Tout simplement car je n’ai pas une équipe dédiée au projet…

4/ J’ai ensuite réfléchi au versionning de l’application, lié à la roadmap. Je me suis arrêté à 3 niveaux X.Y.Z :

  • X : Version principale de l’application. J’ai pris le parti d’1 version par an, en donnant un thème à cette version (sécurité, rapidité, nouvelle charte graphique, refonte du old core, etc.)
  • Y : Cette version est liée directement à la roadmap. Tous les mois, son numéro est incrémenté
  • Z : Cette version est donc liée à la correction de bugs et aux modifications rapides prioritaires

5/ Il est important d’avoir un roadmap meeting tous les mois. Ce meeting permet de confirmer les priorités de développement du cycle prochain (idéalement le meeting devrait se situer avant la fin du cycle en cours) et de définir les priorités du cycle suivant. Il permet aussi un retour sur l’actuelle version, sur les tests du précédent cycle.
N’oubliez pas d’avoir toujours un backlog à jour ! N’hésitez pas à demander à votre PO de le mettre à jour et confirmer les priorités !

Voilà le travail que j’ai effectué et qui semblait convenir. Cependant, une nouvelle est arrivée en cours de route, mettant en pause la roadmap… Du coup je n’ai pas encore de retour d’expérience de cette mise en place.

Vous aimerez aussi...

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *