Mejores Practicas y Patrones
Cuando usar BMAD
BMAD no es para todo. Brilla en escenarios con ciertas caracteristicas.
Ideal para
- Features de 8+ horas de desarrollo: si una tarea toma menos de medio dia, el overhead de las 6 fases no se justifica
- Multiples stakeholders: cuando hay requisitos de producto, tecnicos y de negocio que deben alinearse
- Requisitos complejos: features con multiples edge cases, integraciones o flujos de usuario
- Proyectos con compliance: regulaciones que exigen documentacion y trazabilidad de decisiones
- Equipos que usan IA extensivamente: si ya trabajas con agentes de IA, BMAD estructura esa interaccion
- Proyectos greenfield: empezar desde cero con BMAD establece buenas bases de documentacion
Ideal para estos tipos de proyecto
- Aplicaciones SaaS con multiples modulos
- APIs complejas con autenticacion y autorizacion
- Aplicaciones mobile con logica de negocio significativa
- Plataformas con integraciones a servicios externos
- Proyectos con requisitos de seguridad estrictos
Cuando NO usar BMAD
Situaciones donde BMAD agrega friccion innecesaria
- Bug fixes rapidos: si sabes exactamente que esta roto y como arreglarlo, usa el Quick Spec Flow o directamente corrige
- Prototipos y POCs: cuando el objetivo es validar una idea rapido, el overhead de 6 fases mata la velocidad
- Proyectos individuales simples: si trabajas solo en un CRUD basico, los agentes no aportan perspectivas que tu no tengas
- Cambios de configuracion: actualizar variables de entorno o ajustar settings no necesita un Analyst
- Refactors mecanicos: renombrar variables, mover archivos o actualizar imports son tareas directas
La regla practica
Si puedes describir el cambio completo en 3 oraciones o menos, probablemente no necesitas BMAD. Si necesitas un parrafo para explicar que hay que hacer y otro para explicar por que, BMAD probablemente ayuda.
Anti-patrones
Estos son los errores mas comunes al adoptar BMAD. Evitarlos marca la diferencia entre un flujo productivo y uno frustrante.
1. Saltarse fases
El error: “Ya se lo que hay que hacer, voy directo al Developer.”
Por que es problema: sin el PRD del PM, el Developer no tiene criterios de aceptacion claros. Sin la arquitectura, toma decisiones estructurales al vuelo que despues son costosas de cambiar. Sin stories atomicas, intenta implementar features gigantes de una vez.
La solucion: si una fase parece innecesaria, usa el Quick Spec Flow en vez de saltarte fases del Standard Flow.
2. No revisar artefactos intermedios
El error: ejecutar cada fase y aceptar el output sin leerlo.
Por que es problema: los artefactos son la columna vertebral de BMAD. Si el PRD tiene un requisito mal entendido, ese error se propaga al Architect, al Scrum Master, al Developer y al QA. Corregirlo al final es 10 veces mas costoso que al principio.
La solucion: despues de cada fase, dedica 5 minutos a revisar el artefacto generado. Busca inconsistencias, requisitos faltantes o suposiciones incorrectas.
3. Dejar que el Developer lea el PRD completo
El error: darle al Developer el PRD de 15 paginas en vez de stories atomicas.
Por que es problema: el Developer no necesita el contexto completo del producto. Necesita saber exactamente que implementar en esta story, con que criterios de aceptacion, y que dependencias tiene. Un PRD completo lo distrae, confunde y llena la ventana de contexto con informacion irrelevante.
La solucion: el Developer solo recibe la story actual, el archivo de arquitectura relevante y los schemas de datos que necesita. Nada mas.
4. No versionar artefactos en Git
El error: generar los artefactos y no commitearlos.
Por que es problema: los artefactos BMAD son documentacion viva del proyecto. Si no estan en Git, se pierden entre sesiones, no se pueden comparar versiones y no hay trazabilidad de decisiones.
La solucion: cada artefacto se commitea inmediatamente despues de su aprobacion. La estructura _bmad/ es parte del repositorio.
5. Stories demasiado grandes
El error: stories que toman mas de un dia en implementarse.
Por que es problema: stories grandes exceden la ventana de contexto del LLM, acumulan incertidumbre y son dificiles de revisar en QA.
La solucion: si una story toma mas de 4-6 horas estimadas, el Scrum Master debe dividirla. Una buena story cabe en una sesion de trabajo.
6. Usar Party Mode para todo
El error: activar Party Mode para cada decision, por pequena que sea.
Por que es problema: Party Mode consume contexto significativo (multiples agentes respondiendo). Usarlo para decisiones triviales desperdicia tokens y tiempo.
La solucion: Party Mode solo para decisiones con trade-offs genuinos. Si hay una respuesta “obvia”, no necesitas 4 agentes debatiendo.
Tips de Productividad
Empezar con Standard Flow
No intentes personalizar BMAD desde el dia uno. El Standard Flow de 6 fases esta disenado para cubrir el 80% de los casos. Usalo tal cual en tu primer proyecto. Despues de completar un ciclo completo, tendras el contexto para saber que ajustar.
Usar Party Mode para decisiones dificiles
Reserva Party Mode para los momentos donde genuinamente no sabes que camino tomar. Es particularmente util para:
- Elegir entre dos arquitecturas viables
- Definir el alcance de una feature ambigua
- Evaluar si un trade-off de performance vs simplicidad vale la pena
Revisar workflow-status.md frecuentemente
BMAD mantiene un archivo workflow-status.md que registra el estado actual del proyecto: que fase esta activa, que stories estan completadas, cuales estan bloqueadas. Revisarlo al inicio de cada sesion te ubica inmediatamente en el contexto correcto.
Mantener stories de maximo 1 dia
Una story que no se completa en un dia pierde contexto entre sesiones. El LLM necesita recargar el contexto la proxima sesion, lo que consume tokens y puede introducir inconsistencias. Stories pequenas, completadas en una sesion, mantienen la coherencia.
Commitear artefactos con tags
Usa tags o prefijos en los commits de artefactos para encontrarlos facilmente:
bmad: analyst complete - product brief
bmad: pm complete - PRD v1
bmad: architect complete - system design
bmad: sm complete - sprint 1 storiesResumen del Proyecto Kanban
A lo largo de este tutorial, el proyecto Kanban paso por todas las fases de BMAD. Esta tabla resume que ocurrio en cada una:
| Fase | Agente | Artefacto | Resultado |
|---|---|---|---|
| 1. Brainstorming | Analyst | Product Brief | Vision cristalizada: Kanban con auth, boards, cards, drag&drop |
| 2. Requisitos | PM | PRD + User Stories | 15 stories con criterios de aceptacion detallados |
| 3. Arquitectura | Architect | Architecture Doc | Stack definido, schemas de DB, diagramas de sistema |
| 4. Stories | Scrum Master | Sprint Backlog | Stories atomicas de max 1 dia, ordenadas por dependencias |
| 5. Implementacion | Developer | Codigo + Tests | Backend API + Frontend React, tests unitarios e integracion |
| 6. QA | QA | Review Reports | Validacion de seguridad, cobertura y criterios de aceptacion |
El Kanban fue el vehiculo, no el destino. Lo importante es que cada fase genero artefactos que alimentaron la siguiente, y que los problemas se detectaron temprano en vez de acumularse al final.
Comparativa Final
Desarrollo tradicional vs Vibe Coding vs BMAD
| Aspecto | Tradicional | Vibe Coding | BMAD |
|---|---|---|---|
| Planificacion | Documentos extensos, reuniones | Ninguna, se empieza a codear | Estructurada por agentes, artefactos minimos |
| Velocidad inicial | Lenta (semanas de planning) | Muy rapida (se empieza de inmediato) | Moderada (horas de setup por proyecto) |
| Calidad a largo plazo | Alta si el equipo es disciplinado | Decae rapidamente | Alta por revision sistematica |
| Documentacion | Separada del codigo, se desactualiza | Inexistente | Vive en el repo, se genera automaticamente |
| Escalabilidad | Depende del equipo | No escala | Escala con agentes custom y workflows |
| Costo cognitivo | Alto (muchos roles humanos) | Bajo inicial, alto despues | Bajo (agentes manejan la complejidad) |
| Deteccion de errores | En code review o QA manual | En produccion | En cada fase, por agentes especializados |
| Ideal para | Equipos grandes, proyectos largos | Prototipos, hackathons | Proyectos medianos con IA como herramienta |
La conclusion
Desarrollo tradicional funciona pero es caro en tiempo y coordinacion humana.
Vibe Coding (“solo pedile a la IA que lo haga”) es rapido pero fragil. Funciona para prototipos y scripts, pero produce deuda tecnica insostenible en proyectos reales.
BMAD ocupa el punto medio: usa IA de forma estructurada, mantiene la calidad sin el overhead del desarrollo tradicional, y genera documentacion como subproducto natural del proceso.
Recursos
- Documentacion oficial: docs.bmad-method.org
- Comunidad Discord: canal de discusion, templates y soporte
- GitHub: repositorio con templates, agentes de ejemplo y proyectos de referencia
- BMad Builder: herramienta online para configurar agentes custom
Siguiente paso
La mejor forma de aprender BMAD es usandolo. Elige un proyecto que tengas pendiente, preferiblemente uno con al menos 3-4 features significativas, y ejecuta el Standard Flow completo.
No intentes optimizar el proceso en tu primera pasada. Sigue las 6 fases tal como las describe este tutorial. Despues del primer ciclo completo tendras opinion propia sobre que ajustar, que fases aportan mas valor en tu contexto y cuando usar Party Mode.
BMAD es una herramienta, no un dogma. Adaptala a tu equipo y tu proyecto.