Saltar al contenido principal

Sprint 2

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

Feedback General (Conocimiento Transversal)​

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

Presentación y Comunicación​

  • Killer Opener: Debe ser realista y conectar directamente con el producto. Introducir objetos o conceptos que no correspondan con la propuesta real reduce credibilidad. El killer opener bien conectado con la demo mejora notablemente el impacto de la presentación.
  • Demo del Producto: La demo puede ser diferente a la grabada en el vídeo, con el objetivo de explicar mejor los flujos, usar más zoom y mostrar los casos de uso de forma más clara. Hay que priorizar mostrar funcionalidades core y dar protagonismo a los distintos tipos de usuario y sus interacciones con la aplicación.
  • Orden y Estructura: Conviene presentar primero al equipo y la metodología de desarrollo y después los problemas encontrados, no al revés. La primera parte bien enlazada es muy valorada.
  • Síntesis: Se debe evitar entrar en demasiado detalle en ciertos apartados. El mensaje debe ser claro, directo y sin ambigüedades. Expresiones como "todas las tareas están en plazo salvo algunas que no lo están" generan confusión y restan credibilidad.
  • Análisis de Competidores: Debe incluirse en una diapositiva independiente con una tabla clara. El análisis uno a uno es efectivo cuando está bien estructurado. No se debe presentar una comparativa de tecnologías extensa; basta con indicar lo seleccionado y el motivo.

Diseño Visual​

  • Carga de texto: Algunas diapositivas siguen teniendo demasiado texto. Es necesario sintetizar y priorizar información visual. Los elementos gráficos deben tener una función representativa, no meramente decorativa.
  • CI/CD: Las diapositivas de CI/CD deben ser legibles: texto e iconos suficientemente grandes, sin elementos demasiado juntos. El sistema de CI/CD debe explicar el framework de prueba aplicado para cada tipo y nivel.
  • Identidad Visual: Las fotos del equipo deben ser homogéneas y unificadas en toda la presentación. Los colores usados deben alinearse con la identidad del proyecto.
  • Gráficas de Rendimiento: Es necesario incluir gráficas para medir y mostrar la evolución del equipo a lo largo del tiempo, tanto a nivel del sprint actual como de forma acumulada.
  • Diagrama de Gantt: Debe incorporar indicadores claros del progreso de las tareas (como porcentajes o barras de progreso), y reflejar si se han eliminado actividades del sprint como consecuencia de la refactorización.

Gestión de Proyecto y Equipo​

  • Desviaciones de Tiempo: Hay que mostrar la desviación de tiempo por persona tanto a nivel del sprint actual como del proyecto completo, reflejando su evolución. Si hay retrasos en el camino crítico, deben destacarse.
  • Commitment Agreement: Al reportar el seguimiento del Commitment Agreement, hay que diferenciar claramente las desviaciones de tiempo respecto a las métricas de rendimiento, ya que son dos conceptos distintos. Deben definirse objetivos claros y evaluables dentro del propio compromiso.
  • KPIs: No se deben modificar los KPIs para encajar con la situación actual. Lo que debe cambiar es la forma de trabajo para poder cumplirlos.
  • Burndown Chart: El análisis del burndown chart debe ser profundo y permitir extraer conclusiones sobre el progreso del sprint. No basta con mostrarlo; hay que interpretarlo.
  • Rendimiento del Equipo: En la gráfica o cuadrante de rendimiento, no solo hay que mostrar la posición de cada miembro, sino también explicar por qué algunos tienen bajo rendimiento y qué medidas se van a aplicar para mejorarlo.
  • Refactorización: Debe quedar explícito si la refactorización ha implicado cambios en el cronograma y si se han tenido que quitar actividades del sprint para acometerla. Priorizar funcionalidades sobre refactorización debe estar justificado.
  • Replanificación: Es necesario mostrar con claridad las replanificaciones del sprint y que el análisis realizado se traduce en decisiones concretas. El análisis sin decisiones no aporta valor.

Plan de Pruebas​

  • Plan de Pruebas del Sprint actual: El plan de pruebas debe presentarse actualizado para el sprint en curso, no el del sprint anterior. Debe incluir los módulos a probar, los tipos de prueba a realizar, el orden y prioridad de ejecución, y los objetivos específicos de cada prueba.
  • Frameworks por tipo y nivel: Hay que especificar qué framework se utiliza para cada tipo y nivel de prueba (por ejemplo: JUnit para unitarias, Selenium para interfaz). El número de pruebas realizadas y las reglas a seguir también deben aparecer.

Problemas y Soluciones​

  • Nivel de Detalle Adecuado: Los problemas encontrados deben presentarse con suficiente detalle: medidas aplicadas, lecciones aprendidas y planes de contingencia. Sin embargo, no hay que incluir demasiados problemas; conviene centrarse en los más críticos (aproximadamente 5), especialmente los que afectan al camino crítico.
  • Métricas y Umbrales: Para cada solución planteada, deben definirse métricas con umbrales claros y el período en el que se espera que la solución sea efectiva. Esto debe quedar explícito en la presentación, no solo mencionado de forma vaga.

Gestión de Usuarios Piloto​

  • Feedback Recibido: Si ya se ha recibido feedback de los usuarios piloto, hay que demostrar cómo se está reaccionando a él. El mero hecho de recibirlo sin mostrar respuestas concretas no es suficiente. Se valora positivamente mostrar el ciclo completo: feedback -> acción tomada.
  • Metodología de Recogida: El modelo de recogida de feedback puede ser el que se decida, pero debe quedar claro. No limitarse a formularios; considerar también el contacto directo y la observación del comportamiento de los usuarios con la aplicación.
  • Precio del Producto: Conviene plantear a los usuarios piloto qué precio estarían dispuestos a pagar por el producto, para contrastar con las estimaciones de ingresos y verificar si el modelo de negocio es viable.
  • Lista de Usuarios Piloto: Debe aparecer en el entregable pero no necesariamente como diapositiva explícita en la presentación. Incluirla es una condición necesaria del entregable.

Negocio y Finanzas​

  • Escala de Costes: Los costes deben expresarse en miles de euros. No conviene detallar cifras en cientos; reduce la legibilidad y la credibilidad del análisis financiero.
  • Fiscalidad: Hay que revisar si se están teniendo en cuenta todos los impuestos aplicables, no solo la Seguridad Social.
  • Previsiones de Crecimiento: Deben incluirse estimaciones de la evolución del número de usuarios piloto y verificar si se están cumpliendo. Estas previsiones deben estar ligadas a las estimaciones de coste para comprobar si son coherentes entre sí.

Metodología y Arquitectura​

  • Stack Tecnológico: Un stack bien justificado y adecuado al proyecto es valorado positivamente. En la presentación basta con indicar lo seleccionado y el motivo, sin comparativas extensas.
  • División de Equipos: Hay que explicar con claridad el motivo de la división en equipos o squads, ya que esta decisión afecta a la planificación y al rendimiento.
  • Team Building: Las actividades de team building son valoradas positivamente. Hay que detallar qué actividades se proponen, con qué frecuencia se realizan y si están siendo efectivas para el equipo.

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

Feedback General (Conocimiento Transversal)​

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

Fortalezas (Qué hemos hecho bien)​

  • TODO

Debilidades (Qué tenemos que mejorar/corregir)​

  • TODO

Acciones Tomadas / A realizar​

  • TODO