Saltar al contenido principal

Feedback Grupo 7 NexUs

[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 y Cierre: El "killer" funciona porque deja claro lo que aportamos. Muy buen eslogan/alegato final.
    • Gestión Agile: Buena adaptación del sprint (aunque falta aclarar el método para las weeklys).
  • Debilidades (Qué tenemos que mejorar/corregir):

  • Gestión del tiempo (Crítico): Peor imposible. Más de 5 minutos solo con la idea inicial y demasiado detalle innecesario en la metodología. Necesitamos planes de contingencia por si el grupo anterior se pasa de tiempo.

  • Foco y Priorización: Explicar login y registro no es core; hay cosas más interesantes. Hay que aplicar "First things first" (poner primero lo importante, de izquierda a derecha y de arriba a abajo).

  • Métricas y Commitment Agreement: Las métricas actuales son demasiado generales (blanco y negro). Medir el rendimiento requiere diferenciar roles (no es lo mismo evaluar a un coordinador, a un dev o a un documentador).

  • Seguimiento de Riesgos: Falta información clave sobre los problemas encontrados. Hay que especificar si eran riesgos ya identificados, su estado (resuelto/en proceso), porcentajes de resolución (no solo "lecciones aprendidas") y usar métricas para evaluar las medidas de contención.

  • Herramientas y QA: Cuidado con SonarQube/análisis estático y la cobertura (depende de muchos factores). Cuidado con hacer pruebas de rendimiento en producción (pueden fundir los créditos, son para preproducción).

  • Formas y Visuales: Queda raro contar los problemas de un compañero estando presente. En el Gantt hay poco contraste (poco texto negro sobre color) y hay huecos desaprovechados. Faltó mostrar gráficas de evolución del código.

  • 🛠️ Acciones Tomadas / A realizar (Planificación próxima semana):

    • ⚠️ IMPORTANTE - Usuarios Piloto: Durante el S2 se nos asignarán 2 grupos de usuarios piloto internos. Tendremos una tarea extra: realizar un máximo de 6 horas de revisión a otro grupo. Debe haber al menos 2 personas por caso de uso core. Hay que establecer un modelo de gestión y una fecha tope para enviar/recibir este feedback.
    • DEMO y Presentación (16 minutos clavados): La próxima semana hay que hacer una DEMO real (directo o vídeo, pero nada de mockups). Reestructurar la presentación para incluir el "Killer opener", stack tecnológico (con despliegue de entregas), y análisis financiero breve (presupuesto y competencia).
    • Retrospectiva del S1: Análisis detallado del S1 completado vs. previsto, evolución del código (gráficas), desviaciones de los miembros (anonimizadas) y revisión del plan para detallar profundamente el S2 (y por encima el S3).
    • Revisión de Métricas: Crear una "tier list" anónima y definir métricas de rendimiento realistas y específicas por rol. Explicitar los sistemas de CI/CD.
    • Pipeline de Calidad (Feedback Antiguo Alumno): Asegurar un buen pipeline de CI/CD desde ya para garantizar la calidad del código; aunque cueste al principio, ahorrará mucho tiempo después.

2. Feedback General (Conocimiento Transversal)

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

  • Requisitos y Evaluación:

    • Soporte Visual: Comprobar la checklist sobre la presentación, no sobre el discurso. Si no hay soporte visual de algo exigido = SUSPENSO.
    • Cumplimiento: Que se note que cada miembro cumple el commitment agreement.
    • Comportamiento: Tolerancia cero a hablar mientras exponen los compañeros.
  • Negocio y Finanzas:

    • Análisis de Costes (CAPEX vs OPEX): Diferenciar entre costes de capital (compras amortizables, ej. servidores) y costes operativos (servicios contratados no amortizables).
    • Salarios: Diferenciar claramente entre salario neto, bruto y el coste real para la empresa (que incluye Seguridad Social y es casi el doble del neto).
  • Gestión de Proyecto y Equipo:

    • Usuarios Piloto: Deben ser de todo tipo, con perfiles más y menos técnicos. Es vital recibir su feedback y responder ante ellos (entrevistas).
    • Trazabilidad S1/S2: Para el S1 no basta con un Gantt; hay que especificar qué está hecho, qué no, y cómo se ha solucionado. El S2 debe venir ultra detallado.
    • Riesgos: Mantener siempre el hilo conductor y dejar muy claro cómo se solucionan los riesgos y cómo se aplican esas soluciones.
    • Team Building: Recomendación de hacer "team meetings" (quedadas de grupo más relajadas).