Cet article présente un retour d’expérience sur plusieurs années pendant lesquelles nous avons mis en place de la méthodologie agile, principalement Scrum, dans notre contexte de développement et de recherche scientifiques.
En préambule, quelques articles basiques permettant de comprendre les principaux fondements de ces méthodes :
Au fil des différentes projets de développement encadrés et réalisés par les ingénieurs du SED, nous avons progressivement convergé vers une méthodologie que nous proposons aux EPI bénéficiant d’un support ingénieur pour leurs développements logiciels.
Jeu de rôle
Certains rôles doivent être tenus a minima : le client et le scrum master (le développeur s’il est seul).
Il est important que la personne qui attend d’obtenir un résultat de développement soit là pour se focaliser sur le "quoi" développer. Le scrum master (le développeur lorsqu’il est seul, éventuellement accompagné de son référent SED) se focalisant plutôt sur le "comment" réaliser les choses, notamment à quel niveau de détail, avec quelle techno et en combien de temps.
Dans tous les cas, même si chacun peut avoir une opinion sur ces différents aspects, il est important de passer dans ce fonctionnement "jeu de rôle" pour assurer un bon déroulement de la méthode.
Notion de cycle
De façon à avancer par petits pas, les méthodes agiles proposent de travailler sur des cycles courts, avec la production d’un livrable (démonstrateur, code fonctionnel) à chaque fin de cycle. Plusieurs durées sont possibles : pour des preuves de concept (PoC) de quelques mois, 1 à 2 semaines peuvent suffire, pour des projets de développements de plus longues durées, des cycles de 3 à 4 semaines sont mieux adaptés.
Un des atouts de la méthode est de raisonner de façon temporelle en adaptant les objectifs à la durée plutôt que le contraire.
L’ensemble des développements se font sur la cadence de cycles successifs, en veillant à préserver des périodes de "relâche" de courte durée entre les cycles pour que les ingénieurs aient le temps de vaquer à d’autres occupations (professionnelles) que le projet de développement lui-même (veille techno, état de l’art, etc.).
Chaque cycle suit alors la même chronologie :
- Réunion de début de cycle (1h30 pour un cycle d’un mois, 30 minutes à 1h pour un cycle d’une semaine)
- Développements planifiés au cours de la réunion de début de cycle
- Réunion de fin de cycle (30 minutes pour un cycle d’un mois, 10 à 20 minutes pour un cycle d’une semaine)
- Période de "relâche" (1 WE à 2 ou 3 jours peuvent suffire)
Ces cycles s’inscriront plus largement dans le projet de développement, et il sera important que les livrables successivement produits atteignent les jalons fixés initialement.
Réunion de début de cycle
Pour débuter chaque cycle, il convient de définir un cahier des charges et une roadmap minimale pour la période.
Pour cela, la réunion se déroule en plusieurs étapes.
- Fixer les dates des échéances et la quantité de temps développeur disponible pour le cycle
on note la date de début effectif de l’activité de développement première demi-journée suivant la réunion de début de cycle par exemple), la date de réunion de fin de cycle et le nombre de "jetons" disponibles pour ce cycle. Le jeton est l’unité de temps la plus petite utilisée pour estimer la durée des tâches ultérieurement. Pour un cycle d’un mois, on prendra des jetons d’une demi-journée, pour des cycles d’une semaine, plutôt d’une à deux heures. On peut aussi fixer la date de la prochaine réunion de début du cycle suivant, de façon à programmer le temps de relâche. - Lister les fonctionnalités souhaitées pour ce cycle
le client expose les fonctionnalités qu’il a envie ou besoin de voir lors de la démonstration de fin de cycle prévue. Le scrum master (développeur) veille à comprendre précisément à quoi le client s’attend (GUI, cas d’utilisations, données, visualisation, etc.) et doit être en mesure de préciser ce qui est faisable techniquement (identifier et contourner les éventuels verrous techniques). Cette phase est cruciale et conduit à de nombreux échanges permettant de bien définir et analyser le besoin du demandeur. - Evaluer la durée de chaque tâche
on utilise pour cela la méthode du poker planning permettant d’estimer le nombre de jetons utiles à chaque tâche (Wikipédia Planning Poker), mais directement à mains levées, sans cartes (comptage 1-2-3 puis chaque personne en capacité de le faire montre le nombre de jetons estimés pour réaliser la tâche).
Si l’écart entre les estimations est trop important, on demande à celui qui a fait la plus longue estimation, car il a soit anticipé des difficultés que les autres n’ont pas vues, soit sur-interprété le contenu de la tâche. Dans tous les cas, il est important de bien préciser les choses entre le client et le développeur, puis de refaire une estimation une fois les incertitudes levées. - Arbitrer et finaliser la liste des tâches / fonctionnalités à réaliser
in fine, il est maintenant possible de compter le nombre de jetons nécessaires à accomplir l’ensemble des tâches avec le niveau de détail attendu.
Plusieurs scénarios à ce stade :
- pas assez de tâches : on indique aux clients de demander plus de fonctionnalités dans ce cycle (cas rare)
- le timing estimé colle parfaitement avec le nombre de jetons disponibles (ça arrive)
- le nombre de jetons prévu initialement est trop petit, on peut:
a. supprimer des tâches (les moins prioritaires)
b. faire certaines tâches plus rapidement (ou moins bien)
c. ajouter quelques demi-journées en décalant la réunion de fin de cycle
Le scrum master (développeur) envoie une roadmap (emploi du temps détaillé, planning du cycle) au client comme compte-rendu de cette réunion. ceci permet de garder trace des ces échanges riches si nécessaire d’y revenir ultérieurement, mais aussi d’anticiper les périodes où le développeur aura besoin de certaines information ou données que le client doit lui fournir.
Développement du prototype
Le développeur s’efforce de suivre la roadmap établie initialement. Il arrive (souvent) qu’une tâche dure au-delà de ce qui était initialement prévu, ou que l’on parvienne à anticiper que le nombre de jetons estimé sera insuffisant pour achever la tâche au niveau fixé. Dans ce cas, le développeur doit solliciter le client en cours de cycle pour adapter le programme de travail : diminution des objectifs (on diminue la "qualité" de ce qui doit être fait sur cette tâche) ou suppression de certaines tâches. Dans tous les cas, le client reste le décideur de ce qui est le plus important pour lui.
Réunion de fin de cycle
La réunion de fin de cycle doit rester courte et focaliser sur une présentation du livrable (une démonstration complète du logiciel développé / amélioré) est idéal.
Dans cette réunion, le développeur montre le résultat de son activité, en précisant à quelle tâche chaque partie de la démonstration répond.
