Démo Squad produit

Ce que vous démontrez#

Que la squad est une méthodologie, pas seulement un générateur de code. La même ossature Recherche → Planification → Implémentation → Revue qui pilote la démo Azure anime aussi la découverte métier et la livraison — sous la responsabilité de spécialistes nommés, avec décisions et historique conservés, et une validation pour chaque action à conséquences. La différence pour un client non technique : chaque étape aboutit à un livrable qu'il peut lire et approuver — un document d'exigences, une feuille de route, une présentation — jamais à du Markdown brut enfoui dans un dépôt.

Avant de commencer#

Cette démo n'accède à aucun cloud et n'écrit que des documents : elle s'exécute donc partout où VS Code et Copilot sont disponibles — idéale pour une première présentation. La seule option supplémentaire qui mérite d'être configurée est l'approbation depuis un téléphone, pour qu'un sponsor non technique puisse approuver le travail de la squad depuis son appareil.

Ancrez la démo dans leur réalité#

Le scénario ci-dessous utilise une variable, {{CLIENT_PROCESS}} — un processus métier que le client souhaite améliorer (accueil des nouveaux arrivants, approbation des dépenses, réception des demandes de support, achats, ou tout autre processus). Adaptez-la à chaque client ou, en direct, laissez le client nommer lui-même son problème à l'étape 1. Les rôles de découverte sont généralistes : la squad traite donc le sujet qu'il apporte.

Étape 0 — Initialiser la squad#

/squad profile=product request="Set up the squad for a business improvement project."

Le coordinateur découvre le dépôt, propose le profil product et initialise la squad après votre confirmation. À expliquer : « Une seule équipe — spécialistes de la découverte, des exigences, de la feuille de route, de l'expérimentation et de la présentation — accompagnée de l'ossature méthodologique : researcher, lead, developer, tester, pour que recherche → planification → réalisation → revue reste toujours présente, même pour les travaux métier. »

À l'initialisation, le coordinateur propose un canal d'approbation. Choisissez github-issue pour permettre à un sponsor d'approuver depuis un téléphone avec un commentaire /approve ; conservez le canal par défaut in-chat pour une exécution simple à votre poste.

Étape 1 — Découverte#

/squad request="Explore the problem of {{CLIENT_PROCESS}}. Map the people involved, their journey today, and where it hurts — produce personas and a journey map."

Le researcher rassemble le contexte et le designer (DT Coach) mène les phases d'empathie et de définition du Design Thinking — personas et carte du parcours. Cette étape est manifestement non technique : elle porte sur les personnes et le processus, pas sur les systèmes. Conseil pour le direct : demandez au client de fournir {{CLIENT_PROCESS}} ici — c'est bien plus convaincant qu'un scénario préparé.

Étape 2 — Exigences (BRD)#

/squad request="Turn the discovery into a Business Requirements Document for {{CLIENT_PROCESS}} — goals, scope, stakeholders, business requirements, and success measures."

L'analyst (BRD Builder) produit un document d'exigences prêt à être approuvé. C'est ici que la méthodologie devient visible : la rédaction du BRD est une étape de niveau confirm : la squad effectue donc les recherches et planifie le document avant de le rédiger, puis le revoit — le livrable métier est planifié et revu, pas improvisé.

Étape 3 — Feuille de route et backlog#

/squad request="Sequence the requirements into a phased roadmap and a refined backlog of goal-oriented stories with acceptance criteria."

Le lead planifie les phases et le product-owner (Functional Planner) organise le backlog en une hiérarchie validée d'éléments de travail orientés résultats, avec critères d'acceptation. Le client termine l'étape avec une feuille de route et un backlog prêt à être mis en œuvre — le lien entre l'idée et la livraison.

Étape 4 — Valider à moindre coût#

/squad request="Design a Minimum Viable Experiment to test the riskiest assumption behind {{CLIENT_PROCESS}} before we build anything."

L'experimenter (Experiment Designer) formule une hypothèse et conçoit l'expérimentation la moins coûteuse qui pourrait la confirmer ou l'infirmer. À expliquer : « Avant de dépenser un dollar pour construire, la squad nous indique le plus petit test capable de réduire le risque lié à l'idée. »

Étape 5 — Revue de préparation (feu vert / arrêt)#

/squad request="Run a go/no-go readiness review of the plan and backlog before we commit — call out gaps, risks, and conditions."

Le product-owner vérifie l'adéquation du produit et le tester (Plan Validator) recoupe le plan avec la découverte et les exigences, puis rend un avis clair : feu vert / conditions / arrêt. C'est une gouvernance compréhensible par un sponsor non technique : la squad ne laisse pas passer le travail lorsqu'une véritable lacune subsiste.

Étape 6 — Présentation de direction#

/squad request="Build an executive summary deck of the whole initiative: the problem, the journey, the requirements, the roadmap, and the experiment — for a non-technical leadership audience."

Le presenter (PowerPoint Subagent) assemble une présentation prête pour le conseil d'administration à partir des livrables déjà produits par la squad. Le suivi systématique de revue (Review Follow-Through) sollicite ensuite tester pour vérifier la présentation par rapport aux livrables sources : le livrable final est donc validé, pas simplement généré. Le client repart avec un support qu'il peut utiliser en réunion de direction.

La version « une demande, une exécution »#

Le même parcours s'exécute à partir d'une seule demande autopilot qui exprime le besoin sans nommer les étapes. La squad déduit elle-même leur enchaînement :

/squad mode=autopilot profile=product request="We want to improve {{CLIENT_PROCESS}} for our team. Understand who is involved and where it hurts today, write up the business requirements, lay out a phased roadmap with a refined backlog, design a cheap experiment to test the riskiest assumption, do a readiness review, and finish with an executive summary deck for non-technical leadership. Keep me in control of anything that needs my sign-off."

À partir de cette seule ligne, autopilot organise le pipeline et ne s'arrête que lorsque c'est nécessaire :

• Initialisation — propose le profil product et attend votre confirmation.
• Recherche → Planification — découverte (researcher + designer), puis plan de la feuille de route (lead).
• Implémentation — analyst, product-owner, experimenter et presenter rédigent le BRD, le backlog, l'expérimentation et la présentation.
• Revue — tester valide chaque livrable par rapport à la découverte et aux exigences.
• Validation du résultat final — envoie une notification au contact que vous avez enregistré et attend votre accord avant de déclarer l'initiative terminée.

Vous n'intervenez qu'à la confirmation du profil et à la validation finale — c'est le mode « dites-le une fois, laissez-le travailler ». Si l'approbation github-issue a été configurée à l'initialisation, un sponsor peut donner cet accord depuis un téléphone.

Solutions de repli en cas de problème#

Points clés pour conclure#

• C'est une méthodologie, pas un modèle. Recherche → planification → réalisation → revue s'exécute dans chaque profil : même la découverte métier est donc planifiée et revue par des spécialistes nommés.
• Chaque étape est un livrable. Découverte, BRD, feuille de route, expérimentation, présentation — le client approuve des livrables, pas du code.
• Approuver où que l'on soit. Avec l'approbation github-issue, un sponsor non technique donne son accord depuis un téléphone.
• Exécution en direct sans risque. Sans cloud, sans dépense, sans code — idéale pour une première présentation, et un conseil dimensionné selon le risque intervient dès qu'un véritable risque apparaît.