El libro "Extreme Programming Explained"

Hace muchos años llegué a este libro por recomendación y leyéndolo con aquellos ojos me encantó su planteamiento. Sintetizaba todas las discusiones frente a la máquina de café que habíamos tenido los desarrolladores allá por los 90 (a ver, salvando el detalle de que yo era un pipiolo) debido a las malas prácticas empresariales que sufríamos a menudo como consecuencia de un sector todavía en maduración.

Si bien entonces XP podría se considerado poco más que un ensayo experimental más sobre gestión de proyectos (por entonces el manifiesto agile ni siquiera existía), hoy ya no se puede negar la influencia de XP en la cultura o filosofía (o lo que sea) agile. Los llamados métodos y principios "ágiles" llamaron verdaderamente la atención de muchas empresas, preocupadas por el desarrollo de software, solo algunos años después de publicarse este libro. Al menos en nuestro país.

Extreme Programming Explained es el primer libro sobre XP y quizás el más importante que puedes leer sobre el tema. Teniendo en cuenta que refleja la perspectiva de su creador, se agradece que consigue transmitir su entusiasmo por el tema. Y releerlo de vez en cuando no viene mal, porque es uno de esos libros donde no sobra ningún párrafo, y merece la pena retomarlo con conceptos ya más asimilados.

¿Por qué fue un libro innovador?

Lo que verdaderamente fue innovador entonces fue el enfoque que cambiaba completamente la forma de planificar los proyectos, basado en la idea de las interacciones del equipo sobre los procesos. XP propone que la planificación de un proyecto se realiza en dos fases paralelas: una planificación de alto nivel y otra detallada para cada iteración. La primera tenía como objetivo determinar las funcionalidades que se realizarán en el futuro inmediato, y generalmente se realiza junto con el cliente. Lo que comunmente conocemos como definir las historias de usuario con el cliente.

Pero la gracia del asunto está en la existencia de una segunda fase de la planificación, que podemos decir que se plantea en un segundo plano y de manera iterativa. Después de tener ya definidas las historias de usuario es necesario crear un plan de publicaciones, en inglés "release plan", donde se indiquen las historias de usuario que se crearán para cada versión del programa y las fechas en las que se publicarán estas versiones. Cada "release plan" es una planificación donde los desarrolladores y clientes establecen los tiempos de implementación ideales de las historias de usuario, la prioridad con la que serán implementadas y las historias que serán implementadas en cada versión del programa. Al final de la misma, se ponían en producción sólo aquellas historias que habían superado las pruebas de aceptación. Pruebas que habían sido definidas previamente junto con el cliente.

Esto rompía con lo que a muchos nos habían enseñado en la universidad. Porque ahora XP planteaba que todo proyecto se tenía que dividir en iteraciones (de aproximadamente 3 semanas de duración) y dejábamos de lado las antiguas fases del ciclo de vida en cascada, las pilas de documentación (los más viejos del lugar: ¿recordáis Metrica3?) o las planificaciones que nunca se cumplían para centrarnos en tareas de unos pocos días de duración que, una vez terminadas, aportaban por si mismas valor al proyecto desde el primer momento. Que permitían detectar rápidamente cambios en las especificaciones. Y que permitían que el equipo se adaptase rápidamente a esos cambios.

El problema que nos encontrábamos a veces en el enfoque clásico (el ciclo de vida en cascada), es que la resolución de un problema implicaba un incremento de costes que podía ser exponencialmente mayor en unas fases que en otras. Así, por cada unidad monetaria que te podías gastar en arreglar algo en las fases iniciales del proyecto, podías gastarte 1.000 veces más arreglando eso mismo si llegaba a producción sin ser detectado. Todo regado con un ciclo de vida poco flexible en el que la comunicación entre las partes no era suficientemente fluída. De esto, y de nada más, va XP.

¿Es XP tan maravilloso?

En mi opinión, puede que si, pero como siempre no todo es de color de rosa. XP es apropiado para algunos tipos de proyectos, pero tengo mis dudas de que lo sea para otros. Por ejemplo, un tipo de proyecto donde XP no es adecuado podría ser (aquí dejo volar mi imaginación) un sistema crítico de seguridad de una central nuclear donde los cambios de costo y refactorización pueden ser altísimos. O ciertos proyectos "legacy" donde su estructura no permite la aplicación de ciertos métodos o la rápida retroalimentación. Y por supuesto hay que tener en cuenta que muchos clientes demandan, sin posibilidad de negociar, una especificación de requisitos perfectamente detallada, inflexible y completa desde el principio.

