Curso de XP (Extreme Programming) para tu equipo — Calidad y entrega

Entender XP como una disciplina de desarrollo ágil centrada en excelencia técnica y feedback constante.

Diferenciar XP de Scrum, Kanban, Lean, DevOps, SAFe y enfoques ágiles centrados solo en gestión.

Identificar el origen de XP como respuesta a proyectos con cambio frecuente, incertidumbre y alto coste de defectos.

Comprender la relación entre valores, principios y prácticas de XP.

Reconocer que XP no consiste en programar más rápido, sino en reducir desperdicio, riesgo y retrabajo.

Analizar por qué XP exige disciplina técnica, colaboración real y transparencia.

Identificar señales de necesidad de XP: bugs recurrentes, miedo a cambiar código, releases dolorosas y deuda creciente.

Revisar el papel de feedback rápido en decisiones de producto y diseño.

Entender XP como sistema de prácticas interdependientes, no como menú de técnicas aisladas.

Crear un vocabulario común para aplicar XP en equipos modernos.

Aplicar comunicación para reducir malentendidos entre negocio, desarrollo, QA, diseño y operaciones.

Usar simplicidad como criterio para construir lo necesario ahora sin hipotecar el futuro.

Buscar feedback rápido mediante pruebas, integración, cliente, métricas y revisión de código.

Practicar coraje para refactorizar, decir no, eliminar código, cambiar decisiones y hacer visible la deuda.

Incorporar respeto como base para pair programming, propiedad colectiva y mejora del equipo.

Traducir los valores en comportamientos observables dentro del sprint o iteración.

Detectar cuándo un equipo dice aplicar XP pero mantiene dinámicas opacas o defensivas.

Resolver tensiones entre rapidez comercial y calidad técnica desde valores compartidos.

Usar los valores para tomar decisiones cuando no existe una regla clara.

Crear acuerdos de equipo alineados con comunicación, simplicidad, feedback, coraje y respeto.

Trabajar con humanidad, aceptando límites reales de atención, energía, aprendizaje y colaboración.

Mantener economía de decisiones, priorizando valor, coste de cambio y riesgo.

Diseñar para beneficio mutuo entre cliente, equipo, negocio, operaciones y usuarios.

Buscar mejora continua mediante retrospectivas, métricas y experimentos de equipo.

Asumir diversidad de perspectivas como fuente de mejor diseño y menos sesgo.

Reflexionar sobre fallos sin culpabilizar, convirtiendo errores en aprendizaje técnico y operativo.

Favorecer flujo continuo frente a grandes lotes de trabajo acumulado.

Aceptar oportunidades de mejora técnica en lugar de posponerlas indefinidamente.

Reducir redundancia innecesaria en procesos, documentación, código y validaciones.

Tomar decisiones reversibles siempre que sea posible para aprender con menor coste.

Entender el sistema completo de prácticas: planning game, small releases, TDD, refactoring, pair programming y CI.

Relacionar diseño simple con TDD y refactorización continua.

Conectar integración continua con propiedad colectiva y estándares de código.

Usar releases pequeñas para obtener feedback de usuario antes de construir demasiado.

Aplicar ritmo sostenible para evitar deuda creada por presión constante.

Integrar cliente o representante de negocio en ciclos frecuentes de decisión.

Entender que una práctica aislada pierde fuerza si el resto del sistema no acompaña.

Identificar qué prácticas puede adoptar primero un equipo según madurez.

Detectar conflictos habituales al implantar XP parcialmente.

Diseñar una hoja de ruta de adopción progresiva sin perder coherencia.

Escribir historias pequeñas que representen valor observable, no tareas técnicas disfrazadas.

Separar épicas, historias, spikes, bugs, tareas de refactorización y deuda técnica.

Usar criterios de aceptación claros para guiar pruebas y conversación.

Dividir historias grandes por regla, flujo, usuario, dato, canal, operación o riesgo.

Evitar historias enormes que no caben en una iteración ni permiten feedback.

Aplicar INVEST con sentido práctico: independiente, negociable, valiosa, estimable, pequeña y testeable.

Incorporar ejemplos concretos para que negocio, desarrollo y QA entiendan lo mismo.

Convertir incertidumbre técnica en spike limitado y con aprendizaje esperado.

Preparar historias que faciliten TDD, integración y entrega incremental.

Mantener conversación continua sobre historias en lugar de tratarlas como contratos cerrados.

Entender el Planning Game como colaboración entre negocio y equipo técnico para decidir alcance y prioridad.

Separar decisiones de valor, coste, riesgo y secuencia de entrega.

