Saltar al contenido principal

Feedback y Mejoras

[Entrega 2: S1 (Mid)] - Fecha: 26/02/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):

    • Reacción al feedback de usuarios: El tema de reaccionar al feedback de los usuarios está bien. Bien remontado con modificaciones del diagrama Gantt.
    • Usuarios piloto: El apartado de usuarios piloto destacó muy positivamente entre los profesores.

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

    • Transparencias de relleno: Hay slides extra innecesarias que no aportan valor a la presentación.
    • Mención temprana del feedback de usuarios: Faltaría mencionarlo al principio con los mocks para dar más contexto desde el inicio.
    • Soporte visual del Scrum: Importante tener soporte visual para el tema del Scrum. Checklist sobre presentación a hierro.
    • Riesgos y lecciones aprendidas: Poco detalle sobre riesgos, problemas encontrados y lecciones aprendidas. Faltan planes de mitigación activos y cómo se están aplicando.
    • Slides mínimas ausentes: Falta slide para análisis de competidores, commitment agreement y presentación de equipos.
    • Evolución del Commitment Agreement: No se muestra la evolución del commitment agreement.
    • Medición de rendimiento: La medición por issues completadas es incompleta en tiempo y forma. Usar puntos de historia por semana (ej: 2 issues × 10 pts = 20 pts / 7 días ≈ índice 2).
    • Presentación del feedback recibido: Presentar en grande un feedback específico y mostrar qué se ha implementado a partir de él, tanto para feedback positivo como negativo.
    • Killer Opener y Core de la app: El killer opener es soso. Especificar claramente el core de la aplicación.
    • Herramientas open source: Mirar la letra pequeña; pueden surgir costes adicionales no previstos.
    • Aseguramiento de código: Usar herramientas de aseguramiento de calidad del código.

  • 🔧 Acciones Tomadas / A realizar:

    • Commitment Agreement individual: Plasmar el commitment agreement individualmente, incluyendo desviaciones y anonimización.
    • Checklist de presentación: Seguimiento del checklist al detalle antes de cada presentación.
    • Detalle del Sprint 1: Especificar más a detalle replanificaciones y tareas cumplidas y no cumplidas durante el S1.
    • Hilo argumentativo: Mejorar la conectividad entre los distintos tópicos de la presentación.
    • Análisis de costes: Diferenciar entre costes de capital (amortizable) y operativos (no amortizable). Mayor detalle en salarios y añadir costes de Seguridad Social.
    • Gestión de riesgos: Explicar cómo se han solucionado los riesgos y cómo funcionan las soluciones de mitigación planteadas.
    • Usuarios piloto para S2: Reaccionar al feedback de usuarios piloto. Al menos 2 personas por cada caso de uso core, con perspectivas distintas. Máximo 6 horas de revisión por grupo.

