Pourquoi faire Agile au lieu d'aller tout droit ?

Les coachs Agile et autres Scrum Masters, ça m'a toujours un peu gonflé.

Ceux que j'ai croisé sont très axés sur la méthode, mais ils peinent parfois à en expliquer l'intérêt.

Agile ?

Non mais tu me prends pour un acrobate ?

Bien sûr que s'il faut changer un truc, on va le changer. Personne n'a envie de conserver mordicus (ça existe encore cet adverbe ?) une fonctionnalité qui ne sert à rien ou un code mal conçu.

Le monde des codeurs et codeuses ne se sépare pas en deux. Avec d'un côté ceux qui sont agiles, cools, ouverts d'esprit, à l'écoute des utilisateurs. Et de l'autre ceux qui s'arc-boutent sur leur code comme si c'était une oeuvre d'art.

La question de l'agilité, c'est d'abord un choix de méthode. Il n'est pas guidé par la tendance du moment, mais par la nature des projets.

Et il y a 2 méthodes. La spirale ou la recette.

La recette

Lorsqu'on cuisine, on a une représentation assez précise du résultat. Avouons qu'il est rare de commencer à cuisiner un pot-au-feu pour se retrouver avec une tarte aux fraises à la fin.

Pourquoi ?

Parce qu'on suit la recette.

Elle détaille pas à pas les étapes pour parvenir au résultat que l'on connaît à l'avance.

Et bon nombre de projets fonctionnent sur ce mode. Par exemple, lorsqu'on construit une maison.

Le maître d'oeuvre élabore un plan détaillé de la maison, puis il définit les différentes étapes pour parvenir au produit final. D’abord le terrassement, puis les fondations, puis le vide sanitaire, puis la dalle du plancher, puis les murs, … Et hop, à la fin, une maison.

Mais comment faire quand on ne connait pas la cible ?

Du genre : "j’aimerais faire un jeu de société, qui plaise aux enfants et aux adultes, qui ne soit pas trop difficile à comprendre, et qu’on puisse emmener facilement en vacances ?"

Comment faire quand on créé un truc nouveau ?

Et bien on fait comme pour entraîner un modèle d’IA constitué d'un réseau de neurones.

🌀 On itère.

La spirale

En l'absence de représentation précise du résultat, on va essayer de se rapprocher petit à petit de la solution.

Comment savoir si on s’approche ou si l’on s’éloigne ?

Il faut une fonction de coût.

Un feedback immédiat qui nous dise "ah là tu chauffes" ou "non là c’est froid".

Comme lorsque tu cherches le point d'équilibre d'un manche à balai. La fonction de coût, c'est l'ampleur et le côté vers lequel penche le balai. S'il tombe (doucement) vers la droite, on déplace (légèrement) le point d'équilibre vers la droite. Et tu réessaies. Itératif. Agile

Cette fonction de coût, c'est un peu comme une boussole pour savoir si on avance dans la bonne direction quand on n'a pas de carte.

Dans le code, c’est pareil.

On ne sait jamais exactement à quoi va ressembler le code à la fin.

Alors il faut commencer par se doter d’une boucle de rétroaction pour savoir si on code dans la bonne direction.

Il y a pleins de moyens pour faire ça : les tests, l’auto-critique, les code-reviews, les APM. Et surtout le comportement des utilisateurs.

Alors au début d’un projet agile, plutôt que de réfléchir au langage, au framework, au nombre de CPUs du serveur, mieux vaut réfléchir à la rétroaction.

Démarche agile = démarche exploratoire

C'est ça le principe d'une démarche agile.

Elle sert à avancer sur des projets :

• dont on ne connaît pas le produit fini,
• à condition d'avoir bien identifié la boucle de rétroaction.

Et c'est incroyable combien on se force parfois à vouloir ABSOLUMENT l'utiliser sur des projets qui n'ont aucune de ces 2 caractériques !

Pas besoin de méthode agile lorsqu'on sait parfaitement ce qu'on veut faire (exemple : un site de e-commerce, avec un design très précis). Rien n'empêche d'avancer pas-à-pas comme dans une recette de cuisine, ni de changer des détails en cours de route. Mais on dispose d'un plan. D'une recette. Ca n'a rien d'exploratoire.

Réciproquement, inutile de vouloir adopter une méthode agile sans rétroaction. Et ce n'est jamais l'avis au doigt mouillé du responsable produit. C'est une métrique précise qui donne un retour rapide sur la valeur de ce qui est en ligne.

Vous voulez faire de l'agile ?

Alors c'est comme pour un modèle d'IA. Réfléchissez d'abord à la façon de mesurer vos erreurs.

Alors : agile ou pas pour mon projet ?

Une méthode agile, ça n'est pas forcément le bon choix pour un projet.

Parce qu'elle impose d'échouer souvent, de faire pleins d'erreurs que l'on va chercher à corriger petit à petit pour obtenir le design définitif.

Je n'ai pas échoué. J'ai simplement trouvé 10000 solutions qui ne fonctionnent pas.
– Thomas Edison

Pour coder quelque chose de nouveau, c'est parfait. Il n'y a pas vraiment de recette universelle pour coder un truc, alors on avance face à des tests. Durant le développement, quand un test échoue, ça ne casse rien.

Par contre, pour concevoir une fusée, on a plutôt envie que ça fonctionne du premier coup, sans passer par des milliers d'itérations (ah mince, elle a explosé en vol. Essayons encore).

Et pour des projets qui disposent d'un plan déjà établi par d'autres à de nombreuses reprises, c'est une perte de temps ! Pour cuisiner une tarte au fraise, on ne va pas essayer tous les fruits jusqu'à trouver celui qui a le goût de la fraise.

En résumé :

Alors la prochaine fois que vous entendez :

• "Avec une méthode Agile, on peut chiffrer + précisémment le coût total du projet"
• "On développe votre site de e-commerce avec Shopify en méthode agile, c'est plus rapide"
• "On va copier exactement l'application Uber, en méthode agile"
• "Grâce à notre méthode Agile, on n'a pas besoin de l'avis des utilisateurs"

Fuyez.