agency-phase-3-build

Déclencheurs

• phase de build
• exécution de sprint
• boucle dev qa
• implémentation de feature
• planification de sprint
• assignation de tâche
• build parallèle
• orchestrateur d'agents
• itération de build
• sprint review
• sprint retrospective
• gestion des échecs de tâche
• boucle dev
• boucle QA
• sprint d'implémentation
• développement de feature

Instructions

La Phase 3 implémente toutes les features via des boucles Dev-QA continues. Chaque tâche est validée avant le début de la suivante. C'est là que se concentre l'essentiel du travail et où l'orchestration apporte le plus de valeur. Durée : 2-12 semaines.

Pré-conditions

Vérifier avant de commencer :

1. Quality Gate Phase 2 passée (fondation vérifiée)
2. Backlog Sprint Prioritizer disponible avec scores RICE
3. Pipeline CI/CD opérationnel
4. Design system et library de composants prêts
5. Scaffold API avec système d'auth prêt

La boucle Dev-QA — Mécanique centrale

L'Agents Orchestrator gère chaque tâche via ce cycle :

FOR EACH task IN sprint_backlog (ordered by RICE score):
  1. ASSIGN task to appropriate Developer Agent
  2. Developer IMPLEMENTS task
  3. Evidence Collector TESTS task (screenshots: desktop, tablet, mobile + acceptance criteria + brand check)
  4. IF PASS: Mark task complete, move to next
     ELIF FAIL AND attempts < 3: Send QA feedback to Developer, fix, retry
     ELIF attempts >= 3: ESCALATE to Orchestrator (reassign, decompose, defer, or accept)
  5. UPDATE pipeline status report

Utilisez organization_spawn avec le rôle Agents Orchestrator pour gérer cette boucle. Utilisez organization_delegate pour les assignations de tâches individuelles.

Matrice d'assignation des agents

Pistes de build parallèles

Pour les déploiements complets, quatre pistes s'exécutent simultanément :

Piste A : Développement du produit core (Agents Orchestrator) :

• Frontend Developer, Backend Architect, AI Engineer, Senior Developer
• QA : Evidence Collector, API Tester, Test Results Analyzer
• Cadence de sprint de 2 semaines

Piste B : Préparation Growth & Marketing (Project Shepherd) :

• Growth Hacker : Conception de viral loops et mécaniques de parrainage
• Content Creator : Construction du pipeline de contenu de lancement
• Social Media Strategist : Planification de campagne multi-plateforme
• App Store Optimizer : Préparation de la fiche store (si mobile)

Piste C : Qualité & Operations (Agents Orchestrator) :

• Evidence Collector : QA screenshots pour chaque tâche
• API Tester : Validation d'endpoints pour chaque tâche API
• Performance Benchmarker : Tests de charge périodiques
• Workflow Optimizer : Identification des améliorations de process
• Experiment Tracker : Configuration de tests A/B pour les features validées

Piste D : Polish marque & expérience (Brand Guardian) :

• UI Designer : Affinage de composants
• Brand Guardian : Audit de cohérence marque périodique
• Visual Storyteller : Assets de narration visuelle
• Whimsy Injector : Micro-interactions et moments de délice

Template d'exécution de sprint

Sprint Planning (Jour 1) : Sprint Prioritizer revoit le backlog, sélectionne les tâches par vélocité, assigne aux agents, identifie les dépendances, fixe l'objectif de sprint.

Exécution quotidienne : Orchestrator gère les boucles Dev-QA, suit le statut :

• Tâches complétées aujourd'hui
• Tâches en QA / en développement / bloquées
• Taux de réussite QA

Sprint Review (Jour N) : Project Shepherd facilite la démo, revoit les preuves QA, collecte le feedback des stakeholders.

Sprint Retrospective : Workflow Optimizer anime — ce qui a bien fonctionné, ce à améliorer, métriques d'efficacité du processus.

Gestion des échecs de tâche

• Tentative 1 : Envoyer le feedback QA spécifique au développeur
• Tentative 2 : Envoyer le feedback accumulé, envisager une réassignation
• Tentative 3 : ESCALADER — réassigner, décomposer, réviser l'approche, accepter avec limitations, ou différer

Décision de Gate

Gate Keeper : Agents Orchestrator

• PASS : Application feature-complete -> Phase 4
• CONTINUE : Plus de sprints nécessaires -> Continuer Phase 3
• ESCALATE : Problèmes systémiques -> Intervention du Studio Producer

Utilisez knowledge_write pour persister les résultats de sprint, preuves QA et rapports de statut.

Livrables

• [ ] Tous les sprint tasks passent QA (100% completion)
• [ ] Tous les API endpoints validés
• [ ] Baselines performance respectées (P95 < 200ms)
• [ ] Cohérence marque vérifiée (95%+ respect)
• [ ] Aucun bug critique (zéro P0/P1 ouvert)
• [ ] Tous les acceptance criteria respectés
• [ ] Code review complétée pour tous les PRs
• [ ] Summaires de sprint review et action items de retrospective

Métriques de succès

• 100% completion des sprint tasks avec QA pass
• Tous les API endpoints validés via regression
• Temps de réponse P95 < 200ms
• Cohérence marque 95%+ respect
• Zéro P0/P1 bugs ouverts
• Tous les acceptance criteria respectés par tâche
• Code review complétée pour tous les PRs
• Taux QA first-pass s'améliorant sprint après sprint

Vérifier

• Le livrable de cette phase existe en tant qu'artefact concret (doc, ticket, board, repo) et son emplacement est partagé, pas décrit
• Chaque engagement a un propriétaire nommé, une date limite et une definition-of-done qu'une autre personne que l'auteur pourrait vérifier
• Les risques sont listés avec probabilité/impact et une mitigation nommée, pas une bullet générique 'risques : TBD'
• Les dépendances sur d'autres équipes/vendors/agents sont explicites ; un ack de chaque dépendance est enregistré ou marqué 'pending'
• Les critères de succès de la phase suivante sont numériques ou autrement objectivement testables
• Un critère de rollback / kill-switch / 'nous arrêterons si X' est écrit avant le début du travail