Saltar al contenido principal

Sprint 1

[Entrega 2: S1] - Fecha: 05/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 tener suficiente protagonismo y no dar sensación de haber sido preparado con prisa. Se recomienda que el killer opener y la demo aparezcan al principio de la presentación para maximizar el impacto.
  • Hilo Conductor: El uso de un hilo conductor basado en responder preguntas ha sido considerado muy efectivo para mantener la atención y coherencia en la presentación.
  • Demostración del Producto: 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. La demo debe mostrar claramente el valor del producto. Se valora positivamente llegar a la demo con tranquilidad y sin precipitación.
  • Análisis de Competidores: La comparativa con competidores debería mostrarse en una diapositiva independiente con una tabla clara. El análisis de competidores uno a uno se considera claro cuando está bien estructurado.

Diseño Visual​

  • Carga de texto: Algunas diapositivas siguen estando demasiado cargadas de texto. Es necesario sintetizar y priorizar información visual.
  • Elementos gráficos: Los elementos gráficos o ilustraciones deberían tener una función más representativa y menos decorativa. Aunque elementos como mascotas pueden gustar, en algunos casos ocupan espacio que podría usarse para información relevante.
  • Identidad visual: El uso de algunos colores (especialmente rojo) puede transmitir sensación de alerta y no coincidir con la identidad visual del proyecto. Los colores deben alinearse con la marca del proyecto.
  • Imagen de marca: La imagen de marca del proyecto y elementos distintivos (como mascotas) cuando están bien integrados son valorados positivamente tanto por alumnos como por profesores.

Gestión de Proyecto y Equipo​

  • Planificación y Gantt: El Gantt puede tener poca granularidad y mostrar tareas demasiado generales por semana. La organización del Gantt por equipos/squads permite identificar bien qué tareas realiza cada grupo. Se recomienda separarlo en más diagramas y mostrar más detalle de tareas.
  • KPIs y Seguimiento: Los KPIs deberían mostrarse junto con su seguimiento o evolución, no solo como valores estáticos. Se valora positivamente incluir medidas más allá del simple conteo de horas de trabajo.
  • Riesgos: Los riesgos deberían representarse de forma más visual mostrando problema, solución y medida de forma clara y estructurada.
  • Prácticas de desarrollo: El uso de pair programming se considera una buena práctica dentro del equipo cuando se aplica correctamente.

Gestión de Usuarios Piloto​

  • Metodología de feedback: El feedback de usuarios piloto no debería limitarse a formularios y debería incluir contacto directo para observar su comportamiento al usar la aplicación. La observación directa aporta información más valiosa que solo respuestas escritas.

Negocio y Finanzas​

  • Desglose de costes: El desglose de costes detallado es valorado positivamente. Debe ser completo y realista.
  • Retorno de inversión: El retorno de inversión debe ser realista. Estimaciones como recuperar la inversión en 19 años se consideran poco realistas y deben revisarse.

Metodología y Arquitectura​

  • Stack tecnológico: Un stack tecnológico bien justificado y adecuado al proyecto es valorado positivamente.

Herramientas y Documentación​

  • Matriz RACI: La matriz RACI puede aparecer desconectada del hilo conductor de la presentación. Si no es obligatoria, se podría dedicar ese tiempo a reforzar otros aspectos más relevantes. En su lugar, se pueden usar diagramas de Gantt para explicar la relevancia de cada equipo en las actividades.

[Entrega 2: S1] - Fecha: 26/02/2026​

Feedback General (Conocimiento Transversal)​

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

