Libros Sistemas

Ágil y Scrum en la práctica

"Ágil no es un proceso — es una mentalidad. El proceso viene después."

Qué vas a aprender en este capítulo

Las metodologías ágiles revolucionaron cómo se construye software. Este capítulo va más allá de la introducción de ADS415 — acá profundizás en Scrum como ingeniería de software: cómo funciona realmente en un equipo, cómo estimás bien, cómo medís la velocidad, y cómo Kanban complementa o reemplaza Scrum según el contexto.

2.1 El Manifiesto Ágil

💡 Intuición

En 2001, 17 desarrolladores frustrados con los procesos pesados de la industria se reunieron en Snowbird, Utah, y firmaron el Manifiesto Ágil. Cuatro valores, doce principios.

Los cuatro valores:

  1. Individuos e interacciones sobre procesos y herramientas.
  2. Software funcionando sobre documentación extensiva.
  3. Colaboración con el cliente sobre negociación contractual.
  4. Respuesta ante el cambio sobre seguir un plan.

Cada valor incluye "sobre X" — ágil no niega el lado derecho. Los procesos importan, la documentación importa, los contratos importan, los planes importan. Pero si hay conflicto, el lado izquierdo gana.

Lo que ágil NO es:

  • Sin documentación (la documentación útil sí existe).
  • Sin planificación (se planifica, pero a corto plazo).
  • Caótico (hay estructura, pero liviana).
  • Permiso para cambiar todo siempre (hay un backlog priorizado).

📐 Fundamento

Los 12 principios ágiles (resumidos):

  1. Entrega continua de software valioso — prioridad máxima.
  2. El cambio en requerimientos es bienvenido, incluso tarde en el desarrollo.
  3. Entrega frecuente de software funcionando (semanas, no meses).
  4. El cliente y el equipo de desarrollo trabajan juntos diariamente.
  5. Construir proyectos alrededor de individuos motivados. Darles el entorno y la confianza.
  6. El método más eficiente de transmitir información: conversación cara a cara.
  7. Software funcionando es la medida primaria de progreso.
  8. Los procesos ágiles promueven el desarrollo sostenible. Ritmo constante indefinido.
  9. La atención continua a la excelencia técnica y el buen diseño mejora la agilidad.
  10. Simplicidad — el arte de maximizar el trabajo no hecho.
  11. Las mejores arquitecturas emergen de equipos autoorganizados.
  12. El equipo reflexiona regularmente sobre cómo volverse más efectivo.

2.2 Scrum en detalle

💡 Intuición

Scrum es el framework ágil más usado. Tiene tres pilares:

  • Transparencia: Todo el equipo ve todo — el backlog, el progreso, los impedimentos.
  • Inspección: Se revisa frecuentemente el progreso y el proceso.
  • Adaptación: Se ajusta según lo que se inspecciona.

En la práctica, Scrum es la siguiente rutina repetida cada 1-4 semanas:

Sprint → planificar → construir → revisar → mejorar el proceso → repetir.

📐 Fundamento

Artefactos de Scrum:

Artefacto Descripción
Product Backlog Lista ordenada de todo lo que el producto debe hacer. Priorizado por el PO. Nunca está "terminado".
Sprint Backlog Subconjunto del Product Backlog que el equipo se comprometió a completar en el sprint actual. Más los ítems del plan para alcanzar el Sprint Goal.
Incremento La suma de todos los ítems del backlog completados durante el sprint, más todos los sprints anteriores. Siempre debe ser "potencialmente entregable".

Ceremonias de Scrum:

Ceremonia Duración (sprint 2 sem.) Objetivo
Sprint Planning Máx. 4h Qué se hará este sprint y cómo
Daily Scrum 15 min Sincronizar el equipo
Sprint Review Máx. 2h Mostrar el incremento al PO y stakeholders
Sprint Retrospective Máx. 1.5h Mejorar el proceso del equipo
Backlog Refinement 10% del tiempo del sprint Aclarar y estimar ítems del backlog

Definition of Done (DoD):

Criterios que deben cumplirse para que un ítem se considere "Done". Ejemplo para La Esquina:

  • El código está escrito y revisado por un peer.
  • Hay pruebas unitarias con ≥80% de cobertura.
  • El código pasa todos los tests en CI.
  • La funcionalidad fue probada manualmente en staging.
  • El PO la aprobó en la Sprint Review.

🛠️ En la práctica

Sprint Planning de La Esquina (Sprint 3):

Sprint Goal: El mozo puede tomar un pedido completo desde su teléfono y enviarlo a la cocina.

El PO presenta las historias priorizadas:

  • HU-003: Registrar pedido (8 pts) — estimada en sprint 2, pendiente de aceptación
  • HU-004: Ver menú del día (3 pts)
  • HU-005: Enviar pedido a cocina (5 pts)
  • HU-006: Confirmar pedido recibido en cocina (3 pts)

