Las Prácticas de XP: Una Visión General

XP no es un menú donde eliges tus favoritas. Las prácticas están diseñadas para reforzarse mutuamente. Elimina una, y las demás se vuelven más difíciles o menos efectivas.

Por ejemplo:

• La refactorización es segura porque tienes pruebas exhaustivas
• El diseño simple es posible porque puedes refactorizar cuando cambian los requisitos
• La propiedad colectiva funciona porque tienes estándares de código
• La integración continua es factible porque tienes entregas pequeñas y pruebas

Esta naturaleza entrelazada es la razón por la que "hacer TDD pero no refactorizar" o "programación en parejas sin pruebas" a menudo falla. Estás eliminando una pared de carga.

Dicho esto, tienes que empezar en algún lugar. Discutiremos la adopción incremental en el Módulo 5.

Estas son las prácticas centrales que la mayoría de los equipos de XP adoptan:

Prácticas de Planificación:

• Historias de Usuario: Requisitos como iniciadores de conversación
• Juego de Planificación: El negocio elige qué, los desarrolladores eligen cómo
• Entregas Pequeñas: Entregar valor frecuentemente
• Planificación de Iteración: Dividir historias en tareas para cada iteración

Prácticas de Desarrollo:

• Desarrollo Guiado por Pruebas (TDD): Escribe la prueba primero
• Programación en Parejas: Dos desarrolladores, un teclado
• Refactorización: Mejorar el código sin cambiar el comportamiento
• Diseño Simple: Lo más simple que funcione
• Integración Continua: Integrar y probar muchas veces al día

Prácticas de Equipo:

• Equipo Completo: Todos los necesarios para entregar, en una sala
• Propiedad Colectiva del Código: Cualquiera puede cambiar cualquier código
• Estándares de Código: Convenciones de código acordadas
• Ritmo Sostenible: Sin horas extras como regla

Cubriremos cada una de estas en profundidad en los siguientes módulos.

Estas prácticas son poderosas pero requieren más madurez o condiciones específicas:

• Participación Real del Cliente: El cliente real, no solo un representante
• Análisis de Causa Raíz: Arreglar el sistema, no solo el síntoma
• Código Compartido: Todo el código es visible para todos los desarrolladores
• Código y Pruebas: El código y las pruebas son los únicos artefactos permanentes
• Base de Código Única: Una rama, no muchas
• Despliegue Diario: Desplegar a producción todos los días
• Contrato de Alcance Negociado: Contratos que abrazan el cambio
• Pago por Uso: Retroalimentación directa de clientes reales

Estas no son "XP avanzado". Son prácticas que funcionan bien en el contexto correcto pero podrían ser inapropiadas o imposibles en otros.

Una forma de entender las prácticas de XP es a través de sus ciclos de retroalimentación:

Segundos: Pruebas unitarias Minutos: Programación en parejas Horas: Integración continua Día: Standup Semana: Planificación de iteración, demo del cliente Mes/Trimestre: Entrega, retrospectiva

En cada escala, XP crea oportunidades para aprender y ajustar. Esto es intencional. Cuanto más rápido aprendes, más rápido puedes corregir el rumbo.

Si no estás obteniendo retroalimentación en cada una de estas escalas, algo falta.

Esto puede parecer abrumador. No intentes adoptar todo a la vez.

La mayoría de los equipos comienzan con:

1. TDD o al menos escribir pruebas
2. Integración Continua
3. Iteraciones (o sprints si usas Scrum)
4. Retrospectivas

Estos forman la base. Una vez que estén funcionando, agrega:

• Programación en parejas (comienza solo con problemas difíciles)
• Refactorización (comienza con el código más desordenado)
• Entregas pequeñas (comienza entregando con más frecuencia)

Cubriremos estrategias de adopción en el Módulo 5. Por ahora, solo entiende el panorama.