Party Mode
Regroupez tous vos agents IA dans une seule conversation.
Quâest-ce que le Party Mode ?
Section intitulĂ©e « Quâest-ce que le Party Mode ? »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
Remettre en question une mauvaise architecture
Section intitulĂ©e « Remettre en question une mauvaise architecture »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. »
Brainstorming créatif
Section intitulĂ©e « Brainstorming crĂ©atif »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. »
Décision technique
Section intitulée « Décision technique »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. »
Glossaire
Section intitulée « Glossaire »Footnotes
Section intitulée « Footnotes »-
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. â©
-
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. â©