Módulo 01: Metodologías ágiles y Scrum

Objetivos del módulo

  • Comprender qué es Agile y sus principios
  • Dominar el framework Scrum: roles, artefactos, ceremonias
  • Conocer Kanban como alternativa
  • Entender el rol del QA en entornos ágiles

1. ¿Qué es Agile?

Agile no es una metodología, es un conjunto de valores y principios para el desarrollo de software. Nació como reacción a los procesos pesados y burocráticos (cascada).

El Manifiesto Ágil (2001)

Valoramos:

  • Individuos e interacciones sobre procesos y herramientas
  • Software funcionando sobre documentación extensiva
  • Colaboración con el cliente sobre negociación de contratos
  • Respuesta ante el cambio sobre seguir un plan

⚠️ Importante: El manifiesto NO dice que los elementos de la derecha no importan, dice que los de la izquierda se valoran MÁS.

12 Principios de Agile (resumen)

# Principio
1 Satisfacer al cliente mediante entrega temprana y continua
2 Aceptar cambios en los requisitos, incluso tarde
3 Entregar software funcional frecuentemente (semanas, no meses)
4 Negocio y desarrolladores trabajan juntos diariamente
5 Construir proyectos con personas motivadas
6 Comunicación cara a cara como método más eficaz
7 Software funcionando = medida principal de progreso
8 Desarrollo sostenible a ritmo constante
9 Excelencia técnica y buen diseño mejoran la agilidad
10 Simplicidad: maximizar el trabajo no realizado
11 Equipos auto-organizados
12 Reflexión regular para mejorar

2. Cascada vs Agile 

graph TD
    subgraph Cascada
        WA[Requisitos] --> WB[Diseño]
        WB --> WC[Desarrollo]
        WC --> WD[Testing]
        WD --> WE[Despliegue]
    end
    subgraph Agile
        SA[Sprint 1<br/>Requisitos → Código → Test] --> SB[Sprint 2<br/>Requisitos → Código → Test]
        SB --> SC[Sprint 3<br/>Requisitos → Código → Test]
        SC --> SD[Sprint N<br/>...]
    end
Aspecto Cascada Agile
Planificación Todo al inicio Iterativa
Entrega Al final del proyecto Cada sprint (2-4 semanas)
Cambios Costosos y difíciles Bienvenidos
Testing Al final Continuo
Riesgo Se descubre tarde Se mitiga pronto
Feedback Tardío Constante

3. Scrum

Scrum es el framework ágil más utilizado. Define roles, artefactos y ceremonias.

3.1 Roles de Scrum

Product Owner (PO)

Responsabilidad Descripción
Visión del producto Define qué se construye
Product Backlog Crea y prioriza las historias de usuario
Decisiones de negocio Acepta o rechaza el trabajo completado
Representar al usuario Es la voz del cliente dentro del equipo

Scrum Master (SM)

Responsabilidad Descripción
Facilitar Scrum Asegura que el equipo sigue el framework
Eliminar impedimentos Resuelve bloqueos del equipo
Proteger al equipo Evita interrupciones externas
Coaching Enseña y mejora los procesos

📘 Concepto: El Scrum Master no es un jefe. Es un líder servidor que ayuda al equipo a ser más efectivo.

Equipo de desarrollo (Development Team)

Característica Descripción
Auto-organizado Deciden cómo hacer el trabajo
Multifuncional Tienen todas las habilidades necesarias
Tamaño ideal 3-9 personas
Responsabilidad Colectiva sobre el incremento

3.2 Artefactos de Scrum

Product Backlog

Lista priorizada de todo lo que podría necesitar el producto.

# Product Backlog (ejemplo)
| # | Historia de usuario | Prioridad | Puntos |
|---|---------------------|-----------|--------|
| 1 | Como usuario quiero registrarme para acceder | Alta | 5 |
| 2 | Como usuario quiero hacer login con email | Alta | 3 |
| 3 | Como admin quiero ver estadísticas | Media | 8 |
| 4 | Como usuario quiero recuperar contraseña | Baja | 5 |

Sprint Backlog

Subconjunto del Product Backlog seleccionado para el sprint actual, más el plan para entregarlo.

Incremento

El resultado del sprint: software funcional y potencialmente entregable.

3.3 Ceremonias de Scrum 

graph LR
    A[Sprint Planning] --> B[Daily Standup<br/>cada día]
    B --> C[Sprint Review]
    C --> D[Sprint Retrospective]
    D --> E[Siguiente Sprint]
    style A fill:#2196F3,color:white
    style C fill:#4CAF50,color:white
    style D fill:#FF9800,color:white

Sprint Planning (inicio del sprint)

Aspecto Detalle
Duración Máximo 8 horas para sprint de 1 mes (2h para 2 semanas)
Participantes Todo el equipo Scrum
Objetivo Definir qué se hará y cómo
Resultado Sprint Backlog con tareas estimadas

Daily Standup (diaria)

Aspecto Detalle
Duración Máximo 15 minutos
Participantes Equipo de desarrollo
Cada persona responde ¿Qué hice ayer? ¿Qué haré hoy? ¿Tengo impedimentos?
De pie Sí, para que sea breve

Sprint Review (fin del sprint)

Aspecto Detalle
Duración Máximo 4 horas (sprint de 1 mes)
Participantes Equipo + stakeholders
Objetivo Demostrar el incremento, obtener feedback
Resultado Product Backlog actualizado

Sprint Retrospective (después de la Review)

Aspecto Detalle
Duración Máximo 3 horas
Participantes Equipo Scrum (sin stakeholders)
Preguntas clave ¿Qué fue bien? ¿Qué mejorar? ¿Qué acciones tomar?
Resultado Acciones de mejora para el siguiente sprint

