Extreme Programming. No todo es Scrum

La Programación Extrema (Extreme Programming, en adelante XP) es una metodología ágil de desarrollo del software, muy orientada a equipos pequeños y medianos y centrada en mejorar la productividad a través del cambio social. Sobre todo en las relaciones interpersonales entre los miembros del equipo de desarrollo, algo que tradicionalmente se había convertido en un cuello de botella en la gestión de proyectos allá por los años 90, cundo el waterfall era el estándar de facto en empresas y universidades.

Desde que fuera "formulada por" Kent Beck, a través del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999), ha llovido mucho. Pero muchos de sus principios siguen vigentes 20 años después, y otros han influído de manera decisiva en el desarrollo de otras metodologías ágiles.

Personalmente me parece una metodología muy basada en las prácticas, algo rígida y que pone en cada momento demasiado en el centro la interacción actual. Pero a fin de cuentas, es una gran metodología de la que todavía hoy podemos sacar grandes enseñanzas.

Supon que es el año 2000, y escuchas hablar por primera vez de XP. ¿Por qué puede resultarte interesante? Aprendiendo los principios del XP, nos plantearemos dejar atrás hábitos y patrones del pasado para centrarnos en otros más orientados a la productividad, y en definitiva, en la creación de valor.

La dificultad inherente a este tipo de metodologías es que nos ayudan de tal manera a saber qué somos capaces de hacer, que lo tendremos que hacer. Y deberemos esperar lo mismo de otros miembros del equipo. Y eso implica trabajar de forma muy productiva, lo cual convertirá a los desarrolladores en mejores desarrolladores y a los equipos en mejores equipos.

Pero dejemos los eslóganes y hablemos de cosas más palpables. esto suena bonito pero no será posible sin trabajo duro orientado a la excelencia y sobre todo sin buenas relaciones interpersonales entre los miembros del equipo. XP le da a esto tanta importancia como al desarrollo en sí. ¡Vamos a ver cómo!

Elementos en los que se enfoca XP

XP nos proporciona una serie de herramientas orientadas a conseguir los objetivos ya expuestos. Podemos enumerar las más importantes:

• Técnicas de programación orientadas a la excelencia.
• Técnicas para que la comunicación entre los miembros del equipo sea lo más clara posible.
• Técnicas para enfocarse en el trabajo en equipo, y evitar las singularidades.
• Un claro enfoque en la comunicación enfocada al feedback, con énfasis en la simplicidad, el respeto y la creación de valor.
• Técnicas y principios que nos ayudarán a generar el valor.
• El control del riesgo a través de la entrega contínua y el feedback.
• La adaptación a cambio: el software cambia. Los requerimientos cambian. El diseño cambia. El equipo cambia. La tecnología cambia. Así que para XP el problema no debe ser el cambio, porque el cambio ocurre siempre. XP intenta mitigar el impacto del cambio adaptándose lo más rápidamente a él.

Los pilares de XP: valores, principios y prácticas.

XP se basa en tres pilares. Son como las patas de una banqueta: para no fracasar, ambos deben sujetar de forma conjunta nuestro desarrollo. Una pata sin las otras, no sujetará nada.

Las prácticas

Son las cosas que haces en tu día a día. Lo que diferencia a un buen profesional de un aficionado. Las prácticas nos dan un punto de partida. Y deben ser claras. Sin embargo por si solas son algo estéril. Deben alinearse fuertemente con los valores, que detallaremos más adelante. De momento quédate con que no sirve de nada hacer test sólo porque te lo mandan, sino porque crees en ello, y eso se traduce en que defiendes unos valores, en este caso, los del XP.

¿Por qué las prácticas deben estar alineadas con los valores? porque son demasiado concretas. Porque su aplicación varía en cada situación y debes ser capaz, en cada momento, de decidir qué práctica es adecuada. Intenta entender lo importante que es esto: si te quieres orientar a la perfección, no podrás si no tienes claros los objetivos y sabes qué prácticas debes aplicar para conseguirlos.

Kent Bexk en su "Extreme Programming Explained" ya proponía una serie de prácticas, no sin antes plantearte que las usaras como hipótesis, que experimentaras para ver de qué manera te ayudaban y decidieras en consecuencia. Son además prácticas que interactúan bien entre ellas, de modo que puedes ir escalando en tu día a día introduciéndolas y midiendo resultados para decidir si las adoptas. Ya las han hecho otro antes y funcionan, de modo que puedes tener cierta garantía de que aplicarlas te dotará de nuevas habilidades y experiencia.

