Aller au contenu
đŸ€– Consolidated, AI-optimized BMAD docs: llms-full.txt. Fetch this plain text file for complete context.
🚀 Build your own BMad modules and share them with the community! Get started or submit to the marketplace.

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. ↩