Saltar al contenido principal

Estrategia de Trabajo y Metodología

Versión: 1.0
Estado: Borrador
Metodología: Kanban + Docs-as-Code

Este documento describe el marco metodológico adoptado para el desarrollo del Proyecto Salud. Nuestro enfoque se centra en la agilidad, la trazabilidad de decisiones y la Documentación Viva (Living Documentation).

1. Gestión del Flujo (Kanban)​

Hemos optado por Kanban para permitir un flujo continuo de entrega de valor. A diferencia de los Sprints cerrados, priorizamos la finalización de tareas y la gestión de cuellos de botella.

HerramientaFunciónRelación con la Documentación
DocusaurusFuente de VerdadContiene el "CÓMO" y las reglas de negocio.
Monday.comGestión de EjecuciónContiene el "QUIÉN", "CUÁNDO" y el estado real.
Miro / FigmaDiseño y FlujosReferenciados mediante Embeds dentro de Docusaurus.
GitHubRepositorioAloja el código y la documentación Markdown.

Los Estados en el Tablero de Trabajo​

Los estados se dividen en las siguientes etapas críticas:

  1. Backlog: Requerimientos de negocio y técnicos pendientes de priorizar.
  2. Definición (Docs-as-Code): Etapa donde se redactan las reglas de negocio en Docusaurus y se diseñan los flujos en Miro. Ninguna tarea avanza sin documentación base.
  3. Ready for Dev: Tareas con diseño aprobado y arquitectura definida.
  4. In Progress: Desarrollo activo de Backend y Frontend.
  5. Testing / QA: Validación funcional y revisión de la documentación técnica (Swagger/Markdown).
  6. Done: Código desplegado, documentación actualizada y validada.

2. Estrategia de Documentación Viva (Living Docs)​

  1. Prioridad de Documentación: No se inicia el estado EN DESARROLLO si el documento técnico en Docusaurus no tiene definida la lógica base o el contrato de API.
  2. Peaje de Calidad: Al mover una tarea a LISTO PARA DESARROLLO, es obligatorio adjuntar el link del documento de Docusaurus en Monday.
  3. Actualización en Caliente: Si durante el desarrollo se descubre una excepción lógica no documentada, se debe actualizar el Markdown antes de subir el código a revisión.
  4. Uso de IDs: Cada tarea en Monday debe llevar el prefijo técnico del Roadmap Técnico.

La documentación no es un proceso posterior al desarrollo; es parte integral de él.

  • Docs-as-Code: Toda la documentación reside en Git, permitiendo versionamiento, revisiones vía Pull Requests y una "única fuente de verdad".
  • Integración de Miro: Los diagramas de flujo y prototipos de baja fidelidad se integran mediante Embeds en Docusaurus. Si el flujo cambia en Miro, se refleja automáticamente en el portal de documentación.
  • Sincronización de API: El Backend utilizará Swagger/OpenAPI para generar automáticamente la referencia técnica, la cual será consultable desde este portal.

3. Registros de Decisiones Arquitectónicas (ADRs)​

Para evitar reuniones repetitivas sobre "por qué se hizo así", utilizamos ADRs. Cualquier cambio significativo en la arquitectura (ej. uso de un nuevo motor de búsqueda, cambio en la lógica de seguros o reuso de Celebremos) debe quedar registrado.

Estructura de un ADR:

  • Contexto: El problema o necesidad.
  • Decisión: La solución técnica adoptada.
  • Consecuencias: Qué ganamos y qué sacrificamos (deuda técnica, costos, etc.).

4. Colaboración Diseño-Desarrollo​

El equipo de diseño (UI/UX) y frontend utiliza Miro como lienzo de ideación rápida.

  1. Exploración: Se dibujan los flujos de usuario en Miro.
  2. Referencia: Se vinculan estos boards en la sección de "Producto" de esta documentación.
  3. Implementación: Los desarrolladores utilizan el Miro como guía lógica y el Figma como guía visual.

5. Control de Calidad y Revisión por Pares​

  • Code Review: No solo se revisa el código, también se verifica que los archivos Markdown relacionados hayan sido actualizados.
  • Actualización de Glosario: Si se introduce un término nuevo en el código, es obligatorio reflejarlo en el glosario.md.