Las prácticas básicamente se dividen en dos tipos:

• Prácticas primarias: se trata de aquellas prácticas que puedes comenzar a introducir de forma segura cuando comienzas a experimentar con XP.
• Prácticas "corolario": son aquellas prácticas que se pueden aplicar cuando se dominan las prácticas primarias. De lo contrario, serán complicadas de introducir.

Pero ¿cómo decidir qué prácticas introducir?

Un buen ejercicio puede ser el de hacer un mapa mental de prácticas. En medio de cada diagrama ponemos el nombre de la práctica. Y alrededor cualquier cosa que se te ocurra en relación a esa práctica: ventajas, inconvenientes, signos de que algo no va bien cuando la estás aplicando, etc.Pair ProgrammingVentajasMenos bloqueosLas ideas quedan más clarasAmbos programadores se mantienen centradosLogros a nivel personalMe sube la moralSi soy novato en una tecnoogía, aprendoConozco mejor a mis compañerosInconvenientesDifícil valance trabajo / vida personal porque dependo de otroDifícil de hacer en remotoNo puedo medir la productividad individualCoste personalConflictosCiertas tareas prefiero hacerlas soloEs cansado enseñar a otroMejor control de calidad (dos ojos ven más que uno)

Es conveniente que este ejercicio lo hagan todos los miembros del equipo de cara a consensuar qué prácticas llevar a cabo.

Más adelante nos adentraremos en prácticas concretas de XP, pues no tiene sentido detallarlas sin abordar antes la cuestión de los valores y principios.

Los valores

son aquello que determina qué nos gusta y no nos gusta en cada situación. En XP los valores que se fomentan son:

• Simplicidad para desarrollar sólo aquello que se necesita. Parece algo trivial, pero se trata del valor que requiere más esfuerzo intelectual de todos los valores de XP. Pero ojo, simplicidad no es simpleza. Simplicidad no va sólo de hacer cosas simples sino de eliminar la complejidad residual que sólo embarra nuestro proyecto. Este valor pretende complementar a los demás.
• Comunicación entre todos los participantes del proyecto, trabajando todo el equipo en un lugar común si es posible y manteniendo reuniones cara a cara con los clientes para entender mejor cualquier gesto o impresión de clientes y miembros del equipo. Es quizás el valor más importante para que un equipo de desarrollo funcione. La comunicación es importante para crear sentido de equipo y conseguir que la cooperación sea efectiva.
• Feedback entre miembros del equipo y clientes. El cliente recibe entregas funcionales del proyecto y las usa para poder dar su opinión sobre lo que ya se ha hecho y lo que falta por hacer. Este valor es necesario desde el momento en el que establecemos que XP debe ayudarnos a adaptarnos al cambio. Y si el cambio es inevitable, la necesidad de feedback es automática. Cuando más rápido sea ese feedback, más rápido nos adaptaremos a los cambios. El feedback puede tener sentido a muchos niveles:
  • ¿qué opciones tengo para resolver esto?
  • ¿qué pinta tiene mi código?
  • ¿funcionan mis test?
  • ¿cómo funciona mi sistema una vez está desplegado?Es importante, no obstante, controlar el exceso de feedback, pues las chorraditas nos pueden hacer perder el foco de lo importante. Es por eso que para que este valor funcione, también debe funcionar bien el anterior (la comunicación).
• Coraje para introducir mejoras en el código o rechazar el que no juzguemos adecuado. Un lema muy extendido entre desarrolladores es «Si funciona no lo toques«, en XP se busca una mejora contínua y se ha de tener coraje para modificar todo aquello que sepamos que mejorará el estado actual y futuro del proyecto en desarrollo. El coraje puede tomar muchas formas: puede manifestarse en forma de acción ante un problema que sabemos resolver, o de paciencia ante un problema que todavía no sabemos cómo abordar. El coraje por sí solo puede ser peligroso, si no se complementa con el resto de valores de XP, porque nos aboca a dar palos de ciego o correr en círculos sin llegar a ninguna parte. El equipo debe confiar plenamente en sus valores para poder asumir el coraje necesario para afrontar el proyecto.
• Respeto: Realmente los valores anteriores son la base para el verdadero valor global. Parece obvio, pero es necesario remarcarlo para entender el por qué de otros valores: somos humanos, con nuestra limitaciones, nuestra cultura y nuestras inquietudes. Debemos ser capaces de trabajar por el bien común salvando nuestras diferencias.
• Y muchos otros: XP no limita sus valores a los que enuncia Kent Beck en su libro, sino que deja abierta la posibilida de que cada empresa cree sus propios valores complementarios siempre que tengan como objetivo apoyar a los principales que ya he enunciado. Y sobre todo deben ser valores con los que todos los miembros del equipo puedan alinearse.

