# Qué es ScrumXP (resumen corto) **ScrumXP** no es un nuevo framework mágico: es usar **Scrum** como marco de trabajo para organizar el equipo y la cadencia (sprints, eventos, roles, backlog) y complementar eso con **prácticas técnicas** de eXtreme Programming (XP) — tests automáticos, integración continua, pair programming, refactor, diseño simple, releases frecuentes — para que lo que Scrum planifica termine siendo software de calidad y sostenible. En otras palabras: Scrum da la estructura; XP da la disciplina técnica. ([Scrum.org][1]) # Por qué combinarlas (beneficios principales) * Acelera entrega de valor real y desactiva la deuda técnica (porque XP obliga a tests y refactor). * Reduce riesgo: releases pequeñas + integración continua hacen que los errores se detecten temprano. * Mejora predicibilidad: sprint tras sprint con feedback técnico constante. * Aumenta colaboración: pair programming + revisión continua elevan el conocimiento del equipo. * Mantiene enfoque en la calidad sin sacrificar velocidad. ([Scrum.org][1]) # Prácticas XP que debes conocer (lo esencial) (implementa la que puedas, pero prioriza **TDD** + **CI/CD** + **pair programming**) * **Test-Driven Development (TDD)** — escribir tests primero, código después. * **Pair Programming** — dos devs en la misma tarea (driver + navigator). * **Continuous Integration / Continuous Delivery (CI/CD)** — integra y despliega pequeñas porciones frecuentemente. * **Refactor** continuo — mejorar el diseño sin cambiar comportamiento. * **Simple Design** — el diseño más simple que funcione hoy. * **Collective Code Ownership** — cualquiera puede tocar cualquier parte del código. * **Small Releases / Frequent Integration** — acortar el tiempo entre idea y producción. * **Coding Standards** — reglas compartidas para legibilidad y consistencia. ([Scrum.org][1]) # Cómo encaja cada cosa con Scrum (práctico) * **Sprint Planning**: prioriza ítems que tengan en cuenta la capacidad de hacer TDD/automatización. * **Daily**: además del impedimento, usa el daily para sincronizar prácticas técnicas (p.ej. pairing necesario hoy). * **Sprint Review**: muestra valor realmente testeado y desplegable. * **Sprint Retrospective**: usa retro para ajustar prácticas XP (¿más pair? ¿mejor CI?). * **Definition of Done (DoD)**: incluye criterios XP — por ejemplo "unit tests + integración verde + revisión de código". Esto hace que “done” signifique **entregable y mantenible**. ([Scrum.org][1]) # Roadmap de adopción (pasos concretos) 1. **Alineá el equipo en la idea**: Scrum es el marco, XP las prácticas. Hacé una sesión corta para acordar objetivos de calidad. 2. **Definí DoD que incluya prácticas XP** (tests, CI, build verde). 3. **Instalá CI básico** (pipeline que corre tests en cada push). 4. **Empieza con TDD en una feature pequeña** (prueba y aprende). 5. **Promové pair programming en tareas críticas** (no hace falta 100% del tiempo). 6. **Automatizá releases** — un pipeline que pueda desplegar al menos a staging con un click. 7. **Mide, retroalimenta y ajusta**: velocidad, tasa de fallos en producción, tiempo de recuperación. Hazlo iterativo: no intentes imponer TDD + pairing + cambios de arquitectura en una semana; ve sumando prácticas cada sprint. ([Scrum.org][1]) # Métricas útiles (no te vuelvas esclavo) * **Lead time / Cycle time** (idea → producción). * **% de builds verdes** y **fallos en CI**. * **Cobertura de tests** (útil como indicador, no como dios absoluto). * **Defects en producción** y **MTTR** (tiempo medio de reparación). * **Velocidad del equipo** (pero priorizá calidad, no solo bajar números). # Riesgos y trampas comunes (y cómo evitarlos) * *Trampa:* “hacemos TDD pero escribimos tests inútiles”. → Priorizar tests que aporten valor (integración + unit). * *Trampa:* usar pair programming todo el tiempo sin rotación → fatiga; rotá pares. * *Trampa:* DoD vacío = falso progreso. → Hacela real: build verde + tests + deployable. * *Trampa:* querer automatizar todo de golpe → empezar por lo mínimo viable (pipeline + tests PR). * *Trampa:* management espera entregas rápidas sin invertir en prácticas técnicas → educar stakeholders y mostrar ROI (menos bugs, despliegues más confiables). ([Scrum.org][1]) # Ejemplo de sprint (flujo integrado Scrum + XP) 1. **Sprint Planning** — definir 3 historias pequeñas, cada una con criterios de aceptación y DoD que incluye tests y despliegue a staging. 2. **Desarrollo** — TDD para la lógica crítica; pair programming en la primera implementación; commits pequeños. 3. **CI** — cada PR dispara pipeline: lint → tests → build. 4. **Review & Merge** — code review + aprobación. 5. **Deploy** — despliegue automático a staging; demo en Review. 6. **Retro** — ajustar prácticas (p.ej. hacer más pair o mejorar flujos de test). # Herramientas recomendadas (rápido) * **CI/CD**: GitHub Actions, GitLab CI, Jenkins, CircleCI. * **TEST**: frameworks de unit/integration según stack (JUnit, NUnit, pytest, jest...). * **Code review**: PRs en GitHub/GitLab + linters. * **Observability**: Sentry, Prometheus, Grafana para errores y métricas. # 10) Checklist rápido para el equipo (usa esto cada sprint) * [ ] ¿La DoD incluye tests y build verde? * [ ] ¿Cada PR tiene pipeline que pasa? * [ ] ¿Se aplicó TDD en al menos una story crítica? * [ ] ¿Se usó pair programming en una tarea para transferir conocimiento? * [ ] ¿Se deployó a staging y se hizo demo en review? * [ ] ¿La retro definió al menos 1 acción para mejorar prácticas técnicas? # 11) Mi opinión honesta (fuerte, como pediste) Si tu equipo tiene problemas de calidad o deuda técnica, **Scrum sin XP es humo bonito**: entregás rápido pero con trompazos. XP te obliga a hacer el trabajo técnico que evita la bancarrota del código. La mejor estrategia es pura: **Scrum para organizar → XP para construir**. Si no vas a invertir tiempo en automatizar tests y CI, no esperes acelerar sin romper cosas. Punto. ([Scrum.org][1]) --- Si querés, te lo convierto en: * Un **one-pager** imprimible (resumen ejecutivo + checklist). * Un **plan de 3 sprints** con tareas concretas para implantar TDD + CI. * O un **script** con comandos para pipeline CI básico en GitHub Actions (si me decís el stack: Node/.NET/Java/Python). Te dejo la fuente principal que revisé (explica cómo Scrum y XP se complementan y por qué aplicar prácticas XP dentro de Scrum tiene sentido). ([Scrum.org][1]) Listo. ¿Querés que arme el plan de 3 sprints para tu equipo y lo deje ready-to-run? Te lo hago en modo guerrilla: práctico y sin paja. [1]: https://www.scrum.org/resources/blog/scrum-and-extreme-programming-xp "Scrum And eXtreme Programming (XP) | Scrum.org"