Un pas en arrière, deux pas en avant

Un pas en arrière, deux pas en avant
Photo de Jan Canty sur Unsplash

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 :

  • Afin d'obtenir du feedback utilisateur et confirmer qu'on est sur la bonne voie, ajuster le tir à défaut. Agile 101.

  • Afin de rendre l'avancée visible et d'éviter ainsi l'effet tunnel, première cause d'insomnie chez les managers.

  • Afin de sécuriser ce qui a déjà été fait : tant qu'il n'est pas utilisé par de vraies gens, le code est en danger. Le moindre changement de priorités peut lui être fatal.

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. Franchement, c'est 1 pas en arrière, 2 pas en avant, c'est pas efficace.

Exemple : vous êtes la SPA et souhaitez montrer tous les chats en attente d'adoption. Vous pouvez envisager les étapes suivantes :

  1. Une simple page avec les 177 chats 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 chat, l'information est disponible. Pour limiter le temps de chargement, vous rajoutez de la pagination.

  2. 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, et même parfois compliquée à gérer, alors vous décidez de la supprimer.

Donc vous avez mis en place la pagination pour la supprimer presque aussitôt 🤨

Autrement dit, s'il s'agit de faire 100%, on ne fait pas 50%, puis 70%, puis 100%. On va plutôt faire 50%, revenir à 45%, aller à 70%, revenir à 60% et aller enfin à 100% :

  • La théorie : 50% → 70% → 100%
  • La vie : 50% → 45% → 70% → 60% → 100%

Ce qui se traduit par un effort légèrement supérieur :

  • La théorie : (50 - 0) + (70 - 50) + (100 - 70) = 100
  • La vie : (50 - 0) + (70 - 45) + (100 - 60) = 115

En regardant les chiffres, on pourrait se dire que procéder ainsi coûte plus cher. C'est totalement vrai, et c'est totalement d'accord. Ce léger surcoût n'est jamais que le coût de la sécurité, autrement dit une prime de risque : on achète la sécurité de construire la bonne chose, dans de bonnes conditions, et de pouvoir s'arrêter en plein milieu comme on peut s'arrêter pour souffler sur n'importe quelle marche d'un escalier.

Sauf que ce raisonnement est fallacieux, car le 100% n'est en général pas définissable à l'avance. Vous ne pouvez pas dire ce que représentent ces 100%, et vos utilisateurs non plus car le besoin se découvre à l'usage. 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, disons à 50%, pour construire ensuite un autre 100% !

Subscribe to Mathieu Eveillard

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe