Muchas personas que no están familiarizadas con XP pueden pensar que la "Programación Extrema" implica que los programadores codifiquen sin descanso, siguiendo una metodología que busca exprimir al máximo su productividad. Es el sueño de muchos managers de la vieja escuela.
Sin embargo, nada más lejos de la realidad. Lo que XP realmente busca llevar al extremo son ciertas prácticas que se centran principalmente en la comunicación entre las áreas de negocio y desarrollo, algo que a menudo se pasaba por alto en los inicios de la ingeniería de software.
Cuando Kent Beck acuñó el término, probablemente imaginó que el aspecto extremo debía ser la comunicación entre el cliente y el equipo de desarrollo. Tanto es así que enfatizó la buena práctica de la participación del cliente a tiempo completo. El cliente debía elegir uno o más representantes que pudieran comunicarse eficazmente con el equipo de desarrollo, participar en él e incluso contribuir a la definición de las pruebas de aceptación del sistema.
Enfatizar a las personas (un concepto que en el mundo ágil a veces ha recibido connotaciones de Nueva Era) era simplemente un contrapunto al enfoque clásico en los procesos de la ingeniería de software anterior al milenio.
Sí, adoptar este enfoque centrado en las personas y reflejarlo tanto en los valores como en los principios de XP requirió definir un conjunto de prácticas alineadas con ellos: programación en pareja, propiedad colectiva del código, procesos de desarrollo sostenibles que impliquen jornadas laborales manejables para las personas---todas estas son aplicaciones prácticas del principio de la "Humanidad", el primer principio descrito por Kent Beck en su famoso libro. El orden que eligió no fue accidental.
En el proceso de la programación extrema, los clientes participan en la especificación de los requisitos del sistema e incluso en el establecimiento de sus prioridades. Esto es importante porque los requisitos ya no se definen como una lista de funciones. Ahora, el cliente, junto con el equipo de desarrollo, participa en discusiones sobre escenarios, que luego se traducen en una serie de tarjetas de usuario. A partir de ahí, el equipo de desarrollo se concentra en implementar cada una de estas tarjetas en futuros entregables del software. Estos entregables incluyen de forma natural todas las pruebas de aceptación del sistema y las pruebas ya existentes para las historias implementadas anteriormente (no hay término medio en esto).
Una tarjeta de historia de usuario es tan simple como una tarjeta con un título y una descripción. Por supuesto, en el momento de escribir, los requisitos pueden seguir siendo bastante vagos. Una vez redactada, el equipo de desarrollo debe ser capaz de desglosarla en tareas, estimar el esfuerzo y los recursos necesarios para generar un entregable.
Durante este proceso, el cliente prioriza todas las tarjetas para el área de negocio. El enfoque se centra principalmente en aquellas que pueden proporcionar un valor inmediato al cliente, asumiendo que de esta manera se puede generar valor prácticamente desde el inicio. A lo largo de este proceso, el cliente resuelve muchas de las dudas planteadas por los desarrolladores.
Sin embargo, este proceso de recopilación de requisitos no es tan rígido como en el ciclo de vida en cascada. Como sabemos, los requisitos cambian, y cuando lo hacen, afectan a las historias que aún no se han implementado, las cuales deben ser revisadas o descartadas. Si los cambios afectan a historias ya entregadas, se genera una nueva tarjeta de historia, que se reintroduce en la cola de prioridades según el proceso explicado anteriormente.
Por lo tanto, XP es una redefinición de los antiguos ciclos de desarrollo hacia modelos más iterativos. Porque, como sabemos, en cualquier desarrollo surgen cambios imprevistos que tienden a degradar la estructura del software. XP intenta implementar mejoras tan pronto como se detecten, además de identificarlas de forma continua.
Naturalmente, para lograr esto, el software debe ser fácil de entender y modificar cada vez que se necesite implementar nuevas historias. Y no te imaginas la cantidad de prácticas que XP propone para alcanzar este objetivo. Pero quizás las más importantes sean aquellas que definen cómo probar el sistema.
Para XP, las pruebas son uno de los aspectos más importantes.
Tenga en cuenta que, al tratarse de un desarrollo iterativo, ya no disponemos de una especificación completa del sistema como ocurría con el enfoque en cascada. Ahora, tenemos que confiar en un sistema de pruebas del software que es, digamos, más "informal". Sin embargo, no informal en un sentido negativo, sino en el sentido de adoptar un enfoque centrado en reducir la probabilidad de que cada nuevo incremento de software introduzca errores en el software previamente generado.
Aquí es donde entra en juego TDD, la joya de la corona.
Escribir pruebas antes de desarrollar una funcionalidad (donde la funcionalidad puede ser cada una de las tareas en las que se divide una historia) reduce en gran medida los problemas de que los desarrolladores malinterpreten los requisitos y se produzcan inconsistencias en las interfaces.
También mejora la comunicación con el cliente al involucrarlo en la generación de las pruebas de aceptación, que definen que el sistema cumple funcionalmente con las expectativas del cliente. Las pruebas se convierten en otro componente de nuestro software que se ejecuta de manera independiente.
El tema de las pruebas puede ser uno de los aspectos más potentes de XP, pero al mismo tiempo, uno de los más complejos. Según mi experiencia, las mayores complejidades se centran en tres aspectos:
- Para las pruebas de aceptación, se requiere un compromiso significativo por parte del cliente, probablemente a tiempo completo. No todos los clientes están dispuestos a asumir tal compromiso.
- Algunas pruebas, especialmente aquellas que implican la interfaz de usuario, pueden ser tan dolorosas de escribir como un dolor de muelas.
- Los programadores siempre prefieren programar funcionalidades en lugar de escribir pruebas. A veces es una tarea complicada convencerlos de que es importante aplicar el mismo nivel de excelencia al escribir pruebas que al implementar una funcionalidad, y sobre todo, no sucumbir a la tentación de dejarlas a medio camino al evitar la implementación de situaciones excepcionales. Implementar correctamente las pruebas es tan importante (si no más) como implementar correctamente una tarea.
Entonces, volviendo a la pregunta inicial:
"¿Por qué es extrema la Programación Extrema?"
La respuesta es: por muchas razones, que se pueden reducir a la idea de que la metodología lleva los elementos beneficiosos de las prácticas tradicionales de ingeniería de software a niveles "extremos", especialmente en lo que respecta a las pruebas.