Saltar al contenido principal

Sprint 2

📅 [Entrega 3: S2] - 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):

    • Análisis de competidores: Muy bien ejecutado, debe mantenerse así.
    • Plan de pruebas: Buena primera versión del plan.
    • Apertura: El inicio sigue siendo efectivo.
    • Innovación en métricas: La nueva herramienta introducida está muy chula (aunque hay que afinar los datos).

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

    • Gestión de la DEMO: Se hace muy larga, hay silencios y ocurren demasiadas cosas. Error crítico depender de Eduroam/conexión en directo. Faltó explicar qué casos de uso y usuarios estaban implicados en cada módulo mostrado.
    • Métricas engañosas e inexactas: En la diapo de trabajo en equipo se listan 5 cosas que no son métricas. Las gráficas de tiempos son engañosas; no contrastan lo esperado con lo cumplido.
    • Falta de detalle en problemas y pruebas: Faltan métricas concretas y umbrales para saber si un problema se ha solucionado. No queda claro el modelo de recogida de feedback. En testing, no se especifica qué pruebas van por módulo ni a qué nos referimos con "minor bugs".
    • Carga visual y de contenido: El diagrama de despliegue tiene demasiada información y no se aprecia. Exceso de detalle en la sección de usuarios piloto y costes calculados "al céntimo" en lugar de explicar la base del cálculo.
    • Ausencias críticas: Falta detalle de Team Building (motivo de SUSPENSO si no está). No se diferencia claramente el cumplimiento del Commitment Agreement respecto al simple conteo de horas.
    • Puesta en escena: El Killer Opener se está volviendo repetitivo; hay que innovar.

  • 🛠️ Acciones Tomadas / A realizar:

    • Control de tiempo estricto: Reducir y ensayar TODA la exposición para clavarla en 16 minutos exactos. Ni un segundo más.
    • Reestructuración de la DEMO: Traerla en vídeo (recortado o por módulos) para ahorrar tiempo y evitar fallos de conexión. Añadir zoom o pantallas más grandes en las partes críticas e ir narrando los casos de uso/usuarios en directo.
    • Limpieza de diapositivas: Simplificar o dividir en dos el diagrama de despliegue. Recortar la diapo de usuarios piloto (solo lista y plan de gestión). Explicar cómo se calcula el CAPEX/OPEX en lugar de dar cifras al céntimo.
    • Definición de Métricas Exactas: * Cambiar los nombres en la diapo de equipo para que sean métricas reales (usar horas, código, la nueva "herramienta Lolo", etc.).
      • Modificar las gráficas de tiempo para contrastar mínimo exigido vs. real (retratar en rojo a quien no llega, ver quién se pasa, etc.).
      • Establecer métricas y umbrales de éxito concretos para la resolución de problemas.
    • Aclaraciones de Proyecto: Definir explícitamente el modelo de recogida de feedback (formulario, excel, etc.). Definir qué son "minor bugs" y asignar prioridades/tipos de prueba por módulo. Diferenciar visualmente Horas vs. Cumplimiento del Commitment Agreement.
    • Team Building: Incluir obligatoriamente los detalles de las actividades de cohesión de equipo.
    • Evolución del Killer Opener: Explorar alternativas donde interactúen los 4 ponentes o el público, buscando algo atractivo pero sin repetir la fórmula de semanas anteriores.

💡 2. Feedback General (Conocimiento Transversal)​

Anotaciones objetivas y aprendizajes generales comentados durante las exposiciones del resto de grupos.

  • Presentación y Puesta en escena:

    • Killer Opener visual: El uso de objetos reales o dinámicas muy visuales funciona muy bien para enganchar, siempre que deje clarísimo desde el primer segundo qué ofrece la app.
    • Ejecución de la DEMO: Debe ser rápida y directa. Es vital contextualizar a la audiencia: indicar siempre qué caso de uso se está mostrando y qué tipo de usuario lo está ejecutando para que nadie se pierda.
    • Diseño de diapositivas: Menos texto y más apoyo visual (iconos, imágenes explicativas).

  • Gestión de Proyecto y Equipo:

    • Métricas de Rendimiento: Gusta mucho el uso de gráficas de dispersión para trackear las horas, pero hay que justificar los "puntos atípicos" (gente que trabaja de más o de menos).
    • Commitment Agreement vs. Horas: Es obligatorio diferenciar entre echar las horas mínimas (ej. 10h semanales) y el rendimiento real/cumplimiento de objetivos del Commitment Agreement.
    • Resolución de Problemas ("Less is more"): No hace falta dar un listado interminable de problemas. Lo que puntúa es detallar el riesgo, la acción correctiva, la métrica usada para controlarlo y el umbral que define si está solucionado.
    • Team Building: Las actividades de cohesión de equipo son obligatorias para aprobar. Deben explicarse de forma estructurada y profesional (no basta con mencionar salidas informales).

  • Requisitos Técnicos y Pruebas (QA):

    • Pruebas medibles y actuales: No hablar de pruebas "a futuro". Hay que indicar el número exacto de pruebas que ya se están haciendo por módulo, de qué tipo son (unitarias, integración), y sus umbrales de aceptación. Se valora mucho plantear pruebas de rendimiento y de aceptación con usuarios piloto.
    • Trazabilidad y CI/CD: El diagrama de Gantt debe tener fechas de despliegue realistas. Hay que mostrar visualmente la evolución del código a lo largo del tiempo.
    • Transparencia con IA: El uso de IA debe ser específico (no genérico), reconociendo dónde se utiliza y demostrando cómo se audita/revisa ese código generado.

  • Negocio, Costes y Usuarios Piloto:

    • Precisión Financiera: No poner cifras económicas al céntimo. Cuidado con clasificar compras de equipos de desarrollo en CAPEX sin tener en cuenta su correcta amortización.
    • Contextualización Económica: Hay que enlazar la previsión de crecimiento de usuarios con los costes y beneficios. Una buena métrica a extraer de los usuarios piloto es: ¿Cuánto estarían dispuestos a pagar por el producto?
    • Gestión de Usuarios Piloto: No listar los nombres uno a uno en la presentación. Mostrar un resumen de alto nivel (estadísticas, categorización de las incidencias reportadas) y explicar claramente el plan de gestión y cómo se está reaccionando a su feedback.