Metodologías ágiles y SCRUM para el TAI: lo que cae del Bloque III

Equipo de desarrollo trabajando con el método SCRUM sobre una pizarra con notas adhesivas

Dentro del Bloque III, el tema de metodologías de desarrollo de software suele generar dudas porque mezcla conceptos de gestión de proyectos con desarrollo puro. Para el TAI no necesitas ser un experto en SCRUM, pero sí tienes que dominar tres cosas: qué diferencia hay entre metodologías tradicionales y ágiles, cómo funciona el marco SCRUM paso a paso, y qué roles y artefactos usa.

¿Qué diferencia hay entre el modelo en cascada y las metodologías ágiles?

El modelo en cascada (waterfall) divide el desarrollo en fases secuenciales y cerradas: análisis, diseño, implementación, pruebas y mantenimiento, cada una empieza cuando termina la anterior. Es fácil de planificar pero muy rígido ante cambios. Las metodologías ágiles (SCRUM, Kanban, Extreme Programming) rompen ese proyecto en ciclos cortos e iterativos, entregan software funcional con frecuencia y aceptan que los requisitos cambien durante el proyecto. El examen suele preguntar por esta diferencia de fondo antes de entrar en detalle en SCRUM.

Equipo colocando notas adhesivas en un tablero para planificar un sprint ágil
Las metodologías ágiles organizan el trabajo en ciclos cortos llamados sprints.

¿Qué roles tiene SCRUM y qué hace cada uno?

SCRUM define tres roles y suele ser justo aquí donde el examen busca confundirte con opciones parecidas:

  • Product Owner: representa al negocio o al cliente, prioriza el Product Backlog y decide qué se construye primero.
  • Scrum Master: facilita el proceso, elimina obstáculos del equipo y vela por que se sigan las reglas del marco, pero no da órdenes técnicas.
  • Equipo de desarrollo: el grupo autoorganizado que construye el incremento de producto en cada sprint.

¿Qué artefactos y eventos hay que memorizar?

Los artefactos son el Product Backlog (lista priorizada de todo lo que puede necesitar el producto), el Sprint Backlog (lo que el equipo se compromete a hacer en el sprint actual) y el Incremento (el resultado entregable al final del sprint). Los eventos son la Planificación del Sprint, el Daily Scrum (reunión diaria breve), la Revisión del Sprint y la Retrospectiva. Una pregunta clásica de examen es identificar qué evento corresponde a una descripción concreta, así que memorizar el orden y el propósito de cada uno es la forma más eficaz de no fallar aquí.

Bloque III del temario
Bloque III TAI: Desarrollo de Sistemas

Metodologías de desarrollo, SCRUM, modelado de datos y bases de datos, explicados dentro del Bloque III completo.

¿Cómo se estudia este tema si no has trabajado nunca en un equipo de desarrollo?

No hace falta experiencia real en proyectos ágiles para aprobar esta parte, pero sí ayuda visualizarlo como un proceso: primero se prioriza el trabajo (Product Backlog), luego se elige qué se hace en las próximas semanas (Sprint Backlog), se trabaja día a día (Daily Scrum), se enseña lo construido (Revisión) y se mejora el propio proceso (Retrospectiva). Dibujar ese ciclo una sola vez ayuda más que leerlo diez veces seguidas.

Equipo planificando un proyecto ágil en una pizarra de oficina
Dibujar el ciclo completo del sprint ayuda a fijar los conceptos mejor que memorizar listas sueltas.

Preguntas frecuentes

¿Hay que saber programar en SCRUM para aprobar esta parte del TAI?

No. El examen pregunta por el marco de trabajo (roles, eventos, artefactos) y por la comparación con metodologías tradicionales, no por código.

¿SCRUM y Kanban son lo mismo?

No. SCRUM organiza el trabajo en sprints con duración fija y roles definidos, mientras que Kanban se basa en un flujo continuo de tareas visualizado en un tablero, sin sprints cerrados.

¿Qué pasa si confundo Product Owner con Scrum Master en el examen?

Es el error más común en este tema. Una forma de no fallar es recordar que el Product Owner decide "qué" se hace y el Scrum Master facilita "cómo" se hace, sin mandar sobre el equipo técnico.

¿Este tema tiene mucho peso dentro del Bloque III?

Comparte protagonismo con el modelado de datos y las bases de datos, pero conviene no descuidarlo porque suele aparecer en forma de preguntas muy concretas y fáciles de acertar si conoces bien la terminología.