Estimar de forma ligera sin convertir la planificación en negociación artificial.

Priorizar historias por valor, riesgo, aprendizaje, dependencia y urgencia real.

Diseñar iteraciones cortas con objetivos concretos y capacidad realista.

Evitar comprometer más trabajo del que el equipo puede terminar con calidad.

Revisar el plan cuando aparece nueva información técnica o de negocio.

Incorporar bugs, deuda técnica y refactorización dentro de la capacidad disponible.

Mantener trazabilidad entre historias, pruebas, cambios y feedback.

Crear una cadencia de planificación que reduzca incertidumbre sin burocracia.

Dividir producto en incrementos pequeños, usables y revisables.

Evitar lanzamientos enormes que acumulan riesgo técnico, funcional y operativo.

Definir releases internas, beta, piloto, canary, feature flags y despliegues controlados.

Medir aprendizaje de cada release mediante uso, feedback, errores y métricas.

Separar despliegue técnico de activación funcional cuando conviene.

Diseñar entregas que reduzcan incertidumbre antes de ampliar alcance.

Integrar small releases con CI/CD, trunk-based development y observabilidad.

Preparar comunicación de release para negocio, soporte, usuarios y operaciones.

Gestionar rollback, rollback funcional y desactivación segura.

Convertir cada release en oportunidad de aprendizaje, no solo en hito de entrega.

Entender TDD como ciclo rojo, verde y refactorización.

Escribir primero una prueba que exprese comportamiento deseado.

Implementar el mínimo código necesario para pasar la prueba.

Refactorizar manteniendo todas las pruebas en verde.

Usar TDD para diseñar APIs, objetos, funciones, servicios y reglas de negocio.

Evitar pruebas acopladas a detalles internos sin comportamiento observable.

Elegir nombres de test que expliquen intención y caso de negocio.

Trabajar ejemplos simples antes de aplicar TDD a módulos complejos.

Identificar cuándo una prueba difícil de escribir revela mal diseño.

Crear hábito de TDD sin convertirlo en ritual mecánico o dogmático.

Aplicar TDD en código con dependencias externas, bases de datos, APIs, colas o sistemas legacy.

Diseñar seams, interfaces, ports y dobles de prueba para aislar comportamiento.

Diferenciar mocks, stubs, fakes, spies y test doubles según necesidad.

Evitar sobreuso de mocks que impiden refactorizar y ocultan errores reales.

Crear tests de caracterización antes de modificar código heredado.

Usar outside-in TDD cuando el comportamiento nace desde un caso de uso o interfaz pública.

Aplicar inside-out TDD cuando se construyen componentes de dominio o algoritmos.

Integrar TDD con arquitectura hexagonal, DDD, clean architecture o módulos frontend.

Mantener tests rápidos, deterministas y comprensibles.

Definir una estrategia equilibrada entre tests unitarios, integración, contrato y end-to-end.

Traducir criterios de aceptación en ejemplos concretos y verificables.

Usar BDD, Specification by Example o tests de aceptación cuando aportan claridad.

Escribir escenarios con lenguaje comprensible para negocio y equipo técnico.

Evitar escenarios demasiado detallados que duplican implementación.

Crear ejemplos para casos normales, límites, errores, permisos y excepciones.

Conectar pruebas de aceptación con historias pequeñas e incrementos entregables.

Automatizar pruebas críticas sin intentar automatizar todo a cualquier coste.

Mantener pruebas de aceptación estables frente a cambios internos de diseño.

Usar ejemplos ejecutables como documentación viva del comportamiento del sistema.

Revisar fallos de aceptación como oportunidad de aprendizaje sobre requisitos.

Entender refactorizar como mejorar estructura sin cambiar comportamiento observable.

Usar pruebas automatizadas como red de seguridad para cambios internos.

Identificar code smells: duplicación, métodos largos, clases grandes, acoplamiento y nombres confusos.

Aplicar refactorizaciones pequeñas, frecuentes y reversibles.

Evitar posponer toda mejora técnica a un “sprint de deuda” que nunca llega.

Separar refactorización de cambios funcionales cuando el riesgo lo aconseja.

Mejorar nombres, responsabilidades, cohesión, encapsulación y simplicidad.

Medir impacto de refactorización en facilidad de cambio, testabilidad y defectos.

Refactorizar legacy mediante pasos seguros y pruebas de caracterización.

Crear cultura donde dejar el código mejor de lo que se encontró sea norma.

Aplicar el diseño más simple que permita resolver el problema actual con calidad.

Evitar sobrearquitectura basada en necesidades futuras no validadas.

