Clase 3 — Scrum como Marco de Trabajo Ágil

Resumen Ejecutivo

La sesión presenta Scrum como un marco de trabajo ágil estructurado en torno a tres pilares fundamentales: roles, eventos (reuniones) y artefactos. Se explica el flujo completo de un sprint —desde la planificación hasta la retrospectiva— y se detallan las responsabilidades diferenciadas del Product Owner, el Scrum Master y el equipo de desarrollo. Se enfatiza repetidamente que Scrum no contempla la figura de jefe de proyecto y que los equipos deben ser autoorganizados y multifuncionales (cross-functional).

Conceptos Clave

Scrum: Marco de trabajo ágil (no metodología) para gestionar proyectos de forma iterativa e incremental. ⚠️ EXAMEN
Sprint: Iteración de duración fija en la que se desarrolla un incremento del producto. ⚠️ EXAMEN
Product Owner (Dueño de Producto): Responsable de maximizar el valor del producto y gestionar la pila de producto.
Scrum Master: Facilitador que asegura la correcta aplicación de Scrum; no es jefe de proyecto. ⚠️ EXAMEN
Equipo de Desarrollo: Grupo autoorganizado y multifuncional que implementa el incremento.
Pila de Producto (Product Backlog): Especificación priorizada de todas las características del sistema.
Pila de Sprint (Sprint Backlog): Subconjunto de la pila de producto comprometido para un sprint, descompuesto en tareas.
Burn Down Chart: Gráfico de seguimiento del avance del sprint (no es artefacto propio de Scrum, pero se usa habitualmente).

Desarrollo del Temario

1. Naturaleza de Scrum y su sencillez

Scrum es un marco general de trabajo, no una metodología cerrada. Su popularidad se debe a su sencillez: se reduce a roles, eventos y artefactos. Es tan genérico que puede aplicarse fuera del software (vida personal, fabricación, etc.). A diferencia de XP (Programación Extrema), Scrum no prescribe prácticas de ingeniería concretas. ⚠️ EXAMEN

La referencia oficial es la Scrum Guide, mantenida por Sutherland y Schwaber.

2. Pilares de Scrum: Transparencia, Inspección y Adaptación ⚠️ EXAMEN

Transparencia: Toda la información del proyecto (pila de producto, objetivos, avance) debe ser accesible y visible para todos los miembros del equipo. Se materializa en tableros, wikis o repositorios documentales.
Inspección: No basta con que la información esté disponible; los participantes deben revisarla activamente y de forma frecuente.
Adaptación: Cuando se detectan desviaciones, problemas o información incompleta, se toman medidas correctoras de inmediato.

3. Valores de Scrum

Compromiso, Coraje, Focalización, Apertura y Respeto (este último añadido en 2016). ⚠️ EXAMEN

Estos valores conectan directamente con los cuatro valores del Manifiesto Ágil:

Valor del Manifiesto Ágil	Cómo lo implementa Scrum
Individuos e interacciones > procesos y herramientas	Equipo autoorganizado, reuniones frecuentes (al menos daily)
Software funcional > documentación excesiva	Entregas al final de cada sprint, demostradas en la revisión
Colaboración con el cliente > negociación contractual	Figura del Product Owner como interlocutor permanente
Respuesta al cambio > seguir un plan	Pilares de transparencia, inspección y adaptación

4. Fases de Scrum: Prejuego, Juego y Posjuego

Prejuego: Definición y mantenimiento de la pila de producto + planificación del sprint al comienzo de cada iteración.
Juego: Desarrollo de las funcionalidades del sprint, con seguimiento diario (dailies).
Posjuego: Reunión de revisión (demo al cliente) + reunión de retrospectiva (análisis técnico interno).

5. Los Roles en detalle

Product Owner (Dueño de Producto) ⚠️ EXAMEN

No es jefe de proyecto. No asigna tareas ni supervisa al equipo.
Responsable del éxito del producto y de maximizar el ROI (Retorno de la Inversión).
Gestiona y prioriza la pila de producto.
Puede no tener formación técnica; su expertise es el dominio de negocio.
Puede ser externo a la empresa desarrolladora (viene de la empresa cliente).
Participa formalmente en: planificación de sprint y revisión de sprint.
Decide si el incremento pasa a producción.

Ejemplo: Si desarrollamos un sistema de gestión de inventarios para IKEA, el Product Owner puede venir de IKEA porque conoce los procesos logísticos, de facturación y contratación, que los desarrolladores no tienen por qué dominar.

Equipo de Desarrollo

Autoorganizado: nadie externo les asigna tareas individualmente. ⚠️ EXAMEN
Multifuncional (cross-functional): no hay subroles fijos (frontend, backend, tester...). Todos deben poder contribuir donde se necesite. ⚠️ EXAMEN
Estima esfuerzos, se compromete con la pila de sprint y demuestra la entrega.

Ejemplo del profesor: Si un sprint requiere mucho trabajo de frontend, todo el equipo debe poder hacer HTML, CSS o React. Si solo trabaja "el de front", el resto está ocioso. Por eso los roles especializados rígidos son "caca" en Scrum.

