Introduction au développement agile

Article écrit par Ludovic 

Nous avons adopté une approche agile dans notre gestion des développements. Notre objectif est de renforcer la relation entre nos équipes et le client dans le but de produire une solution répondant totalement à ses besoins.

Je vous propose de voir dans cet article notre cycle de développement.

Vue générale

Nous développons un produit en le découpant en unités plus petites — que nous appellerons cartes — pour faciliter leur réalisation. Afin d’être au plus près des besoins du client, nous travaillons par itération de 2 semaines.

Chaque itération s’appelle un sprint et représente un cycle de développement autour d’un produit potentiellement livrable. On entend par ce terme un ensemble de fonctionnalités plus ou moins abouties, mais qui se doivent d’être totalement fonctionnelles et sans bogue.

Certaines ne seront probablement pas disponibles auprès des utilisateurs et feront l’objet d’une nouvelle itération, d’autres seront à l’essai auprès d’un public restreint et enfin une partie sera effectivement mise à disposition.

Les besoins exprimés par le client sont organisés sous différentes catégories. J’utilise ici la terminologie anglaise, car elle est courante dans le métier : use case (cas utilisateur), user story (scénario utilisateur), defect (défaut), etc.

Le périmètre de chaque besoin est analysé puis découpé en feature (fonctionnalité), enhancement (amélioration), requirement (prérequis)… qui rejoindront une liste appelée product backlog. Celle-ci est pilotée par le client — ou product owner pour reprendre la terminologie Scrum.

Une itération consiste à réaliser lors d’un sprint un certain nombre de cartes du product backlog puis de recommencer jusqu’à ce qu’un milestone soit atteint. Ce cycle se poursuit tant que le product owner alimente le product backlog.

Voyons ci-après ensemble les différentes phases qui composent nos sprints.

Phase 0 : préparer le product backlog

La première phase consiste à rassembler l’ensemble des demandes et à les qualifier. C’est le rôle du chef de projet d’établir un certain consensus avec le product owner afin de délimiter le périmètre des demandes et de les transformer en cartes pour le product backlog.

Si certaines demandes ont un périmètre large, il est nécessaire de rédiger une spécification fonctionnelle avec les éléments connus au moment de sa rédaction.

Ce document devra évoluer au fil des sprints. Afin de garder une vision d’ensemble, il est nécessaire de regrouper les différentes cartes associées en une carte de type epic. Celle-ci évolue sur plusieurs sprints et il est probable que d’autres cartes s’y ajoutent par la suite.

Certaines cartes portées à l’attention du product owner sont du fait des équipes techniques. Il est important que le client ait une certaine compréhension du produit tout en évitant le jargon technique. Dans ce cas, il est préférable d’adopter une vision d’ensemble et de fournir des documents d’architecture et diagrammes.

Le résultat produit devant être à l’image du business du client, ce dernier doit définir un vocabulaire métier clair qui sera partagé entre toutes les équipes.

Cette étape se déroule en amont du premier sprint, puis en parallèle de celui-ci en vu du sprint prochain.

Phase 1 : planification du sprint

Cette phase intervient avant le démarrage d’un sprint et se fait en deux étapes :

Étape 1 – Le product owner va prioriser / dé-prioriser les cartes du product backlog en fonction de ses objectifs, mais également des prérequis (parfois techniques). Les objectifs fixés par le product owner doivent être connus par les équipes lors du sprint.

Étape 2 – Les équipes passent en revue chaque carte du product backlog pour décider si elle entre dans le sprint via une méthode basée sur les poids (voir la partie Estimation du poids (ou story points)). Il s’agit d’un engagement : toute carte acceptée doit être réalisée à l’issue du sprint. Les critères d’acceptation sont rédigés en vue de la phase de recette, certains arbitrages pouvant être nécessaire selon les objectifs du sprint.

Pour éviter les mauvaises surprises, il est nécessaire de comparer le poids total du sprint avec la vélocité, c’est-à-dire le poids correspondant aux cartes réalisées dans le sprint précédent. Attention, cet indicateur est fluctuant. Il existe toujours des tâches non-visibles de prime abord : réunion, correctif urgent, problème en production, administratif, actions qualitatives, environnements HS, demande utilisateur, congés, formations, etc.

Enfin, avant d’accepter définitivement, il est bon de voir si les poids sont cohérents entre les cartes.

