La pression pour livrer vite est légitime : un produit en retard n'apprend rien à ses utilisateurs. Mais "vite" ne veut pas dire "sale". Voici quatre pratiques que nous appliquons systématiquement chez Leadershift.
1. Le périmètre se discute, la qualité non
Quand un délai se tend, on coupe des fonctionnalités, jamais les tests ou la revue de code. Sinon la dette explose dans les semaines qui suivent, et on perd plus de temps qu'on en a gagné.
2. Découper jusqu'au "shippable" en moins de deux jours
Une story qui ne tient pas en 1-2 jours est trop grosse. On la redécoupe verticalement (une vraie tranche utilisable) plutôt qu'horizontalement (du back sans le front).
3. Refactorer en continu
On ne planifie pas de "sprint de dette" semestriel. Chaque PR contient un petit nettoyage du code touché — la règle du boy-scout. La base reste saine sans coût visible.
4. Mesurer ce qui ralentit
On suit deux métriques internes : le lead time d'une PR (création → merge) et le temps de build/test. Si l'un dérive, on arrête tout et on l'investigue. Pas plus tard, maintenant.
Aller vite, c'est livrer souvent. Livrer souvent, c'est garder un système qu'on n'a pas peur de toucher.
Ces quatre habitudes ne sont pas glamour. Elles fonctionnent.