Los principios

Los cuatro valores XP que he enunciado anteriormente son criterios que tienen como objetivo alcanzar una solución satisfactoria al problema. Sin embargo se trata de conceptos demasiado vagos para ayudarnos a decidir qué prácticas se llevarán a cabo. Muchas empresas se centran demasiado en los valores y dedican largos documentos y comunicados para intentar transmitirlos al equipo. Acribillar al equipo a documentación sobre valores no es la mejor manera de difundirlos, y sin embargo todavía hoy hay empresas empeñadas en hacerlo así. XP propòne definir una serie de principios que ayuden a cumplir con los valores de la metodología. Los principios, por tanto, son más concretos que los valores. Hay una serie de principios fundamentales:

• Retroalimentación rápida: el tiempo transcurrido entre una acción y su retroalimentación es crucial en el proceso de aprendizaje. Se ha de obtener retroalimentación sobre toda acción realizada, interpretarla y reflejar en el sistema lo aprendido tan rápido como sea posible.
• Humanidad: a menudo, el desarrollo del software no está alineado con las necesidades de las personas que integran el equipo, su fragilidades y su fortalezas. A menudo se plantea el trabajo en equipo como si cada individuo fuera igual al siguiente, como las piezas de un mecanismo de relojería. Una parte muy importante del trabajo en equipo es el balanceamiento de las necesidades individuales de cada miembro que lo compone, porque si sólo les exigimos sacrificios el equipo acabará siendo disfuncional.
• Economía: Al producir software, también se debe producir valor para el negocio. Dos aspectos de la economía son la clave para XP:
• valor actual: un euro hoy, vale más que un euro mañana, por lo que el desarrollo de software más temprano, hace ganar dinero y hacerlo más tarde hace gastar dinero, cuanto más pronto sea, mayor será la ganancia que dará.
• El valor de las opciones. el valor actual está relacionado con el valor de las opciones. Si puedes aplazar las inversiones de diseño hasta que tu necesidad sea obvia, eso será valioso para el negocio. Prácticas de XP, como el diseño incremental, se centran en el valor de negocio para el cliente, y el pago por uso (pay-per-use) facilita aplazar o diferir las decisiones.
• Beneficio mutuo: Este es quizás el principio más importante de XP y sin embargo el más complicado de conseguir. Simplemente consiste en asumir que hay planteamientos que pueden solucionar problemas a una persona y creárselos a otra. Este tipo de soluciones son frecuentes cuando se actúa de forma desesperada, ante un "incendio". Un ejemplo de algo que viola el principio del beneficio mutuo es escribir documentación extensa o el exceso de burocracia. XP cuenta con mecanismos para detectar y corregir violaciones de este principio entre desarrolladores de un mismo equipo como:
  • El TDD. Escribir test automatizados no sólo me ayuda como punto de partida para escribir una funcionalidad sino que además ayuda a otros programadores en el futuro a la hora de comprenderla y modificarla.
  • La refactorización, con el objetivo de eliminar la complejidad accidental, elimina también la deuda técnica. El código resultante será más fácil de leer por otros.
  • El estándar de codificación se basa en elegir nombres intuitivos y coherentes para los diferentes elementos.
  • En definitiva, toda práctica que te ayude a resolver más problemas de los que creas.