Scrum Master ⚠️ EXAMEN

No es jefe de proyecto. Es un facilitador.
Asegura que los valores, principios y prácticas de Scrum se cumplan.
Vela por la comunicación del equipo, el respeto, el acceso a la información.
Ayuda al Product Owner si este no sabe gestionar la pila de producto.
Tiene más sentido en equipos inmaduros; en equipos experimentados, su rol puede ser absorbido por los propios miembros.
En la práctica, suele repartirse entre varios proyectos.

Diferenciación crítica de roles: ⚠️ EXAMEN - El Scrum Master ≠ Product Owner ≠ Equipo de desarrollo (roles distintos y separados). - El Product Owner NO asigna tareas. - El Product Owner NO detecta desviaciones técnicas (eso es responsabilidad del equipo). - No existe la figura de Project Manager en Scrum.

6. Eventos (Reuniones)

Planificación de Sprint

Se realiza al inicio de cada sprint.
Participan: Product Owner + Equipo de desarrollo.
El PO propone qué quiere hacer; el equipo indica qué es viable técnicamente.
Las historias de usuario (de la pila de producto) se descomponen en tareas de ingeniería.
Resultado: la pila de sprint (compromiso del equipo). ⚠️ EXAMEN

Ejemplo: El PO llega con "la carta a los Reyes Magos" pidiendo muchas funcionalidades. El equipo responde: "Esto no se puede porque no tenemos el back preparado" o "Son demasiadas horas para cinco personas". Negocian y acuerdan el alcance.

Daily Scrum (Reunión diaria)

Cada día, al inicio de la jornada.
El equipo evalúa el avance del sprint.
Se apoya en herramientas como el Burn Down Chart.

Revisión de Sprint (Sprint Review)

Al final del sprint.
Se demuestra el incremento al Product Owner (y opcionalmente a stakeholders, usuarios finales).
El PO decide si la entrega pasa a producción.
Proporciona retroalimentación directa del cliente.

Retrospectiva del Sprint ⚠️ EXAMEN

Después de la revisión.
Carácter técnico e interno (equipo de desarrollo + Scrum Master).
Se analiza: qué se hizo bien, qué se hizo mal, por qué hubo retrasos, cómo mejorar.
Es donde se tratan problemas interpersonales o de rendimiento del equipo.

7. Artefactos

Pila de Producto (Product Backlog): Lista priorizada de todas las características/historias de usuario del sistema. La gestiona el Product Owner. Es pública y visible.
Pila de Sprint (Sprint Backlog): Subconjunto de la pila de producto seleccionado para el sprint, descompuesto en tareas técnicas concretas (base de datos, API, formularios...).
Incremento: El resultado funcional y potencialmente desplegable al final de cada sprint.

8. Reglas importantes sobre los Sprints

Duración fija y constante: Si los sprints son de 2 semanas, todos deben ser de 2 semanas. Esto mejora las estimaciones con el tiempo. ⚠️ EXAMEN
No planificar todos los sprints a priori: Asignar funcionalidades sprint por sprint al comenzar cada uno. Planificar 16 sprints de antemano es un error que va contra la agilidad. ⚠️ EXAMEN
Iteraciones cortas son preferibles porque: (1) se obtiene retroalimentación más frecuente del cliente, y (2) las estimaciones son más precisas a corto plazo.
La pila de sprint queda "congelada" durante el sprint, pero si surge una urgencia (ej. vulnerabilidad día cero), se puede repriorizar hablando con el Product Owner.

Ejemplo: Es más fácil estimar si en una hora me da tiempo a ducharme y vestirme, que estimar todas las tareas de una semana entera. Cuanto más corto el horizonte temporal, más precisas las estimaciones.

9. Equipo de Scrum vs. Equipo de Desarrollo

Equipo de Scrum = Product Owner + Scrum Master + Equipo de Desarrollo. ⚠️ EXAMEN

Equipo de Desarrollo = solo los desarrolladores. Es un subconjunto del equipo de Scrum.

Preguntas de Autoevaluación

¿Cuáles son los tres pilares de Scrum y cómo se relacionan entre sí?
¿Por qué es un error planificar el contenido de todos los sprints al inicio del proyecto?
Explica por qué el Product Owner no es un jefe de proyecto. ¿Cuáles son sus responsabilidades reales?
¿Qué diferencia hay entre la reunión de revisión y la de retrospectiva? ¿Quién participa en cada una?
¿Por qué Scrum exige que los equipos de desarrollo sean cross-functional? Pon un ejemplo.
¿Cuál es la diferencia entre la pila de producto y la pila de sprint? ¿Quién gestiona cada una?
¿Por qué es importante que la duración de los sprints sea constante?
¿En qué situaciones tiene sentido la figura del Scrum Master y cuándo pierde relevancia?
Relaciona los cuatro valores del Manifiesto Ágil con prácticas concretas de Scrum.
¿Qué ocurre si durante un sprint surge una incidencia crítica que no estaba planificada?

Guía generada automáticamente a partir de transcripción con faster-whisper + Claude Opus 4.6.