Back to posts
Il y a quelques semaines, je me suis intéressé à la méthode agile.
Pas aux méthodes agiles en général, mais plutôt à l’essence même de la méthode agile : le manifeste agile.
En tant que développeur, voici 4 questions que je me suis posé avant de commencer à m’intéresser à “la méthode agile” 👇
Qui a créé le manifeste agile ?
Le manifeste a été élaboré en 2001 par 17 informaticiens afin de répondre à une problématique que nous connaissons tous :
“Pourquoi les projets informatiques échouent ?”
Et notamment car cette question en amène beaucoup d’autres :
Pourquoi
- on n’arrive pas à livrer à temps en production,
- on jette du code à la poubelle,
- notre soft ne fonctionne pas,
- ça bug tout le temps…
Et tellement plus encore.
En tant que développeur, pouvons-nous vraiment réussir à livrer du code correct dans un temps donné ?
C’est ce que le manifeste essaye de faire, décrire les fondements d’une gestion de projet réussie. 👌
Dans le manifeste agile, on retrouve donc 4 valeurs sur lesquelles se basent 12 principes dont le but est assez clair : livrer à son client le plus rapidement possible un projet de qualité.
Comme cet article est relativement court, je t’invite à lire mon analyse complète qui détaille les valeurs et principes du manifeste agile (en images).
Le manifeste se veut donc être un guide pour que les développeurs réussissent au mieux leur travail.
Les méthodes agiles sont-elles toujours d’actualité ?
Les méthodes agiles ont pas mal été décriées depuis leurs élaborations il y a 20 ans.
Pas la méthode agile en tant que telle (le manifeste lui, bien que parfois remis en question, n’est pas la cible des attaques).
Ce sont les implémentations des méthodes agiles, ces frameworks comme Scrum, Kanban, Extreme Programming etc qui sont aujourd’hui critiqués.
Pour la petite histoire, au moins 2 signataires originels du manifeste, Ron Jeffries et Andy Hunt, se sont retirés il y a quelques années.
Pour eux, les méthodes agiles sont mal appliquées, mal utilisées…
On retombe dans les travers des anciennes méthodes managériales.
Soit tout ce que l’on voulait éviter au départ.
On dit aussi souvent que les méthodes agiles ne sont pas toujours faciles à utiliser.
Et c’est vrai.
La gestion de projet en général est un métier à part entière, il faut se former et acquérir de l’expérience pour maîtriser pleinement ce domaine.
Pour moi, les méthodes agiles ne sont pas mortes, loin de là.
Ces dernières années on a constaté une augmentation significative des “managers bienveillants”, essayant de rendre la vie des exécutants (ici les développeurs) plus agréable au travail.
“C’est fini de pisser du code, les managers ont désormais pris conscience que les codeurs peuvent penser.”
Il ne faut pas oublier que les méthodes agiles ont été créées par et pour les développeurs.
Aussi, ces outils sont toujours adaptés à notre mode de travail actuel. Et mieux encore, ils sont souvent synonyme de réussite pour le projet.
Quand utiliser les méthodes agiles ?
Je conseille souvent de partir sur une approche agile lorsque le scope évolue au fur et à mesure que l’on développe l’outil.
Parfois, on doit commencer les développements alors que le cahier des charges n’est pas totalement bouclé ni même commencé.
👉 Le client a besoin que l’on commence à développer l’outil rapidement et des réunions de synchro sont prévues chaque semaine dans le but d’avancer sur les spécifications fonctionnelles.
Ces changements de directions impliquent d’être souple et réceptif aux changements de manière générale (et ça tombe bien car c’est exactement ce pourquoi le manifeste a été écrit !).
C’est un go pour l’agilité !
👉 À l’inverse, si le client a une deadline serrée, un périmètre précis qui nécessite que les acteurs s’engagent sur une date et un budget, une méthode de gestion de projet plus traditionnelle comme le cycle en V sera plus adaptée.
Ce sera sans l’agilité !
Comme souvent, c’est une question de situation.
Est-ce que le planning est susceptible de bouger ? A-t-on besoin de commencer à utiliser le produit rapidement ? Le client a-t-il besoin d’un engagement de moyen ou de résultat ?
Autant de questions à se poser avant de choisir d’adopter une démarche agile.
Quelle “méthode agile” choisir ?
Il existe plusieurs méthodes agiles (au sens framework du terme) assez populaires.
On peut citer Scrum par exemple, dont tu as déjà je pense entendu parler ou que tu pratiques peut-être ?
Il y a aussi XP qui est considéré comme “LA” méthode agile pour les développeurs.
Ou Kanban qui est très populaire chez les ceux qui aiment avoir quelque chose de visuel.
Mais du coup… Quel framework utiliser ?
Bonne nouvelle : ils sont tous suffisamment différents pour que ça puisse coller aux différentes équipes et aux différents projets.
Une seconde bonne nouvelle est que l’on peut uniquement utiliser certains outils des méthodes agiles sans pour autant s’enfermer dans un framework !
La gestion de projet ne consiste pas nécessairement à l’adoption d’une méthode en particulier, elle peut également se faire en piochant ce qu’il y a de mieux dans chaque monde.
“Composition over inheritance!”
Un framework comme XP aura un ensemble d’outils à sa disposition : Pair Programming, TDD, BDD, là où Scrum préférera des Sprints, Daily Meetings, Poker Planning…
Pourquoi ne pas choisir les outils qui nous conviennent ?
Il faut que les méthodes agiles s’adaptent à l’équipe et non l’inverse.
Imposer à son équipe de faire du TDD serait une bêtise si l’équipe ne le souhaite pas…
L’important, c’est que les process soient clairement définis en amont et que tout le monde soit en accord avec cela.
Un développeur heureux est un développeur productif.
Mon conseil serait donc d’en discuter en amont avec ses équipes. Puis de choisir la méthode et les outils qui matchent au mieux les besoins du client et les envies de l’équipe.☀️
Alex est développeur depuis bientôt 10 ans et blogueur. Chaque mois, il donne des conseils exclusifs par e-mail pour devenir un meilleur développeur. N’hésitez pas à vous inscrire à sa newsletter !
