Principios de XP

Los valores te dicen qué es importante. Las prácticas te dicen qué hacer. ¿Pero cómo los conectas? Ahí es donde entran los principios.

Los principios son el puente. Son más concretos que los valores pero más abstractos que las prácticas. Cuando estás decidiendo si adoptar una práctica o modificarla para tu contexto, los principios te guían.

XP tiene muchos principios, pero nos enfocaremos en los más importantes.

El software es hecho por personas, para personas.

Este principio nos recuerda que los desarrolladores no son recursos intercambiables. Las personas tienen necesidades:

• Seguridad (física y psicológica)
• Logro (hacer trabajo significativo)
• Pertenencia (ser parte de un equipo)
• Crecimiento (aprender y mejorar)
• Intimidad (relaciones cercanas y de confianza)

Las prácticas de XP deben satisfacer estas necesidades. La programación en parejas satisface las necesidades de pertenencia e intimidad. El desarrollo guiado por pruebas satisface las necesidades de logro y seguridad. El ritmo sostenible protege la salud física y mental.

Cuando una práctica se siente mal, pregunta: "¿Esto está violando necesidades humanas?"

El dinero importa. El tiempo tiene valor. Las opciones tienen valor.

XP toma la economía en serio:

• Valor temporal del dinero: Una funcionalidad entregada hoy vale más que la misma funcionalidad en seis meses
• Opciones: Mantener las opciones abiertas tiene valor (de ahí evitar el compromiso excesivo)
• Costo del retraso: Esperar para entregar valor tiene costos reales

Este principio respalda las entregas pequeñas (entregar valor temprano), el diseño incremental (no invertir demasiado por adelantado) y la planificación iterativa (responder a lo que aprendes).

También respalda el ritmo sostenible: los desarrolladores agotados cometen errores costosos.

Cada práctica debe beneficiar a todos los involucrados.

Las mejores prácticas de XP son ganar-ganar-ganar:

• Las pruebas ayudan al desarrollador (confianza), al equipo (documentación) y a futuros desarrolladores (red de seguridad)
• La programación en parejas ayuda a ambos compañeros (aprendizaje, detección de errores) y al código (calidad)
• El código simple ayuda al autor (más rápido de escribir) y a los lectores (más fácil de entender)

Evita prácticas que ayudan a un grupo a expensas de otro. La documentación escrita solo para cumplimiento, nunca leída por desarrolladores, falla en el beneficio mutuo. El código escrito para ser ingenioso en lugar de claro también falla.

Si una práctica crea resentimiento, probablemente viola el beneficio mutuo.

Los patrones que funcionan en una escala a menudo funcionan en otras.

XP aplica los mismos patrones a diferentes escalas:

• Rojo-verde-refactorizar (pruebas): Hazlo fallar, hazlo pasar, hazlo limpio
• Planear-hacer-estudiar-actuar (iteraciones): Planea el trabajo, haz el trabajo, estudia los resultados, ajusta
• Recolectar-agrupar-votar (retros): Reúne datos, encuentra patrones, decide acciones

Cuando encuentres algo que funciona, pruébalo a diferentes escalas. El juego de planificación funciona para la planificación de entregas y la planificación de iteraciones. Los principios de revisión de código funcionan para la revisión de diseño y la revisión de arquitectura.

Comienza donde estás y mejora continuamente.

XP no exige perfección desde el primer día. Exige movimiento. Comienza con lo que puedes hacer hoy y mejora desde ahí.

• ¿No tienes pruebas? Escribe una prueba para el próximo error que corrijas.
• ¿No programas en parejas? Pruébalo durante una hora mañana.
• ¿No hay integración continua? Haz commits con más frecuencia.

El objetivo no es "hacer XP". El objetivo es mejorar. XP es una dirección, no un destino.

Este principio también respalda fallar de manera segura. Los experimentos que no funcionan son oportunidades de aprendizaje, no fracasos.

Entrega valor continuamente, no en grandes lotes.

Este principio alinea XP con el pensamiento lean y Kanban. Los grandes lotes ocultan problemas. Los lotes pequeños los sacan a la luz rápidamente.

• Historias pequeñas (días, no semanas)
• Entregas frecuentes (semanales, no trimestrales)
• Integración continua (horas, no días)
• Pruebas inmediatas (segundos, no horas)

El flujo reduce el trabajo en progreso, lo que reduce el cambio de contexto, lo que mejora el enfoque y la calidad. También da valor a los clientes más pronto y retroalimentación más rápida.

La calidad no es negociable.

Esto parece obvio, pero las implicaciones son profundas. XP dice que puedes negociar alcance o cronograma, pero nunca calidad.

Esto significa:

• Las pruebas no son opcionales cuando el tiempo es ajustado
• La refactorización no es un lujo
• La deuda técnica no es aceptable
• "Entregar ahora, arreglar después" no es un plan

¿Por qué? Porque la calidad es la base de la velocidad. La mala calidad crea errores que te ralentizan. La mala calidad crea código difícil de cambiar. La mala calidad crea sistemas costosos de mantener.

La calidad es la forma más rápida de ir rápido.

Da el paso más pequeño que genere progreso.

Los grandes cambios son riesgosos. Los cambios pequeños son seguros. XP siempre prefiere pasos pequeños:

• Escribe una prueba que falle antes de escribir cualquier código
• Refactoriza una cosa a la vez
• Integra después de cambios pequeños, no grandes
• Entrega incrementos pequeños, no grandes entregas

Los pasos pequeños no significan progreso lento. Mil pasos pequeños pueden cubrir más terreno que diez grandes saltos, y con menos posibilidad de caer.

Cuando estés atascado, pregunta: "¿Qué es lo más pequeño que puedo hacer ahora mismo que genere progreso?"