Une liste de prompts à copier ne vaut rien : l’outil change et ce que vous avez appris ne vaut plus. Un gabarit est un formulaire à trous dont chaque trou est une décision que vous devez avoir prise avant de parler à l’agent. Aucun nom de produit, aucune capacité de modèle, aucune syntaxe propriétaire : un gabarit décrit une exigence, et il doit survivre au changement d’outil.
Chaque gabarit a sa page. Vous y trouverez ses trous avec la raison de chacun, le corps à copier, ce que vous devez recevoir en retour et ce qui doit vous faire refuser. Les motifs de refus comptent autant que le corps : vous ne refuserez jamais spontanément une réponse, non par complaisance mais parce que vous ne saurez pas sur quoi vous appuyer.
Une page par gabarit, et non les vingt-quatre d’un bloc : la filière compte le budget de données parmi les critères de décision technique, et une page de référence qu’on consulte depuis un téléphone d’entrée de gamme sur une connexion facturée au mégaoctet doit tenir cette règle avant de l’enseigner.
Phase 1. Cadrage
Ce projet doit-il être construit, et si oui, maintenant et sous cette forme ?
Cadrer un besoin · phase 1 · rôle à tenir par l’agent : Responsable produit
À employer au tout premier échange, quand vous n'avez qu'une intention et aucun document écrit. À ne pas employer si une note de cadrage existe déjà : dans ce cas c'est le gabarit de renvoi qu'il faut, pas une seconde note qui contredira la première.
Phase 2. Découverte
Comment le travail se fait-il aujourd’hui, réellement, et sur quelles données ?
Cadrer un besoin · phase 2 · rôle à tenir par l’agent : Analyste métier
À employer quand le produit doit remplacer, prolonger ou se brancher sur quelque chose qui tourne déjà. À ne pas employer sur un projet parti de rien : vous obtiendriez une carte inventée.
Phase 3. Spécification
Que doit faire exactement le produit, et à quoi verra-t-on qu’il le fait ?
Rediger une specification · phase 3 · rôle à tenir par l’agent : Analyste métier
À employer une fois le cadrage figé, pour un seul parcours à la fois. À ne pas employer pour spécifier trois parcours d'un coup : la spécification devient illisible et l'agent en construira un et demi.
Rediger une specification · phase 3 · rôle à tenir par l’agent : Analyste métier
À employer dès qu'un objet du métier change de statut au fil du temps : une commande, un dossier, une demande de congé. À ne pas employer pour un objet qui ne fait que naître et mourir.
Rediger une specification · phase 3 · rôle à tenir par l’agent : Concepteur d’expérience
À employer quand le parcours est spécifié et qu'il faut décrire l'écran qui le porte. À ne pas employer avant la spécification du parcours : vous obtiendriez un joli écran qui ne sert aucun enchaînement connu.
Phase 4. Architecture
Quelle structure retenons-nous, et que nous rendra-t-elle difficile plus tard ?
Choisir une architecture · phase 4 · rôle à tenir par l’agent : Architecte
À employer quand une décision structurante se présente et que vous ne savez pas juger. À ne pas employer pour demander « la meilleure solution » : un agent répondra toujours, et sa réponse dépendra de la façon dont vous avez posé la question.
Choisir une architecture · phase 4 · rôle à tenir par l’agent : Architecte
À employer avant d'accepter qu'un agent ajoute une bibliothèque, un service payant ou un fournisseur tiers. À ne pas employer après coup : une dépendance installée se retire difficilement.
Phase 5. Préparation du chantier
Le chantier est-il équipé pour que la preuve soit produite automatiquement ?
Preparer le deploiement · phase 5 · rôle à tenir par l’agent : Ingénieur d’exploitation
À employer une fois l'architecture décidée et avant le premier incrément. À ne pas employer après avoir commencé à construire : rattraper un atelier absent coûte davantage que de le monter.
Phase 6. Construction
L’incrément demandé existe-t-il, et sa preuve est-elle reproductible par un tiers ?
Construire un increment · phase 6 · rôle à tenir par l’agent : Responsable technique
À employer pour une tranche de travail qui, une fois finie, se démontre en une minute devant quelqu'un. À ne pas employer pour lancer un chantier entier : un agent à qui l'on demande une application rend une application incontrôlable.
Construire un increment · phase 6 · rôle à tenir par l’agent : Développeur serveur
À employer quand quelque chose fonctionne et doit fonctionner autrement. À ne pas employer pour une fonctionnalité neuve : le risque n'est pas le même, et le gabarit d'incrément complet convient mieux.
Construire un increment · phase 6 · rôle à tenir par l’agent : Ingénieur données
À employer avant tout changement de la forme des données, y compris l'ajout d'un simple champ. À ne pas employer pour une modification qui ne touche que l'affichage.
Construire un increment · phase 6 · rôle à tenir par l’agent : Développeur interface web
À employer quand l'écran a été spécifié par écrit et qu'il faut le construire. À ne pas employer sans description écrite : vous obtiendriez un écran plausible, et vous n'auriez rien pour le refuser.
Corriger un defaut · phase 6 · rôle à tenir par l’agent : Responsable technique
À employer une fois la cause désignée et le test de non régression écrit. À ne pas employer tant que le test qui échoue n'existe pas : vous n'auriez aucun moyen de savoir si la correction agit.
Documenter · phase 6 · rôle à tenir par l’agent : Rédacteur technique
À employer après chaque décision que vous avez prise et qui engage la suite. À ne pas employer pour raconter ce que l'agent a fait : le journal enregistre vos décisions, pas son activité.
Refuser et renvoyer · phase 6 · rôle à tenir par l’agent : Responsable technique
À employer quand une livraison s'écarte de ce qui était demandé et que l'essentiel est récupérable. À ne pas employer quand le travail est bon mais que vous avez changé d'avis : ce n'est pas un refus, c'est une nouvelle demande, et elle se paie.
Phase 7. Vérification
L’ouvrage est-il conforme à ce qui a été spécifié, prouvé par quelqu’un qui ne l’a pas construit ?
Ecrire des tests · phase 7 · rôle à tenir par l’agent : Contrôle qualité
À employer juste après la spécification et avant la construction, avec un agent distinct de celui qui construira. À ne pas employer avec l'agent constructeur : il écrirait les tests que son code passe.
Ecrire des tests · phase 7 · rôle à tenir par l’agent : Contrôle qualité
À employer immédiatement après la reproduction d'un défaut, avant sa correction. À ne pas employer après la correction : le test écrit ensuite ne prouve pas qu'il aurait détecté le défaut.
Auditer la securite · phase 7 · rôle à tenir par l’agent : Responsable sécurité
À employer sur un incrément déjà livré, avec un agent distinct de celui qui l'a construit. À ne pas employer comme audit général du produit : une revue sans périmètre rend une liste que personne ne traite.
Auditer la securite · phase 7 · rôle à tenir par l’agent : Responsable sécurité
À employer avant toute mise en service, et après tout incrément qui ajoute une adresse joignable de l'extérieur. À ne pas employer sur du code qui ne sera jamais exposé au réseau.
Refuser et renvoyer · phase 7 · rôle à tenir par l’agent : Contrôle qualité
À employer chaque fois qu'un agent affirme qu'une chose fonctionne sans le montrer. À ne pas employer quand la preuve a été fournie et que vous ne l'avez pas lue : relisez d'abord.
Phase 8. Mise en service
Pouvons-nous mettre en service, et savons-nous en sortir si cela tourne mal ?
Preparer le deploiement · phase 8 · rôle à tenir par l’agent : Ingénieur d’exploitation
À employer avant chaque mise en service, y compris les petites. À ne pas employer pendant un incident : un plan écrit sous pression est un plan que personne ne relit.
Phase 9. Exploitation
Le produit tient-il en service, et ce qu’il nous apprend revient-il au chantier ?
Preparer le deploiement · phase 9 · rôle à tenir par l’agent : Ingénieur d’exploitation
À employer juste après la première mise en service, quand les pannes possibles sont connues et qu'aucune n'est encore survenue. À ne pas employer pendant un incident.
Documenter · phase 9 · rôle à tenir par l’agent : Rédacteur technique
À employer quand une fonctionnalité est acceptée et va servir à quelqu'un d'autre que vous. À ne pas employer pour documenter le code : ce n'est pas le même lecteur ni le même document.