La gestion de projet standard est rigide. Il y a un projet à exécuter, un délai et un budget. Et lorsque l’on veut changer quelque chose dans ce schéma, cela impacte tout le reste, et l’équipe de projet doit refaire valider tout son travail. De nos jours, il faut une approche plus agile.
Ce cadre méthodologique agile existe. Il provient du monde de l’informatique, mais tend à se généraliser, y compris dans le marketing. Son nom est SCRUM.
« SCRUM » signifie « mêlée » en français. Cette méthode agile révolutionne la manière dont on gère un projet. Son nom provient du rugby, sport dans lequel l’équipe effectue une mêlée. Il permet de délivrer et de modifier un projet, un produit ou une fonctionnalité très rapidement.
L’agilité de la méthode SCRUM
Mettons que vous souhaitiez créer un produit. Une application par exemple. Vous avez toutes sortes de demandes et d’exigences, de la part de clients, de la part des commerciaux, des utilisateurs ou encore de la Direction.
Comment gérer un tel développement de manière rapide et agile, sans se laisser noyer ? Grâce à la méthode agile SCRUM. Elle est basée sur des rôles :
Les rôles de la méthodologie SCRUM
- Il y a l’équipe. Elle est composée de développeurs, de testeurs, d’architectes et de tout autre métier nécessaire à la réalisation du projet. Elle est idéalement composée de 6 à 10 personnes mais peut être beaucoup plus grosse.
- Le Product Owner ou « chef de produit » représente le client. Il définit les spécifications fonctionnelles et établi la liste des priorités de ce qu’il faut développer. C’est aussi le Product Owner qui valide les fonctionnalités.
- Le Scrum Master est garant du respect des processus SCRUM. Il s’assure d’une bonne communication entre les membres de l’équipe.
Maintenant que les rôles sont définis, parlons du processus.
La gestion de projet agile de SCRUM
Tout commence par une « User Story », en français « l’histoire de l’utilisateur ». Il s’agit de décrire l’expérience-utilisateur en utilisant le langage, le vocabulaire et la terminologie de l’usager. Par exemple : notre appli doit pouvoir donner l’heure de tous les fuseaux horaires dans le monde. Je tape une ville et elle me donne l’heure locale.
Chaque User Story comporte un identifiant, un nom qui décrit la fonction du produit de manière succincte, l’importance (une valeur qui définit la priorité de la story), une estimation du travail nécessaire, une démonstration (un test simple de la story) qu’il faudra valider et des notes qui comportent toute autre information nécessaire à la réalisation de cette story.
De la User Story, il va émaner des exigences. Elles seront hiérarchisées avec le client dans ce que l’on appelle un « Product Backlog » – une sorte de carnet de commande 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 la User Story. Par exemple : pour l’appli, il faut créer une interface, s’adapter aux changements d’heure, ajouter de fonctionnalités et ainsi de suite.
Ce Backlog va constamment évoluer pour refléter les nouveaux besoins.
Une fois que l’on est d’accord sur la User Story et les exigences (le Product backlog), il est temps de ce 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.
Le Sprint, étape clé de la réalisation du projet
Un Sprint commence par une réunion de planification, dénommé le « Sprint Planning Meeting ». Au cours de cette séance, l’on va aller puiser les éléments du Product Backlog prioritaires qui seront développées dans les Sprints.
Durant chaque sprint, qui durent de 2 à 4 semaines, il y aura du développement, puis un contrôle qualité, c’est-à-dire du test, et enfin, une livraison.
L’ensemble des livraisons des sprints cumulés se nomment le « Sprint Backlog ».
Durant les sprints, il y a des mêlées, des « SCRUM », qui sont organisées quotidiennement. Il s’agit de réunions quotidiennes d’un quart d’heure, souvent effectuées debout en début de journée, qui 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 – la personne garante du respect de la méthodologie SCRUM – tient un « Burn Down Chart », c’est-à-dire un graphique qui décrit l’évolution du projet.
Comment se déroule une réunion SCRUM
Les séances SCRUM sont clairement codifiées. Chaque membre de l’équipe doit pouvoir s’exprimer et expliquer 3 choses :
- 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’il rencontre 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, environ 15 minutes.
A la fin de la réunion, le Scrum Master aura mis à jour le Burn Down Chart et délégué les problèmes identifiés pendant le meeting aux membres de l’équipe. A la fin du Sprint, c’est-à-dire après deux semaines en général, un 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 prioritisés ensuite dans des Sprints.
SCRUM – l’agilité avec le client au centre
Ce cadre méthodologique est conçu sur des cycles de développement courts durant lesquels on s’adapte constamment, tout 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 des Sprint Meeting Review.
En résumé
Un processus SCRUM se déroule de la manière suivante :
- Le Product Owner définit le périmètre du projet et compile les fonctionnalités voulues par les utilisateurs sous forme de User stories
- Les exigences et les développements nécessaires d’une User Story sont hiérarchisés dans le Product Backlog. Celui-ci est susceptible d’évoluer en fonction des nouveaux besoins.
- La réalisation des éléments du Product Backlog s’effectue dans des Sprints, des développements itératifs courts de deux à quatre semaines.
- Un Sprint commence par un Sprint Planning Meeting, dans lequel on prend les éléments prioritaires du Product Backlog. Durant le sprint, l’équipe de projet se voit tous les jours un quart d’heure dans des meetings de mêlée ou SCRUM.
A la fin d’un SCRUM, lors d’un Scrum Meeting Review, l’équipe de projet livre ce qu’elle a effectué pendant le SCRUM au Product Owner, qui va tester la qualité et faire des retours appropriés.
- En fonction des retours-utilisateurs ou du Product Owner, l’équipe de projet va alimenter le Product Backlog et améliorer le produit. Et ainsi de suite, pour toutes les fonctionnalités des User Stories.
Vous le voyez, SCRUM change les règles de la gestion de projet et permet de gagner en efficacité.
