Saltar al contenido principal

Flujo de Trabajo (Kanban)

Este documento detalla el flujo de trabajo técnico sincronizado con nuestro tablero de Monday. El cumplimiento de estos estados garantiza la trazabilidad y la calidad de la ingeniería.

1. El Tablero Visual (Sincronizado)​

La progresión de cualquier tarea en el tablero sigue estrictamente este orden:

2. Definición de Estados y Puertas de Calidad​

A. BACKLOG​

Tareas pendientes de priorización por el Product Owner. No tienen asignación de recursos aún.

B. EN DEFINICIÓN / UX​

Fase de Ingeniería y Diseño.

  • Se redacta la lógica en Docusaurus.
  • Se crean flujos en Miro y los prototipos en Figma.
  • Ubicación en Monday: Grupo "EN PROCESO" o "PENDIENTES POR REALIZAR".

C. LISTO PARA DESARROLLO (Definition of Ready)​

Puerta de Calidad Obligatoria. Es el estado de transición entre diseño y código. Solo se puede mover una tarea aquí si:

  • Existe un link válido en la columna Docusaurus/Github Link.
  • El equipo de Backend/Frontend ha validado el contrato de API.

D. EN DESARROLLO​

Construcción técnica activa del requerimiento por parte del equipo de Backend o Frontend.

  • Ubicación en Monday: Grupo "EN PROCESO".

E. QA / REVISIÓN (Code & Doc Review)​

Validación funcional. El revisor comprueba que la funcionalidad cumple con los criterios de aceptación y que el archivo Markdown técnico en Docusaurus ha sido actualizado con los cambios finales de implementación.

F. TERMINADO (Definition of Done)​

Funcionalidad desplegada en producción y documentación viva actualizada y veraz.

  • Ubicación en Monday: Grupo "TERMINADO".

3. Automatizaciones Críticas​

Para mantener la higiene del tablero, el sistema gestiona automáticamente los movimientos:

  1. Auto-Mover: Cambiar a EN DEFINICIÓN o EN DESARROLLO mueve la tarea al grupo EN PROCESO.
  2. Auto-Cerrar: Cambiar a TERMINADO mueve la tarea al grupo TERMINADO.
  3. Validación de Doc: Si el estado es LISTO PARA DESARROLLO y el link de documentación está vacío, el sistema revierte a EN DEFINICIÓN automáticamente y notifica al responsable.

4. Playbook de Release y Rollback​

4.1 Release checklist (previo a producción)​

  • OpenAPI y docs actualizados en mismo PR.
  • pnpm run ci:docs en verde.
  • Migraciones revisadas (up/down) y probadas en staging.
  • Feature flags definidas para cambios de alto impacto.
  • Smoke tests ejecutados: login, registro, búsqueda, cita.
  • Changelog completado usando 14-release-changelog.md.

4.2 Secuencia de release​

  1. Merge a main con checks requeridos.
  2. Deploy canary/rolling en ECS.
  3. Monitoreo 15-30 min (p95, error rate, saturación).
  4. Si estable, promoción completa.

4.3 Criterios de rollback automático/manual​

  • Error rate > 5% sostenido por 5 min.
  • Incremento de latencia p95 > 2x baseline por 10 min.
  • Fallo en health-check crítico (/healthz, /readyz).
  • Evidencia de corrupción de datos o incidentes de seguridad.

4.4 Pasos de rollback​

  1. Congelar despliegues.
  2. Revertir task definition/imagen estable previa.
  3. Si aplica, ejecutar rollback de migración o restaurar snapshot.
  4. Ejecutar smoke tests de verificación.
  5. Registrar incidente y RCA con acciones preventivas.