Extreme Programming (XP) es una disciplina para el desarrollo de software basada en los valores de simpleza, comunicación, feedback y coraje. Reune al Equipo Completo junto a prácticas simples, con el feedback suficiente feedback para permitirle al equipo ver en dónde está y ajustar las prácticas a su situación única.

Vamos a repasar algunos de los conceptos y prácticas más importantes de Extreme Programming.

Equipo completo

Todos los contribuyentes de un proyecto XP se sientan juntos, son miembros de un mismo equipo. El equipo tiene que incluir a un representante del negocio -el "Cliente"- quien provee requerimientos, establece prioridades, y guia al proyecto. Lo mejor es que el Cliente o uno de sus asistentes sea el usuario final que conoce al dominio y lo que necesita. Por supuesto, el equipo incluye a los programadores. El equipo puede incluir testers, que ayudan al Cliente a definir las pruebas de aceptación del cliente. Los analistas pueden servir como asistentes del Cliente, ayudándolo a definir los requerimientos. Suele haber un coach, que ayuda al equipo a mantener el rumbo y facilitar el proceso. Puede haber un manager, que brinda recursos, se encarga de la comunicación externa y coordina actividades. Ninguno de estos roles es propiedad exclusiva de una persona: todos en un equipo XP contribuyen de la manera que pueden. Los mejores equipos no tienen especialistas, sino contribuyentes generales con habilidades especiales.

Planificación

La planificación en XP responde dos preguntas clave del desarrollo de software: predecir qué se habrá terminado para la fecha de entrega, y determinar qué hacer después. Se hace énfasis en guiar al proyecto -que es bastante directo- en vez de predecir exactamente lo que se necesitará y cuánto tiempo tomará hacerlo -que es bastante dificil. Hay dos pasos claves en la planificación de XP, que responde estas dos preguntas: 

• Planificación de la Entrega, es una práctica en donde el Cliente presenta las características deseadas a los programadores, y los programadores estiman la dificultad. Teniendo las estimaciones de costo, y sabiendo la importancia de las características, el Cliente establece un plan para el proyecto. Los planes iniciales de entregas son necesariamente imprecisos: ni las prioridades ni las estimaciones son sólidas, y tampoco sabremos qué tan rápido trabaja el equipo hasta que empiece a trabajar. Sin embargo, incluso el primer plan de entrega es lo suficientemente preciso como para tomar decisiones, y el equipo XP revisa de forma regular el plan.
• Planificación de la Iteración, es la práctica en donde el equipo establece el rumbo cada un par de semanas. Los equipos XP construyen software en iteraciones de dos semanas, y entregan software útil al finalizar cada iteración. Durante la Planificación de la Iteración, el Cliente presenta las características deseadas para las siguientes dos semanas. Los programadores las descomponen en tareas, y estiman su costo (a un nivel de detalle más fino que durante la Planificación de la Entrega). El equipo entonces se compromente a terminar ciertas características basándose en la cantidad de trabajo que pudieron terminar en la iteración anterior.

Estos pasos de planificación son muy simples, y le brindan al cliente muy buena información y excelente flexibilidad para guiar al proyecto. Cada dos semanas se hace completamente visible el progreso. No existe el "90% terminado" en XP: una historia está terminada, o no lo está. Este foco en la transparencia resulta en una bonita paradoja: por un lado, con tanta visibilidad, el Cliente está en la posición de cancelar el proyecto si el progreso no es suficiente. Por otro lado, como el progreso es tan visible, y hay completa libertad para decidir qué se hará después, los proyectos XP tienden a entregar más de lo necesario, con menos presión y estrés.

Pruebas automatizadas

Como parte de la presentación de cada característica deseada, el Cliente también definie una o más pruebas de aceptación automatizadas para mostrar que la característica funciona. El equipo construye estas pruebas y las utiliza para demostrar al cliente y a ellos mismos que la característica se implementó de forma correcta. La automatización es importante porque, por la presión del tiempo, se suelen saltear las pruebas manuales. Y eso es como apagar las luces cuando se viene la noche.

Los mejores equipos XP tratan a las pruebas del cliente de la misma manera que a las pruebas de los programadores: una vez que la prueba se ejecuta bien, el equipo la mantiene corriendo bien de ahí en adelante. Esto significa que el sistema sólo mejora, siempre avanzando, nunca retrocediendo.

Entregas

Los equipos XP realizan entregas pequeñas de dos formas importantes: 

