Saltar al contenido principal

Feedback Grupo 8 - Bookmerang

[Entrega 1: S2] – [Fecha: 12/03/2026]​

Nuestro Feedback Directo​

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

  • 🟢 Fortalezas (Qué hemos hecho bien):

    • La primera parte de la presentación está muy bien enlazada y tiene buena cohesión narrativa.
    • La demo al principio de la presentación funciona bien y capta la atención del público.
    • El trabajo de team building ha sido valorado positivamente; se reconoce el esfuerzo en la dinámica de equipo.

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

    • La demo del vídeo/entrañable puede ser diferente a la de la PPT para explicar mejor las cosas, con más zoom y más claridad en los flujos mostrados.
    • Faltan previsiones y estimaciones del crecimiento de usuarios piloto y verificación de si se está cumpliendo, ligando esas estimaciones con las de coste para ver si se corresponden.
    • Hay que incluir el análisis de competidores; se debe quitar el planning del Sprint 1 y eliminar la comparativa de tecnologías (solo mencionar lo seleccionado y el motivo).
    • Se deben enseñar las desviaciones de tiempo por persona, tanto del sprint actual como del total del proyecto.
    • Hay que establecer métricas concretas sobre si las soluciones propuestas están funcionando o no, con umbrales claros y el período en que se espera que sean efectivas.
    • Los costes deben expresarse en miles de euros; no detallar cientos. Revisar también si hay otros impuestos aplicables además de la Seguridad Social.
    • Las fotos del equipo deben ser homogéneas y unificadas en toda la presentación.
    • Al reportar temas del Commitment Agreement, hay que separar claramente las desviaciones de tiempo de las métricas de rendimiento, ya que son dos conceptos distintos.
    • Sobre el team building, añadir más detalle: qué actividades se proponen, con qué frecuencia se realizan y si están siendo efectivas.
    • Se necesita más detalle en el feedback recibido por los usuarios piloto. Si ya se ha recibido, hay que demostrar cómo se está reaccionando a ese feedback.
    • Plantear a los usuarios piloto qué precio estarían dispuestos a pagar por el producto, para contrastar con las estimaciones de ganancias.
    • Añadir la lista de usuarios piloto al entregable (no incluirla explícitamente en la diapositiva); esto es una nueva condición de fallo.
    • El plan de pruebas debe presentarse del Sprint 2 (no del S1), especificando el framework de prueba aplicado para cada tipo y nivel (ej: JUnit para unitario, Selenium para interfaz).
    • Los problemas encontrados necesitan mayor nivel de detalle: medidas aplicadas, lecciones aprendidas, planes de contingencia y métricas con umbrales explícitos.
    • Dejar claro si la refactorización ha implicado cambios en el cronograma y si se han tenido que eliminar actividades del sprint para llevarla a cabo.
    • Se percibe que se prioriza añadir funcionalidades sobre refactorizar; hay que justificar bien esa decisión o corregirla.
    • Dar más importancia a los casos de uso dentro de la demo visual: tipos de usuarios, cómo interaccionan con la aplicación y qué flujos se muestran.
    • Contar los problemas después de presentar al equipo y la metodología de desarrollo, no antes.
    • Explicar más concretamente el motivo de la división de equipos.
    • Algunas diapositivas tienen demasiado texto; hay que sintetizar y aligerar el contenido visual.
    • Incluir una gráfica para representar el rendimiento del equipo.
    • Mostrar la desviación a nivel de sprint y a nivel de proyecto completo, reflejando cómo ha ido evolucionando.

  • Acciones Tomadas / A realizar:

    • Diferenciar el vídeo de la demo del contenido de la PPT para aportar mayor claridad y contexto visual.
    • Incorporar gráficas de evolución de usuarios piloto reales vs. estimados, y enlazarlas con las proyecciones de coste.
    • Incluir la sección de análisis de competidores y eliminar contenido obsoleto del Sprint 1 (planning, comparativa tecnológica).
    • Añadir tablas o gráficas de desviación por persona a nivel de sprint y acumulado del proyecto.
    • Definir métricas con umbrales y periodos temporales explícitos para cada solución planteada a los problemas identificados.
    • Ajustar todas las cifras de costes a miles de euros y revisar la fiscalidad aplicada.
    • Unificar y homogeneizar las fotos del equipo.
    • Separar en diapositivas distintas el seguimiento del Commitment Agreement y el análisis de rendimiento individual.
    • Ampliar la sección de team building con actividades concretas, frecuencia y resultados obtenidos.
    • Mostrar el feedback recibido de usuarios piloto junto con las acciones tomadas en respuesta a ese feedback.
    • Añadir al entregable la lista completa de usuarios piloto (sin exponerla en la diapositiva).
    • Actualizar el plan de pruebas para el Sprint 2 indicando el framework usado por tipo y nivel de prueba.
    • Detallar los problemas del sprint con lecciones aprendidas, planes de contingencia y criterios de resolución.
    • Plasmar explícitamente si la refactorización afectó al alcance planificado del sprint.
    • Reestructurar el orden de la presentación: primero equipo y metodología, luego los problemas encontrados.
    • Incluir gráfica de rendimiento del equipo y evolución de la desviación acumulada.
    • Reducir la carga textual en diapositivas densas, priorizando visualizaciones y resúmenes.

[Entrega 2: S2] – [Fecha: 26/03/2026]​

Nuestro Feedback Directo​

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

🟢 Fortalezas (Qué hemos hecho bien):

  • TODO

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

  • TODO

🛠️ Acciones Tomadas / A realizar:

  • TODO