¿Qué es Scrum?
Scrum es una metodología ágil para la gestión y desarrollo de proyectos, especialmente de software, se centra en la adaptación continua, la colaboración del equipo y la entrega incremental de valor. Busca responder a entornos cambiantes y requisitos poco definidos, priorizando la satisfacción del cliente.
Componentes de Scrum
Reuniones (Eventos)
Scrum se estructura en reuniones clave para planificar, ejecutar y revisar:
• Planificación del Sprint (Sprint Planning Meeting): Dura hasta 8 horas (dividida en dos partes). Se selecciona del Product Backlog qué se hará en el Sprint, se define el Sprint Backlog y se estima esfuerzo.
• Reunión Diaria (Daily Scrum): 15 minutos diarios. Cada miembro responde: ¿Qué hice ayer? ¿Qué haré hoy? ¿Qué impedimentos hay?
• Revisión del Sprint (Sprint Review): Hasta 4 horas al final del Sprint. Se presenta el incremento funcional y se recibe feedback de stakeholders.
• Retrospectiva del Sprint (Sprint Retrospective): Hasta 3 horas. El equipo analiza qué salió bien, qué mejorar y define acciones para el próximo Sprint.
Roles
Se dividen en "Cerdos" (comprometidos directamente) y "Gallinas" (involucrados indirectamente):
- Cerdos:
• Product Owner: Representa al cliente, prioriza el Backlog, define requisitos y maximiza el valor del producto.
• Scrum Master: Facilita el proceso, elimina impedimentos y asegura que se siga Scrum.
• Equipo de Desarrollo: 5-9 personas multidisciplinares que construyen el producto en Sprints.
- Gallinas:
• Usuarios: Usuarios finales.
• Stakeholders: Beneficiarios del proyecto.
• Managers: Toman decisiones estratégicas.
Elementos (Artefactos) de Scrum
• Product Backlog: Lista priorizada de requisitos (historias de usuario) que evoluciona con el proyecto. Incluye ID, descripción, estimación (en puntos o días), prioridad (e.g., MoSCoW: Must, Should, Could, Would) y dependencias. Historias de usuario siguen formato "Como [rol], quiero [función] para [beneficio]".
• Sprint Backlog: Subconjunto del Product Backlog para un Sprint, descompuesto en tareas (4-16 horas cada una). Se gestiona con herramientas como Scrum Taskboard (columnas: Pendiente, En curso, Hecho).
• Incremento: Parte funcional y operativa del producto entregada al final de cada Sprint, lista para usar.
Desarrollo de las fases en Scrum
1. Preparación del Proyecto (Sprint 0)
Fase inicial para entender el negocio y agregar valor. Incluye definir el proyecto, "terminado" (Definition of Done), Backlog inicial, entregables y constituir el equipo. Estimaciones son aproximadas (en días), priorizando ROI.
2. Planificar un Sprint
Reunión para seleccionar ítems del Product Backlog. Estimación con Planning Poker (cartas con valores como 1, 2, 3, 5, 8... para evitar sesgos). Se mantiene el Sprint Backlog actualizado y se usa Burndown Chart para rastrear progreso (gráfico de trabajo restante vs. tiempo).
3. El Desarrollo del Sprint
Ejecución en Sprints de 2-4 semanas. Se realizan las reuniones diarias, se autogestiona el equipo y se produce un incremento. No se permiten cambios externos durante el Sprint.
4. Diagrama Detallado de Fases
El proceso es iterativo: Revisión de planes → Sprint (desarrollo, empaquetar, revisión, ajustes) → Sprint Review → Cierre (si aplica). Se repite hasta completar el Backlog.
Programación Extrema (XP)
La programación extrema (XP), introducida por Kent Beck en los años 90 y detallada en su libro Extreme Programming Explained: Embrace Change (1999), es una metodología ágil de desarrollo de software que prioriza la adaptabilidad a cambios de requisitos sobre la predictibilidad rígida. Enfatiza prácticas técnicas extremas para producir código de alta calidad de forma rápida, centrándose en simplicidad, comunicación y retroalimentación constante.
Fases del ciclo de vida
XP se estructura en fases iterativas continuas:
- Exploración: Definición inicial del alcance mediante "historias de usuario" escritas por el cliente; estimaciones preliminares de tiempos.
- Planificación: Acuerdo entre cliente, desarrolladores y gerentes sobre prioridades y cronograma de entregas ("Release Plan").
- Iteraciones: Desarrollo principal en ciclos cortos (1-3 semanas); análisis detallado, codificación, pruebas y entregables funcionales.
- Puesta en Producción: Ajustes finales sin nuevos desarrollos; opcional hasta funcionalidad completa.
- Escuchar/Retroalimentación: Comunicación constante para ajustes (en algunas descripciones, integrada como fase transversal).
Etapas Clave
- Planificación: Diálogo continuo con historias de usuario (sustituyen casos de uso); estimaciones, spikes para riesgos; planes simples y flexibles.
- Diseño: Simplicidad extrema (YAGNI, DRY); metáforas, soluciones spike, refactorización continua.
- Implementación: Cliente in situ; estándares de codificación; programación en parejas; desarrollo guiado por pruebas (TDD).
- Pruebas: Unitarias automatizadas (escritas antes del código); aceptación por cliente; integración continua.
Valores (5 Principales)
• Comunicación: Diálogo cara a cara; mínima documentación.
• Simplicidad: Código mínimo funcional, legible y testable.
• Retroalimentación: Entregas frecuentes y ajustes inmediatos.
• Respeto: Colaboración y responsabilidad colectiva.
• Coraje/Valentía: Aceptar cambios y asumir resultados.
Principios Derivados
• Retroalimentación rápida.
• Cambios incrementales.
• Aceptar el cambio.
• Trabajo de calidad.
Prácticas (12 Principales, Agrupadas en 4 Categorías)
• Calidad del Código: TDD, refactorización, integración continua, propiedad colectiva, estándares de codificación.
• Planificación: Juego de la planificación, lanzamientos pequeños, cliente in situ.
• Equipo: Programación en parejas, metáfora del sistema.
• Ritmo: Semana de 40 horas (máx. 45, sin overtime sostenido).
Roles
• Cliente: Define objetivos, escribe historias, prioriza y prueba.
• Programador: Estima, codifica, pruebas unitarias; propiedad colectiva.
• Tester: Ayuda en pruebas de aceptación; automatiza baterías.
• Tracker: Monitorea velocidad y progreso.
• Coach: Guía en adopción de XP (opcional).
• Gestor (Big Boss): Visión general; puede ser cliente.
Ventajas
• Reduce costos y tiempos; código estable y mantenible.
• Alta satisfacción del cliente por participación.
• Menos defectos vía pruebas continuas y pares.
• Flexibilidad en requisitos cambiantes.
• Equipos motivados y visibles.
Desventajas
• Requiere cliente disponible y comprometido (estrés si no).
• Estimaciones iniciales imprecisas; documentación escasa.
• Programación en parejas +15% tiempo; no ideal para equipos distribuidos o grandes (>12 personas).
• Cambio cultural drástico; depende de desarrolladores experimentados.
• Enfoque excesivo en código vs. diseño global.
Comparación con Otros Ágiles
vs. Scrum: Iteraciones más cortas y flexibles; XP más técnico (pruebas/código), Scrum organizacional (sprints 2-4 semanas, roles fijos).
vs. Kanban: Flujo continuo vs. iteraciones; ambos flexibles, pero Kanban visualiza WIP.
vs. Lean: Filosofía anti-desperdicio vs. prácticas específicas; ambos entregan MVP rápido.
Cuando Usar XP
Ideal para equipos pequeños (12), proyectos de alto riesgo/cambios frecuentes, con pruebas automatizables y cliente in situ. Requiere coach inicial y cultura ágil. No para entornos distribuidos, clientes ausentes o sistemas con requisitos fijos.
Conclusión
Las metodologías ágiles representan un paradigma transformador en la gestión y desarrollo de proyectos de software, priorizando la adaptabilidad a cambios, la colaboración intensa y la entrega incremental de valor sobre enfoques tradicionales rígidos y predictivos. Tanto Scrum como Programación Extrema (XP) encarnan los principios del Manifiesto Ágil (2001).
Fuente
Mendoza, M. L. (2020, November 6). Scrum y Extreme Programming, no se trata de cuál, se trata de cómo. OpenWebinars.net. https://openwebinars.net/blog/scrum-y-extreme-programming-no-se-trata-de-cual-se-trata-de-como/
