Specs et cadrage, le cœur du métier

5.1 Ce que le builder tient vraiment

Le build est délégué. Le périmètre, non. Votre vrai métier consiste à décider ce qui se construit, dans quel ordre, et ce que « terminé » veut dire. Tout ce qui est en amont du code vous appartient : l'intention, les tranches, les arbitrages, le niveau d'acceptation. Perdez le périmètre, et aucune vitesse d'exécution ne vous sauvera.

5.2 L'inventaire d'écrans, le meilleur outil de cadrage qui existe

Avant de construire une fonctionnalité, listez chaque écran qu'elle touche, et pour chaque écran, les quatre états qu'il doit gérer : chargement, vide, erreur, succès. Cette seule habitude attrape l'essentiel du périmètre que vous découvririez sinon en plein build. Une fonctionnalité, ce n'est pas « le chemin heureux ». C'est le chemin heureux plus les trois états que tout le monde oublie. Jamais d'écran blanc.

Le principe plus profond : concevez pour le chemin qui échoue, pas seulement pour celui qui marche. L'état vide et l'état d'erreur ne sont pas des cas limites, c'est là que la confiance se gagne ou se perd. La plupart des fonctionnalités inachevées le sont précisément là.

5.3 « Terminé », dans ses trois formes

« Terminé » ne veut pas dire la même chose selon l'altitude, et nommer les niveaux évite les disputes. Terminé-codé : ça build, ça type-check, le changement existe. Terminé-vérifié : ça a été testé dans un vrai navigateur, les quatre états fonctionnent, les cas limites sont traités. Terminé-livré : c'est en production et vous l'avez confirmé en ligne, le test de fumée est passé. Une chose peut être terminée-codée et très loin d'être terminée-livrée. Dites toujours de laquelle vous parlez.

La Definition of Done, en checklist. Une tranche est terminée quand : elle build et type-check ; les quatre états fonctionnent dans un vrai navigateur ; les cas limites et les chemins d'argent sont testés pour de vrai ; c'est commité et poussé ; c'est déployé et confirmé en ligne (test de fumée passé) ; et la doc ou le changelog est à jour. Tout ce qui est en deçà, c'est « à peu près terminé », autrement dit pas terminé.

5.4 La règle du go, et pourquoi elle est littérale

Quand vous dites « go », ça veut dire go : la décision est prise, on ne redébat pas. Quand quelque chose est marqué livré, c'est livré : on mesure et on itère, on ne le reconstruit pas. Ça paraît évident et c'est violé en permanence. Une grande part du temps perdu vient du rejugement de décisions déjà tranchées. Écrivez la décision, avec son alternative rejetée (Loi 3), et avancez.

5.5 Comment une demande devient du vrai travail

Une demande n'est pas une tâche. « Est-ce que ça pourrait aussi faire X » est une envie floue. La transformer en travail, c'est clarifier le résultat réellement attendu, le dimensionner (incrément ou chantier), trouver où il vit dans le code, trancher les arbitrages, puis le découper. L'écart entre « oui, facile » et le vrai travail est là où naît chaque mauvaise estimation. Cadrez par écrit, pas dans votre tête.

Pour le CTO en vous

la distinction qui évite le plus de conflits est bug ou évolution. Un bug, c'est le produit qui ne fait pas ce qui avait été spécifié. Une évolution, c'est une chose nouvelle que vous voulez maintenant. Urgences différentes, responsables différents, files différentes. Les confondre transforme chaque « il faudrait aussi que » en fausse urgence.

5.6 Parcourez le trajet avant de spécifier, et découpez verticalement

Avant d'écrire une spec, parcourez tout le trajet de l'utilisateur à voix haute, étape par étape : comment cette personne arrive, se connecte, atteint la chose, et que voit-elle à chaque étape. Une spec qui verrouille parfaitement le modèle de données et les points d'entrée mais saute le « comment se connecte-t-elle » livre une fonctionnalité qui existe techniquement et pas concrètement. La question « montre-moi le trajet de bout en bout » vient avant la spec, pas après.

Et découpez verticalement, pas horizontalement. Livrez d'abord un chemin complet et fin (un utilisateur s'inscrit, se connecte, atterrit sur un écran vide qui fonctionne), puis approfondissez. Construire toute la plomberie à l'horizontale avant qu'un seul trajet ne fonctionne de bout en bout, c'est la meilleure façon d'accumuler une classe de bugs qui n'apparaissent qu'au moment où les morceaux se rencontrent enfin.

5.7 La spec qu'un agent ne peut pas mal lire

C'est la compétence au plus fort effet de levier de tout le rôle, et presque personne ne la nomme. Un humain lit une spec approximative et comble les trous avec son jugement. Un agent lit une spec approximative et comble les trous avec une supposition, en toute confiance. Vous écrivez donc pour le lecteur qui ne posera pas de question. Une spec qu'un agent ne peut pas mal lire contient : un objectif en une phrase ; les fichiers et fonctions exacts à toucher, et une liste explicite de ce qu'il ne faut PAS toucher ; les décisions déjà prises, pour qu'il ne les reprenne pas ; les tests qu'il doit faire passer ; et un arbitrage à la fois, jamais un tas. L'ambiguïté n'est pas une petite taxe avec un agent. C'est l'échec lui-même. Si une phrase peut se lire de deux façons, un agent en choisira une et la construira très bien.

5.8 L'hygiène de décision : protéger la seule ressource rare

La ressource rare dans cette façon de travailler n'est pas la puissance de calcul, c'est votre attention de décideur. Protégez-la. Tranchez un arbitrage à la fois, pour que chacun reçoive une vraie réflexion. Dites non par écrit et avec une raison, pour que le non tienne et ne revienne pas la semaine suivante. Groupez les petits choix réversibles et allez vite dessus ; ralentissez uniquement sur ceux qui sont difficiles à défaire (Partie 4). Et tenez un journal de décisions avec l'alternative rejetée (Loi 3), pour ne jamais rejuger une décision acquise pendant qu'une nouvelle attend. Un builder qui dépense son attention sur tout n'en a plus pour les décisions que lui seul peut prendre.