Mantener flexibilidad mediante buenas pruebas, bajo acoplamiento y refactorización.

Diseñar APIs, clases, módulos y servicios con intención clara.

Usar principios SOLID, GRASP y cohesión sin convertirlos en dogma.

Diferenciar simplicidad de simplismo o falta de diseño.

Evitar abstracciones prematuras que complican lectura y mantenimiento.

Hacer emerger diseño a partir de pruebas, feedback y necesidades reales.

Documentar decisiones arquitectónicas relevantes con ADRs ligeros.

Combinar XP con arquitectura evolutiva en productos de larga vida.

Entender pair programming como colaboración activa entre dos personas sobre el mismo problema.

Practicar roles driver/navigator y rotación frecuente.

Usar pairing para problemas complejos, onboarding, refactorización, diseño, bugs y zonas críticas.

Evitar que una persona dicte y otra solo teclee.

Crear acuerdos de comunicación, respeto, ritmo y toma de decisiones.

Alternar parejas para distribuir conocimiento y reducir silos.

Aplicar remote pairing con herramientas colaborativas, llamadas y entornos compartidos.

Medir valor de pairing por calidad, aprendizaje, reducción de defectos y velocidad sostenible.

Resolver resistencias habituales: cansancio, ego, presión de productividad y diferencias de nivel.

Integrar pairing con TDD, refactorización, diseño y revisión continua.

Aplicar trabajo en grupo para problemas de alta incertidumbre o gran impacto.

Definir roles: driver, navigator, mob, facilitador y observadores activos.

Usar rotación para mantener participación y aprendizaje.

Resolver decisiones de diseño en tiempo real con todo el conocimiento disponible.

Evitar sesiones masivas sin foco, preparación o objetivo claro.

Trabajar con TDD para mantener ritmo y dirección durante el mob.

Usar ensemble programming para onboarding, arquitectura, incidentes, legacy o dominios complejos.

Gestionar energía, pausas, turnos y participación de perfiles introvertidos.

Combinar mob, pair y trabajo individual según tipo de tarea.

Crear retrospectivas específicas para mejorar la dinámica colaborativa.

Integrar código con frecuencia en la rama principal para reducir divergencia.

Ejecutar build, tests, análisis estático y validaciones automáticas en cada cambio.

Mantener la rama principal siempre en estado saludable.

Reducir ramas largas que acumulan conflictos, integración tardía y trabajo oculto.

Reparar builds rotos con prioridad alta.

Configurar pipelines rápidos que den feedback en minutos.

Separar validaciones rápidas de suites lentas o nocturnas.

Incorporar métricas de salud: duración del pipeline, fallos, flaky tests y frecuencia de integración.

Conectar CI con estándares de código, seguridad y revisión.

Crear disciplina de integración que soporte small releases y entrega continua.

Trabajar con ramas cortas y cambios pequeños integrados rápidamente.

Usar feature flags para separar integración de activación de funcionalidades.

Diseñar flags temporales, permanentes, operativos y experimentales con gobernanza.

Evitar ramas de larga vida que ocultan problemas hasta el final.

Mantener compatibilidad progresiva en base de datos, APIs y frontend.

Crear estrategias de rollout parcial, canary y desactivación rápida.

Limpiar flags obsoletos para evitar complejidad acumulada.

Probar caminos activados y desactivados cuando el riesgo lo exige.

Integrar trunk-based development con XP, CI/CD y small releases.

Crear acuerdos de equipo para trabajar en main sin miedo y con seguridad.

Entender collective code ownership como responsabilidad compartida sobre calidad y evolución del sistema.

Evitar silos donde solo una persona puede tocar un módulo.

Usar pairing, mob, revisión, documentación y rotación para distribuir conocimiento.

Establecer estándares técnicos que permitan editar código de otros con coherencia.

Mantener tests y CI para que los cambios compartidos sean seguros.

Crear acuerdos para modificar zonas críticas sin bloquear al equipo.

Evitar “mi código” frente a “nuestro producto”.

Gestionar ownership equilibrado: responsabilidad compartida sin ausencia de responsables.

Usar code owners cuando ayudan, sin impedir aprendizaje cruzado.

Medir reducción de dependencia de personas clave y mejora de resiliencia del equipo.

Definir estándares de naming, estructura, formato, tests, errores, logging y arquitectura.

Automatizar formato con linters, formatters y hooks para evitar discusiones superficiales.

Crear convenciones de proyecto que faciliten propiedad colectiva.

Mantener estándares vivos y revisables, no documentos rígidos olvidados.

Incorporar seguridad, rendimiento, accesibilidad y observabilidad en estándares.

