Le rugby pour de la gestion de projets plus agile
Connaissez-vous les méthodes agiles ? Vous avez sûrement entendu parler de gestion de projet agile ou encore de SCRUM.
La gestion de projet standard est assez rigide. Il est un projet à exécuter, un délai et un budget, et lorsque l’on veut changer quelque chose à ce schéma, cela impacte tout le reste et l’équipe doit refaire valider tout son travail. Il existe cependant un cadre méthodologique plus agile. Il provient du monde de l’informatique et tend à se généraliser y compris dans l’industrie et les services. La gestion de projet agile se dit SCRUM qui signifie "mêlée" en français (comme une mêlée de rugby). Ce cadre méthodologique agile révolutionne la manière dont on gère un projet.
Il permet de délivrer et de modifier un projet, un produit ou une fonctionnalité très rapidement.
Les rôles de la méthode agile SCRUM
Il y a l’équipe qui est composée de développeur, d’architecte, de testeur et de tous autres métiers nécessaires à la réalisation du projet. (6 à 10 personnes)
Le « Product Owner » ou chef de produit représente le client. Il définit les spécifications fonctionnelles et établies la liste des priorités de ce qu’il faut développer, c’est aussi lui qui valide les fonctionnalités.
Le SCRUM Master est garant du respect des processus SCRUM et s’assure d’une bonne communication entre les membres de l’équipe.
Il y a également du coach agile en support qui aide à trouver les bonnes voies pour réaliser les tâches et atteindre les objectifs et qui cherche l'engagement des collaborateurs.
Le processus de la méthode agile SCRUM
Le processus commence par une "user story" ou histoire de l’utilisateur en français. Il s’agit de décrire l’expérience utilisateur en utilisant le langage, le vocabulaire et la terminologie de l’usager. Chaque user story comporte :
Un identifiant, c’est-à-dire un nom qui décrit la fonction du produit de manière succincte
L’importance, c’est-à-dire une valeur qui définit la priorité de la story
Une estimation du travail nécessaire
Une démonstration qui est un test simple de la story qu’il faudra valider et les notes qui comportent toutes autres informations nécessaires à la réalisation de cette story.
De cette user story va émaner des exigences. Elles sont hiérarchisées avec le client dans ce que l’on appelle un « product backlog ». C’est une sorte de carnet de commandes pour le produit. Le product backlog est un miroir de ce qu’il faut faire pour réaliser les besoins du client et délivrer l’user story. Ce « product backlog » va constamment évoluer pour refléter les nouveaux besoins. Une fois que l’on est d’accord sur l’user story et les exigences, c’est-à-dire le product backlog, il est temps de se lancer dans la réalisation du projet. Celui-ci sera découpé en plusieurs itérations que l’on nomme des sprints.
Dans le jargon SCRUM, un sprint commence par une réunion de planification dénommée le sprint planning meeting. Au cours de cette séance, on va aller puiser les éléments prioritaires du product backlog qui seront développés dans les sprints. Dans chaque sprint qui dure de 2 à 4 semaines, il y aura un développement puis un contrôle qualité, c’est-à-dire du test, et enfin une livraison. L’ensemble des livraisons des sprints cumulé se nomme « sprint backlog. Durant les sprints il y a des mêlées, c’est-à-dire des Scrum qui sont organisées chaque jour. Il s’agit de réunions quotidiennes d’un quart d’heure souvent effectuées debout en début de journée. Elles permettent à l’équipe de mesurer l’avancement du projet et de s’assurer de la qualité des livrables et du respect des délais.
Le SCRUM Master, c’est-à-dire la personne qui est garante du respect de la méthodologie Scrum, tient un « burn down chart » qui est un graphique qui décrit l’évolution du projet. Les séances SCRUM sont clairement codifiées. Chaque membre de l’équipe doit pouvoir exprimer et explique trois choses rapidement. Ce qu’il a fait la veille et les éventuels problèmes rencontrés, ce qu’il va faire pendant la journée et s’ils rencontrent des difficultés pour continuer son travail.
Le but est d’identifier et de communiquer les éventuels problèmes mais pas de les résoudre pendant cette séance qui doit rester courte. À la fin de la réunion le SCRUM Master aura mis à jour le Burn down chart et déléguer les problèmes identifiés pendant le meeting aux membres de l’équipe. À la fin du sprint, autre meeting sera organisé. Le sprint meeting review, il s’agit de présenter la solution au client sous forme de démonstration et d’avoir son retour. Les éventuelles améliorations suggérées et les problèmes rencontrés seront alors ventilés dans le product backlog et priorisé ensuite dans des sprints.
Ce cadre méthodologique est conçu sur des cycles de développement court durant lesquels on s’adapte constamment tout en maintenant l’utilisateur au centre. Les progrès sont aussi très visibles, que ce soit sur le burn down chart ou sous forme de démonstration lors d’un sprint meeting.
En résumé, un processus SCRUM se déroule de la manière suivante.
Tout d’abord, le product owner définit le périmètre du projet et compile les fonctionnalités voulues par les utilisateurs sous forme d’User Story
Le product backlog regroupe les éléments à développer pour réaliser l’User Story
Le développement est itératif par sprints de 2 à 4 semaines
Un sprint (Débute par un sprint planning meeting; Comporte des Scrums chaque jour; Se termine par un sprint meeting review)
Les changements/nouveaux développements sont intégrés au Product Backlog
SCRUM change les règles de la gestion de projet et permet de gagner en efficacité.