Por Manuel Perez
XP es mi intento de reconciliar humanidad y productividad en mi práctica de desarrollo de software, y compartir esa reconciliación. He empezado a darme cuenta de cuánto más humanamente me trato a mí mismo, y a otros más productivos somos todos. - Kent Beck.
Cuando empecé a escuchar el termino de XP, no pude evitar pensar en el clásico hacker, encerrado en su sótano programando a un velocidad sin igual, usando técnicas prohibidas solo al alcance de unos cuantos privilegiados.
Nada más lejos de la realidad. XP se enfoca en mejorar las relaciones humanas para que esta mejora se refleje en el código, reduciendo los cuellos de botella y haciendo entregas más frecuentes. Así que sí, podríamos decir que al final trabajas más rápido, pero muy lejos de la fantasía del hacker que tenía en mi cabeza.
Podemos decir que XP, con una serie de valores, principios y prácticas que ponen su foco en el corazón de la máquina, trata de reconciliar la humanidad y la productividad, aplicando técnicas para prepararse y enfrentar el cambio de forma ágil. Se basa principalmente en mejorar los ciclos de feedback y aportar valor continuamente.
En este post, trataré de resumir escuetamente los valores, principios y prácticas de XP.
Una de las historias que cuenta en su libro Kent Beck, es muy ilustrativa a cómo se entiende el desarrollo de software dentro de XP.
Kent Beck nos cuenta la vez que fue con su madre para aprender a conducir. Su madre conducía y él estaba en el asiento del copiloto. Su madre le pidió que cogiera el volante para que notara lo que se siente al sostenerlo. Ella soltó el volante y Kent se despistó por un instante, saliéndose ligeramente de la carretera y las ruedas pasaron por encima de la grava del arcén. Su madre, que cogió el volante y recuperó el rumbo del coche tranquilamente, le dijo a Kent:
Conducir no va solo sobre llevar el coche en la dirección correcta. Conducir es prestar atención constantemente, haciendo una pequeña corrección aquí y alguna corrección allá.
Este es el paradigma de XP. Estar atento. Adaptarse. Cambiar.
Los valores principales en XP son comunicación, simplicidad, feedback, coraje y respeto entre otros, y son la base que justifica las prácticas. Necesitamos hacer estos valores explícitos a la hora de trabajar con las prácticas, ya que de otra manera, las prácticas se deteriorarían rápidamente. Por ejemplo, practicamos pair programming porque valoramos la comunicación y el feedback rápido. Esto es necesario recordarlo a menudo para no perder el rumbo hacia donde vamos.
La mayoría de problemas dentro de un equipo, vienen dados más por una falta de comunicación que por una falta de conocimiento técnico. Probablemente ya exista gente dentro del equipo que conozca la solución a ese problema, o por lo menos, tenga la suficiente orientación como para solucionarlo.
Por otra parte, la comunicación es importante para crear pertenencia al grupo y una mejor colaboración.
Hacer un sistema simple que cumpla los requerimiento de hoy es difícil. Buscar siempre esta simplicidad es uno de los valores principales en XP, que trata de evitar el desperdicio de recursos en un futuro no muy lejano.
La necesidad de feedback es una de las piedras angulares de XP. Este feedback, se usa para alcanzar poco a poco, ese ideal de perfección que el equipo tiene sobre la dirección a donde quiere ir, así como adaptarse al cambio lo más rápido posible.
Ver un problema dentro de un equipo, señalarlo y tomar acción requiere coraje. No todos los equipos tienen una cultura blameless, o están abiertos a una mejora continua, e incluso a veces en aquellos que sí tienen esta cultura, sigue siendo difícil aplicar una solución a un problema. Esto no quiere decir que haya que actuar sin medir las consecuencias. El coraje individual no tiene sentido si no está alineado con el equipo y con otros valores.
Este es el valor más importante en XP. Si los miembros del equipo no tienen respeto entre ellos y por lo que hacen, XP no funcionará. Todos somos seres humanos que hacen software y todos somos capaces de aportar valor a un equipo. Personalmente, me cuesta imaginar equipos donde no se respete este valor, ya que tengo la percepción de que no me he encontrado en esta situación, pero no hay que ser ingenuo. Hay que saber que hay equipos con grandes disfunciones, luchas de ego, faltas de respeto, poco cuidado del código… Como ya hemos señalado, si no hay respeto, XP no puede funcionar.
Los principios, nacen de la necesidad de reducir el nivel de abstracción y hacer de puente entre valores y prácticas. Un ejemplo bastante ilustrativo del libro nos cuenta: los documentos tienen la intención de comunicar así como una conversación. ¿Qué es más efectivo? La respuesta depende en parte en del contexto, y en parte de principios. En este caso, el principio de humanidad sugiere que una conversación, satisface la necesidad de conexión. Por tanto, es la forma preferida de comunicación.
Las personas son las que desarrollan software. En muchos entornos de trabajo, a menudo se ignoran las necesidades humanas y se ponen por encima las necesidades de negocio. Este principio, nos invita a equilibrar estas necesidades, así como equilibrar las necesidades individuales de cada persona y las necesidades del equipo.
¿Qué necesitan las personas?
Este principio parte de la necesidad de pagar las cuentas. Alguien tiene que hacerlo, por lo tanto, hay que asegurarse de que lo que se hace, aporta valor al negocio.
Este es el principio más importante de XP. Siempre hay una solución a un problema que perjudica a otra. El negocio del desarrollo es un negocio de personas y trabajar en mantener esas relaciones es importante. Beneficio mutuo en XP es buscar prácticas que me beneficien ahora, a mí más tarde y a mi cliente.
Este principio se refiere a la implementación de mismas soluciones a diferentes niveles. Por ejemplo, en el caso de la obtención de feedback a varios niveles, tanto en el más bajo como la implementación de unit tests como la de reuniones semanales.
En XP no existe la palabra perfecto si no el verbo perfeccionar. Hacer lo mejor que puedas hoy sabiendo que tienes que hacer para mejorar un poco mañana.
Aquellos equipos donde todos tienen el mismo background y hay demasiada comodidad no son efectivos. Los equipos necesitan una variedad de habilidades, actitudes y perspectivas para enfrentar los problemas. Con la diversidad llega el conflicto y con el conflicto viene la confrontación de ideas. Se trata de ver la confrontación no como algo desagradable sino como una oportunidad para encontrar una mejor solución.
Este principio se basa en el análisis de cómo trabaja el equipo y por qué están trabajando de esa manera para así depurar y mejorar procesos y herramientas.
Este principio se basa en la entrega constante de valor en vez de las gigantes entregas de antaño donde se desplegaba una o pocas veces al año.
Es la actitud de ver los problemas como oportunidades. Cada problema es un reto y una oportunidad para el crecimiento personal, mejorar las relaciones y mejorar el software.
En XP la redundancia es un principio clave ya que muchas prácticas están encaminadas a prevenir el desastre y estos sobre costes están más que pagados si logra evitar estos desastres. Pair programming, testing, integración continua entre otras prácticas añaden coste al proceso de desarrollo pero previenen de continuos fuegos que apagar. Esto no quiere decir que sean una bala de plata, pero sin duda ayudan a prevenir el grueso de los errores que puedan llegar a producción.
Este principio nos invita a fallar si no estamos teniendo mucho éxito. El fracaso no es un desperdicio si viene acompañado de aprendizaje.
Los proyectos no avanzan más rápido aceptando una calidad menor y no van más lento por tener mayor calidad. Apostar por más calidad a menudo resulta en entregas más rápidas. No hay límites a los beneficios de la calidad, solo límites en nuestra habilidad de entender cómo alcanzar un nuevo nivel de calidad.
La calidad tampoco es un factor puramente económico, las personas también necesitan hacer un trabajo de que sientan orgullo.
Es muy tentador hacer grandes cambios de golpe. Tenemos mucho que hacer en poco tiempo y esto es peligroso. Grandes pasos nos hacen ser inflexibles ante el cambio. Es mejor aplicar 5 pasos con coste 5 que aplicar un solo paso que cueste 20 ya que el riesgo de llegar a un punto equivocado es demasiado grande. Esto nos permite ver de donde venimos y a donde vamos ajustando la dirección en caso de que sea necesario.
La responsabilidad no puede ser asignada, solo aceptada. Con la responsabilidad viene la autoridad y no queremos que las personas tomen decisiones si no van a vivir con las consecuencias.
En esta sección veremos las principales prácticas usadas en XP. En palabras de Kent Beck, si las prácticas no están respaldadas por valores, estas se pudren. Las personas necesitan saber cuales son los fundamentos de las prácticas. Que estas tienen un propósito y no son un capricho de iluminados que tienen la verdad. Eventualmente todas las prácticas flaquean de una manera u otra, y cuando llegue ese momento el equipo tiene que recordar los valores para poder mantenerlas.
Esta práctica se refiere a priorizar el desarrollo en espacios colaborativos así como priorizar las comunicaciones a ser posible cara a cara. Con está práctica el equipo ganará en comunicación, humanidad y sentido de pertenencia.
Por lo general se suelen ver equipos especializados, es decir, un equipo de front, otro de back, diseño, sistemas… Esta práctica nos sugiere hacer equipos que sean capaces de terminar una historia de principio a fin. Equipos que concentren gran diversidad de perspectivas gracias a un background profesional diferente, lo que se conoce como equipos verticales.
Con esta práctica se pretende generar espacios de trabajo abiertos que favorezcan la comunicación cara a cara así como mejorar la comunicación con respecto al proyecto usando kanban u otros medios que comuniquen su estado. También se recomienda tener espacios más privados donde se pueda trabajar en solitario o tener reuniones.
Otro punto importante es que es posible conocer el estado general de un proyecto observando su espacio de trabajo y cuales son los valores que lo construyen. En el trabajo remoto obtener esa clase de información es más complicado ya que perdemos las sutilezas del trato en situ y es uno de los retos al que nos enfrentamos como consultoría.
Trabaja siendo productivo tanto tiempo como sea sostenible. Esta práctica anima a los desarrolladores a cuidarse a si mismos buscando un flujo de trabajo enfocado sostenible y libre de distracciones. Quemarse trabajando más horas no beneficia al equipo, ni a la empresa y mucho menos al propio trabajador así como tampoco beneficia a nadie trabajar enfermo.
Una de las prácticas estrella. Alabada y criticada a partes iguales. Dos personas haciendo una misma tarea, por lo tanto duplicando el coste por tarea. A ojos de cualquier persona esto es una locura a nivel presupuestario. Sin embargo, el coste de evitar el desastre es un coste que con gusto deberíamos pagar.
Las ventajas de esta prácticas son muchas mejorando la comunicación, teniendo ciclos de feedback cortos, conocimiento compartido entre los miembros del equipo, aprendizaje mutuo, más enfoque en la tarea, ideas más claras, mejor diseño a raíz de las discusiones sobre la tarea, reducción de la frustración entre otras.
Hay que tener en cuenta que hacer pair programming es agotador, ya que no solo estamos pensando en encontrar una solución a un problema, sino que estamos comunicándolo con nuestra pareja y además está pasando un filtro de calidad en el que tiene que haber un consenso para aplicar la solución.
Esta práctica nos invita a generar historias que sean comprensibles por los usuarios. Esto nos dará un punto de partida que mejorará la comunicación entre los stake holders y los desarrolladores. Una vez escrita esta historia de usuario se pueden hacer split técnicos que separen la historia en varias historias técnicas que usen lenguaje de desarrollo listas para ser implementadas.
Se trata de la clásica reunión a principio de un sprint en el que se repasa el progreso del anterior sprint y se seleccionan nuevas historias que implementar. Estos ciclos no tienen que ser obligatoriamente de una semana, se puede adaptar a las necesidades de los equipos.
Con la implementación de estos ciclos se pretende generar un flujo de entrega continuo y hacer retrospectiva sobre el equipo.
Con estos ciclos se pretende identificar cuellos de botella en el proceso de desarrollo, especialmente aquellos generados fuera de los equipos de desarrollo, hacer retrospectiva, planear siguiente ciclo. Todo esto se hace con una visión de conjunto de la organización y ver dónde encajan y cómo interactúan los equipos entre si.
Un problema que suele surgir a menudo en los equipos es comprometerse con más de lo que pueden entregar. Esto genera un clima de desconfianza difícil de revertir. Lo que nos propone esta práctica es reservar una serie de tareas sencillas para añadir al quaterly cycle que en caso de que las principales tareas no sean capaces de salir a tiempo, al menos estas tareas más sencillas lo puedan hacer.
Esto es un ideal, una meta a la que aspirar. Los largos builds and deploys de horas nos alejan del feedback que necesitamos por tanto con esta práctica lograremos reducir los ciclos de feedback y si logramos automatizarlo reduciremos una gran fricción.
Una de las prácticas favoritas que nos sugiere generar sistemas que integren a partir de la ejecución exitosa de una batería de tests sólida. Hay dos estilos de integración, asíncrona en el que la integración se ejecuta, por ejemplo, una vez al día e integración síncrona, en el que la integración se ejecuta después de una acción del desarrollador, push o merge a una rama, por ejemplo.
Otra de las prácticas estrellas donde encajaría TDD. Como su propio nombre indica se trata de invertir el flujo normal de desarrollo empezando por desarrollar tests en rojo para después implementar código productivo que hagan pasar estos tests.
Entre las ventajas de esta práctica podemos destacar identificación de problemas de acoplamiento y cohesión (si es muy difícil de testear es posible que haya problemas de diseño), confianza en el código y ritmo ya que hacer el test nos hace pensar y replantear el problema lo que nos ayuda con el flujo de desarrollo obteniendo entregas constantes.
Esta práctica nos sugiere trabajar en el diseño en todos los pasos del desarrollo. En el pasado se sugería empezar con un diseño definido antes de empezar a programar y tener muy claro que features iban a ser incluidas en la aplicación con el fin de evitar cambios muy costosos a mitad de desarrollo.
El tiempo ha demostrado inviable este enfoque ya que el cambio es natural en los desarrollos de software. El principal de motivo de cambio surge de los propios stake holders y otro motivo es el conocimiento adquirido a través del propio desarrollo.
Entonces empecemos con un diseño mínimo que se ajuste a nuestras necesidades y evolucionemos el sistema según vayan apareciendo nuevas necesidades.
Estas son una serie de prácticas que se recomiendan explorar después de implementar y afianzar las prácticas primarias. De otra manera puede ser contraproducente para el equipo. Por ejemplo, si no conseguimos un ratio de errores cercano a cero, usando prácticas como Pair Programming o Test-First, sería peligroso implementar la práctica de Daily Deployment.
Involucrar a los propios clientes puede aportar mucha información al equipo de desarrollo entendiendo sus necesidades y motivaciones a la hora de usar su producto. Es una práctica difícil de implementar ya que es muy difícil implicar a personas fuera del equipo/empresa a que dediquen su tiempo ya sea con entrevistas o encuestas y además hay posibilidades de que la información recabada no sea del todo fiable debido al bajo nivel de compromiso.
Esta práctica nos dice que es demasiado arriesgado hacer grandes deploys de una sola pieza. En vez de eso, nos propone partir la aplicación en módulos que puedan ser desplegables con independencia.
En este negocio es muy común que las personas roten de empleo habitualmente en busca de un salario mejor. También es común que en las empresas se vean a los trabajadores como piezas reemplazables que pueden mover de aquí allá sin consecuencias. Esta práctica nos invita a mantener los equipos que funcionan en el tiempo. Eso no quiere decir que sean totalmente estáticos, pero que no haya una constante entrada y salida de personas.
Esta práctica nos dice que según vaya aumentando la eficiencia de los equipos estos se pueden ir reduciendo siempre en busca de una optimización de recursos.
Cada vez que se encuentre un error en producción, elimina el defecto y su causa. El objetivo no buscar culpables sino que el error no vuelva a ocurrir. Para el análisis después de la corrección del error el autor recomienda la técnica de los 5 por qué.
Todas las personas deberían tener la oportunidad de mejorar cualquier parte del código. Esta práctica solo puede llevarse a cabo cuando en el equipo existe una sensación de responsabilidad compartida con el código.
Con esta práctica lo que se pretende conseguir es que se traten al código y a los tests como una descripción de lo que hace el sistema, es decir, es la documentación más cercana a la realidad. Podemos tener una documentación para explicar qué es lo que está pasando en el sistema o por el contrario podemos trabajar en aumentar la claridad del código y los tests para eliminar desperdicios. Esta en mi opinión es una de las prácticas más difíciles donde se necesitan un set de habilidades muy depurado así como mucha experiencia en el dominio, código limpio y arquitectura.
Simplemente nos sugiere que la ramificación del código no viva mas de unas horas y mucho menos que existan muchas versiones en paralelo de un mismo producto.
Cuanto más trabajo exista en el escritorio de un desarrollador que no esté en producción más riesgo existe. Esta práctica nos invita a reducir el tiempo de deployment a una vez al día.
Negociar el tiempo, coste y alcance del sistema que estamos desarrollando reduce los riesgos ya que invita a los involucrados en el desarrollo a comunicar sus expectativas e inquietudes y es una buena herramienta para alinearse.
Quedan muchas aristas que refinar para entender todo lo que significa XP. Aquí solo hemos podido rascar la superficie y quedan muchos conceptos en el libro que no he podido explicar aquí, una parte porque no he resonado con ellos y otra parte por falta de entendimiento de todo lo que significan.
Como todas las grandes obras, siempre es bueno revisitarlas cada cierto tiempo para seguir descubriendo y absorbiendo conceptos que en otros momentos pasamos por alto.
¿Quieres más? te invitamos a suscribirte a nuestro boletín para avisarte cada vez que recopilemos contenido de calidad que compartir.
Si disfrutas leyendo nuestro blog, ¿imaginas lo divertido que sería trabajar con nosotros? ¿te gustaría?
Pero espera 🖐 que tenemos un conflicto interno. A nosotros las newsletter nos parecen 💩👎👹 Por eso hemos creado la LEAN LISTA, la primera lista zen, disfrutona y que suena a rock y reggaeton del sector de la programación. Todos hemos recibido newsletters por encima de nuestras posibilidades 😅 por eso este es el compromiso de la Lean Lista
