Êtes-vous vraiment agile ?
L’agile en pratique : Retour d’expérience d’une agilité efficace au sein d’une feature team chez l’un de nos clients
L’agilité, tout le monde pense savoir ce que c’est, beaucoup en parlent, peu la mettent vraiment en pratique. L’important n’est pas de connaître la théorie par cœur, mais bien de l’utiliser au jour le jour pour pouvoir l’améliorer avec l’équipe et l’adapter à son projet. Voici donc un exemple de mise en place concrète à un instant T d’un processus agile.
1 — L’équipe
Elle est composée d’un maximum de 7 personnes, dont :
- 1 PO (Product Owner) : Il transforme les besoins et les découpe en fonctionnalités.
- 1 BA (Business Analyst) : Il positionne et évalue constamment les trackers. Il est garant de l’efficacité des fonctionnalités et donc du respect des règles métier par l’équipe.
- 1 Tech Lead : Il recueille les avis de son équipe pour résoudre les problématiques au niveau global du produit. C’est aussi lui qui doit “vendre” des tickets techniques au PO.
- Les développeurs : Ils développent le produit, prennent les tickets et les traitent un par un.
Chaque membre de l’équipe a un trigramme. Il servira à l’associer à des actions ou des tickets. Par exemple le mien est TLE, pour Thomas Leduc.
2 — En amont du sprint
2.1 — L’expression des besoins
Le PO, en partenariat avec le BA, propose des améliorations techniques ou fonctionnelles, ainsi que de nouvelles fonctionnalités du produit. Elles sont le résultat d’une écoute des retours client sur le produit et des besoins business.
2.2 — Le grooming
Toute la team se réunit 1 à 2 heures pour que le PO puisse présenter les taches, que le BA puisse exprimer les acceptances et qu’ensemble, toute l’équipe rédige des spécifications. C’est à ce moment que des tickets (issues) sont ouverts sur le git manager (github, gitlab, bitbucket… bref votre gestionnaire git).
3 — Au cours du sprint
3.1 — La spécification et le découpage
Juste après le grooming, il est important que les tickets ouverts soient retranscrits sur le board. Chacun d’entre eux est retranscrit sur un post-it avec, en haut à droite, le numéro de l’issue créée sur github. Chaque ticket est positionné dans la colonne “prêt à découper” par le PO quand il a fini de spécifier plus amplement l’issue du git manager. Il spécifie ensuite les tickets tout au long du sprint. Son but est d’exprimer le plus précisément possible le besoin et de garder la colonne “prêt à découper” pleine.
Tips : C’est parfois très utile de maîtriser le markdown pour un PO, par exemple pour faire des checklists des acceptances.
Quand les devs manquent de tickets, ils découpent ensemble ces tickets en plus petites tâches qu’ils inscrivent sur des plus petits post-its qu’ils collent au dos du ticket. Après cette étape, ces tickets sont placés dans la colonne “ready to dev” et chaque développeur peut prendre un des tickets le plus haut dans la liste pour le développer.
3.2 — Les “dailies”
Tous les matins, une réunion à une heure fixe (ex : 9h20) doit être faite avec toute l’équipe. La réunion se déroule debout et devant le board. Un totem (une peluche ou un objet référence du produit) est passé de main en main pour donner la parole. Celui qui a le totem doit résumer ce qu’il a fait la veille, ce qu’il pense faire aujourd’hui, et éventuellement les difficultés qu’il rencontre sur un ticket. 2 minutes grand maximum sont accordées au porteur du totem. Idéalement, pour des questions de rapidité, il ne doit pas poser de question et personne ne doit intervenir.
3.3 — Le développement
Le développeur commence par prendre le ticket et par le mettre dans la colonne “en cours”. Cette dernière est composée de 3 sous-colonnes :
- “issue” : où est placé le ticket.
- “tasks” : où sont placées les différentes tâches du ticket.
- “doing” : où est placée la tache en cours de développement.
Le développement ne peut commencer sans la création d’une nouvelle branche git. Le nom de cette branche est défini par le nom de l’issue et son numéro pour ensuite faciliter la recette par le PO / BA. Ainsi, on peut facilement naviguer entre le ticket (board), l’issue git, et la branche de la feature.
Tips : Ne pas hésiter à expliciter ces règles sur le board, à la vue de tous. Et à en ajouter d’autres. Par exemple : la branche doit commencer par le type d’issue :
- US : User story (la création d’une nouvelle feature)
- TECH : Un ticket de refacto ou de changement de technologie.
- FIX : Le fix d’un bug
Si plusieurs teams travaillent sur le même projet, préciser un trigramme d’équipe (PLE).
Lorsque le développement commence à prendre forme, une “pull request” est faite de la branche de feature (exemple : US.5456.SEA.Add.faq.link.to.member.space) vers la branche principale (master). Cette pull request doit être référencée dans l’issue correspondante.
Si vous êtes assez à l’aise avec le déploiement continu, cette pull request peut donner lieu à une application de recette qui se créera automatiquement si les tests techniques passent via des webhooks. Voir Deploy with pull request pour Bitbucket et Delivering deployments pour Github. Par exemple, chez notre client, un webhook github propose à Heroku de créer une review app pour chaque PR. Puis une review app pour master.
3.4 — La recette : Une fois toutes les sous-tâches terminées, le ticket est traité et une application de review doit être mise en place pour que le PO puisse la valider.
Un post-it PR est mis dans la sous-colonne “Tasks” pour qu’un autre membre de la team puisse la review et la valider.
Pour que le PO commence sa recette, il est nécessaire que :
- La branche feature soit rebase avec master (à jour avec la version que tout le monde a),
- Les tests techniques passent,
- Une application de recette soit créée et son adresse mise dans l’issue / PR,
- Le ticket soit déplacé dans une colonne “à recetter”,
- La PR soit validée par un membre technique de l’équipe.
Une fois ce ticket validé par le PO, le ticket passe dans la colonne… “validé PO”. À partir de là, le processus de mise en prod démarre :
- Merger la pull request sur master,
- Déployer l’application en pré-prod,
- Recette PO,
- Déployer en prod,
- Recette PO / BA.
4 — En fin de sprint
4.1 — Les rétros
Une fois par sprint et à date précise (ex : l’avant-dernier jour du sprint), une séance avec toute l’équipe doit être effectuée pour recueillir l’ambiance générale du dernier sprint et améliorer les process. L’idée est de ne pas avoir des processus fixes mais d’améliorer en continu l’agilité de l’équipe en supprimant les douleurs et en exploitant ce qui fonctionne déjà bien. Un intervenant externe (qui ne connaît pas le projet ni la team) anime la rétro :
Notation du projet sur le “mood” personnel et le “work together” du sprint passé. Chacun note sur 4 ces 2 points sur un post-it. Les notes les plus hautes et les plus basses sont brièvement expliquées par ceux qui les ont mises.
Toujours en décrivant le sprint. On donne 5 post-it à chacun où il exprime des ressentis sur 4 thèmes décidés par l’animateur exemple : (“Brouillon”, “J’ai raté”, “J’ai aidé”, “Pénible”)
De ces douleurs ou ces réussites, on extrait des actions pour fixer ou changer les choses. On les renseigne sur des post-it qu’on affichera sur le board. Sur le post-it sera noté le trigramme d’un membre de l’équipe responsable de l’appliquer.
4.2 — La démo
Après que le BA a analysé les retours des nouvelles fonctionnalités et des améliorations du sprint, une démo est réalisée pour montrer aux autres équipes et à la société l’avancée du projet et les retours de production (montée d’utilisateur actif, augmentation du taux de conversion, etc.)
4.2 — Les célébrations
Pour essayer de garder la motivation et le team spirit, il est important de fêter les victoires, même les plus petites. La mise en production d’une fonctionnalité attendue, un heureux événement d’un membre de l’équipe, la première bourde ou fonctionnalité du nouveau sont autant d’événements que l’on peut fêter tout au long du projet. Il est important que tout le monde sache pourquoi il travaille, et que ses réalisations soient vues par tout le monde.
5 — Conclusion
L’agilité n’est pas quelque chose de fixe ou d’universel. Ce n’est pas un dogme à suivre à la lettre. Les processus doivent être adaptés pour chaque équipe et chaque projet. Pourtant, on retrouve souvent le même déroulement tout le long de la vie d’un ticket, qu’il soit un “bug fix” ou une “feature” :
- Besoin métier ou détection de bug,
- Priorisation par PO/BA,
- Grooming : création d’un ticket en réunion avec toute l’équipe,
- Découpage technique entre développeurs,
- Développement,
- Recette,
- Mise en production,
- Retour tracking et mesures business.
Et n’oubliez pas : l’agilité, qu’elle soit scrum ou kanban, est toujours au service de la productivité et de la souplesse du projet. Cependant, elle n’est en aucun cas une substitution aux spécifications, qui sont la base de tout ticket bien réussi comme elles étaient la base d’un projet mené à bien avec le traditionnel cycle en V.
Et si vous désirez en savoir plus sur les outils de communication plébiscités en équipe agile, jetez un œil à l’article de nos Partners sur ce sujet :
Nous publions régulièrement des articles sur des sujets de développement produit web et mobile, data et analytics, sécurité, cloud, hyperautomatisation et digital workplace.
Suivez-nous pour être notifié des prochains articles et réaliser votre veille professionnelle.
Retrouvez aussi nos publications et notre actualité via notre newsletter, ainsi que nos différents réseaux sociaux : LinkedIn, Twitter, Youtube, Twitch et Instagram
Vous souhaitez en savoir plus ? Consultez notre site web et nos offres d’emploi.
L’auteur
Tech Partner / FullStack Engineer / JS Aficionado
