Plan de entrega al negocio — Argos QA (MVP 1)

Estado: Borrador · Última actualización: 2026-08-25 Deriva de: especificaciones (HU-001…HU-027) · Detalle técnico: backlog-desarrollo.md · Decisión: DEC-062

1. La idea en una frase

Construir Argos QA en 5 sprints, donde cada sprint entrega algo que se puede usar y mostrar —no una capa técnica a medias—, avanzando por la cadena de valor del producto: del requerimiento al caso de uso, del plan a la ejecución, y del bug al reporte de calidad.

Cada sprint es una rebanada vertical: al cerrarlo, hay una demo concreta que el negocio puede ver funcionando. El producto queda utilizable de punta a punta hasta esa fase, y el siguiente sprint lo extiende.

2. Los 5 sprints de un vistazo

¹ Estimación con 1 developer senior full-stack usando IA (8 h/día). Total ~700 h ≈ 18 semanas. No incluye fechas: es planificación por sprint, no calendario. El detalle por historia y tarea está en backlog-desarrollo.md.

Momento de valor: desde S2 ya hay una demo con gancho (la IA generando casos). El flujo QA completo —ejecutar, evidenciar, reportar— queda cerrado en S5.

3. Detalle por sprint

Sprint 1 · Plataforma y proyectos

Qué se demuestra. Un usuario entra con su cuenta corporativa (Flagare), ve los proyectos que importó desde Argos Operaciones, arma el equipo del proyecto (Product Manager, QA, Developer, Client) y carga un primer requerimiento. Cada acción queda registrada para auditoría.

Por qué primero. Es la base sobre la que todo lo demás se apoya: identidad, proyectos, equipo y el registro de auditoría. Sin esto no hay dónde colgar los casos, las pruebas ni la evidencia. Concentra además el trabajo de fundaciones técnicas que se paga una sola vez.

Incluye: autenticación (SSO Flagare y roles), gestión de miembros y roles del proyecto, importación y sincronización de proyectos desde Operaciones, archivar/reactivar proyectos, y la auditoría transversal. No incluye (aún): generación de casos con IA (S2), plan de pruebas (S3), ejecución (S4).

Sprint 2 · AI Workspace — casos de uso

Qué se demuestra. El usuario pega un requerimiento en texto o Markdown; la IA lo analiza y propone casos de uso. El usuario los ajusta, crea otros a mano, los revisa y los congela: quedan como una línea base inmutable y versionada.

Por qué aquí. Es la primera demostración con impacto: convierte un documento suelto en casos de uso estructurados en minutos. Aterriza el módulo estrella del producto.

Incluye: ingesta de requerimientos, análisis con IA, generación y edición de casos, congelamiento y versionado, y la orquestación de las operaciones de IA. No incluye (aún): convertir esos casos en escenarios de prueba (S3).

Sprint 3 · Plan de pruebas y ambientes

Qué se demuestra. Desde los casos congelados, la IA genera el plan de pruebas y sus escenarios con criterios de aceptación y una matriz de cobertura que muestra los huecos. El Product Manager aprueba el plan. Se registra y prepara el ambiente donde se probará. A partir de aquí, los hitos disparan notificaciones.

Por qué aquí. Cierra la brecha entre "qué hay que probar" y "cómo se prueba", con una definición estable y aprobada. Es el sprint más liviano y sirve de colchón.

Incluye: generación y edición de escenarios, criterios, matriz de cobertura, aprobación del plan, registro de ambientes (referencias a vault, nunca credenciales) y el motor de eventos/notificaciones. No incluye (aún): la ejecución de los escenarios (S4).

Sprint 4 · Ejecución guiada y evidencia

Qué se demuestra. El QA abre un ciclo de pruebas y ejecuta los escenarios paso a paso, marcando cada uno como Pass, Fail o Blocked, dentro o fuera de un ciclo, y adjunta evidencia (capturas, logs, archivos) en cada paso.

Por qué aquí. Es el corazón operativo del producto: estandariza qué significa "validado" y deja rastro de cómo se validó. Es también el sprint con la funcionalidad más compleja (la ejecución guiada).

Incluye: apertura de ciclos, ejecución guiada paso a paso, ejecución fuera de ciclo y captura/conservación de evidencia. No incluye (aún): el registro formal de bugs y bloqueos y los reportes (S5).

Sprint 5 · Cierre: bugs, bloqueos, reportes y portal cliente

Qué se demuestra. Cuando un escenario falla, se registra un bug que viaja a Argos Operaciones como ticket; se gestionan bloqueos; tras la corrección se reejecuta; se cierra el ciclo con su reporte de calidad; el equipo consulta el dashboard de cobertura y avance, y el Client ve el reporte agregado de su proyecto.

Por qué al final. Cierra el lazo completo de la cadena de valor y depende de que exista la ejecución (S4). Al terminar este sprint, el MVP está completo.

Incluye: registro de bugs hacia Operaciones, bloqueos y su resolución, reejecución tras corrección, cierre de ciclo y reporte de calidad, dashboard de observabilidad y la vista del cliente.

4. Supuestos y notas para el negocio

• Un solo developer full-stack apoyado en IA. Más gente en paralelo comprime el calendario,

sobre todo en S2–S5 (S1 es más secuencial por las fundaciones).

• Sin fechas comprometidas en este plan: son tamaños relativos por sprint. El calendario se

fija al arrancar, con el equipo real y las prioridades del negocio.

• Dependencias externas (API de Operaciones, JWT de Flagare, vault de secretos, modelos de

IA, notificaciones) no bloquean la planificación: cada una se resuelve al construir la tarea que la toca. El detalle está en backlog-desarrollo.md, sección 6.

• Alcance del MVP: quedan fuera funciones marcadas para fases posteriores (automatización

con Playwright, grabación de pantalla, búsqueda semántica, ingesta de binarios).