Saltar al contenido principal

Feedback Grupo 6 KeaKit

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

    • Killer opener efectivo: La apertura de la presentación resultó clara y logró captar la atención inicial del público.
    • Orientación del producto bien definida: La propuesta muestra una dirección clara y coherente respecto al objetivo del producto.
    • Aplicación de Scrum bien explicada: Se valoró positivamente la explicación sobre cómo se ha adaptado la metodología Scrum al proyecto.

  • 🔴 Debilidades (Qué debemos mejorar):

    • Ritmo de presentación demasiado rápido: La exposición se realizó con excesiva rapidez en algunos momentos, lo que dificultó la comprensión de ciertos apartados.
    • Falta de sincronización entre presentadores: Se detectaron diferencias en el ritmo de intervención entre los miembros del equipo, lo que afectó a la fluidez general.
    • Transiciones entre secciones poco claras: La presentación carece de conexiones claras entre las distintas partes, lo que dificulta seguir el hilo argumental.
    • Mockups poco contextualizados: No se aclaró adecuadamente el momento en el que comenzaba la explicación de los mockups ni cómo se relacionaban con los casos de uso.
    • Visualización de mockups mejorable: El uso de capturas de pantalla dificulta apreciar el flujo de navegación de la aplicación. Se recomienda mostrar el recorrido completo por la app para entender mejor la interacción.
    • Diferenciación de usuarios en mockups insuficiente: Es necesario indicar claramente qué tipo de usuario interviene en cada caso de uso o funcionalidad mostrada.
    • Presentación poco autocontenida: Algunos elementos requieren contexto adicional para ser comprendidos, lo que reduce la claridad para el público.
    • Planificación del proyecto poco detallada: El diagrama de Gantt y el desglose de tareas necesitan mayor nivel de detalle.
    • Estado de las tareas poco visible: No queda claramente reflejado el estado actual de las tareas dentro del sprint.
    • Análisis de despliegue insuficiente: Falta profundizar en las posibles amenazas o riesgos asociados al despliegue de la aplicación.
    • Presupuesto poco desarrollado:
      • No se han incluido costes asociados a la publicación de la app en App Store y Play Store.
      • Falta diferenciar entre costes de capital y costes operativos.
      • Los costes de recursos humanos requieren mayor desglose, incluyendo salario por rol, costes de seguridad social y otros gastos asociados.
      • No se ha incluido un cálculo detallado del coste por desarrollador o por hora.
      • Falta contemplar cómo evolucionarán los costes cuando la aplicación se encuentre en fase de despliegue y mantenimiento.
      • No se ha diferenciado el presupuesto según fases del proyecto (desarrollo, despliegue, operación).
    • Viabilidad económica poco justificada: Es necesario comparar el presupuesto proyectado con el número de usuarios potenciales o usuarios piloto para evaluar si el proyecto puede cubrir sus costes.
    • Gestión de riesgos incompleta: No se ha medido la efectividad de las acciones de mitigación propuestas ni se han definido métricas para evaluar si funcionan correctamente.

  • 🛠️ Acciones Tomadas / A realizar:

    • Ajustar el ritmo de la exposición y coordinar previamente los tiempos entre los distintos presentadores.
    • Mejorar las transiciones entre secciones para reforzar el hilo argumental de la presentación.
    • Introducir claramente el inicio de la sección de mockups y explicar el flujo de uso de la aplicación paso a paso.
    • Mostrar la navegación real o simulada entre pantallas en lugar de utilizar únicamente capturas estáticas.
    • Indicar explícitamente qué tipo de usuario interactúa en cada caso de uso mostrado.
    • Detallar el diagrama de Gantt y el desglose de tareas del proyecto.
    • Incluir el estado actual de las tareas para mejorar la transparencia del avance del sprint.
    • Profundizar en los riesgos asociados al despliegue y definir estrategias de mitigación.
    • Ampliar el presupuesto del proyecto incorporando:
      • Costes de publicación en App Store y Play Store.
      • Diferenciación entre costes de capital y costes operativos.
      • Desglose detallado de costes de recursos humanos.
      • Estimación de coste por desarrollador y por hora.
      • Diferenciación de costes según fases del proyecto.
    • Comparar el presupuesto proyectado con la estimación de usuarios potenciales para analizar la sostenibilidad económica.
    • Definir métricas para medir la efectividad de las acciones de mitigación ante riesgos e incidencias.

    [Entrega 2: S1] - 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 (Lo que hemos logrado y debemos mantener):

    • Demostración del producto: La demo del sistema fue clara y permitió visualizar el funcionamiento de la aplicación. El uso de comentarios y pequeños elementos de humor ayudó a mantener la atención del público durante la explicación.
    • Paralelización del trabajo: Se valoró positivamente la capacidad del equipo para trabajar en paralelo en distintas tareas durante el sprint, lo que favorece la eficiencia del desarrollo.
    • Retrospectiva del sprint: La retrospectiva fue completa y permitió identificar tanto los problemas surgidos durante el sprint como las soluciones aplicadas.
    • Gestión de incidencias: La exposición de los problemas encontrados y las soluciones propuestas fue clara y bien estructurada.
    • Planificación financiera: La gráfica de presupuesto con identificación de puntos de ruptura fue valorada positivamente como herramienta para analizar la sostenibilidad económica del proyecto.

  • 🔴 Debilidades (Áreas de mejora y puntos de dolor):

    • Duración de la demo: Aunque la demostración fue correcta, se recomienda reducir ligeramente su duración para mantener un ritmo más dinámico durante la presentación.
    • Comunicación oral: Se detectaron algunas muletillas durante la exposición y signos de nerviosismo que pueden afectar a la claridad del discurso.
    • Elementos visuales poco relevantes: Algunos recursos gráficos utilizados durante la explicación del sprint review (por ejemplo, ciertos dibujos o elementos decorativos) no aportaban información significativa al contenido presentado.
    • Análisis del burndown: Es necesario profundizar en la interpretación del burndown chart, analizando posibles cuellos de botella, cambios de ritmo en el desarrollo o escalones en la evolución del trabajo.
    • Exceso de transparencias en la sección de problemas: Aunque la identificación de problemas fue adecuada, el número de diapositivas utilizadas resultó excesivo. Se recomienda centrarse en incidencias más generales o representativas.
    • Descompensación de horas de trabajo: Se detectaron desequilibrios en la distribución del esfuerzo entre miembros del equipo, lo que requiere medidas de ajuste.
    • Seguimiento de desviaciones en tareas: Es necesario implementar mecanismos que permitan monitorizar de forma sistemática las desviaciones respecto a la planificación inicial.
    • Medición de la calidad del trabajo: Debe diferenciarse entre completar una tarea y garantizar la calidad de la contribución realizada.
    • Coordinación entre equipos: Es necesario evaluar si la coordinación entre subequipos está funcionando correctamente y si los responsables están facilitando adecuadamente la comunicación y el seguimiento del trabajo.
    • Análisis financiero incompleto: Aunque la gráfica de presupuesto fue positiva, se recomienda incluir estimaciones optimistas y pesimistas para reflejar distintos escenarios posibles.

  • 🛠️ Acciones Tomadas / A realizar (Mejoras de formato y planificación):

    • Reducir ligeramente la duración de la demo del producto, manteniendo únicamente los pasos más representativos del funcionamiento del sistema.
    • Trabajar la comunicación oral, reduciendo muletillas y mejorando la seguridad durante la exposición.
    • Revisar los elementos visuales utilizados en la presentación, eliminando aquellos que no aporten valor informativo.
    • Realizar un análisis más profundo del burndown chart, identificando posibles cuellos de botella, variaciones en el ritmo de trabajo y patrones en la evolución del sprint.
    • Sintetizar la sección de problemas detectados, agrupando incidencias similares y priorizando las más relevantes para el proyecto.
    • Implementar medidas para equilibrar la distribución de horas de trabajo entre los miembros del equipo.
    • Diseñar un sistema de monitorización de desviaciones en tareas, que permita identificar con mayor precisión retrasos o cambios en la planificación.
    • Incorporar mecanismos para evaluar la calidad de las contribuciones, diferenciándola del simple cumplimiento de tareas asignadas.
    • Mejorar la coordinación entre subequipos, por ejemplo mediante métricas de seguimiento específicas o análisis del progreso por equipo.
    • Ampliar el análisis del presupuesto, incluyendo escenarios optimistas y pesimistas que permitan evaluar distintos niveles de riesgo financiero.