[Entrega 2: S1 (Final)] - 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):

    • Stack tecnológico: El stack tecnológico del proyecto ha sido bien valorado y se considera adecuado para las necesidades del proyecto.
    • Hilo conductor: El hilo conductor de la presentación basado en responder preguntas ha sido considerado muy efectivo y ha permitido mantener la coherencia.
    • Demo: La demo del producto se ha entendido bien y permite visualizar correctamente la aplicación. Se valora positivamente haber llegado a la demo con tranquilidad y sin precipitación.
    • Exposición del equipo: La forma general de presentar y la coordinación del equipo han gustado a los profesores.
    • Mejoras implementadas: Se ha valorado positivamente la reacción al feedback anterior, especialmente en la organización del Gantt por equipos y la inclusión de medidas más allá del simple conteo de horas.
    • Prácticas de desarrollo: El uso de pair programming se considera una buena práctica dentro del equipo.

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

    • Killer Opener: El killer opener no ha tenido suficiente protagonismo y da sensación de haber sido preparado con prisa. Debe aparecer al principio junto con la demo.
    • Foco en funcionalidades core: En la demo se debería priorizar mostrar funcionalidades core y no tanto procesos como login o autenticación. Algunos casos de uso mostrados no se consideran realmente core.
    • Diseño de diapositivas: Algunas diapositivas siguen estando demasiado cargadas de texto. Los elementos gráficos deberían tener una función más representativa y menos decorativa.
    • Identidad visual: El uso de algunos colores (especialmente rojo) transmite sensación de alerta y no coincide con la identidad visual del proyecto.
    • Análisis de competidores: La comparativa con competidores debería mostrarse en una diapositiva independiente con una tabla clara.
    • Presupuesto: El retorno de inversión estimado en 19 años se considera poco realista y debe revisarse.
    • Feedback de usuarios piloto: El feedback de usuarios piloto no debería limitarse a formularios; debe incluir contacto directo para observar su comportamiento al usar la aplicación.
    • Matriz RACI: La matriz RACI aparece algo desconectada del hilo conductor de la presentación. No era obligatoria, por lo que se podría haber dedicado ese tiempo a reforzar otros aspectos.
    • KPIs: Los KPIs deberían mostrarse junto con su seguimiento o evolución, no solo como valores estáticos.
    • Representación de riesgos: Los riesgos deberían representarse de forma más visual mostrando problema, solución y medida.
    • Granularidad del Gantt: El Gantt tiene poca granularidad y muestra tareas demasiado generales por semana.

  • 🔧 Acciones Tomadas / A realizar:

    • Optimización de diapositivas: Se ha procedido a eliminar el texto excesivo de las diapositivas y revisar las ilustraciones para asegurar que cada una tiene función representativa.
    • Alineación de colores: Se han modificado los colores para que siempre se alineen con la identidad visual del proyecto.
    • Reorganización de la presentación: Se ha movido la demo al inicio de la presentación junto con un killer opener más desarrollado.
    • Comparativa de competidores: Se ha propuesto realizar de nuevo la comparación de competidores en una tabla independiente clara.
    • Eliminación de contenido no esencial: Se ha eliminado la matriz RACI de la presentación, usando los diagramas de Gantt para explicar la relevancia de cada Squad.
    • Mejora del Gantt: Se ha modificado el Gantt para mostrar más tareas con mayor detalle, separándolo en más diagramas.
    • Revisión de riesgos: Se ha cambiado la disposición y representación de los riesgos para hacerlos más visuales.
    • Estrategia de usuarios piloto: Se ha propuesto incluir detalles de feedbacks de usuarios piloto con contacto directo para las próximas presentaciones.
    • Revisión del presupuesto: Pendiente revisar el modelo de retorno de inversión para hacerlo más realista.

2. Qué tener para la semana que viene​

Requisitos y contenido esperado para la próxima sesión.

  • 📋 Formato: 16 minutos de presentación + 5 minutos de feedback.

  • 📌 Contenido obligatorio:

    • Retrospectiva del Sprint 1: Previsión inicial del sprint, rendimiento actual y cómo se está avanzando. Plan de desarrollo orientado al S2 (bien detallado) y S3 (menos detallado).
    • Killer Opener: Idea de proyecto clara con un buen killer opener que especifique el core de la aplicación.
    • Stack tecnológico: Con análisis de riesgos y explicando cómo se van a desplegar todas las entregas.
    • Lecciones aprendidas: Cómo funcionan las soluciones planteadas para los problemas encontrados.
    • Demo: Valorar si se hace en directo (riesgo de tiempos de espera) o en vídeo pregrabado.
    • Metodología de desarrollo: Visión a alto nivel explicando las particularidades del equipo.
    • ALM (CI/CD): Visión breve del sistema de integración y entrega continua.
    • Usuarios piloto: Lista de usuarios piloto, cómo se gestiona y cómo se va a extender.
    • Metodología de feedback para S2: Cómo se va a recoger y gestionar el feedback en el Sprint 2.