Saltar al contenido principal

Sprint 2

[Sprint 2] – [Fecha: 05/03/2026]​

1. Nuestro Feedback Directo​

Anotaciones sobre lo que los profesores han comentado específicamente sobre nuestra presentación y proyecto.

  • 🟢 Fortalezas (Qué hemos hecho bien):

    • Killer opener: ha funcionado muy bien.
    • Demo en vídeo: ha sido una muy buena idea y encaja con la presentación.
    • Metodología y flujo de CI/CD: están muy bien explicados, especialmente con el diagrama de flechas.
    • Desarrollo por funcionalidad: el cambio se ha percibido como una buena decisión.
    • Métodos de pago: están bien explicados.
    • Gráficas y Gantt: los gráficos funcionan muy bien y el Gantt se entiende con claridad.
    • Identidad visual: los colores son muy representativos y coherentes.
    • Costes: se perciben como realistas.

  • 🔴 Debilidades (Qué tenemos que mejorar/corregir):

    • Hilar video y killer opener: Que en la demo se haga referencia al killer opener para llevar un hilo conductor

[Sprint 2] – [Fecha: 12/03/2026]​

1. Nuestro Feedback Directo​

Anotaciones sobre lo que los profesores han comentado específicamente sobre nuestra presentación y proyecto.

  • 🟢 Fortalezas (Qué hemos hecho bien):

    • Commitment agreement: se nos dice que está muy completo y que nos puede ayudar bastante durante el proyecto
    • Identificación de puntos de equilibrio: Se ha valorado positivamente la inclusión de la diapositiva 46 (punta de equilibrio), sugiriendo incluso darle más protagonismo.
    • Estructura de seguimiento: Buen enfoque en el seguimiento tanto a nivel de Sprint como del proyecto completo.

  • 🔴 Debilidades (Qué tenemos que mejorar/corregir):

    • Hilar mejor la demo con el killer opener.
    • Vídeo demo: indicar al principio qué casos de uso se van a ver.
    • Edición del vídeo: añadir títulos que indiquen qué se está haciendo y qué usuario lo está haciendo, para que quede más claro quién hace qué.
    • Analisis de despliegue: ha sonado repetitiva y no parece el mejor sitio para ese contenido porque ya se había mencionado antes. Mencionarlo junto a los riesgos del stack
    • Análisis sacrificable: el análisis de proveedores y de IA es más prescindible dentro de una presentación de 16 minutos.
    • Pruebas por módulo: dejar clara su obligatoriedad.
    • Umbrales y detalle de pruebas: definir umbrales objetivos y desglosar mejor cuántas pruebas se van a hacer, cuándo se van a hacer y de qué tipo serán.
    • GraphQL: no presentarlo como tipo de prueba, sino como prueba de integración.
    • Prueba 16 / riesgo de integración: remarcar que ya no es solo un riesgo, sino un problema que ya ha ocurrido.
    • Métricas de solución: medir mejor cómo se están solucionando los problemas y cómo se evalúa esa mejora.
    • CAPEX: cuidado con presentar el desarrollo como CAPEX, porque es arriesgado.
    • Fórmulas: acercar los resultados de las fórmulas a su explicación para que se entiendan mejor.
    • Gráficas: añadir ejes y hacerlas más claras.
    • Redundancias: evitar explicar dos veces la misma fórmula.
    • Seguimiento del commitment agreement: mostrarlo tanto sobre el sprint actual como sobre el proyecto completo.
    • Team building: darle más profundidad.
    • Conexión entre secciones: algunas partes quedan algo inconexas, especialmente del Sprint 2 al Sprint 3.