103 lines
6.7 KiB
Markdown
103 lines
6.7 KiB
Markdown
# 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"
|