Requisitos y Evaluación​

  • Soporte Visual Obligatorio: Comprobar la checklist sobre la presentación, no sobre el discurso. Si no hay soporte visual de algo exigido equivale a suspenso. Lo que se pide explícitamente para cada semana tiene que tener soporte visual en las diapositivas sí o sí.
  • Cumplimiento del Commitment Agreement: Que se note que cada miembro cumple el commitment agreement. Incluir evidencias visuales del cumplimiento mediante mecanismos de seguimiento interno del equipo (checklists, evaluaciones internas).
  • Comportamiento: Tolerancia cero a hablar mientras exponen los compañeros.
  • Corrección conceptual: No es MVP sino Core; el MVP se va construyendo durante la clase.

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). El modelo financiero debe distinguir entre inversión inicial y costes operativos mensuales.
  • 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). Desglosar costes de recursos humanos por rol.
  • Presupuesto Completo: Debe contemplar todos los tipos de costes, no únicamente recursos humanos. Incluir costes de publicación en App Store y Play Store, licencias, APIs y coste por tokens. Contemplar el factor tiempo y la diferencia temporal entre ejecución de tareas y devengo/pago de gastos.
  • Sostenibilidad económica del proyecto: Acompañar el presupuesto con proyecciones que relacionen costes, crecimiento de usuarios y posibles ingresos. Explicar cómo el crecimiento en número de usuarios contribuirá a compensar los costes. Representar gráficamente la evolución del presupuesto, mostrando el punto de equilibrio y cuándo podría alcanzarse la rentabilidad. Comparar el presupuesto proyectado con el número de usuarios potenciales para evaluar viabilidad.
  • Modelo de Monetización: Considerar distintos modelos (comisiones por transacción, planes de suscripción, microtransacciones). Evitar afirmaciones sin base sólida como "rentable desde el minuto 1".

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). Gestionar la introducción de usuarios piloto en fases tempranas para evitar experiencias negativas que provoquen abandono prematuro. Debe establecerse una estrategia progresiva de incorporación. Definir estrategia clara para ampliar el número de usuarios piloto. Presentar en grande un feedback específico y mostrar qué se ha implementado a partir de él. Durante el S2 se asignarán grupos de usuarios piloto internos con tarea de revisión (máximo 6 horas, al menos 2 personas por caso de uso core). Activamente usar el feedback recibido, no limitarse a formularios; incluir contacto directo para observar comportamiento real.
  • 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. El diagrama de Gantt debe mostrar claramente qué tareas ya se han completado y cuáles quedan pendientes dentro del sprint. Incluir el estado actual de las tareas para mejorar transparencia. Debe tener suficiente granularidad mostrando tareas específicas, no generalizaciones por semana. Organización por equipos/squads permite identificar bien qué tareas realiza cada grupo.
  • Replanificación de Sprints: Justificar con mayor detalle la replanificación realizada, explicando los cambios e impacto en el proyecto. Contar con el tiempo extra que supondrá procesar el feedback de usuarios piloto. Tener en cuenta las semanas no lectivas.
  • Riesgos y Problemas: Mantener siempre el hilo conductor y dejar muy claro cómo se solucionan los riesgos y cómo se aplican esas soluciones. Documentar los problemas detectados, su estado de resolución y las acciones correctivas aplicadas. Especificar si eran riesgos ya identificados, su estado (resuelto/en proceso), porcentajes de resolución. Representarlos visualmente mostrando problema, solución y medida.
  • Medición de soluciones: No todas las acciones aplicadas pueden considerarse automáticamente una mejora; es necesario medir su impacto antes de convertirlas en lecciones aprendidas. Establecer métricas que permitan medir si las soluciones implementadas realmente están funcionando. Definir métricas para evaluar efectividad de acciones de mitigación.
  • Seguimiento del equipo: Incluir indicadores o visualizaciones del progreso de cada miembro durante el sprint. Mostrar desviaciones de los miembros (anonimizadas). Incluir gráficos (Clockify) por personas y no solo por tareas.
  • Calidad de tareas: Diferenciar entre una tarea completada y una tarea realizada con la calidad esperada.
  • Métricas y Rendimiento: Las métricas deben ser específicas por rol (no es lo mismo evaluar a un coordinador, un dev o un documentador). Definir umbrales objetivos claros (máximos y mínimos). Trabajar por milestones. La medición por issues completadas es incompleta; usar puntos de historia por semana. Incluir métricas basadas en objetivos, no solo en horas. Mostrar KPIs junto con su seguimiento o evolución.
  • Team Building: Recomendación de hacer "team meetings" (quedadas de grupo más relajadas).
  • Cultura de Equipo: Todos los equipos deben realizar código; eliminar separación por departamentos. Todos los integrantes deben tener tareas de desarrollo asignadas.
  • Retrospectiva: Incluir la Retrospectiva en el esquema de Scrum académico. Análisis detallado del S1 completado vs. previsto, evolución del código (gráficas), desviaciones y revisión del plan.

