Agence logicielle · Delivery
Livraison logicielle et recette client
Menez chaque jalon des exigences validées à une recette client enregistrée. Le client confirme les critères d'acceptation et valide la recette via un lien public, et aucune version ne lui parvient avant l'approbation de la QA et du responsable technique.
- Durée: 4 à 8 semaines
- Fréquence: Pour chaque jalon
- Étapes: 11 étapes
- Agents IA: 2 agents IA
- Approbations: 3 approbations
Plan gratuit, sans carte de crédit.
Ce que ce modèle change
Sans le modèle
Le client se souvient d'une fonctionnalité indispensable pendant la démo de sprint.
Une version à moitié testée arrive en préproduction la veille de la démo client.
La recette se résume à un pouce levé en visio, introuvable un mois plus tard.
La QA rédige chaque plan de test en partant de zéro.
Avec le modèle
Le client confirme les critères d'acceptation avant le développement, et l'équipe travaille sur une seule liste.
Les tests client restent verrouillés jusqu'à ce que la QA et le responsable technique approuvent la version.
Le client valide sur l'exécution, avec les contrôles cochés, son nom et l'heure.
Un agent IA rédige le plan de test à partir des critères, et l'ingénieur QA le relit.
Le modèle, étape par étape
Chaque étape indique qui la réalise : une personne de votre équipe, un agent IA ou le client via un lien public. Une approbation garde toutes les étapes suivantes verrouillées jusqu'à ce qu'elle soit donnée.
- Réalisé par votre équipe
- Réalisé par un agent IA
- Réalisé par le client, via un lien public
Démarre quand
Un jalon du contrat est prêt à démarrer. Le chef de produit lance une exécution avec le nom du client et le jalon.
- 1
Rédiger le périmètre et les critères d'acceptation
Semaine 1Chef de produit · Équipe
Transformez le jalon du contrat en user stories avec des critères d'acceptation testables, notez les questions auxquelles le client doit encore répondre, et envoyez le tout par e-mail avec les maquettes au product owner du client.
Checklist
- Chaque story a des critères d'acceptation
- Ce qui est hors périmètre est noté
- Critères et maquettes envoyés au client
Champs à remplir
- Jalon (obligatoire)
- Critères d'acceptation (obligatoire)
- Questions pour le client
- Lien vers les maquettes (obligatoire)
- 2
Le client confirme les exigences
Semaine 1Product owner du client · Lien public
Le product owner du client lit les critères d'acceptation, les maquettes et les questions envoyés par le chef de produit, puis répond aux questions et confirme le périmètre via le lien public. L'équipe développe et teste sur ce qui est confirmé ici.
Checklist
- Critères d'acceptation lus
- Maquettes examinées
- Questions ouvertes traitées
Champs à remplir
- Réponses aux questions ouvertes
- Lien vers les règles métier ou des exemples
- Je confirme les critères d'acceptation (obligatoire)
- 3
Rédiger le plan de test
Semaine 1Rédacteur de plans de test · Agent IA
Le rédacteur de plans de test transforme chaque critère d'acceptation confirmé en cas de test avec étapes et résultats attendus, et ajoute des tests de non-régression pour les fonctionnalités touchées par le jalon.
Champs à remplir
- Brouillon du plan de test (obligatoire)
Contrôle humain: L'ingénieur QA relit et complète le plan de test à l'étape 4.
- 4
Relire le plan de test
Masqué sur le lien publicSemaine 2Ingénieur QA · Équipe
Vérifiez que chaque critère d'acceptation a un cas de test, ajoutez les cas limites oubliés par le brouillon et liez le plan de test définitif.
Checklist
- Chaque critère a un cas de test
- Cas limites ajoutés
- Données de test prêtes en préproduction
Champs à remplir
- Lien vers le plan de test définitif (obligatoire)
- 5
Développer et relire en sprints
Semaines 2 à 5Responsable technique · Équipe
Développez les stories en sprints et relisez chaque modification avant de la fusionner. Si l'équipe attend une réponse du client, marquez l'exécution comme bloquée et notez la question.
Checklist
- Chaque modification relue avant fusion
- Démos de sprint tenues avec le client
- Aucune question ouverte au client
Champs à remplir
- Date de version prévue (obligatoire)
- Notes de sprint (obligatoire)
- Lien vers le travail fusionné (obligatoire)
- Ce que l'équipe attend
- 6
Tester chaque critère en préproduction
Masqué sur le lien publicSemaine 6Ingénieur QA · Équipe
Déroulez le plan de test en préproduction, consignez les anomalies dans l'outil de suivi des tickets et retestez les correctifs jusqu'à ce qu'aucun bug critique ou majeur ne reste ouvert.
Checklist
- Chaque critère testé
- Tests de non-régression passés
- Aucun bug critique ou majeur ouvert
- Problèmes mineurs connus notés
Champs à remplir
- Lien vers le rapport de test (obligatoire)
- Problèmes connus
Approbation: L'approbation de la version reste verrouillée jusqu'à ce que l'ingénieur QA approuve les résultats de test.
- 7
Rédiger les notes de version
Semaine 6Rédacteur de notes de version · Agent IA
Le rédacteur de notes de version rédige pour le client les notes à partir des critères d'acceptation, des notes de sprint et des problèmes connus : ce qui est nouveau, ce qui a changé et ce qui reste ouvert.
Champs à remplir
- Brouillon des notes de version (obligatoire)
Contrôle humain: Le responsable technique corrige les notes et approuve la version à l'étape 8.
- 8
Approuver la version pour la recette client
Semaine 6Responsable technique · Équipe
Lisez le rapport de test, corrigez les notes de version et vérifiez que la préproduction fait tourner la version testée. Approuvez-la ensuite et envoyez par e-mail au product owner du client le lien de préproduction et les notes de version.
Checklist
- Rapport de test lu
- Notes de version corrigées
- La préproduction fait tourner la version testée
Champs à remplir
- Lien de préproduction envoyé au client (obligatoire)
Approbation: La recette client reste verrouillée jusqu'à ce que le responsable technique approuve la version.
- 9
Le client teste en préproduction et valide
Semaine 7Product owner du client · Lien public
Le product owner du client teste la version en préproduction, avec le lien envoyé par l'équipe, au regard des critères d'acceptation, puis coche chaque contrôle et enregistre sa décision via le lien public. Les problèmes vont dans le champ ci-dessous, avec des liens vers des captures d'écran ou des enregistrements.
Checklist
- Chaque critère d'acceptation testé
- Notes de version lues
Champs à remplir
- Décision (obligatoire)
- Problèmes constatés
- Liens vers des captures d'écran ou des enregistrements
- 10
Statuer sur les constats du client
Semaine 7Chef de produit · Équipe
Passez en revue la décision et chaque constat avec le responsable technique. Si un constat bloque la recette, marquez l'exécution comme bloquée avec le motif jusqu'à ce que le correctif soit vérifié et que le client soit d'accord, puis approuvez la mise en production.
Checklist
- Chaque constat classé bloquant ou non
- Constats bloquants corrigés et vérifiés
- Autres constats planifiés pour un jalon ultérieur
Champs à remplir
- Constats reportés à un jalon ultérieur
Approbation: La mise en production reste verrouillée jusqu'à ce que le chef de produit l'approuve.
- 11
Mettre en production et clôturer le jalon
Semaine 7Ingénieur DevOps · Équipe
Déployez la version validée avec le plan de retour arrière prêt, lancez les smoke tests et notez la version mise en production.
Checklist
- Plan de retour arrière prêt
- Smoke tests réussis
- Supervision vérifiée après la mise en production
Champs à remplir
- Version mise en production (obligatoire)
- Date de mise en production (obligatoire)
Terminé quand
Le client a validé le jalon au regard des critères convenus, et la version est en production avec le rapport de test, les approbations et la recette sur l'exécution.
Adaptez-le. Renommez les étapes, changez les responsables et ajoutez des points de checklist, des champs ou des approbations. Le modèle est un point de départ pour la façon de travailler de votre équipe.
Les agents IA de ce modèle
Un agent ne travaille que sur ses propres étapes, et une personne de votre équipe vérifie ce qu'il a fait. Tout ce qu'un agent écrit dans une application connectée attend une approbation, sauf si vous l'autorisez.
Rédacteur de plans de test
Transforme les critères d'acceptation confirmés en brouillon de plan de test.
Ce qu'il fait
- Lit les critères d'acceptation et les réponses du client sur l'exécution
- Rédige des cas de test avec étapes et résultats attendus
- Ajoute des tests de non-régression pour les fonctionnalités touchées par le jalon
- Termine son étape pour que l'ingénieur QA puisse relire
Contrôle humain: L'ingénieur QA relit et complète le plan de test à l'étape 4.
Rédacteur de notes de version
Rédige pour le client les notes de la version qui part en recette.
Ce qu'il fait
- Lit les critères d'acceptation, les notes de sprint et les problèmes connus
- Rédige ce qui est nouveau, ce qui a changé et ce qui reste ouvert
- Écrit les notes dans un langage clair pour le client
- Termine son étape pour que l'approbation de la version puisse commencer
Contrôle humain: Le responsable technique corrige les notes et approuve la version à l'étape 8.
Les questions auxquelles ce modèle répond
Demandez la validation au regard des critères d'acceptation que le client a confirmés au départ, pas au regard d'une démo. À l'étape 9, le product owner du client teste en préproduction, puis coche chaque contrôle et enregistre sa décision via le lien public, avec son nom et l'heure sur l'exécution.
Convenez de critères d'acceptation testables avant le début du développement, et faites-les confirmer par écrit par le client. À l'étape 2, le product owner du client répond aux questions ouvertes et confirme les critères via le lien public, pour que l'équipe développe et teste sur une seule liste convenue.
Faites dépendre les tests client de résultats de test approuvés, pas de la date de la démo. Les étapes 6 et 8 sont des contrôles d'approbation : les tests client restent verrouillés jusqu'à ce que l'ingénieur QA et le responsable technique aient tous deux approuvé la version.
Gardez les critères d'acceptation, les résultats de test et la décision du client au même endroit. L'exécution montre les critères confirmés à l'étape 2, les résultats et approbations des étapes 6 et 8, et la recette de l'étape 9 avec nom et heure.
Laissez l'IA rédiger le plan de test et les notes de version à partir de ce que votre équipe a déjà écrit, et gardez la relecture pour des personnes. À l'étape 3, le rédacteur de plans de test rédige des cas de test que l'ingénieur QA relit à l'étape 4, et à l'étape 7 le rédacteur de notes de version rédige des notes que le responsable technique corrige à l'étape 8.
Séparez les bugs qui bloquent la recette de ceux qui peuvent attendre, et laissez une personne trancher. À l'étape 10, le chef de produit classe chaque constat comme bloquant ou non, garde l'exécution bloquée jusqu'à la vérification des correctifs bloquants, et n'approuve la version qu'ensuite.
Exécutez ce workflow dans OKiDO
Configurez les étapes, les responsables et les approbations une fois, puis lancez une exécution pour chaque nouveau cas.