Les méthodes dites agiles sont à la mode dans le domaine informatique. L’objectif reste le même. Répondre au cahier des charges de la manière la plus efficace. Réaliser le chantier ou la commande du client et s’assurer qu’il soit content. Il faut donc être rapide et efficace.
À ces fins, le chantier peut être organisé de plusieurs manières. On a vu le cycle en V qui répond au besoin si le projet n’est pas trop important. Autrement, le chantier doit être découpé en sous-chantiers. Et se pose alors une question d’organisation des sous-chantiers entre eux.
Mais les méthodes traditionnelles sont dépassées. Au diable l’ancien et place au modernisme.
La méthode agile à la mode est la méthode Scrum. Ce terme signifie ‘mêlée’ en anglais. Il renvoie à l’image du rugby mais pas celle qui laisse le terrain à l’état de chantier à la fin du match.
Un projet organisé par cette méthodologie distingue trois catégories d’intervenants :
- Le client représenté par un groupe d’utilisateurs qui vont exprimer leur besoin.
- Le product owner (ou PO, propriétaire du produit en français) qui va recueillir les besoins des utilisateurs et organiser la prise en compte de ces besoins dans le produit livré
- Et une équipe de développeurs plus ou moins spécialisés qui vont réaliser le produit.
La méthode Scrum est une méthode itérative. Concrètement, le produit final, se construit étape par étape. Et la première étape doit fournir un produit utilisable par les utilisateurs même si toutes les fonctionnalités ne sont pas présente. Vous voulez une voiture, au début on vous fourni un châssis, 4 roues, un moteur, un volant, …. Le minimum pour que la voiture roule sans danger. Le carénage, la batterie, … seront fournis plus tard. Et encore plus tard, l’ABS, le radar de recul, des améliorations du moteur, de la boîte de vitesse, …
Un groupe d’utilisateur, avec l’aide du PO, exprime donc ses besoins dans un journal. Ils décrivent le produit final qu’ils attendent. Ce journal (ou product backlog) est composé de feuilles volantes. Chaque feuille décrit une fonctionnalité attendue dans le produit final. Le journal contient donc plusieurs feuilles.
Ensuite, le PO décide avec les utilisateurs des fonctionnalités qui seront réalisées dans la première version du produit. Il choisit les fonctions indispensables pour que le produit soit utilisable. Les autres fonctionnalités seront réalisées plus tard. Il écrit donc un premier journal qu’il soumet à l’équipe de développement : le sprint backlog.
Sprint parce qu’à partir de ce moment, le projet et lancé. Et chaque itération du projet se nomme un sprint. Un sprint dure entre 2 et 6 semaines (oui, c’est long mais aussi très court pour un projet de construction). Une fois fixée, la durée des sprints ne change plus au cours du projet.
Parlons de la mêlée de développeurs. Il s’agit d’une équipe pluridisciplinaire. Chaque développeur a ses compétences propres et peut intervenir sur d’autres domaines si nécessaire. L’équipe se compose de 4 à 8 développeurs spécialisés dans les domaines différents : développement internet, base de données, réseaux, linux, gestion de configuration, … . Un membre de cette équipe est nommé Scrum master. Il sera le représentant de l’équipe et devra aussi l’animer pour respecter la demande.
Le PO connaît les capacités de cette équipe. Il a donc adapté le sprint backlog pour qu’il soit réalisable. En début de sprint, le PO présente le backlog (et négocie si toutes les fonctionnalités ne peuvent être réalisée). Ensuite, l’équipe s’organise et se répartit les tâches pour mener à bien la mission.
Chaque jour le Scrum master préside une réunion (une mêlée) de 15 minutes maximum pour faire un point sur l’avancée et répartir les tâches entre les membres de l’équipe. Durant le sprint, l’équipe va réaliser les besoins exprimés dans le backlog.
Pendant le sprint, le PO continue à dialoguer avec les utilisateurs pour les aider à exprimer les besoins, les prioriser, …. Lors des sprints suivants, les utilisateurs ayant accès à la première version du produit, en plus d’exprimer de nouveaux besoins, feront des retours sur ce qui ne fonctionnent pas.
Mais revenons à ce premier sprint. Celui-ci se termine et le scrum master, avec le PO, présente la première mouture aux utilisateurs. Cette réunion est critique parce qu’il n’y a qu’une seule première fois. Si tout le monde a travaillé correctement, les utilisateurs sont satisfaits, et les autres fonctionnalités attendues par les utilisateurs seront réalisés dans les sprints suivants. Sinon, il y aura plus de sprint. Le PO se chargeant de réaliser des sprints backlog plus légers pour que l’équipe de développement améliore la qualité du produit livré.
Les avantages de cette méthode ? Les utilisateurs ont une réponse à leurs besoins très rapidement. Le produit est réajusté rapidement.
Cette explication de la méthode Scrum ne satisfera pas les puristes, mais cette méthode n’est pas appliquée partout de la même manière. Je ne décris ici que les grandes lignes. Si vous voulez plus de détails, je vous renvoie à :
- une vidéo Youtube simple et efficace : “La Gestion de Produit Agile en deux mots”
- Un excellent tutoriel diffusé sur le site www.developpez.com : “Scrum et XP depuis les Tranchées”
Dans le prochain épisode, José reprend du service. Son patron décide d’appliquer la méthode Scrum.