Retrospectiva Final - AndersenCastanedaUniAndes/proyecto-1 GitHub Wiki

Retrospectiva Final del Proyecto — MediSupply

Periodo cubierto: 16 semanas
Equipo: 3 desarrolladores
Alcance logrado: Prototipo funcional con la mayoría de las funcionalidades mínimas definidas por el cliente.

1. ¿Qué salió bien?

Cumplimiento de las funcionalidades mínimas

El equipo logró implementar todas las funcionalidades obligatorias:

Web

  • Registro de proveedores y carga masiva/individual de productos.
  • Registro de vendedores y creación de planes de venta.
  • Consulta de informes y reportes de rendimiento.
  • Consulta y localización de inventario en bodega.
  • Generación básica de rutas logísticas.

Móvil – Fuerza de ventas

  • Consulta de clientes por vendedor.
  • Ruta de visitas diaria con tiempos estimados.
  • Registro completo de visitas.
  • Creación de pedidos con consulta de inventario en tiempo real.
  • Procesamiento de video y generación de recomendación inicial.

Móvil – Clientes institucionales

  • Registro de clientes.
  • Creación de pedidos desde la app móvil.
  • Consulta del estado del pedido en tiempo real.
  • Consulta de próximas entregas programadas.

Atributos de calidad demostrados

Durante la presentación del prototipo se pudieron demostrar tácticas de:

  • Seguridad: autenticación con JWT.
  • Disponibilidad: uso de la nube.
  • Confidencialidad: encriptación de información sensible.
  • Latencia: consultas críticas < 4 s.
  • Escalabilidad: autoescalado horizontal.
  • Integración: conexión con módulos móviles y sincronización con la parte web.

Trabajo colaborativo efectivo

  • El equipo mantuvo una cadencia sólida: reuniones diarias, sincronización entre arquitectura y desarrollo, entregas semanales.
  • Se participó activamente en las entregas semanales.

2. ¿Qué no salió tan bien?

Sobrecarga en las semanas 8 a la 10

La integración entre módulos web y móvil tomó más tiempo del esperado debido a:

  • Diferencias en serialización de datos.
  • Cambios tardíos del cliente en los modelos de producto.

Esto generó presión adicional en el backend y retrasó validaciones.

Subestimación de la funcionalidad de rutas

Aunque se implementó la generación de rutas, fue:

  • Menos óptima de lo ideal (no se llegó a heurísticas avanzadas).

Falta de automatización de pruebas

La presión por cumplir funcionalidades críticas redujo:

  • Cobertura más alta de pruebas unitarias.
  • Automatización de pruebas de UI en Flutter.
  • Pruebas de resiliencia en picos reales.

Retrasos en la documentación técnica

La documentación de arquitectura se completó cerca de la semana 15, generando:

  • Menos tiempo para revisión.
  • Reducción de la calidad en la sección de integración externa.

3. ¿Qué aprendimos?

  1. La integración temprana es clave: Integrar web, móvil y backend desde el Sprint 2 hubiera reducido retrabajo.
  2. Las demostraciones frecuentes reducen riesgos: Las demos quincenales evitaron desviaciones mayores del alcance esperado.
  3. La arquitectura no debe cerrarse demasiado pronto: Se aprendió a dejar espacio para evolución, especialmente para algoritmos de rutas y compras.
  4. Es mejor limitar el alcance antes que comprometer calidad: Aunque se cumplió todo lo mínimo, algunos módulos quedaron con deuda técnica.

6. Cierre general de la retrospectiva

El equipo concluyó que:

  • Se cumplió el alcance mínimo completo, tal como exigía el cliente.
  • El prototipo demostró viabilidad técnica y permitió justificar una posible ronda de inversión.
  • La arquitectura base es sólida, escalable y lista para evolucionar en una siguiente etapa.
  • Hay oportunidades claras de mejora para una futura versión, especialmente en optimizaciones, automatización y algoritmos inteligentes.