Pour trouver une vitesse de croisière, on peut commencer avec un nombre réduit de cartes dans le sprint : 2 pendant les premières itérations et plus quand l’équipe prend confiance. Les méthodes agiles favorisent l’adaptation : il est possible d’ajouter en cours de sprint des cartes si ça ne met pas en péril les objectifs et qu’on est certain de pouvoir les réaliser. Il est aussi possible de permuter des cartes en cas de difficulté, mais c’est plus délicat à gérer pour le product owner.

Phase 2 : découpage en tâches

Juste après la planification du sprint, les équipes passent en revue les tâches nécessaires à la réalisation des cartes du sprint. À chaque tâche correspond une carte dans le sprint backlog qui est affectée à un membre d’équipe. Les cartes affectées à cette étape sont traitées dans le courant de la semaine. Nous procédons de nouveau au découpage en tâches la semaine qui suit.

Phase 3 : stand-up

Pendant toute la durée du sprint, les équipes ont un rendez-vous quotidien pour jauger l’état d’avancement des travaux et évaluer s’il y a un risque de débordement. Nos équipes étant en full remote, nous procédons au stand-up par messagerie instantanée Slack ou, en cas de besoin, par visioconférence Google Meet.

Lors de notre stand-up, nous parlons librement, sans ordre spécifique et il n’y a pas d’impératif à échanger (garder le silence, c’est aussi respecter le temps des autres). Afin d’éviter de monopoliser trop de temps, nous restons synthétiques et terminons par un tout d’horizon du sprint backlog. Le stand-up ouvre à discussion par la suite et permet de nous synchroniser.

Phase 4 : revue et rétrospective

En fin de semaine, le chef de projet et les équipes passent en revue la réalisation des cartes du sprint backlog. L’objectif est de faire un état des lieux du travail effectué et de trouver des axes d’amélioration.

Phase 5 : recette

En fin de sprint, une démo est organisée entre les équipes et le product owner afin d’évaluer le travail réalisé. En parallèle, une recette est effectuée côté product owner au fil de la mise à disposition des livrables dans un environnement dédié. La recette peut démarrer tôt dans le sprint si c’est pertinent et se poursuit jusqu’à la démo.

Cette dernière phase clôt notre itération. À l’issue de celle-ci, nous reprenons en phase 1.

Estimation du poids (ou story points)

Les équipes estiment la complexité de chaque carte du product backlog en s’appuyant sur un échange avec le product owner. De cet échange, on déduit les différentes actions à effectuer, mais aussi les critères d’acceptation de la carte.

Une fois les actions identifiées, il faut évaluer la difficulté d’une carte. L’idée est de ne pas donner une estimation en durée, car toute estimation est subjective. De plus, le risque d’estimation biaisée augmente avec la durée de celle-ci.

Il existe 3 façons de se représenter la difficulté d’une carte :

• Le poids (ou story points) : une valeur sur une série de nombres (0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100). Il est classique d’utiliser une méthode dite de Planning Poker pour donner une estimation. Le principe consiste à distribuer à tous les membres un jeu de cartes reprenant la série de chiffres. À la fin de la discussion, tout le monde pose sur la table une carte qui correspond à son estimation de l’effort. S’ensuit un rapide échange afin d’établir un consensus sur le poids finalement retenu.
• La taille de t-shirt : small, medium, large, extra large. Cette méthode est très proche de la représentation par les poids, mais se rapproche plus de l’idée de quantité de travail à fournir.
• Un panier de temps en heure / jours (1h, 2h, 4h, 8h, 2j, 3j, 5j, 10j). Il s’agit ici d’estimer le temps approximatif et de l’associer au panier correspondant.

J’ai également vu des équipes procéder en mélangeant l’estimation au poids et au panier de durée. Les membres découpent les cartes du product backlog en actions (ou tâches) qu’ils estiment en heure ou jours. Le total est placé dans le panier de temps puis converti en story points via une convention adoptée en interne :

Il n’y a pas de méthode idéale ou qui permette d’avoir une valeur juste. Vous devez trouver la méthode qui est le plus efficace pour votre équipe.

Conclusion

Pour avoir expérimenté les projets pilotés par cycle en V, je trouve l’approche des méthodes agiles rafraîchissante. Ce n’est pas évident de l’adopter, car on ne peut pas répondre aussi précisément à la principale question du client : à quelle date mon produit sera livré.

À l’inverse, la question est de savoir ce qu’il est possible de faire en fonction des priorités actuelles, tout en s’adaptant aux priorités à venir. Le mode itératif place le client au centre des décisions et évite les désillusions des projets à rallonge réalisés loin de sa cible.