Evitar estándares tan extensos que nadie los aplica.

Usar ejemplos reales de código bueno y código problemático.

Integrar estándares en CI, code review y onboarding.

Adaptar convenciones al stack: backend, frontend, mobile, data o APIs.

Convertir estándares en habilitador de velocidad, no en burocracia.

Entender sustainable pace como condición para calidad y aprendizaje.

Detectar señales de sobrecarga: bugs, errores, conflictos, deuda, rotación y pérdida de foco.

Evitar usar XP como excusa para exigir más velocidad sin mejorar sistema.

Planificar capacidad real incluyendo bugs, soporte, refactorización, reuniones y aprendizaje.

Reducir trabajo en curso para mejorar flujo y concentración.

Crear límites saludables para urgencias, interrupciones y deuda acumulada.

Usar retrospectivas para revisar ritmo, energía y fricciones del equipo.

Medir throughput, lead time, defectos y satisfacción sin vigilancia individual tóxica.

Defender calidad técnica como parte del ritmo sostenible.

Construir un entorno donde el equipo pueda entregar de forma constante sin quemarse.

Integrar al cliente, usuario experto o representante de negocio en decisiones frecuentes.

Reducir distancia entre necesidad, implementación y feedback.

Convertir dudas funcionales en conversaciones rápidas y ejemplos concretos.

Evitar que el Product Owner sea solo buzón de peticiones.

Crear mecanismos de revisión de incrementos con usuarios reales o proxies válidos.

Gestionar expectativas sobre alcance, coste, cambio y aprendizaje.

Mantener decisiones funcionales visibles y trazables.

Evitar construir meses sobre supuestos no validados.

Incorporar feedback operativo, soporte, ventas y datos de uso.

Crear una relación donde negocio prioriza valor y el equipo explica coste y riesgo.

Integrar prácticas XP dentro de Scrum sin limitarse a ceremonias.

Usar Kanban para gestionar flujo mientras XP mejora calidad técnica.

Adaptar iteraciones, planning y small releases a contextos con soporte o trabajo no planificado.

Evitar que Scrum gestione trabajo pero no mejore ingeniería.

Usar Definition of Done con pruebas, integración, refactorización y revisión real.

Incorporar prácticas XP a equipos distribuidos, remotos o multi-timezone.

Trabajar con dependencias entre squads sin perder feedback rápido.

Ajustar XP a equipos de producto, plataforma, datos, mobile, backend o frontend.

Mantener principios XP aunque cambie el marco organizativo.

Crear una implantación práctica compatible con la realidad de empresa.

Conectar XP con CI/CD, despliegue continuo, observabilidad y responsabilidad operativa.

Diseñar incrementos pequeños que puedan desplegarse con bajo riesgo.

Usar pipelines como sistema de feedback técnico.

Incorporar logs, métricas, trazas y alertas desde el desarrollo.

Reducir handoffs entre desarrollo, QA, seguridad y operaciones.

Aplicar infraestructura como código y entornos reproducibles cuando el producto lo requiere.

Diseñar releases reversibles, rollback, feature flags y despliegues progresivos.

Usar postmortems sin culpa para alimentar mejora de código y proceso.

Evitar separar calidad de desarrollo y estabilidad de operación.

Construir una cultura donde el equipo se responsabiliza del software en producción.

Integrar seguridad desde historias, criterios de aceptación, TDD y revisión.

Añadir pruebas de seguridad, análisis de dependencias, SAST, secret scanning y controles en CI.

Diseñar casos de abuso junto a casos de uso.

Aplicar secure coding standards dentro de los estándares de equipo.

Evitar dejar seguridad para auditorías tardías.

Incorporar threat modeling ligero en historias de alto riesgo.

Revisar autenticación, autorización, validación, logging y gestión de errores en cada incremento.

Usar pair programming para cambios críticos de seguridad.

Automatizar validaciones sin generar ruido excesivo.

Convertir seguridad en parte natural de XP, no en fase separada.

Evaluar legacy sin culpar a equipos anteriores, entendiendo restricciones históricas.

Crear pruebas de caracterización antes de modificar comportamiento existente.

Identificar seams para aislar dependencias y poder probar.

Refactorizar por zonas pequeñas con impacto controlado.

Reducir miedo al cambio mediante CI, tests y cambios frecuentes.

Combinar trabajo funcional con mejora incremental de diseño.

Evitar reescrituras totales sin business case y control de riesgo.

Usar pairing o mob para áreas de código poco conocidas.

Documentar aprendizajes sobre módulos críticos mientras se trabaja.

Convertir legacy en un sistema progresivamente más seguro y modificable.

