Vous avez déjà entendu parler de « Product Owner », « Scrum master », ou « Sprint » ? Non ? Ça tombe bien parce qu’aujourd’hui on parle de la méthode agile SCRUM
Je vais essayer de vous expliquer les grands principes de cette méthodologie et comment je les ai appliqués à mes projets.
Dans un projet, tout part du client (ou de l’utilisateur final).
Dans une team Scrum, il y a plusieurs personnes / équipes :
- Le Product Owner
- Le Scrum Master
- L’équipe technique
Le « Product Owner » (ou propriétaire du produit) sera le garant des fonctionnalités du produit final voulu par le client. Il doit être en mesure de comprendre les besoins du client et des utilisateurs finaux. Il sera le lien entre le client et l’équipe technique.
Le Scrum master est là pour être le garant du respect de la méthode SCRUM, que les tableaux de bord soient tous mis à jour, que les réunions et les plannings soient respectés. Il est le gourou de la méthode , le pilote !
L’équipe technique est en charge de la réalisation de l’application (ou du projet) du client. C’est la partie « opérationnelle ».
Passons maintenant aux différentes étapes.
Les différentes étapes de la méthode agile SCRUM
1ère étape – La définition du « Product Backlog » et des « User stories »
Le Product Owner (PO) définit la liste des fonctionnalités et des attentes du client (les fameuses « User Stories ») dans un registre qui s’appelle le « Product Backlog ». Cet élément est en lien constant avec le client et est mis à jour en temps réel. C’est en gros, la feuille de route vivante du projet.
Dans un Product Backlog, on va donc retrouver les volontés du clients que l’on va découper en 2 niveaux de fonctionnalités:
- Les EPIC (grosse fonctionnalité : exemple : Gestion d’un panier d’achat, gestion d’une liste d’achat)
- Les Users Stories (fonctionnalité simple définie suivant un format fixe : En tant que (persona), je souhaite (le besoin), afin de (l’objectif), exemple : En tant qu’internaute, je souhaite ajouter des produits à mon panier afin de créer ma commande. )
Chaque EPIC sera découpée en plusieurs User Stories.
Ensuite chaque User Story se verra appliquer un « Story Point » (une mesure arbitraire de difficulté 1 pour “très facile”, puis 2 pour “facile”, 3 pour “plus difficile”, 5 pour “encore plus difficile”, etc. Généralement correspond à une suite de Fibonacci, une hausse brutale pour intégrer la complexité des tâches et l’incertitude qui va avec.
Point Info : Pour gérer le Product Backlog, j’utilise soit un tableau blanc avec des post-it (Le gros avantage est qu’il n’y ait qu’à lever la tête pour voir le voir), soit un tableau sous Trello par exemple (gratuit)).
2ème étape – Le Sprint Planning Meeting
L’idée est de découper les volontés du client en sous-élément facilement planifiable.
C’est là qu’entre en ligne, le « Sprint Planning Meeting ». C’est une réunion qui servira à sélectionner et à prioriser chaque « User Story » du « Product Backlog » (PB). Elle peut être considérée comme une négociation entre le Product Owner et l’équipe technique.
L’équipe technique traduit ainsi chaque User Story du PB en tâches techniques qui viendront alimenter un autre registre, le « Sprint Backlog » (SB).
C’est simple non ?
3ème étape – Le Sprint
Le Sprint Backlog est constitué de 3 colonnes : A faire, En cours, Réalisé.
Chaque tâche sera affectée à chaque personne de l’équipe SCRUM suivant les compétences de chacun (Développeur / Designer / Devops …) et le propriétaire de la tâche lui affecte un délai pour l’effectuer. Ainsi, il est facile de voir pendant un Sprint si l’équipe tient ses objectifs et ses timings ! Du coup, cela obligera l’équipe à plus d’efficacité !
Ensuite, durant toute la durée du Sprint, chaque jour commence généralement par une mini-réunion de 10 à 15min maxi, debout généralement pour aller plus vite ! Qui s’appelle le « Daily ». Cette réunion est très importante pour garder la motivation de l’équipe et se reposer sans cesse la question du sens de ses actions.
Chaque personne va aborder 3 sujets :
- Ce qu’il a fait hier
- Les problèmes qu’il a rencontrés.
- Ce qu’il va faire aujourd’hui.
Attention, les problèmes rencontrés ne doivent pas trouver de solution durant le Daily. Il s‘agit juste d’exposer le problème et si quelqu’un de l’équipe à la solution, ils verront ça ensemble APRÈS le Daily.
4ème étape – Le Sprint Review
A la fin de chaque Sprint (le vendredi généralement), l’équipe technique présente au Product Owner (et au client s’il est présent) la fonctionnalité développée via une mini démo. Ainsi le PO peut confirmer ou non la fonctionnalité. Cette réunion peut déclencher d’autres User Stories. Le Sprint est ainsi clôturé et on redémarre le nouveau Sprint le lundi suivant.
Également, le Sprint Review sert à identifier ce qui a été fait, les goulots d’étranglements et ce qui aurait pu être mieux fait.
Le pilote !
Et le Scrum Master dans tout ça ? Pour gérer efficacement toutes les équipes, il y a le gourou de la méthode Scrum, le Scrum Master.
Il est là pour s’assurer que toute l’équipe suive les principes Agile SCRUM et que les Backlog (Sprint et Product) soient maintenus à jour. Il s’assure également de l’efficacité de ses équipes via quelques tableaux de bord simples à réaliser.
Statistiques
Le Burnup
Ce graphique permet d’afficher clairement le travail accompli sur le projet en comparaison au travail total attendu par le client.
On le présente comme suit :
- Axe des abscisse : l’évolution du temps (en sprint ou en semaine)
- Axe des ordonnées : La charge de travail (heure / jours / Story Point / Nombre de tâches etc.)
Burndown
A l’inverse, le Burdown permet de visualiser le travail restant à accomplir. Ce que j’aime dans ce graphique, c’est qu’il permet également de visualiser si l’équipe est efficace ou non.
On le présente comme suit :
- Axe des abscisses: L’évolution du temps en jours (ou autres)
- Axe des ordonnées: La sommes des story points (difficulté des User Stories)
La première ligne bleue représente la somme des story points restant à effectuer.
La seconde ligne en rouge est une ligne droite correspondant à l’idéal de développement. (de 100% à 0 dans le temps imparti)
En pointillé, il s’agit de la courbe de tendance de la ligne bleue (on voit si le projet risque de déborder ou non).
Pour visualiser l’efficacité de l’équipe, il suffit de regarder la ligne bleue :
- Si elle est sous la ligne rouge, votre équipe est performante
- Si elle est au-dessus, votre équipe n’est pas efficace, il y a quelques choses à corriger.
Velocity
Le dernier graphique à intégrer dans votre gestion et la vélocité.
Il s’agit de déterminer l’effort qu’est capable de fournir une équipe de développement pour réaliser les tâches d’un sprint.
Elle s’exprime en nombre de Story Point. C’est tout simplement la moyenne du nombre de points livrés sur plusieurs sprints.
Si en moyenne, vous pouvez livrer 20 Story Point sur une moyenne de 10 sprints, le jour où vous planifiez 40 points en 1 sprint, vous savez que ça ne fonctionnera pas.
Vous l’aurez compris, le Scrum Master est le garant de l’efficacité de son équipe, il doit être au petit soin pour sa team. Il doit veiller à ce que son équipe ait tous les outils nécessaires et les formations nécessaires pour réaliser le projet. Et si le fait de leur apporter un café chaque jour aide l’équipe à être plus performante, il fera le service !
Conclusion
La méthode Agile SCRUM est donc à privilégier pour des moyens et gros projets. C’est une méthode utile à plusieurs niveaux :
- Gestion de projets
- Management de l’équipe
- Bienveillance de ses collaborateurs
- …
Autant, je l’ai utilisé dans de nombreux projets informatique, autant cette méthode peut s’adapter à n’importe quel type de projet. Que vous soyez dans le batiment, l’industrie ou encore le marketing …
Quelques soient la taille de votre entreprise également, ETI, PME et TPE, vous pouvez donc utiliser la méthode SCRUM pour gérer vos projets.
Si vous souhaitez en savoir plus ou que nous vous accompagnons dans la gestion de vos projets, vous pouvez nous contacter par email sur contact@abymap.fr ou par téléphone au 06.56.68.25.35.
Voilà, vous savez tout de la méthode agile SCRUM ! Lisez aussi notre article sur la méthode agile LSD en cliquant ici.