Au sein des équipes de développement que j'ai intégrées, du début de mes études jusqu'à la fin de mon alternance, notre rythme de fonctionnement s'est toujours basé sur les méthodologies agiles, plus précisément sur la méthode SCRUM. SCRUM est une méthode de gestion de projet agile largement utilisée dans le domaine du développement de logiciels, et c'est la méthode qui a été choisie pour les nombreux projets que j'ai réalisé en partenariat avec des entreprises pendant mes études. J'ai donc eu l'occasion de me familiariser avec celle-ci dès mes premières années d'apprentissage, et cette façon de fonctionner me suit encore aujourd'hui dans la vie professionnelle, offrant un cadre à la fois familier et rigoureux pour m'organiser et structurer mon travail.
Elle se caractérise par sa structure itérative et collaborative, permettant aux équipes de travailler de manière efficace et flexible. L'équipe de développement est auto-organisée et responsable de la réalisation des tâches assignées lors de cycles de développements appelés « sprints ».
Chaque sprint est une période de temps définie, généralement de deux à quatre semaines. Par exemple, chez Valeco, l'entreprise où j'ai effectué mon alternance, un sprint dure 3 semaines, mais un sprint durant 2 semaines permet un feedback plus régulier de la part des clients, ce qui peut être approprié pour des projets étudiants ou des projets demandant une supervision accrue. A l'inverse, si les fonctionnalités sont particulièrement complexes et longues à développer, on préférera peut-être des sprints de 4 semaines afin d'avoir du contenu à montrer aux clients en fin de sprint.
Au cours de chaque sprint, l'équipe de développement se concentre sur la réalisation des fonctionnalités prioritaires. Le travail à effectuer est défini dans un Product Backlog, une liste ordonnée des fonctionnalités à développer. Au début de chaque sprint, l'équipe de développement se réunit lors d'une réunion de planification pour sélectionner les éléments du backlog à inclure dans le sprint et estimer la quantité de travail nécessaire.
Une fois que les tâches sont définies, l'équipe se coordonne quotidiennement lors de réunions courtes appelées « stand-up meetings » ou « daily scrums ». Ces réunions, d'une durée de 15 minutes environ, se déroulent debout pour favoriser la concision et la focalisation. Chaque membre de l'équipe partage brièvement ses progrès depuis la dernière réunion, expose les tâches prévues pour la journée et soulève tout obstacle qui pourrait entraver son travail. Ces réunions permettent de maintenir une communication régulière, de détecter rapidement les problèmes potentiels et de coordonner les efforts de l'équipe. Il n'est pas rare que des sessions de code collaboratif ou des réunions supplémentaires découlent de ces daily scrums, et chaque membre de l'équipe garde généralement un créneau disponible juste après la réunion pour venir en aide aux autres développeurs.
Cela permet par exemple de demander des informations complémentaires au Product Owner, chargé de la transmission du besoin fonctionnel, ou de faire le point sur une modification potentielle de la base de données qui pourrait impacter l'ensemble de l'équipe projet. Cela permet également d'identifier la faisabilité du sprint à mesure du déroulement de celui-ci, qui s'en sort plus vite que prévu et qui rencontre des difficultés inattendues.
À la fin de chaque sprint, une revue de sprint est organisée pour présenter les fonctionnalités développées aux clients, notamment à travers des démos et recueillir les commentaires des différentes parties prenantes. C'est un moment privilégié où les développeurs peuvent être en contact plus direct avec les clients, sans nécessairement passer par le biais du product owner, et recueillir leurs besoin et leurs retours sur le travail effectué, même si dans de plus grosses équipes tous les développeurs ne seront pas forcément présents lors de cette réunion de communication.
Une rétrospective de sprint est également tenue pour évaluer le processus de développement, identifier les points forts et les points faibles, et proposer des améliorations pour les sprints futurs. C'est un espace de discussion pour les membres de l'équipe qui peuvent alors exprimer leurs ressentis, positifs ou négatifs, de façon honnête afin de pouvoir en dégager ce qui a bien fonctionné, et ce qui doit être modifié pour que la suite du développement se passe dans de meilleures conditions.
Pour donner un exemple concret, j'ai récemment constaté au sein de mon équipe qu'il y avait quelques problèmes dans la relecture et la validation du code que nous produisions avant sa mise en production. Pour être plus précis, même si le code était relu, testé et validé, les pull requests (requête de fusion du travail actuel avec la version principale de l'application pour déployer une fonctionnalité) mettaient beaucoup de temps à être acceptées, et elles commençaient à s'accumuler comme des voitures dans un bouchon. L'ayant remarqué, j'ai soulevé cette problématique lors de la rétrospective, et mon impression sur la situation étant partagée par mes collègues, nous avons cherché à identifier la source du problème. Seul le Tech Lead de l'équipe était actuellement habilité à confirmer les pull requests, or au vu de son agenda de plus en plus rempli, il lui fallait déléguer cette responsabilité. Un développeur sénior de l'équipe a donc été choisi, et depuis, l'autoroute des pull requests est de nouveau fluide !
En somme, la méthode SCRUM encourage l'adaptabilité et la flexibilité, permettant aux équipes de répondre rapidement aux changements de priorités ou aux nouvelles exigences du client. Grâce à sa structure transparente, ses cycles itératifs et ses pratiques de communication continue, SCRUM favorise la collaboration, l'efficacité et la livraison régulière de fonctionnalités de haute qualité.