El equipo tiene una velocidad de 18 pts por sprint. Suman: 8+3+5+3 = 19. Demasiado. Negocian dejar HU-006 para el siguiente sprint. Toman 16 pts.

Daily Scrum típico:

Desarrollador A: "Ayer terminé el endpoint de crear pedido. 
                  Hoy voy a conectarlo con el frontend. 
                  No tengo bloqueos."

Desarrollador B: "Ayer no pude avanzar — la API de autenticación 
                  tiene un bug extraño. 
                  Hoy voy a investigar más. 
                  Bloqueo: necesito acceso al servidor de staging."

Scrum Master: "Me encargo de conseguirte el acceso. Hablamos después."

El Daily no es un reporte — es una sincronización. Los problemas se resuelven después del daily, no durante.

2.3 Estimación con Story Points

💡 Intuición

Story points son una unidad relativa de esfuerzo — no horas. Una historia de 2 puntos no es "2 horas" — es "la mitad de esfuerzo que una de 4 puntos".

¿Por qué no horas? Porque los humanos somos malos estimando tiempo absoluto (siempre subestimamos), pero somos buenos estimando relación (A es el doble de difícil que B).

Los story points combinan:

  • Complejidad (¿qué tan difícil es?)
  • Incertidumbre (¿qué tanto no sabemos?)
  • Volumen (¿cuánto trabajo hay?)

Fibonacci para story points: Los equipos usan Fibonacci (1, 2, 3, 5, 8, 13, 21) porque la escala creciente refleja la incertidumbre creciente. No tiene sentido distinguir entre 7 y 8 puntos — pero sí entre 8 y 13.

📐 Fundamento

Planning Poker:

Técnica de estimación grupal que evita el "anchoring" (que el primero en hablar influencie a todos):

  1. El PO presenta una historia.
  2. Cada miembro del equipo elige una carta (Fibonacci) en secreto.
  3. Todos revelan simultáneamente.
  4. Si hay divergencia, los extremos explican su razonamiento.
  5. Se vuelve a estimar hasta consenso (o 2-3 rondas y se promedia).

Velocidad del equipo:

La velocidad es el promedio de story points completados por sprint, calculado sobre los últimos 3-5 sprints.

Velocidad=∑pts completados en uˊltimos N sprintsN\text{Velocidad} = \frac{\sum \text{pts completados en últimos N sprints}}{N}

Proyección de lanzamiento:

Si el backlog tiene 200 puntos y la velocidad es 25 pts/sprint:

Sprints restantes=⌈200/25⌉=8 sprints=16 semanas\text{Sprints restantes} = \lceil 200 / 25 \rceil = 8 \text{ sprints} = 16 \text{ semanas}

Importante: La velocidad es del equipo, no de individuos. Comparar velocidades entre equipos es una mala práctica — diferentes equipos calibran los puntos diferente.

🛠️ En la práctica

Calibración inicial para La Esquina:

El equipo empieza eligiendo una "historia base" de referencia: "HU-001: Iniciar sesión" se estima como 2 puntos (algo simple pero no trivial). Ahora todo se estima relativo a eso.

Historia Estimación Razonamiento
HU-001: Iniciar sesión 2 pts Historia base
HU-003: Registrar pedido 8 pts Complejo: múltiples platillos, envío en tiempo real
HU-006: Reporte de ventas 5 pts BD + lógica de agrupación, interfaz simple
HU-009: Exportar PDF 3 pts Librería existente, pero hay que integrarla
HU-012: Pasarela de pago 13 pts Mucha incertidumbre — nunca lo hicieron

Velocidad de La Esquina después de 3 sprints: 14, 18, 16 pts. Velocidad = 16 pts/sprint.

Con backlog de 95 pts restantes: 95/16≈695/16 \approx 6 sprints más = 3 meses.

2.4 Kanban

💡 Intuición

Kanban viene de la manufactura japonesa (Toyota). "Kan" = visual, "ban" = tarjeta. El principio: visualizás el trabajo en un tablero para detectar y eliminar cuellos de botella.

A diferencia de Scrum, Kanban no tiene sprints ni roles fijos. El trabajo fluye continuamente. Es más adecuado para:

  • Equipos de soporte / mantenimiento (donde el trabajo llega de forma impredecible)
  • Equipos de operaciones
  • Trabajo que no se puede dividir claramente en sprints

Muchos equipos usan un híbrido: Scrumban (sprints de Scrum + visualización de Kanban).

📐 Fundamento

El tablero Kanban:

| Backlog | En progreso | En revisión | Listo para deploy | Hecho |
|---------|-------------|-------------|-------------------|-------|
|  HU-05  |    HU-03    |    HU-01    |       HU-02       |  ...  |
|  HU-07  |             |             |                   |       |
|  HU-09  |             |             |                   |       |

