Le développement n'est qu'un rogue-like IRL
Sprints, bugs et patterns
Chaque sprint est une run
Pense à tes anciens projets. Ceux que tu as abandonnés à mi-chemin, ceux qui sont partis en production dans un état pitoyable, ceux dont tu refuses encore de relire le code.
Ces projets n’étaient pas des échecs. C’étaient des runs.
Dans cette run-là, tu as appris que livrer sans tests, ça coûte cher. Dans celle d’après, tu as compris que l’over-engineering est un piège aussi dangereux que l’absence d’architecture. Dans la suivante, tu as réalisé que le vrai problème n’était pas technique mais humain.
Chaque run t’a rendu meilleur. Pas de façon spectaculaire et immédiate, mais de façon cumulative, presque imperceptible. Comme les stats qui s’accumulent entre deux parties dans Hades.
Le sprint Agile repose exactement sur cette logique. Trois semaines, une boucle fermée, une livraison. L’idée n’est pas de tout planifier à l’avance, c’est de créer des points de mort volontaires et réguliers : des moments où on s’arrête, on regarde ce qu’on a accompli, et on repart avec de meilleures informations qu’avant. Mourir vite. Apprendre vite. Repartir mieux équipé.
Le Scrum Guide de Ken Schwaber et Jeff Sutherland (version 2020) précise que des sprints plus courts raccourcissent le cycle d’apprentissage, limitant ainsi les risques liés aux coûts et à l’effort. Chaque Sprint y est explicitement comparé à un projet court.
Le bug est un boss, pas un mur
Dans un rogue-like, les boss te tuent. Souvent. Et la première fois que tu en rencontres un, tu n’as aucune idée de ses patterns. Tu subis.
Mais à la run suivante, tu sais. Tu anticipes le moment où il va charger. Tu gardes ta potion pour la deuxième phase. Tu as appris son langage.
Les bugs fonctionnent pareil.
La première fois que tu le rencontres, tu passes des heures à chercher ce qui cloche. La dixième fois, tu la repères en lisant le code. La vingtième fois, tu l’as déjà évitée à la conception.
Le bug n’était pas ton ennemi. Il était ton professeur, déguisé en obstacle.
En Agile, les équipes intègrent cette réalité dans leur rythme avec la Definition of Done et les critères d’acceptance. Ce ne sont pas des cases à cocher, ce sont des boss déjà vaincus une fois, qu’on a pris soin de cartographier pour ne plus jamais se faire surprendre de la même façon.
Articles similaires
Quand l'IA code à votre place, qui écrit les règles ?
L'IA génère du code en secondes. Sans schémas contractualisés, elle génère aussi vos futurs bugs de production. Voici comment construire une architecture de la confiance.
Bref. J'ai geeké.
Il n'y a pas d'âge pour geeker. Il n'y a pas de raison de ne pas avoir son site personnel.
Écoconception
Empreinte environnementale estimée · Modèle SWD v4 · 442 g CO₂eq/kWh