Si vous pensez que l'Agilité coûte cher, comprenez que c'est une prime de risque
En informatique, on ne conseillera jamais assez de faire des petites choses : des petites user stories, des petits refactorings.
Faire de petites choses et les pousser en production au fur et à mesure :
-
Pour obtenir du feedback utilisateur et confirmer qu’on est sur la bonne voie (Agile 101).
-
Pour sécuriser ce qui a déjà été fait : du code qui n’est pas en production est du code en sursis.
-
Pour avoir toujours quelque chose à livrer, parce que tôt ou tard, vous manquerez de temps.
Autrement dit, pour minimiser l’effet tunnel, première cause d’insomnie chez les managers.
Cependant, une objection vient rapidement :
Oui, mais à chaque nouvelle étape, cela nous oblige à défaire un peu ce qui a été fait précédemment. L’Agilité, c’est un pas en arrière, deux pas en avant !
En un sens, il y a du vrai.
Exemple : vous êtes une association protectrice des animaux et souhaitez montrer aux familles tous les chats et chiens en attente d’adoption. Vous pouvez envisager les étapes suivantes :
-
Une simple page avec les 177 animaux disponibles à l’adoption. Nom, photo, métadonnées et descriptif sur la même page. Légèrement brut de décoffrage, mais pour qui veut adopter un animal à quatre pattes, l’information est disponible. Pour limiter le temps de chargement, vous rajoutez de la pagination.
-
Feedback : cela fait beaucoup d’information, on s’y perd et ce n’est pas efficace vu que la plupart des personnes a une préférence quant au sexe et à l’âge de l’animal. Alors vous rajoutez des filtres. Seulement, le filtrage rend la pagination un peu moins nécessaire, cela crée des cas limites tordus, vous décidez de la supprimer.
Vous avez donc passé une semaine à mettre en place une pagination aux petits oignons pour la supprimer quelques jours après 🤨
Voyons ce que cela donne si l’on met des chiffres sur ce qui vient de se passer : s’il s’agissait de faire 100%, nous n’avons pas fait 50%, puis 70%, puis 100%. Nous avons plutôt fait 50%, pour revenir ensuite à 45%, avant d’aller vraiment à 70%, revenir encore à 60% pour aller enfin à 100% :
- Théorie : 50% → 70% → 100%
- Pratique agile : 50% → 45% → 70% → 60% → 100%
Ce qui se traduit par un effort légèrement supérieur :
- Théorie : 100 - 0 = 100
- Pratique agile : (50 - 0) + (70 - 45) + (100 - 60) = 115
Sachant qu’il faudrait en toute rigueur tenir compte du coût que représente la suppression d’une fonctionnalité. Passer de 50 à 45%, c’est un coût de 50 - 45 = 5. Ainsi, l’écart se creuse entre la théorie et la pratique :
- Théorie : 100 - 0 = 100
- Pratique agile : (50 - 0) + (50 - 45) + (70 - 45) + (70 - 60) + (100 - 60) = 130
En regardant les chiffres, on pourrait se dire que travailler de manière agile coûte plus cher. Disons que c’est vrai, et que cela nous va bien, car le surcoût (30% ici) est le coût de la sûreté. C’est une prime de risque : en travaillant de manière agile, vous achetez de la sûreté, à savoir la certitude de construire un produit utile, la certitude d’avoir à tout moment quelque chose à livrer et la certitude que le travail déjà réalisé ne sera jamais perdu, parce qu’il est en production.
Oui, vous pourriez aller plus vite en visant directement les 100%. Sauf que ce raisonnement est fallacieux, parce que le 100% n’est pas définissable à l’avance. Vous ne pouvez pas dire ce que sont ces 100% de fonctionnalités, parce que le besoin se découvre à l’usage (même vos utilisateurs ne le savent pas à l’avance !). Il n’y a donc tout simplement pas de base de comparaison. Si vous partez sur un ambitieux 100%, il y a de grandes chances que vous ayez construit des choses inutiles et deviez revenir beaucoup plus en arrière, à 50% peut-être, voire plus loin encore, pour construire ensuite un autre 100%.
Conclusion : l’Agilité ne coûte pas plus cher, elle augmente les chances que votre produit « rencontre » ses utilisateurs. Sans elle, la création de votre logiciel s’apparente à une partie de dés…