1. Primero, el equipo entrega software probado y funcionando, que entrega el valor elegido por el Cliente, en cada iteración. El Cliente puede usar este software para cualquier propósito, sea como evaluación o incluso liberarlo para los usuarios finales (muy recomendado). El aspecto más importante es que el software sea visible y entregado al cliente, al final de cada iteración. Esto hace que todo se mantenga abierto y tangible.
2. Segundo, los equipos XP también entregan software de forma frecuente a los usuarios finales. Los proyectos web XP entregan a diario, los proyectos internos de forma mensual o más seguido. Incluso los productos enlatados se entregan cuatrimestralmente.

Puede parecer imposible crear buenas versiones tan seguido, pero los equipos XP lo hacen todo el tiempo. Pueden ver la Integración Continua para más detalles, y nos daremos cuenta que estas entregas frecuentes son confiables por la obsesión de XP por las pruebas, como ser las Pruebas del Cliente y el Desarrollo Guiado por Pruebas (TDD).

Diseño simple

Los equipos de XP construyen software sobre un diseño simple. Empiezan simple, y a través de las pruebas de programación y las mejoras al diseño, lo mantienen así. Cualquier equipo XP mantiene al diseño para que sea el justo y necesario para cumplir la funcionalidad actual del sistema. No hay desperdicio, y el software siempre está listo para lo que sigue.

El diseño en XP no es algo de "única vez", o que se hace completo al principio, sino que es algo de todo momento. Hay diseño durante la planificación de la entrega y la planificación de la iteración; además, los equipos hacen sesiones rápidas de diseño y revisiones a través del refactor durante todo el proyecto. Resulta esencial tiene un buen diseño en los procesos iterativo incremental, como Extreme Programimng. Por esto se hace tanto énfasis en el diseño a través de toda la vida del proyecto.

Programación de a pares

En XP todo el software productivo se escribe en pareja, dos programadores sentados lado a lado en una misma computadora. Esta práctica asegura que todo el código productivo fue revisado por al menos otro programador, y genera mejores diseños, mejores pruebas y mejor código.

Puede parecer ineficiente que dos programadores hagan el "trabajo de un programador", pero lo contrario es cierto. Los estudios sobre la programación de a pares muestran que las parejas producen mejor código en aproximadamente el mismo tiempo que un programador trabajando solo. Es cierto: ¡dos cabezas son mejor que una! 

Muchos programadores objetan la programación de a pares antes de probarla. Se necesita tiempo y práctica para hacerlo bien, y es necesario aplicarlo por varias semanas para ver los resultados. El 90% de los programadores que aprenden a trabajar de a pares lo prefieren, por lo que la programación de a pares es una práctica recomendada para todos los equipos.

Además de generar mejor código y pruebas, la programación de a pares también sirve para comunicar el conocimiento a través de los equipos. Como las parejas cambian, todos obtienen los beneficios del conocimiento especializado de las personas. Los programadores aprenden, mejoran sus habilidades, se vuelven más valiosos para el equipo y para la organización. La programación de a pares, incluso por fuera de XP, es una ventaja para todos.

TDD

Extreme Programming se obsesiona con el feedback, y en el desarrollo de software el buen feedback necesita de buenas pruebas. Los mejores equipos de XP practican Desarrollo Guiado por Pruebas (TDD), trabajando en ciclos muy cortos de agregar una prueba, y después hacerla funcionar. Casi sin esfuerzo, los equipos producen código con casi un 100% de cobertura de pruebas, lo cual es un gran avance para la mayoría de los lugares (y si ya estás creando pruebas más sofisticadas, mejor todavía!).

No alcanza con escribir pruebas: debemos ejecutarlas. Aquí también XP es extremo. Estas "pruebas del programador" o "pruebas unitarias" se juntan, y cada vez que cualquier programador sube código al repositorio (y las parejas lo suelen hacer dos o más veces al día), cada una de las pruebas unitarias debe correr con éxito. ¡100%, todo el tiempo! Esto significa que los programadores tienen un feedback inmediato sobre cómo están avanzando. Además, estas pruebas brindan un apoyo invaluable a medida que mejora el diseño del software.

Refactor

Extreme Programming se enfoca en entregar valor de negocio en cada iteración. Para lograr esto a lo largo de todo el proyecto, el software debe estar bien diseñado. La alternativa es retrarsarse hasta detenerse por completo. Es por esto que XP utiliza un proceso de mejora continua del diseño llamado Refactoring, sacado del libro de Fowler “Refactoring: Improving the Design of Existing Code“.