Con esto no quiero generalizar, ni criticar XP, al revés: nuestro trabajo como ingenieros debería ser valorar diferentes escenarios y decidir qué solución es la más adecuada para cada uno, siempre basándonos en criterios técnicos y no en modas. XP aporta muchas bondades y un soplo de aire fresco frente al clásico waterfall. Pero también es cierto que en los últimos años, y con el auge de Agile, cada vez más equipos de desarrollo intentaron adoptar estas metodologías, a veces sin una comprensión clara de las implicaciones. Y lo que es peor: también se ha pretendido escalar a otros niveles de la organización sin haber llegado a esa comprensión antes. Por supuesto, dejando muchos cadáveres por el camino. A fin de cuentas, lo que hay detrás de metodologías como XP no es más que la necesidad de mejorar la comunicación entre el equipo de desarrollo y el resto del negocio. Y eso no es fácil, sino una dificultad añadida pero que nos ayudará a lograr la excelencia.

A veces divulgamos tecnologías o métodos que nos han funcionado muy bien, cayendo a veces en la creación inconsciente de dogmas. Este libro, a veces cae en ello, no hay que negarlo. Kent Beck, con todo el talento que tiene (es una figura clave e importantísima para nuestra industria), ejerce como buen estadounidense (/ironic/) vendiéndote aquello que a él le proporcionó un gran éxito en empresas como Chrysler. Incluso se apoya en una coautora especialista en psicología para alimentar y confirmar el énfasis que XP pone en la comunicación entre personas. Es decir: te lo cuenta muy bien, pero también te lo está vendiendo. No hay nada malo de ello, pero cuidado con acabar el libro creyendo que lo que cuenta es la única verdad posible.

Otra crítica que puedo hacer hacia XP es que, en mi opinión, se centra demasiado en las prácticas (uno de sus tres pilares fundamentales, en el libro lo describe más detalladamente). Esto puede hacer que dicha metodología acabe pecando de dogmática. Es cierto que plantea la introducción de dichas prácticas (una de las más famosas es la del Pair Programming) a modo de hipótesis, para decidir si son o no apropiadas para nuestro equipo. Pero seamos sinceros: la impresión que te llevas al acabar el libro es que si no eres capaz de llevar a cabo dichas prácticas, estás fracasando, o como mínimo "no llegando". De hecho, establece dos niveles: unas practicas que básicamente son esenciales, y otro nivel que sólo te recomienda cuando has conseguido dominar las primeras. Pero bueno, la realidad es que la mayor parte de las prácticas que propone están hoy tan consolidadas que son difícilmente discutibles.

Llegados a este punto no quiero que pienses que me he puesto a escribir esto para criticar XP. Sólo señalo lo que considero algunos de sus puntos débiles, que como ves no son tan graves. XP ha hecho aportaciones innegables que todavía hoy perduran: centrar sus prácticas en las relaciones interpersonales, la preocupación por el aprendizaje del equipo, la retroalimentación continua entre el cliente y el equipo del proyecto de desarrollo, la adaptación al cambio, el foco en los desarrolladores, el fomento de las buenas prácticas ... este libro fue absolutamente revolucionario, teniendo en cuenta que salió dos años antes del famoso manifiesto ágil. Estamos hablando de una metodología que comenzó aquí y que todavía hoy está vigentes. 20 años después.

Conclusión

Si quieres adentrarte en el mundo de Agile, es imprescindible conocer XP. Aunque hoy haya sido desplazado por otras metodologías más de moda, no descartes que vuelva a vivir otra época dorada porque no ha envejecido nada mal, y porque su influencia ha sido decisiva.

Si después de leer este libro quieres profundizar más, te puedo recomendar otros libros complementarios, pero creo que no debes empezar por otro que no sea "Extreme Programming Explained".

Libros para ir más allá:

• Kent Beck y Martin Fowler. Planning Extreme Programming. Reading, Addison Wesley, 2000.
• Agile Modeling: Effective Practices for Extreme Programming and the Unified Process. New York, John Wiley & Sons Inc. 2002.
• Fowler, M., Beck, K., Gilicze, B., Nagy, D., & Vlaskovitz, D. (1999). "Refactoring improving the design of existing code". Addison-Wesley.
• Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. James A. Highsmith. Addison-Wesley.
• “Agile Manifesto”. http://agilemanifesto.org/,

Algunos papers interesantes sobre el tema:

• Why Software Fails. Charette, R. N. (2005, 09).
• Get Ready for Agile Methods,with Care. Barry Boehm. University of Southern California.
• Challenges for Stakeholders in Adopting XP. Proc. 3rd International Conference on eXtreme Programming and Agile Processes in Software Engineering-XP in 2002.