Aplicar XP en frontend con componentes pequeños, pruebas de comportamiento y accesibilidad.

Usar TDD en backend para casos de uso, dominio, servicios y reglas.

Diseñar APIs con contratos, tests de contrato y evolución compatible.

Aplicar integración continua en monorepos, repos múltiples y microservicios.

Gestionar cambios distribuidos con small releases y feature flags.

Evitar microservicios con integración tardía y pruebas manuales entre equipos.

Refactorizar componentes, módulos y servicios sin romper consumidores.

Usar mocks con cuidado para no ocultar fallos de integración.

Conectar observabilidad con feedback de producción.

Adaptar prácticas XP al stack técnico sin perder sus principios.

Usar IA generativa como apoyo para TDD, refactorización, análisis de código y documentación.

Evitar aceptar código generado sin entenderlo, probarlo y revisarlo.

Usar asistentes de IA durante pair programming como tercer apoyo, no como sustituto de criterio.

Pedir generación de tests, casos límite y refactorizaciones pequeñas.

Revisar riesgos: alucinaciones, APIs inventadas, vulnerabilidades y tests superficiales.

Mantener propiedad colectiva y estándares aunque parte del código lo proponga una IA.

Usar IA para acelerar comprensión de legacy con verificación en el repositorio.

Integrar IA en CI, PR review o documentación con límites claros.

Evitar “vibe coding” contrario a disciplina XP.

Crear una política de uso responsable de IA alineada con calidad, seguridad y aprendizaje del equipo.

Medir lead time, cycle time, frecuencia de integración, frecuencia de despliegue y defectos escapados.

Analizar cobertura de pruebas con cuidado, sin convertirla en objetivo vacío.

Revisar estabilidad del build, flaky tests y duración de pipelines.

Medir retrabajo, bugs recurrentes, deuda técnica y tiempo de recuperación.

Observar satisfacción del equipo, ritmo sostenible y aprendizaje.

Medir valor entregado mediante outcomes, uso, feedback y métricas de producto.

Evitar métricas individuales de productividad que dañan colaboración.

Usar métricas para mejorar sistema, no para castigar personas.

Crear dashboards de equipo con pocas métricas accionables.

Revisar métricas en retrospectivas y decisiones de mejora.

Evaluar madurez técnica y cultural del equipo antes de imponer prácticas.

Identificar el dolor principal: bugs, lentitud, miedo a cambiar, releases difíciles o baja colaboración.

Elegir prácticas iniciales con impacto visible y dificultad asumible.

Formar al equipo en TDD, pairing, refactorización, CI y diseño simple.

Crear acuerdos explícitos de equipo sobre estándares, integración, pruebas y revisión.

Acompañar la adopción con coaching técnico y retrospectivas frecuentes.

Evitar vender XP como obligación metodológica sin resolver problemas reales.

Integrar a negocio en planificación, feedback y definición de historias.

Medir avance con indicadores de calidad, flujo, aprendizaje y satisfacción.

Escalar XP a más equipos mediante ejemplos, comunidades internas y soporte técnico.

Decir que se aplica XP pero no tener pruebas automatizadas ni integración frecuente.

Hacer pair programming solo como vigilancia o formación unilateral.

Confundir diseño simple con diseño improvisado.

Medir velocidad sin medir calidad ni defectos.

Crear tests frágiles que frenan refactorización.

Mantener ramas largas mientras se afirma practicar integración continua.

Posponer refactorización hasta que el código ya no se puede cambiar.

Tratar al cliente como fuente lejana de requisitos, no como colaborador.

Convertir XP en dogma y no adaptarlo al contexto.

Usar IA para generar código rápido sin feedback, pruebas ni responsabilidad técnica.

Seleccionar una funcionalidad de producto con valor claro, reglas de negocio y cambios probables.

Escribir historias pequeñas con criterios de aceptación y ejemplos verificables.

Planificar una iteración corta con alcance realista, riesgos y objetivo de aprendizaje.

Implementar la funcionalidad mediante TDD, ciclos rojo-verde-refactor y commits pequeños.

Trabajar en pair programming o mob programming para decisiones complejas.

Refactorizar el diseño sin cambiar comportamiento y manteniendo pruebas en verde.

Integrar cambios en la rama principal con pipeline de CI, linters y pruebas automatizadas.

Preparar una release pequeña con feature flag, documentación mínima y criterios de rollback.

Revisar feedback funcional, técnico y de proceso mediante métricas y retrospectiva.

Presentar el resultado como caso XP completo: historia, pruebas, código, integración, release, aprendizaje y mejora continua.