Le développement n'est qu'un rogue-like IRL
Le build émerge en cours de route
L’une des choses les plus fascinantes dans les rogue-likes, c’est la notion de build. Au début d’une partie, tu ne sais pas vraiment ce que tu vas jouer. Tu prends ce que le jeu t’offre. Et progressivement, un style émerge, une cohérence s’installe.
Tu n’avais pas planifié d’être “ce personnage qui empoisonne tout le monde”. Mais les circonstances t’ont amené là, tu as fait des choix qui s’emboîtaient, et maintenant tu as un build solide.
Ta carrière de développeur ressemble à ça. Tu n’avais peut-être pas prévu de devenir expert en observabilité, ou de te spécialiser dans les systèmes distribués, ou de passer autant de temps dans des terminaux à lire des logs. Mais chaque projet a ajouté une pièce, et tu as construit quelque chose de cohérent, de puissant, de toi.
Le build ne se planifie pas entièrement à l’avance. Il se découvre.
C’est ce que le Product Backlog incarne à sa façon : une liste vivante, jamais figée, qui évolue à chaque run. On ne définit pas tout le produit dès le départ. On affine, on priorise, on laisse le build prendre forme au fur et à mesure que la réalité du donjon se révèle.
L’Agilité : un game design pensé pour les équipes
Si on pousse la métaphore, l’Agilité n’est pas juste une méthode de travail. C’est un game design conçu pour transformer une équipe en équipe qui sait jouer aux rogue-likes.
Les sprints encodent le cycle “run courte, feedback immédiat”. La rétrospective est le debriefing post-mort par excellence : qu’est-ce qui nous a tués cette fois ? Qu’est-ce qu’on emporte pour la prochaine run ? Qu’est-ce qu’on abandonne parce que ça ne sert plus à rien ? C’est le moment où l’équipe pose ses apprentissages, exactement comme le joueur qui analyse ses erreurs entre deux parties.
Toujours dans le Scrum Guide (Schwaber & Sutherland, 2020) : la rétrospective de sprint a pour objectif de planifier des moyens d’améliorer la qualité et l’efficacité. L’équipe Scrum y examine comment s’est déroulé le dernier sprint, identifie les hypothèses qui ont conduit à des erreurs et leurs origines, et détermine les changements les plus utiles pour progresser.
La vélocité mérite aussi d’être relue sous cet angle. On en parle souvent comme d’un indicateur de performance. Mais c’est avant tout une stat qui mesure comment l’équipe progresse run après run. Une vélocité qui augmente régulièrement ne dit pas “vous travaillez plus vite”. Elle dit “vous comprenez mieux le donjon”.
Et le MVP ? C’est le build minimal pour survivre au premier boss. Pas le build parfait. Le build suffisant pour entrer dans le donjon, tester ce qui fonctionne, et revenir avec des informations utiles pour la suite.
Sa définition : le MVP est la version d’un nouveau produit qui permet à une équipe de collecter le maximum
d’apprentissages validés sur ses clients avec le minimum d’effort.
[Source]
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