Ejercicios: Metodologías Agile y trabajo en equipo

Explica con tus palabras qué es una metodología ágil y en qué se diferencia de un desarrollo en cascada clásico (análisis → diseño → construcción → pruebas, todo por fases cerradas). Pon un ejemplo de proyecto escolar donde encaje mejor cada enfoque.

En un equipo Scrum aparecen estas tres funciones: (a) decide qué se construye y prioriza la lista de tareas del producto, (b) elimina obstáculos y vela porque se respete el marco de trabajo, (c) construye el producto en cada sprint. Indica qué rol (Product Owner, Scrum Master o equipo de desarrollo) corresponde a cada función y justifica tu elección.

El equipo de una app de recetas usa el tablero Kanban de la figura. Una tarjeta acaba de superar la revisión de código y espera ser colocada. Indica a qué columna debe moverse y qué regla de Kanban hay que comprobar antes de moverla.

Explica qué es un sprint y qué significa que tenga una duración fija («timeboxing»). ¿Qué ventaja tiene comprometerse a no cambiar el alcance de un sprint una vez empezado?

Define qué es un producto mínimo viable (MVP) y explica por qué conviene lanzarlo pronto aunque sea incompleto. Pon un ejemplo de MVP para una app de apuntes compartidos del instituto.

Explica qué es la velocidad de un equipo ágil y para qué se utiliza en la planificación: si un equipo completó $20$, $24$ y $22$ puntos de historia en sus últimos tres sprints, ¿qué velocidad media tiene y cuántos puntos debería comprometer como máximo en el siguiente sprint?

¿Por qué las metodologías ágiles insisten en que el tablero de tareas sea visible para todo el equipo (y, a menudo, también para el cliente)? Explica qué problemas de comunicación evita esta transparencia.

Explica la diferencia entre «terminado» (según la definición de terminado del equipo) y «casi terminado». Razona por qué en Scrum solo cuenta como avance el trabajo completamente terminado y qué problema crea acumular tareas «al 90 %».

Un grupo de cuatro estudiantes desarrolla en un trimestre una app de gestión de préstamos de la biblioteca del instituto, con una demo funcional cada dos semanas ante la bibliotecaria. Explica si te parece más adecuado Scrum o Kanban para este proyecto y razona tu respuesta con al menos dos argumentos.

Un grupo de cuatro estudiantes desarrolla una app de gestión de préstamos de la biblioteca del instituto. Redacta dos historias de usuario con el formato «Como [rol], quiero [función], para [beneficio]» y añade a cada una un criterio de aceptación concreto que permita decidir si está terminada.

Estos eventos de un sprint de Scrum están desordenados: (a) retrospectiva, (b) planificación del sprint, (c) reunión diaria de seguimiento, (d) revisión del incremento con el cliente. Ordénalos, explica qué se hace en cada uno y quién participa.

Un equipo estima sus historias en puntos en lugar de en horas. Explica qué mide la estimación en puntos (esfuerzo, complejidad e incertidumbre relativas) y por qué es más robusta que prometer horas cuando el equipo aún no se conoce bien.

El gráfico de la figura muestra el burndown de un sprint de diez días con $40$ puntos comprometidos: la línea ideal y el trabajo real restante cada día. Interpreta la gráfica: ¿en qué tramo el equipo va retrasado?, ¿qué pudo pasar entre los días 4 y 6?, ¿llegará al final del sprint con el trabajo terminado si mantiene el ritmo de los últimos días?

En la reunión diaria de un equipo cada miembro responde a tres preguntas fijas. Enúncialas y redacta las respuestas que daría un desarrollador que ayer terminó la pantalla de registro, hoy empezará la de perfil y está bloqueado porque el servidor de pruebas no responde. Explica cómo debe actuar el Scrum Master ante ese bloqueo.

Define «deuda técnica» y explica con un ejemplo cómo se acumula (atajos para entregar antes, falta de pruebas, código duplicado). ¿Por qué un equipo que nunca dedica tiempo a reducirla acaba yendo cada vez más lento aunque trabaje las mismas horas?

Tres equipos ágiles desarrollan a la vez la misma plataforma (app móvil, web y servidor). Analiza qué problemas de coordinación aparecen (dependencias entre equipos, integración, prioridades distintas) y propón dos mecanismos para gestionarlos sin volver a una planificación rígida en cascada.

Una empresa encargó a un estudio el desarrollo «llave en mano» de su tienda en línea con contrato en cascada y requisitos cerrados. A los ocho meses, cuando vieron el producto por primera vez, el mercado había cambiado y la mitad de las funciones ya no interesaban. Analiza qué falló en la gestión del proyecto y describe cómo se habría organizado el mismo proyecto con un enfoque ágil: entregas, reuniones y papel del cliente.

Tu clase organiza la feria tecnológica del centro: hay que diseñar los stands, la señalética, la web de inscripción y el programa de charlas en ocho semanas. Diseña el tablero Kanban del proyecto: columnas, límite de trabajo en curso para cada una, una política explícita de «terminado» y cómo visualizarías las tareas bloqueadas.

Alguien afirma: «con metodologías ágiles no se planifica ni se escribe documentación, se programa directamente». Evalúa críticamente esta afirmación apoyándote en los valores del Manifiesto Ágil (individuos e interacciones, software funcionando, colaboración con el cliente, respuesta ante el cambio) y explica qué planificación y qué documentación sí existen en Scrum.

Un cliente exige «todo el alcance, con fecha fija y presupuesto cerrado». Explica el triángulo de hierro de la gestión de proyectos (alcance, tiempo, coste) y razona qué variable debe quedar flexible para que un enfoque ágil funcione. Redacta cómo lo explicarías al cliente sin perder el encargo.

Un equipo Kanban anota que sus últimas diez tareas tardaron desde que entraron «En curso» hasta «Hecho»: $2$, $3$, $3$, $4$, $5$, $5$, $6$, $7$, $8$ y $12$ días. a) Calcula el tiempo medio de ciclo y la mediana. b) Razona qué revela la tarea de $12$ días y qué dos hipótesis la explicarían. c) Explica por qué la mediana es aquí más útil que la media para comprometer plazos.

Una empresa dice hacer Scrum, pero: los requisitos se cierran por contrato al inicio, el Product Owner es en realidad un jefe de proyecto que asigna tareas, las «revisiones» son solo demostraciones internas sin cliente y nunca se cambia nada tras las retrospectivas. Identifica cada anti-patrón y explica por qué el resultado es una cascada con reuniones diarias, no agilidad.

Diseña la retrospectiva de un equipo que acaba un trimestre con la sensación de «ir siempre apagando fuegos»: qué datos objetivos recogerías antes de la reunión (tareas completadas, interrupciones, defectos), qué dinámica usarías para que todos hablen y cómo convertirías las conclusiones en una única mejora accionable para el siguiente trimestre.

Compara la idoneidad de un enfoque ágil para dos proyectos: el software de gestión de una biblioteca y la construcción de un puente de hormigón. Analiza qué hace al software más apto para ciclos cortos (coste de cambio, entregas parciales utilizables, comprobación rápida) y qué principios ágiles sí pueden trasladarse a la obra civil (entregas parciales, reuniones de seguimiento, mejora continua).