3.4 El Sprint

Característica Detalle
Duración 1-4 semanas (lo más común: 2 semanas)
Time-boxed No se extiende
Resultado Incremento funcional
Cancelación Solo el PO puede cancelar un sprint

4. Historias de usuario

Una historia de usuario describe una funcionalidad desde la perspectiva del usuario.

Formato estándar 

Como [tipo de usuario]
Quiero [acción/funcionalidad]
Para [beneficio/objetivo]

Ejemplos 

Como cliente registrado
Quiero filtrar productos por precio
Para encontrar artículos dentro de mi presupuesto

Como administrador
Quiero exportar el listado de usuarios en CSV
Para hacer análisis en Excel

Criterios de aceptación

Cada historia debe tener criterios de aceptación que definen cuándo está “hecha”:

Historia: Como usuario quiero hacer login
Criterios de aceptación:
  ✅ Login exitoso con email y contraseña correctos
  ✅ Mensaje de error con credenciales incorrectas
  ✅ Bloqueo después de 5 intentos fallidos
  ✅ Opción de "recordar sesión"
  ✅ Redirección al dashboard tras login exitoso

INVEST (criterios de calidad)

Letra Criterio Significado
I Independiente No depende de otras historias
N Negociable Puede discutirse
V Valiosa Aporta valor al usuario
E Estimable Se puede estimar el esfuerzo
S Small Suficientemente pequeña para un sprint
T Testable Se puede verificar que funciona

5. Estimación

Story Points

Los equipos Scrum estiman esfuerzo en Story Points (puntos de historia), no en horas.

Puntos Esfuerzo (relativo) Ejemplo
1 Trivial Cambiar un texto en la UI
2 Muy pequeño Añadir validación simple
3 Pequeño CRUD básico
5 Medio Integración con API externa
8 Grande Feature completo con validaciones
13 Muy grande Refactorización de módulo completo
21+ Demasiado grande Dividir en historias más pequeñas

💡 Consejo: Los puntos siguen la secuencia de Fibonacci (1, 2, 3, 5, 8, 13, 21) porque la incertidumbre crece con el tamaño.

Planning Poker

  1. El PO presenta la historia
  2. Cada miembro del equipo elige una carta (puntos)
  3. Todos revelan a la vez
  4. Los extremos (más alto y más bajo) explican
  5. Se discute y se repite hasta converger

6. Kanban

Kanban es otro enfoque ágil más flexible que Scrum.

Aspecto Scrum Kanban
Iteraciones Sprints de duración fija Flujo continuo
Roles PO, SM, Dev Team Sin roles definidos
Tablero Se reinicia cada sprint Continuo
WIP Limits Implícito (sprint backlog) Explícito por columna
Métricas Velocidad, burndown Lead time, cycle time

Tablero Kanban 

| Por hacer | En progreso (máx 3) | En revisión (máx 2) | Hecho |
|-----------|---------------------|---------------------|-------|
| Tarea A   | Tarea D             | Tarea F             | Tarea G |
| Tarea B   | Tarea E             |                     | Tarea H |
| Tarea C   |                     |                     |       |

📘 Concepto: El WIP Limit (Work In Progress) limita cuántas tareas pueden estar en una columna. Esto evita sobrecarga y mejora el flujo.

7. El QA en entornos ágiles

Cambio de mentalidad

Testing tradicional Testing ágil
QA es un fase al final QA está integrado en el equipo
Testers son “guardianes” Todos son responsables de la calidad
Documentación extensa Pruebas automatizadas como documentación
Bugs se reportan al final Bugs se previenen durante el sprint

Responsabilidades del QA en Scrum

Ceremonia Rol del QA
Sprint Planning Ayudar a definir criterios de aceptación
Daily Informar progreso de pruebas, impedimentos
Desarrollo Escribir tests mientras se desarrolla
Sprint Review Validar que los criterios se cumplen
Retro Proponer mejoras en procesos de calidad

Definition of Done (DoD)

El equipo define cuándo una historia está realmente terminada:

✅ Código revisado (code review)
✅ Pruebas unitarias escritas y pasando
✅ Pruebas de integración pasando
✅ Pruebas de aceptación verificadas
✅ Sin bugs críticos abiertos
✅ Documentación actualizada
✅ Desplegado en entorno de staging

8. Ejercicios prácticos

Ejercicio 1: Escribir historias de usuario

Para un sistema de reservas de restaurante, escribe 5 historias de usuario con sus criterios de aceptación. Usa el formato “Como… Quiero… Para…”.

Ejercicio 2: Estimar con Planning Poker

Con las historias del ejercicio 1, asigna story points (Fibonacci: 1, 2, 3, 5, 8, 13) y justifica tu estimación.

Ejercicio 3: Crear un tablero Kanban

Diseña un tablero Kanban con las columnas: Backlog, To Do, In Progress (WIP: 2), Testing (WIP: 1), Done. Distribuye las historias del ejercicio 1.

Ejercicio 4: Definition of Done

Define una DoD para tu equipo que incluya al menos 6 criterios, con al menos 2 relacionados con testing.

Resumen

Concepto Descripción
Agile Valores y principios para desarrollo iterativo
Scrum Framework ágil con roles, artefactos y ceremonias
Roles Product Owner, Scrum Master, Dev Team
Artefactos Product Backlog, Sprint Backlog, Incremento
Ceremonias Planning, Daily, Review, Retrospective
Kanban Flujo continuo con WIP limits
QA Ágil Integrado en el equipo, prevención > detección
Historias “Como… quiero… para…” + criterios de aceptación
Navegación  
← Módulo anterior: Introducción al Testing Siguiente módulo: Gestión con Jira →