Aller au contenu
đŸ€– Consolidated, AI-optimized BMAD docs: llms-full.txt. Fetch this plain text file for complete context.

Party Mode

Regroupez tous vos agents IA dans une seule conversation.

Lancez bmad-party-mode et vous avez toute votre Ă©quipe IA dans une mĂȘme piĂšce - PM, Architecte, DĂ©veloppeur, Designer UX, selon vos besoins. BMad Master orchestre, en sĂ©lectionnant les agents pertinents Ă  chaque message. Les agents rĂ©pondent en personnage, sont en accord ou dĂ©saccord, et construisent sur les idĂ©es des autres.

La conversation continue aussi longtemps que vous le souhaitez. Posez des questions de suivi, remettez en question les rĂ©ponses, redirigez la discussion - c’est un vĂ©ritable Ă©change avec vos agents jusqu’à ce que vous ayez terminĂ©.

Idéal pour :

  • Les grandes dĂ©cisions avec des compromis
  • Les sessions de brainstorming
  • Les rĂ©trospectives post-incident quand les choses tournent mal
  • Les rĂ©trospectives de sprint et la planification

Vous : « Ok l’équipe, notre dernier sprint a Ă©tĂ© un dĂ©sastre. Le service d’authentification est tombĂ© trois fois. Qui a cafouillĂ© ? »

Architecte : « Le design Ă©tait solide - authentification distribuĂ©e avec des fallbacks appropriĂ©s. Si l’implĂ©mentation a dĂ©viĂ© des specs
 »

DĂ©veloppeur : « J’ai suivi le document d’architecture Ă  la lettre. Les specs ne prenaient pas en compte les race conditions lors de l’invalidation de sessions concurrentes. »

PM : « Vous avez tous les deux ratĂ© le vrai problĂšme - nous n’avons pas validĂ© les exigences de gestion des sessions dans le PRD. C’est de ma faute de ne pas l’avoir repĂ©rĂ©. »

TEA : « Et j’aurais dĂ» le repĂ©rer dans les tests d’intĂ©gration. Les scĂ©narios de test ne couvraient pas l’invalidation concurrente. »

Vous : « Comment rendre l’onboarding magique au lieu d’ennuyeux ? »

Designer UX : « Commençons par la divulgation progressive - rĂ©vĂ©lons les fonctionnalitĂ©s au fur et Ă  mesure que les utilisateurs en ont besoin, pas d’un coup dans un tutoriel. »

Storyteller : « Et si l’onboarding Ă©tait une histoire ? Chaque Ă©tape rĂ©vĂšle le parcours d’un personnage - l’utilisateur EST le hĂ©ros. »

Game Designer : « En partant de lĂ  - et si la premiĂšre “quĂȘte” consistait Ă  rĂ©soudre un vrai problĂšme utilisateur ? Ils apprennent en faisant quelque chose d’utile. »

Vous : « Monolithe ou microservices pour le MVP1 ? »

Architecte : « Commencez en monolithe. Les microservices ajoutent une complexitĂ© dont vous n’avez pas besoin Ă  1000 utilisateurs. »

PM : « D’accord. Le time-to-market2 compte plus que la scalabilitĂ© thĂ©orique. »

Développeur : « Monolithe avec des frontiÚres de modules claires. On pourra extraire des services plus tard si nécessaire. »

  1. MVP (Minimum Viable Product) : version minimale d’un produit contenant juste assez de fonctionnalitĂ©s pour ĂȘtre utilisĂ©e par des utilisateurs prĂ©coces et valider les hypothĂšses de marchĂ© avant d’investir dans un dĂ©veloppement plus complet. ↩

  2. Time-to-market : dĂ©lai nĂ©cessaire pour concevoir, dĂ©velopper et lancer un produit sur le marchĂ©. Plus ce dĂ©lai est court, plus l’entreprise peut prendre de l’avance sur ses concurrents. ↩