• Autosimilitud: en definitiva se trata de aplicar la misma naturaleza fractal que utiliza la naturaleza para crear estructuras a diferentes escalas. Se trata de ser capaces de replicar una solución óptima a un problema en otro problema de naturaleza similar, adaptando la escala. Un ejemplo de este patrón lo tenemos en TDD: escribir pruebas que fallan, y luego escribir el código que pasa exitosamente el test. Esto es cierto también en la gestión del proyecto utilizando escalas de tiempo diferentes: en un trimestre, se listan los temas a resolver, y luego escribir las historias (stories) que los describen; en una semana, se listan historias para poner en práctica, se escriben los tests de aprobación, y, finalmente, escribir el código para que el testeo funcione, en pocas horas, ya se escribieron los tests (pruebas) unitarios, y luego el código capaz de hacer que funcionen.
• Asumir simplicidad: se ha de tratar cada problema como si pudiera ser resuelto de un modo ridículamente simple. Generalmente se desarrolla pensando en el futuro, en reusar las funcionalidades. En XP se aprende a resolver los problemas del presente, asumiendo que si en el futuro hay nuevos requisitos seremos capaces de resolverlos eficientemente.
• La mejora contínua: la mejora continua es la clave para XP. Se basa en intentar alcanzar la perfecciónd e forma iterativa, asumiendo que dicha perfección no existe. Todos los días nos esforzaremos por hacerlo lo mejor posible, y también en pensar qué hacer para realizarlo aún mejor, mañana. En la práctica, en cada iteración del sistema se mejorará en calidad y funcionalidades, utilizando la información (feedback) del cliente, a partir de pruebas (test) automatizadas y del propio equipo
• Diversidad: en un equipo donde todos los individuos son iguales, a lo mejor esto no tendŕia sentido. Pero esto nunca ocurre. Los equipos reales incluyen diferentes niveles de conocimiento, habilidades y personalidades, para poder descubrir y resolver problemas. Esto, evidentemente, es una potencial fuente de conflictos que generarán un esfuerzo extra a la hora de ser gestionados. Sin embargo debemos entender que tener diferentes opiniones y proponer soluciones diferentes es muy útil en el desarrollo de software, siempre y cuando, sean capaces de gestionar los conflictos y elegir la mejor alternativa.
• Reflexión: un equipo eficaz no se limita a hacer su trabajo. Se preguntan cómo están trabajando, y por qué están trabajando de esa manera. Tienen que analizar las razones del éxito - o el fracaso - sin ocultar errores, porque si no no podrán aprender de ellos. Debe haber iteraciones trimestrales y semanales, en las que el equipo se tomará tiempo para reflexionar acerca de cómo se está ejecutando el proyecto, y cuáles son las posibles mejoras. Sin embargo, este proceso no debe comerse nuestro tiempo: la reflexión debe venir después de la acción, y antes de la siguiente acción, para ser útil.
• Flujo: flujo significa desarrollar constantemente software que genera valor, realizando todas las actividades de desarrollo de forma simultánea. Las prácticas de XP suponen un flujo continuo de actividades, no una secuencia de fases diferentes como en el ciclo de desarrollo en cascada.. Sólo el flujo continuo permite la retroalimentación (feedback) para asegurar que el sistema está evolucionando hacia la dirección correcta, y evita los problemas relacionados con la integración final.
• Oportunidad: los problemas deben ser vistos como una oportunidad para mejorar. Siempre se presentan problemas, pero si nuestro equipo está orientado a la excelencia, no se puede limitar solamente corregir los problemas. Es necesario convertir dichos problemas en oportunidades de mejora. Por eso no se hacen planificaciones a largo plazo sinoq ue se trabaja en base a interacciones cortas, complementadas con interacciones cada tres meses en las que se planifica a más largo plazo.
• Redundancia: si los problemas críticos y difíciles deben resolver los enfocamos de varias maneras diferentes, cuando una solución falle, las otras van a prevenir un desastre. Hay técnicas que nos ayudan a buscar, encontrar y corregir los defectos de software: pair programming, TDD, la participación activa del cliente en el proyecto, etc.
• Cambio incremental: los grandes cambios hechos simultáneamente pueden derivar en un sistema que no funcione. Cualquier problema se puede resolver mediante una serie de pequeños cambios. Todo en XP debe evolucionar mediante pequeños cambios, incluso la adopción de la metodología por parte de un equipo.
• Abrazando el cambio: la mejor estrategia es la que preserva la mayoría de las opciones mientras que realmente soluciona el problema más apremiante.
• Orientación a la calidad De las cuatro variables que rigen el desarrollo de software, alcance, coste, tiempo y calidad, la calidad no es una variable totalmente libre. En XP sólo puede tomar dos valores, «excelente» o «insultantemente excelente». De otro modo los miembros del equipo no pueden disfrutar con su trabajo, no trabajarán bien y el proyecto tiende al fracaso.

Kent Beck, de cara a explicar la relación entre principios, valores y prácticas, establece la metáfora de un puente. El puente son los principios, que conectan los