On entend souvent parler de la "méthode Agile" comme d'une solution miracle ou, à l'inverse, comme une simple mode remplie de post-its. Pour moi, l'Agilité n'est pas juste une façon de gérer des tickets/tâches dans un logiciel. C'est avant tout une posture d'écoute et d'adaptation. C'est accepter que le plan de départ ne sera pas le plan d'arrivée, et c'est une bonne chose. J'ai eu l'occasion de vérifier cette théorie à travers deux expériences concrètes aux dynamiques très différentes..
1.Le Startup Challenge à Châteauroux
Ma première vraie confrontation avec l'Agilité s'est faite "hors sol", lors d'un Startup Challenge à Châteauroux. Le contexte était particulier : j'étais le seul développeur web au sein d'une équipe composée de trois étudiants en GEA (Gestion) et Marketing. Nous avions un temps très limité pour sortir un MVP (Produit Minimum Viable). Ici, l'Agilité s'est imposée comme un langage commun. Communication Interdisciplinaire : Mes coéquipiers avaient des idées business brillantes mais parfois irréalisables techniquement dans le temps imparti. Les cycles courts nous ont permis de trancher rapidement. Priorisation : Au lieu de rédiger un cahier des charges figé, nous avons itéré. J'ai maquetter les fonctionnalités essentielles pendant qu'ils affinaient les aspects marketing. Cette expérience m'a prouvé qu'un développeur agile est un pont indispensable entre la technique et le business.
De plus, nous profitons tous de l'accessibilité à un moment donné grâce à ce qu'on appelle l'effet "Curb Cut" (effet bateau-pavé). Une rampe pour fauteuil roulant aide aussi le parent avec une poussette ou le livreur avec un diable. Sur le web, c'est pareil : Les sous-titres aident les malentendants, mais aussi ceux qui regardent une vidéo dans le métro sans écouteurs. Donc dans cette logique, un bon contraste aide les malvoyants, mais aussi l'utilisateur qui regarde son écran en plein soleil. > Le spectre du design inclusif de Microsoft illustre comment une solution conçue pour un handicap permanent profite aussi aux situations temporaires et situationnelles.
2. La rigueur technique : Le projet Agenda 2030 - Conseil Départemental.
Ma seconde expérience a eu lieu dans un cadre plus classique, lors d'un projet de groupe avec mes camarades de promotion. Ici, nous parlions tous le même langage technique, mais le risque était la désorganisation ou les avis divergeants. Nous avons appliqué les rituels Scrum pour structurer notre avancée.
- Visibilité : Chacun savait sur quoi l'autre travaillait, évitant ainsi les conflits de code.
- Réactivité : Lorsqu'une fonctionnalité s'avérait plus complexe que prévu, nous pouvions réajuster le tir immédiatement, sans attendre la fin du projet pour constater le retard.
Ici, la méthode Agile a été le garant de notre santé mentale et de la qualité de l'arborescence et maquettes livrés.
3. Le choix des armes : Trello vs GitHub
La méthode ne fonctionne pas sans les bons outils. Au cours de ces projets, j'ai pu comparer l'utilisation de Trello (méthode Kanban) et de GitHub. Mon constat est nuancé :
- Trello pour la simplicité : C'est un outil très visuel et facile à prendre en main. À mon sens, il convient parfaitement à des tâches simples, des petits projets ou, comme à Châteauroux, pour collaborer avec des profils non-techniques qui n'ont pas besoin de voir le code.
- GitHub pour la puissance : Il est certes beaucoup plus complet et la courbe d'apprentissage est plus raide au départ. Cependant, une fois maîtrisé, il devient indispensable pour une équipe de développeurs. Le lien direct entre les "Issues", les "Pull Requests" et le code offre une traçabilité que Trello ne peut pas égaler.
Savoir utiliser les deux me permet aujourd'hui de m'adapter à la complexité du projet et à l'équipe avec laquelle je travaille.
Conclusion
L'Agilité n'est pas une magie, c'est de la discipline. Que ce soit pour dialoguer avec des profils extérieurs à ma discipline ou pour se synchroniser avec d'autres développeurs, elle est l'outil qui permet de livrer de la valeur rapidement. Pour la suite de ma carrière, je souhaite intégrer une équipe qui ne fait pas de l'Agile "parce qu'il faut le faire", mais qui en comprend le sens : s'adapter ensemble, avec les bons outils, pour construire un meilleur produit.
Sources
- Lien : https://agilemanifesto.org/iso/fr/manifesto.html
- https://scrumguides.org/index.html
- https://www.atlassian.com/fr/agile