¿Por qué es extrema la Programación Extrema?

Mucha gente ajena a XP considera que la expresión “Extreme Programming” puede generar la imagen mental de programadores picando código sin descansar ni un minuto, trabajando a través de una metodología orientada a exprimirles para obtener la máxima productividad. El sueño de muchos CEO de la vieja escuela.

Nada más lejos de la realidad. Lo que XP intenta llevar al extremo son ciertas prácticas que se centran, sobre todo, en la comunicación entre las áreas de negocio y de desarrollo, tan poco tenida en cuenta en los albores de la ingeniería del software.

Cuando Kent Beck acuñó el término, seguramente concibió que lo que tenía que ser extrema era precisamente la comunicación entre el cliente y el equipo de desarrollo. Hasta tal punto que enunciaba como buena práctica que la participación del cliente se llevase a cabo con un compromiso a tiempo completo. De tal modo que el cliente tenía que elegir algún o algunos representantes que fueran capaces de comunicarse con el equipo de desarrollo, participar en el mismo e incluso participar en la definición de las pruebas de aceptación del sistema.

Enfocarse a las personas (concepto que en el mundo agile a veces ha sido retorcidamente dotado de connotaciones New Age) no era más que una contraposición al clásico interés por los procesos en la ingeniería del software anterior al nuevo milenio.

Pues si: adoptar este enfoque a las personas, y dejarlo reflejado tanto en los valores como los principios de XP, obligaba a definir una serie de prácticas alineadas con los mismos: la programación en parejas, el concepto de propiedad colectiva del código, los procesos orientados al desarrollo sostenible que implicase jornadas de trabajo humanamente asumibles, no son más que la aplicación práctica del principio “Humanity”, el primer principio que enunciaría Kent Beck en su famoso libro. El orden que eligió, no era casual.

En el proceso de la programación extrema, los clientes se implican en la especificación de los requerimientos del sistema, e incluso en el establecimiento de las prioridades de los mismos. Esto es importante porque los requerimientos ya no se especifican como una lista de funciones. Ahora el cliente junto con el equipo de desarrollo discute acerca de escenarios. Discusiones que se plasman en una serie de tarjetas de historias (story cards). A partir de ahí, el equipo de desarrollo se centrará en plasmar cada una de esas tarjetas en un futuro entregable de software. Entregable que por supuesto incluye todas las pruebas de aceptación del mismo y las que ya existían para el resto de historias ya implementadas en verde (aquí no hay medias tintas).

Una tarjeta de usuario es algo tan sencillo como una tarjeta con un título y una descripción. Evidentemente ésta todavía puede tener una información muy vaga de los requerimientos. Una vez se ha escrito, el equipo de desarrollo debe ser capaz de dividirla en tareas, estimar el esfuerzo y los recursos que necesitan para llegar a generar un entregable.

El cliente, durante este proceso, ordena todas las tarjetas en orden de prioridad para el área de negocio. Se centra sobre todo en aquellas que pueden resultar útiles de manera más inmediata al cliente, asumiendo que de esta manera se va a comenzar a generar valor prácticamente desde el principio. Y durante todo este proceso, por supuesto va resolviendo muchas dudas que los desarrolladores les van planteando.

Pero este proceso de educción de requisitos no es tan inflexible como en el ciclo de vida en cascada: como sabemos los requerimientos cambian, y cuando eso ocurre afectará a historias sin implementar que tendrán que ser revisadas o descartadas. En el caso de que los cambios afecten a historias ya entregadas, lo que se hace es volver a generar otra tarjeta de esa nueva historia y se vuelve a introducir en la cola de prioridades según el proceso ya explicado.

XP es, por tanto, una redefinición de los viejos ciclos de desarrollo hacia modelos más iterativos. Porque como sabemos, en todo desarrollo surgen cambios imprevistos y los mismos tienden a degradar la estructura del software. XP trata de implementar lo más inmediatamente posible las mejoras que se puedan detectar. Y también trata de detectarlas de manera contínua.

Evidentemente, para conseguir esto el software debe ser fácil de entender y cambiar cada vez que haya que implementar historias nuevas. Y no imagináis la cantidad de prácticas que XP propone para conseguir tal fin. Pero probablemente las más importantes sean las que definen la forma de probar el sistema.

Para XP las pruebas son una de las cuestiones más importantes.

Ten en cuenta que al ser un desarrollo iterativo, ya no contamos con una especificación completa del sistema como era el caso del waterfall. Ahora tenemos que contar con un sistema para probar el software que sea, digamos, más “informal”. Pero no informal en el mal sentido, sino en el de crear un enfoque orientado a reducir la probabilidad de que cada nuevo incremento del software introduzca errores en el software ya generado anteriormente.

Aquí es donde entra TDD, la joya de la corona.

Escribir las pruebas antes de desarrollar una funcionalidad (funcionalidad puede ser cada una de las tareas en las que se divide una historia) reduce enormemente los problemas de malinterpretación de requerimientos por parte de los desarrolladores y las inconsistencias en las interfaces.

Además mejora la comunicación con el cliente: implicándolo en la generación de las pruebas de aceptación (es decir, aquellas que definen que a nivel funcional el sistema se ajusta a lo que el cliente espera) . Las pruebas no serán más que un componente más de nuestro software que se ejecutarán de forma independiente.

El tema de las pruebas puede ser una de las partes más potentes de XP pero al mismo tiempo una de las más complejas. Las mayores complejidades, según mi experiencia se centran en tres aspectos:

1. Implican, para el caso de las pruebas de aceptación, un gran compromiso por parte de cliente. Probablemente un compromiso a tiempo completo. No todos los clientes están dispuestos a asumirlo.
2. Algunas pruebas, especialmente las que implican la interfaz de usuario, pueden ser tan dolorosas de escribir como un dolor de muelas.
3. Los programadores siempre prefieren programar funcionalidades a programar pruebas. A veces es una tarea muy ardua concienciar a los mismos de que es importante aplicar el mismo nivel de excelencia escribiendo dichas pruebas que escribiendo la funcionalidad, y sobre todo no caer en la tentación de dejarlas a medias evitando implementar las situaciones más excepcionales. Implementar bien las pruebas es tan importante (o más) como implementar bien una tarea.

Así que volviendo a la pregunta inicial:

¿Por qué es extrema la Programación Extrema?

La respuesta sería: por muchas razones. Que se podrían reducir a que la metodología toma su nombre de la idea de que los elementos beneficiosos de las prácticas tradicionales de ingeniería de software se llevan a niveles "extremos", especialmente las pruebas.