WIP Limit (Work In Progress Limit):

Límite en el número de ítems que pueden estar en una columna a la vez. Ej: "En progreso: máx 2".

Propósito: forzar al equipo a terminar lo empezado antes de empezar algo nuevo. Detecta cuellos de botella (si "En revisión" siempre está llena, el problema está en el proceso de revisión).

Métricas Kanban:

  • Lead time: Tiempo desde que una tarea entra al backlog hasta que está en producción.
  • Cycle time: Tiempo desde que el equipo empieza a trabajar en una tarea hasta que termina.
  • Throughput: Número de ítems completados por unidad de tiempo.

Scrum vs Kanban — guía rápida:

Scrum Kanban
Iteraciones Sprints fijos Flujo continuo
Cambios Solo entre sprints Permitidos en cualquier momento
Roles definidos PO, SM, Dev Team No prescribe roles
Mejor para Features nuevas Mantenimiento, soporte
Métricas Velocidad, burndown Lead time, cycle time

2.5 Ejercicios

✏️ Ejercicio 2.1 — Planning Poker

Tu equipo de 4 personas estima la historia "HU-X: Implementar sistema de cupones de descuento". Los resultados del Planning Poker son: 3, 8, 8, 13.

a. ¿Hay divergencia significativa? ¿Qué hacés? b. El que puso 13 dice: "No sé cómo el sistema de IVA interactúa con los descuentos — puede que requiera cambios grandes." ¿Cómo afecta eso a la estimación? c. El que puso 3 dice: "Simplemente agrego un campo descuento a la tabla de pedidos." ¿Qué le dirías?

Solución

a. Hay divergencia: 3 vs 13 es un rango amplio. Según Planning Poker, los extremos (3 y 13) explican su razonamiento. Luego el equipo vuelve a estimar. No se promedia automáticamente — el objetivo es el entendimiento compartido.

b. La incertidumbre sobre la interacción con IVA sugiere que la historia necesita más refinamiento (clarificación con el PO) antes de estimarla. O se acepta una estimación más alta (8 o 13) que refleje esa incertidumbre. Una historia incierta nunca se subestima.

c. La estimación de 3 asume que la implementación es simple, pero no considera escenarios como: ¿Los cupones pueden apilarse? ¿Tienen fecha de expiración? ¿Se aplican antes o después del IVA? ¿Qué pasa si el cupón da más descuento que el total? Una historia de cupones en sistemas comerciales reales suele ser mucho más compleja de lo aparente.

✏️ Ejercicio 2.2 — Sprint Planning

Tu equipo tiene una velocidad de 22 story points por sprint. El Product Backlog priorizado es:

ID Historia Puntos Prioridad
HU-11 Filtro de menú por categoría 3 Alta
HU-12 Historial de pedidos del mozo 5 Alta
HU-13 Exportar reporte a CSV 3 Media
HU-14 Notificación push en app 8 Alta
HU-15 Modo oscuro en la interfaz 2 Baja
HU-16 Sistema de propinas 5 Alta
HU-17 QR code en mesa para pedir 13 Media

a. ¿Qué historias entrarían al sprint? (Maximizar valor con la capacidad disponible) b. ¿Cuál sería un Sprint Goal apropiado? c. HU-15 (modo oscuro) tiene baja prioridad pero requiere 0 dependencias. ¿La incluirías en el sprint? Justificá.

Solución

a. Las historias de alta prioridad primero: HU-11 (3) + HU-12 (5) + HU-14 (8) + HU-16 (5) = 21 pts. Cabe dentro de 22. Si agregamos HU-13 (3 pts, media prioridad): 24 > 22, no cabe completo. El sprint tomaría HU-11, HU-12, HU-14, HU-16 (21 pts). HU-17 (13 pts) claramente no cabe.

b. "Al terminar el sprint, el mozo puede filtrar el menú, ver su historial de pedidos, recibir notificaciones push de pedidos listos, y el cliente puede dar propina desde la aplicación."

c. No la incluiría. Aunque no tiene dependencias, tiene baja prioridad. Si el equipo termina antes de lo esperado (si sobran puntos), se puede agregar como bonus. Pero comprometerse a ella en el Sprint Planning usa capacidad que podría ser reserva para imprevistos. La velocidad es un promedio, no un mínimo garantizado.

2.6 Para profundizar

Definiciones nuevas: Manifiesto Ágil, sprint, backlog, story points, Planning Poker, velocidad, Definition of Done, Daily Scrum, Sprint Review, Sprint Retrospective, WIP Limit, lead time, cycle time, Kanban, Scrumban.

← Anterior Introducción a la ingeniería de software Siguiente → Calidad del software y tipos de pruebas
Reportar error en este capítulo · Patrocinar este libro