Los Orígenes de XP

En 1996, Kent Beck fue contratado para rescatar un proyecto de nómina fallido en Chrysler llamado C3 (Chrysler Comprehensive Compensation). El proyecto estaba en problemas—el desarrollo en cascada clásico había producido un sistema que no funcionaba y no podía arreglarse.

Beck no solo arregló el proyecto. Sintetizó décadas de sabiduría en ingeniería de software en una metodología coherente. Tomó prácticas que los desarrolladores experimentados sabían que funcionaban—pruebas, revisión de código, desarrollo iterativo—y las llevó a sus extremos lógicos.

Si las pruebas son buenas, prueba constantemente. Si la revisión de código es buena, revisa continuamente mediante programación en pareja. Si la integración es buena, integra varias veces al día. Si las iteraciones cortas son buenas, hazlas aún más cortas.

El proyecto C3 se entregó. Más importante aún, creó una plantilla que remodelaría el desarrollo de software.

En 1999, Kent Beck publicó "Extreme Programming Explained"—a menudo llamado "el Libro Blanco" por su portada. Este se convirtió en el documento fundacional de XP y uno de los primeros manifiestos ágiles.

El libro fue controversial. ¿Programación en pareja todo el tiempo? ¿Sin gran diseño por adelantado? ¿Clientes en el sitio? Muchos en la industria pensaron que Beck estaba loco. Pero los equipos que probaron XP reportaron resultados notables:

• Dramáticamente menos errores llegando a producción
• Ritmo sostenible en lugar de marchas de la muerte
• Software funcionando en lugar de promesas de documentación
• Desarrolladores felices que se sentían en control

Dos años después, en 2001, Beck se unió a otros dieciséis practicantes de software en Snowbird, Utah. Juntos escribieron el Manifiesto Ágil. La influencia de XP es visible en todo—individuos sobre procesos, software funcionando, colaboración con el cliente, responder al cambio.

XP fue la primera metodología ágil completa, y en muchos sentidos, sigue siendo la más rigurosa.

La visión tradicional del desarrollo de software era que el cambio es costoso. El costo de corregir un error crece exponencialmente desde los requisitos hasta el diseño, la codificación, las pruebas y la producción. Por lo tanto, deberías hacer todo lo posible para hacerlo bien la primera vez—de ahí el énfasis de la cascada en el diseño exhaustivo por adelantado.

Beck propuso una alternativa radical: ¿Qué pasaría si pudieras aplanar la curva del costo del cambio?

Si tienes:

• Pruebas automatizadas exhaustivas (los cambios pueden validarse instantáneamente)
• Diseño simple (menos que cambiar)
• Propiedad colectiva del código (cualquiera puede hacer cambios)
• Integración continua (los cambios se integran inmediatamente)
• Habilidades de refactorización (el código puede evolucionar de forma segura)

Entonces el costo del cambio se vuelve aproximadamente constante con el tiempo. Y si el cambio es barato, no necesitas predecir el futuro. Puedes abrazar el cambio como una ventaja competitiva.

Esta es la perspectiva fundamental de XP: las prácticas técnicas pueden hacer que el cambio sea barato, y el cambio barato lo cambia todo.