Une méthode Agile : SCRUM
La méthode Agile SCRUM
Suite à notre premier article introductif sur le management Agile, nous allons ici aborder une des méthodes Agiles : SCRUM. Cette méthode itérative et inductible permet de changer les objectifs du projet quelque soit son état d’avancement. Elle est donc idéale pour les projets Web innovants ou dépendants des besoins changeants des utilisateurs.
Principes de la méthode SCRUM
SCRUM, qui signifie ‘’mêlée’’ en anglais, est fondée sur la cohésion, la motivation et l’émulation de l’équipe productive pour l’atteinte d’un objectif commun, ce qui n’est pas sans rappeler l’esprit qui règne dans le rugby.
Cette méthode permet d’accélérer le rythme et la flexibilité lors de la création de nouvelles applications Web. Le projet est mené par une équipe transversale et pluridisciplinaire à travers différentes étapes qui se juxtaposent.
Cette méthode est régie par 3 valeurs fondamentales :
- La communication : fer de lance de la méthode, un langage commun doit être mis en place dans l’équipe, mais aussi avec le client.
- L’inspection : l’équipe doit faire un point dès qu’une étape de production est finalisée afin de détecter les erreurs avant une validation déclenchant le passage à l’étape suivante.
- L’adaptation : plusieurs types de réunions en équipe sont mis en place en amont du projet afin de réadapter le processus de production au plus vite en cas d’égarement.
Bien que SCRUM ait été créée et utilisée initialement par le milieu du développement, elle peut théoriquement s’appliquer à l’ensemble des projets innovants et complexes.
Les acteurs impliqués dans le projet
Pour mener à bien un projet, SCRUM fait intervenir l’ensemble des parties prenantes. Ainsi, le client et les utilisateurs finals du site ou de l’application sont impliqués dès le début de la conception du produit.
Le propriétaire du produit (product owner) représente le client de l’agence mais doit aussi prendre en compte les attentes des utilisateurs de l’application. Sa présence doit inciter l’équipe à maximiser la valeur du projet développé. Le client fait donc partie intégrante du projet et :
- Spécifie les différentes fonctionnalités du produit dans un carnet de produit.
- Priorise le développement des fonctionnalités
- Assure la bonne compréhension du carnet de produit
- Test et valide les développements fonctionnels terminés
Le Scrum Master est le référent en ce qui concerne la méthode de production. Il doit s’assurer que la méthode SCRUM est bien comprise et bien appliquée. Il est un facilitateur de processus et non un manager. Il a en charge :
- La promotion de SCRUM au sein de son équipe, mais aussi au niveau de l’entreprise
- La mise en place des rituels spécifiques à SCRUM
- La création d’un environnement de travail fécond
- La protection de son équipe des interférences extérieures
L’équipe de production n’a pas de rôle prédéfini mis à part la livraison de l’application ou du site par petits incréments. Elle doit pouvoir à tout moment présenter une version ou une étape fonctionnelle du projet. L’équipe est :
- Autonome : c’est elle qui choisit les méthodes de production sous réserve qu’elles soient compatibles avec le management SCRUM. Il n’y a pas de hiérarchie interne, les décisions sont prises d’un commun accord.
- Pluridisciplinaire : l’équipe doit regrouper l’ensemble des compétences nécessaires à la bonne exécution du projet, sans faire appel à l’externalisation de certaines tâches. Les tâches ne sont pas non plus réparties dans des sous-équipes-métiers.
Le lancement du projet : planification de sprint
Le projet Web est caractérisé par le backlog de produit, soit l’ensemble des fonctionnalités à développer. Préalablement au lancement du projet, Le propriétaire du produit doit mettre noir sur blanc le backlog dans un carnet de produit.
Les fonctionnalités sont spécifiées par une user story. Une user story est un élément fonctionnel livrable individuellement au client en un seul sprint. Elle aide à préciser le rôle de l’utilisateur sur le site ou l’application. Exemple : l’internaute doit se connecter avec ses identifiants pour accéder à son compte. Le propriétaire du produit doit prioriser les user stories.
Le projet est ensuite rythmé par des sprints. Un sprint est une période (un mois au grand maximum) à la fin de laquelle l’équipe livre un ensemble de user stories. Une fois la durée prédéfinie, elle restera constante pour tous les autres sprints. Pendant un sprint :
- Les membres du projet restent les mêmes
- La qualité n’est jamais négociée
- la liste des user stories à réaliser peut être modifiée mais négociée entre le propriétaire du produit et l’équipe de production
Chaque sprint est planifié par le Scrum Master et l’équipe de développement. Ils vont définir son objectif général et choisir des user stories du backlog. L’équipe s’engage donc à les livrer à la fin du sprint.
Pour estimer la charge de travail, l’équipe du projet va estimer en point de temps chacune des user stories par une partie de planning poker. Le directeur du produit explique la user story selon la priorité qu’il lui donne. Chaque membre peut alors demander de plus amples explications et s’exprimer. Une fois que tout le monde est clairement informé des enjeux et de la tâche, les membres vont individuellement estimer son ampleur (en user story points) en choisissant une carte de son jeu de planning poker.
Une fois que tout le monde a voté, les cartes sont retournées. L’estimation est validée s’il y a un consensus. Dans le cas inverse, chacun doit argumenter sa position. Les votes auront ainsi lieu jusqu’au compromis final. Certaines user stories seront retenues tandis que d’autres seront mises de coté pour un prochain sprint. Les user stories sélectionnées vont ensuite être reportées sur des post-it avec les points associés. Cette méthode facilite l’échange, le consentement mutuel et l’implication de chacun dans les étapes du projet.
Le sprint est ensuite divisé en tâches indivisibles et estimées à réaliser : les backlogs de sprint. Ces tâches ne sont pas immédiatement réparties. Chaque membre va s’approprier volontairement des tâches lors de l’avancement du sprint.
Le sprint ne s’arrête pas lorsque les tâches sont effectuées, mais quand le temps estimé s’est écoulé. Il y a donc une obligation de moyen et non de résultat. On peut d’ailleurs calculer la vélocité de l’équipe en comptabilisant le nombre d’user stories qu’elle est capable de livrer durant la durée d’un sprint.
Un nouveau sprint est de nouveau défini et démarre dès la fin du précédent, avec le même processus de planification. Lors de cette nouvelle réunion de planification de sprint, l’équipe de production choisit les users stories qui seront développées grâce au carnet de produit et sa vélocité lors du dernier sprint.
Cette démarche est renouvelée jusqu’à la fin du projet.
Le déroulement d’un sprint
Suite à sa planification, la réalisation du sprint commence. Cette étape est rythmée par plusieurs types de réunions, facilitant la communication et l’avancée du backlog.
La mêlée quotidienne est un moment de coordination entre l’équipe de développement du produit. Le propriétaire du produit n’y est donc pas convié. Cette réunion est planifiée à heure fixe tous les matins et ne doit pas durer plus de 15 minutes. Chacun leur tour, les membres vont annoncer ce qu’ils ont réalisé la veille, le travail qu’ils vont accomplir aujourd’hui et les difficultés qu’ils soulèvent. Cette réunion permet de synchroniser l’équipe et de mieux faire circuler l’information sur l’état d’avancement du projet.
Pendant le sprint, l’équipe de production doit pouvoir visualiser l’avancement des tâches. Un tableau blanc et des post-it suffiront.
Le tableau blanc se présente ainsi : 
Chaque post-it jaune représente une user story. Plusieurs informations y sont reportées : son nom, une courte description, et son estimation révélée lors de la partie de planning poker. Lorsqu’un membre de l’équipe choisi de développer ce backlog, le post-it passe dans la colonne Attribué, puis dans Terminé lorsque la tâche est effectuée.
Les user stories du sprint sont notées sur un autre type de post-it. Lorsque tous ses backlogs sont validés, le post-it passe de la colonne à faire à la colonne Terminé. Afin de visualiser le nombre de user story points total restant, un Burndown Chart est accroché au tableau blanc : 
Une fois le sprint réalisé, l’ensemble des acteurs du projet se réunissent pour une revue de sprint. L’équipe de production va énoncer les users stories terminées et testées puis faire une démonstration de la fonctionnalité développée. Le directeur de produit va alors valider l’avancée de l’équipe. L’équipe et le propriétaire du produit vont eux aménager le carnet du produit (ajout ou modifications de user stories) en fonction des réflexions et des découvertes révélées durant le sprint.
Dans une autre perspective, l’équipe et le scrum master vont se réunir en interne pour réaliser une rétrospective du sprint. Durant cet échange, l’équipe va analyser le déroulement du sprint pour soulever des points à améliorer dans sa dynamique, et si besoin, adapter la méthode Scrum. Chaque membre va exprimer les points positifs et négatifs le concernant, et les points à améliorer individuellement et collectivement.
Conclusion
SCRUM permet de réadapter le processus en fonction de la singularité des projets grâce aux nombreuses itérations entre les acteurs du projet. Cependant, pour que le projet réussisse, il faut que le client ait bien conscience qu’il doit s’investir physiquement, en étant présent aux différentes réunions et en testant toutes les versions des backlogs. Il doit aussi accepter qu’il n’y ait pas une date et un budget précis car l’équipe a une obligation de moyen et non de résultat.