El proceso de refactor se enfoca en eliminar la duplicación (una clara señal de diseño pobre), y en incrementar la cohesión del código, disminuyendo al acoplamiento. Hace ya treinta años que se considera a la alta cohesión y al bajo acoplamiento como el máximo logro de un buen diseño. El resultado es que los equipos XP comienzan con un diseño simple y bueno, y siempre tienen un diseño simple y bueno para el software. Esto les permite mantener la velocidad, y en general suele acelerar la velocidad a medida que el proyecto avanza.

El refactor se apoya en pruebas completas que aseguran que, a medida que el diseño evoluciona, nada se rompa. Las pruebas del cliente y unitarias son críticas para permitir el refactor. Las prácticas de XP se apoyan entre si: son más poderosas que por separado.

Integración continua

Los equipos mantiene integrado al sistema todo el tiempo. Los equipos XP realizan construcciones muchas veces por día.

El beneficio de esta práctica lo vemos al pensar en esos proyectos que todos oímos (o incluso fuimos parte) en donde la contrucción se realizaba semanalmente (o incluso con menos frecuencia), y que usualmente termina en un "infierno de integración", donde todo se rompe y nadie sabe porqué.

La integración infrecuente lleva a problemas serios en el proyecto de software. Primero, aunque la integración es crítica para entregar buen software, el equipo no la practica y a menudo la delega a personas que no están familiarizadas con el sistema completo. Segundo, la integración infrecuente suele generar código con errores. Al momento de integrar aparecen problemas que no se detectaron en ninguna de las pruebas del software sin integrar. Tercero, los procesos de integración débiles generan largos períodos de "congelamiento" del código. El congelamiento de código (o "code freeze") significa que por largos períodos los programadores no pueden agregar  nuevas características, aunque sea necesario. Esto debilita nuestra posición en el mercado y con los usuarios finales.

Propiedad colectiva de código

En  un proyecto XP, cualquier pareja de programadores puede mejorar cualquier porción de código en cualquier momento. Esto significa que el código se beneficia de la atención de las personas, lo cual resulta en una mayor calidad de código y en menos defectos. También hay otro beneficio importante: cuando los individuos son dueños del código, se suelen agregar características en lugares equivocados cuando un programador descubre que necesita agregar algo en un lugar que "no es suyo". El dueño está muy ocupado para hacerlo, por lo que le programador escribe la característica en su propio código, en donde no corresponde. Esto lleva a código dificil de mantener, lleno de duplicación y con baja (mala) cohesión.

La propiedad colectiva de código sería un problema si las personas trabajaran a ciegas en código que no entienden. XP evita estos problemas a través de dos técnicas: las pruebas del programador (unitarias) atrapan los errores, y la programación de a pares significa que la mejor forma de trabajar con código poco familiar es estar en pareja con un experto. Además de asegurar buenas modificaciones cuando se las necesita, esta práctica ayuda a compartir el conocimiento en todo el equipo.

Estándares de código

Los equipos XP usan un estándar de código en común, de manera que el código del sistema se vea como si fuera escrito por una única persona muy competente. No importa mucho el estándar en si mismo: lo importante es que el código se vea familiar, para permitir la propiedad colectiva.

Metáfora del sistema

Los equipos XP desarrollan una visión común sobre cómo funciona el programa, que llamamos la "metáfora". La metáfora es una descripción evocativa simple sobre cómo funciona el programa; por ejemplo "este programa funciona como una colmena de abejas, que salen a buscar polen y lo traen de vuelta a la colmena", podría ser una descripción para un sistema de recuperación de información a través de agentes.

A veces no aparece una metáfora poética. En ese caso, con o sin una imágen viva, los equipos XP usan un sistema común de nombres para asegurarse que todos entiendan cómo funciona el sistema, en dónde buscar la funcionalidad que queremos, o cómo encontrar el lugar adecuado para agregar algo nuevo.

Conclusión

Extreme Programming es una disciplina para el desarrollo de software basada en los valores de simpleza, comunicación, feedback y coraje. Funciona formando un equipo completo y con todas las personas juntas en presencia de prácticas simples, con suficiente feedback para permitirle al equipo ver en dónde están y para ajsutar las prácticas a su situación única.

Traducido de What is Extreme Programming?, por Ron Jeffries.