Metodología y Arquitectura​

  • Presentación de la Metodología: Presentar primero la metodología de desarrollo adoptada y posteriormente el stack tecnológico utilizado. Buena adaptación de Scrum debe ser explicada claramente.
  • Explicación de la adaptación de Scrum: Las diferencias o adaptaciones realizadas respecto a Scrum deberían apoyarse con elementos visuales que faciliten su comprensión. Mantener en las diapositivas las diferencias explícitas respecto al modelo estándar. Si se menciona un elemento (como un tablero), este debe aparecer explícitamente en las diapositivas incluir Weekly meetings.
  • ALM (CI/CD): Explicitar los sistemas de CI/CD. Ser mucho más explícitos al explicar la integración continua. Asegurar un buen pipeline desde el inicio para garantizar calidad del código; aunque cueste al principio, ahorrará tiempo después. Incluir herramientas de aseguramiento de calidad del código.
  • Stack Tecnológico: Priorizar APIs y herramientas ampliamente utilizadas o conocidas para facilitar adopción e integración. Con análisis de riesgos explicando cómo se van a desplegar todas las entregas. Profundizar en la integración y posibilidades de las APIs utilizadas. Realizar análisis de licencias y herramientas. Mirar la letra pequeña de herramientas open source; pueden surgir costes adicionales. Considerar sostenibilidad de créditos/licencias hasta el final del curso.

Presentación y Comunicación​

  • Orientación al Core: Los esfuerzos de desarrollo deben enfocarse en las funcionalidades principales del sistema, priorizando el núcleo del producto frente a funcionalidades secundarias como registro o login. Explicar login y registro no es core; hay cosas más interesantes. Aplicar "First things first". Especificar claramente el core de la aplicación.
  • Killer Opener: Debe funcionar dejando claro lo que se aporta. En la representación, la persona que actúa debe hablar más; no se debe hablar por ella. Puede reutilizarse estratégicamente a lo largo de la presentación. No debe prepararse con prisa y debe tener protagonismo. Se recomienda que aparezca al principio junto con la demo.
  • Gestión del Tiempo: Necesario tener planes de contingencia por si el grupo anterior se pasa de tiempo. Control estricto del tiempo durante la exposición. Próximas presentaciones deben ser de 16 minutos clavados.
  • Foco y Priorización: Centrar primero la idea y después presentar los mockups. Evitar exceso de mockups antes de explicar el core. No extenderse en temas irrelevantes.
  • Narrativa de los Mockups: Debe explicarse con mayor claridad en qué situaciones se produce cada caso de uso mostrado. Contextualizarlos adecuadamente indicando el momento de inicio de la sección. Mostrar recorrido completo de navegación en lugar de capturas estáticas. Diferenciar claramente qué tipo de usuario interviene en cada caso de uso.
  • Demostración del Producto: Demostrar el trabajo realizado con usuarios piloto evidenciando cómo su feedback ha influido en el desarrollo. Presentar la demo mediante un vídeo corto para agilizar y evitar problemas técnicos (riesgo de carga, red inestable, mala percepción si falla). Demos en directo ralentizan y dispersan atención. En demos, priorizar funcionalidades core sobre procesos como login. Casos de uso mostrados deben ser realmente core. Valorar si la demo aparece al principio de la presentación.
  • Marketing y Desarrollo: Las acciones de marketing deben alinearse con el estado actual del desarrollo del producto. Definir plan de captación de usuarios para validar el producto.
  • Fluidez y Transiciones: Mejorar conexiones entre secciones para evitar saltos bruscos. Ajustar ritmo y coordinar tiempos entre presentadores. Evitar falta de sincronización entre miembros del equipo.
  • Análisis de Competidores: Centrarse únicamente en los 2-3 más relevantes. Evitar exceso de tiempo dedicado a este apartado. Incluir slide específica con comparativa final clara en tabla.
  • Presentación Poco Autocontenida: Evitar referencias a presentaciones pasadas ("como dije la semana pasada"). Usar "hemos usado" en lugar de "vamos a usar". Algunos elementos requieren contexto adicional; cada sesión debe ser independiente.
  • Soporte Visual: Debe acompañar adecuadamente la explicación oral. Los elementos gráficos deben tener función representativa, no solo decorativa. Simplificar el Gantt si tiene demasiados colores y poca claridad; desglosarlo para mayor detalle. Evitar slides de relleno innecesarias. Evitar diapositivas demasiado cargadas de texto. Algunos colores (como rojo) transmiten sensación de alerta y pueden no coincidir con la identidad visual.
  • Herramientas y QA: Cuidado con SonarQube/análisis estático y la cobertura (depende de muchos factores). Nunca hacer pruebas de rendimiento en producción (pueden fundir los créditos); son para preproducción.
  • Diseño y UX: Los mockups deben ser suficientemente desarrollados. Necesitan casos de uso desarrollados y explicar la gestión de errores (qué pasa si el usuario se molesta ante un fallo). Definir flujo de usuario claro mostrando el recorrido lógico dentro de la plataforma. Segmentar usuarios definiendo con precisión qué perfil corresponde a cada caso de uso específico.