Recursos de Sergio PereaUna memoria USB que te puede salvar la vida | Sergio Perea

Recomendación: el libro "Extreme Programming Explained"

Extreme Programming Explained: Embrace Change

Descripción del libro

EditorialAddison-Wesley Professional
AutoresKent Beck, Cynthia Andres
Páginas189
ISBN978-0321278654
Puntuación4,0 / 5
ComprarComprar

Hace muchos años llegué a este libro por recomendación y en su momento 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 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 era 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.

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. Lo leí hace años, pero he vuelto a releerlo hace poco, con muchos conceptos ya 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. XP propone que la planificación de un proyecto se realiza en dos fases: 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. 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. Un "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.

Esto rompía con lo que a muchos nos habían enseñado en la universidad. Porque 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.

El problema que nos encontrábamos a veces en el enfoque clásico, es que la resolución de un problema implicaba un incremento de costes que podía ser expotenencialmente 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.

¿Es XP tan maravilloso?

En mi opinión, 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 estigmatizar 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. Y lamentablemente, pese a las bondades que aportan enfoques como XP, creo que esto no siempre ha sido así. 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.

Y el motivo no es otro que la forma en la que 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.

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). 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 es o no es apropiada 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. A mi esto me da un cierto tufillo a dogmático y gamificación que seguramente no sea malintencionado pero si malinterpretable por sus potenciales seguidores. Aunque es cierto que la mayor parte de las prácticas que plantea hoy están bastante consolidadas.

Pero 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 tampoco son tan graves. Al margen de esto, 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 un libro y una metodología que todavía hoy están 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. De hecho, todavía hoy se utiliza.

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.
x
Esta web hace uso de cookies únicamente con el objetivo de mejorar la experiencia de usuario y usabilidad de la web. Este aviso es un requisito legal que me obliga molestarte con detalles que te dan igual. Quiero saber más Acepto