Está familiarizado con las metodologías ágiles, pero la Programación Extrema (XP) sigue siendo un misterio para usted. Suena, bueno, extremo, y no estás seguro de que sea para ti. Sin embargo, no dejes que el nombre te disuada. Se perdería un montón de cosas buenas. Este artículo le explicará todo lo que necesita saber sobre la programación extrema para que usted también pueda aprovecharla.

¿Qué es la programación extrema (XP)?

La programación extrema es una metodología de desarrollo de software que forma parte de lo que se conoce colectivamente como metodologías ágiles. XP se basa en valores, principios y prácticas, y su objetivo es permitir que equipos pequeños y medianos produzcan software de alta calidad y se adapten a los requisitos cambiantes y en evolución.

Lo que diferencia a XP de las demás metodologías ágiles es que hace hincapié en los aspectos técnicos del desarrollo de software. La programación extrema es precisa sobre cómo trabajan los ingenieros, ya que seguir las prácticas de ingeniería permite a los equipos entregar código de alta calidad a un ritmo sostenible. La programación extrema consiste, en pocas palabras, en las buenas prácticas llevadas al extremo. Como programación en parejas es buena, hagámosla siempre. Ya que las pruebas tempranas son buenas, probemos antes de escribir el código de producción.

Breve historia de la programación extrema

El origen de XP se remonta a los años 90, cuando Kent Beck -que más tarde se convertiría en uno de los autores del Manifiesto Ágil — lo creó al ser contratado para dirigir el equipo del Sistema de Compensación Integral de Chrysler.

El proyecto había comenzado en 1993 y en 1996 no había avanzado mucho. Como Beck era nuevo en la gestión de un equipo, decidió que lo mejor sería enseñar a los miembros de su equipo las técnicas y prácticas que a él le funcionaban. Empezaron a aplicar prácticas como la programación por parejas y el TDD con gran éxito. Ron Jeffries -un amigo de Beck y otro autor del Manifiesto Ágil- fue contratado para entrenar al equipo de C3. En 1999, Kent Beck formalizó las prácticas, principios y valores de XP en su libro Extreme Programming Explained: Embrace Change

Cómo funciona la programación extrema (XP)?

XP, a diferencia de otras metodologías, es muy opinable en lo que respecta a las prácticas de ingeniería. Además de las prácticas, XP se basa en valores y principios. Los valores proporcionan un propósito a los equipos. Actúan como una «estrella del norte» para guiar sus decisiones en un alto nivel. Sin embargo, los valores son abstractos y demasiado difusos para una orientación específica. Por ejemplo: decir que se valora la comunicación puede dar lugar a muchos resultados diferentes. Las prácticas son, en cierto modo, lo contrario de los valores. Son concretas y realistas, y definen lo que hay que hacer. Las prácticas ayudan a los equipos a responsabilizarse de los valores. Por ejemplo, la práctica de los espacios de trabajo informativos favorece una comunicación transparente y sencilla. Los principios son directrices específicas del sector que salvan la distancia entre las prácticas y los valores.

Image Src: LucidCharts

Valores de XP

Los valores de XP: comunicación, sencillez, retroalimentación, valor y respeto. Veamos cada uno de ellos con más detalle.

Image Src: Alexsoft.com

Comunicción: La falta de comunicación impide que los conocimientos fluyan dentro de un equipo. A menudo, cuando hay un problema, alguien ya sabe cómo resolverlo. Pero la falta de comunicación les impide conocer el problema o contribuir a su solución. Así, el problema acaba resolviéndose dos veces, generando residuos.

Simplicidad: La simplicidad dice que siempre hay que esforzarse por hacer lo más sencillo que funcione. A menudo se malinterpreta y se interpreta como lo más sencillo y punto, ignorando la parte de «que funciona».

También es crucial recordar que la simplicidad es muy contextual. Lo que es sencillo para un equipo, es complejo para otro, dependiendo totalmente de las habilidades, la experiencia y los conocimientos de cada equipo.

Retroalimentación: La retroalimentación en las metodologías de desarrollo de software más tradicionales, tipo cascada, a menudo es «demasiado pequeña, demasiado tarde».

XP, sin embargo, adopta el cambio y los equipos de XP se esfuerzan por recibir una retroalimentación temprana y constante. Si es necesario corregir el rumbo, los XPers quieren saberlo lo antes posible.

Image src: extremeprogramming.org

La retroalimentación viene en muchas formas y tamaños. Cuando se está programando en pareja, los comentarios de los compañeros son una retroalimentación vital. También lo son las opiniones de otros miembros del equipo sobre una idea, incluido el cliente que, idealmente, es un miembro del equipo. Los exámenes son otra fuente de valiosa retroalimentación que va más allá de los resultados de las pruebas. Si escribir pruebas es fácil o difícil también es una retroalimentación. Si te cuesta escribir pruebas, probablemente tu diseño es demasiado complejo. Escuche la retroalimentación y simplifique su diseño. Algo que parece una gran idea puede no funcionar tan bien en la práctica. Por tanto, el código terminado también es una fuente de retroalimentación, al igual que un producto desplegado. Por último, hay que tener en cuenta que existe el exceso de comentarios. Si un equipo genera más feedback del que puede manejar, el feedback importante puede desaparecer del radar. Es esencial frenar y averiguar qué causa el exceso de feedback y solucionarlo. Valor: Kent Beck define la valentía como «una acción eficaz frente al miedo». Como ingeniero de software, tienes muchas cosas que temer y, por tanto, muchas oportunidades de mostrar coraje. Hace falta valor para decir la verdad, sobre todo la desagradable, por ejemplo, las estimaciones honestas. También hay que ser valiente para dar y recibir información. Y hace falta valor para no caer en la falacia del coste hundido y descartar una solución fallida que ha recibido importantes inversiones. Respeto: Una premisa fundamental de XP es que todos se preocupan por su trabajo. Ninguna cantidad de excelencia técnica puede salvar un proyecto si no hay cuidado y respeto. Toda persona es digna y respetada, y eso incluye, por supuesto, a las personas afectadas por un proyecto de desarrollo de software. Cuando usted y los miembros de su equipo se respetan y se preocupan por los demás, por el cliente, por el proyecto y por sus futuros usuarios, todos ganan.

Principios de XP

Los principios proporcionan una orientación más específica que los valores. Son directrices que iluminan los valores y los hacen más explícitos y menos ambiguos.

Image src: extremeprogramming.org

Por ejemplo, basándose únicamente en el valor del coraje, se podría llegar a la conclusión de que es aconsejable abordar un gran cambio de una vez en el programa. Sin embargo, el principio de los pasos de bebé nos dice que los grandes cambios son arriesgados. Por lo tanto, hay que favorecer los pequeños. Humanidad: Los humanos crean software para los humanos, un hecho que a menudo se pasa por alto. Pero tener en cuenta las necesidades básicas, los puntos fuertes y los puntos débiles de los humanos crea productos que los humanos quieren utilizar. Y un entorno de trabajo que te da la oportunidad de lograr y crecer, el sentimiento de pertenencia y la seguridad básica, es un lugar donde es más fácil tener en cuenta las necesidades de los demás.

Economía: En XP, los equipos prestan atención a las realidades económicas del desarrollo de software todo el tiempo, evalúan constantemente los riesgos económicos y las necesidades del proyecto.

Por ejemplo, implementan las historias de usuario en función de su valor comercial y no de las preocupaciones técnicas.

Beneficio mutuo: Siguiendo a XP, se evitan las soluciones que benefician a una parte en detrimento de otra. Por ejemplo, las especificaciones extensas pueden ayudar a otra persona a entenderlo, pero te aleja de la implementación y lo retrasa para tus usuarios.

Una solución mutuamente beneficiosa es utilizar pruebas de aceptación automatizadas. Tú obtienes un feedback inmediato sobre tu implementación, tus colegas obtienen especificaciones precisas en el código y los usuarios obtienen sus características antes. Además, todos ustedes obtienen una red de seguridad contra las regresiones.

Autosimilaridad: Si una solución determinada funciona en un nivel, también podría funcionar en un nivel superior o inferior. Por ejemplo, la obtención de una retroalimentación temprana y constante está en juego en varios niveles de la XP.

a nivel de desarrollador, los programadores reciben información de su trabajo utilizando el enfoque de «primero la prueba»;
a nivel de equipo, el pipeline de integración continua integra, construye y prueba el código varias veces al día;
a nivel de la organización, los ciclos semanales y trimestrales permiten a los equipos obtener información y mejorar su trabajo según sea necesario.

Mejora: Según el principio de mejora, los equipos no buscan la perfección en una implementación inicial, sino una suficientemente buena, para luego aprender y mejorarla continuamente con la retroalimentación de los usuarios reales. Diversidad: Usted y sus compañeros de trabajo se benefician de la diversidad de perspectivas, habilidades y actitudes. Esta diversidad suele generar conflictos, pero eso está bien. El conflicto y el desacuerdo son oportunidades para que surjan mejores ideas cuando todos se rigen por los valores del valor y el respeto. Valor para expresar puntos de vista opuestos, respeto para expresarlos de forma civilizada y empática. Y todo ello es un ejercicio de comunicación eficaz. Reflexión: Los grandes equipos reflexionan sobre su trabajo y analizan cómo ser mejores. XP ofrece muchas oportunidades para ello. No sólo en sus ciclos semanales y trimestrales, sino en cada práctica que promueve. Es importante tener en cuenta los sentimientos, además del análisis lógico. Tu instinto puede informarte antes de que puedas razonar sobre algo. Y lo mismo puede ocurrir al hablar con personas no técnicas, que pueden hacer preguntas que abren posibilidades totalmente nuevas. Flujo: Las metodologías tradicionales de desarrollo de software tienen fases discretas, que duran mucho tiempo y tienen pocas oportunidades de retroalimentación y corrección del curso. En cambio, el desarrollo de software en XP se produce en actividades que ocurren todo el tiempo, en un «flujo» consistente de valor. Oportunidad: Los problemas son inevitables en el desarrollo de software. Sin embargo, cada problema es una oportunidad de mejora. Aprenda a verlos de esa manera y tendrá muchas más probabilidades de encontrar soluciones creativas y orientadas a los objetivos que también sirvan para evitar que vuelvan a ocurrir. Redundancia: El principio de redundancia dice que si un problema determinado es crítico, hay que emplear muchas tácticas para contrarrestarlo. Por ejemplo, los defectos. No hay una sola táctica que pueda evitar que todos los defectos se escapen a la producción. Así que la solución de XP es apilar un montón de medidas de calidad. Programación en parejas, pruebas, integración continua. Cada una de ellas es una línea de defensa, y juntas forman un muro prácticamente impenetrable.

Fracaso: El fracaso no es un desperdicio cuando se traduce en conocimiento. Actuar y aprender rápidamente lo que no funciona es mucho más productivo que la inacción causada por la indecisión de elegir entre muchas opciones.

Calidad: A menudo la gente piensa que hay un dilema entre calidad y velocidad.

Es todo lo contrario: impulsar las mejoras de calidad es lo que te hace ir más rápido.

Por ejemplo, la refactorización -cambiar la estructura del código sin alterar su comportamiento- es una práctica que facilita la comprensión y el cambio del código. Como resultado, es menos probable que se introduzcan defectos en el código, lo que permite ofrecer más valor antes al no tener que arreglar los errores.

Pasos de bebé: Los grandes cambios son arriesgados. XP mitiga ese riesgo realizando los cambios en pequeños pasos, a todos los niveles.

Los programadores escriben el código en pequeños pasos utilizando el desarrollo dirigido por pruebas. Integran su código a la línea principal varias veces al día, en lugar de hacerlo cada pocas semanas o incluso meses. El proyecto en sí se desarrolla en ciclos cortos, en lugar de en fases de larga duración.

Responsabilidad aceptada: En XP, la responsabilidad debe ser aceptada, nunca asignada.

La responsabilidad debe ir acompañada de la autoridad para tomar decisiones sobre lo que se es responsable. Lo contrario también se aplica. No quieres que la gente tome decisiones si no tiene que vivir con sus consecuencias.

Similitudes y diferenciadores

¿En qué se diferencia XP de las metodologías tradicionales no ágiles? La programación extrema, que forma parte de Ágil, consiste en aceptar y dar la bienvenida al cambio en lugar de seguir planes rígidos. Se trata de un diseño iterativo en lugar de un gran diseño por adelantado. XP se diferencia radicalmente de las metodologías tradicionales -por ejemplo, la cascada- al evitar las fases de larga duración.

En lugar de una fase de planificación, en XP se planifica al principio de cada ciclo de desarrollo, que suele durar sólo una semana.
En lugar de probar episodios, se prueba la aplicación en cuanto se puede: es decir, antes de implementar el código real.
En lugar de implementar características de forma aislada durante las largas fases de implementación y luego luchar para fusionar sus contribuciones a la línea principal, se trabaja en pequeños trozos y se integran esos trozos tan a menudo como sea posible.

¿En qué se diferencia XP de las demás metodologías Ágiles?

La programación extrema, por naturaleza, tiene mucho en común con las demás metodologías ágiles, pero también es única entre ellas. La mayoría de las otras metodologías de desarrollo no dicen mucho, si es que dicen algo, sobre cómo hacer el trabajo.. XP, por el contrario, es muy exigente en este sentido y pone gran énfasis en las prácticas de ingeniería de software.

Programación Extrema vs. Scrum

Scrum es un marco de trabajo para ayudar a los equipos a desarrollar proyectos complejos de manera adaptativa. Scrum no dicta cómo los desarrolladores hacen el trabajo. XP, como se ha mencionado, pone mucho énfasis en las buenas prácticas de programación.

Además, XP es obviamente sobre la programación. Scrum, en cambio, puede aplicarse a cualquier proyecto que se beneficie de un enfoque iterativo. XP acepta cambios en sus componentes. A los equipos se les permite e incluso se les anima a ajustar las prácticas de acuerdo a sus necesidades específicas. La Guía de Scrum, por otro lado, es inflexible al afirmar que «Si bien es posible implementar sólo partes de Scrum, el resultado no es Scrum». Además, Scrum es un marco de trabajo que hay que completar con metodologías y prácticas para hacer el trabajo. Eso significa que no sólo es posible utilizar XP y Scrum juntos, sino que es extremadamente recomendable.

Funciones y responsabilidades clave

Según Kent Beck, un equipo de XP maduro no debería depender de roles rígidos, pero reconoce que los roles pueden ser útiles para los equipos principiantes, hasta que empiezan a obstaculizar la colaboración.

Dicho esto, hay algunos roles comunes que la gente asocia con XP:

Cliente: lo ideal sería que hubiera un cliente real in situ para responder a las preguntas, priorizar las historias de usuario o colaborar con las pruebas de aceptación. Cuando esto no es posible, este papel podría ser desempeñado por un representante del cliente.
Programadores: en un equipo de XP, los programadores estiman el esfuerzo necesario para completar las tareas y las historias, escribir las pruebas automatizadas e implementar las historias.
Entrenador: Tener un entrenador no es necesario, y muchos equipos han logrado el éxito sin uno. Sin embargo, tener a alguien con experiencia en XP para entrenar a un equipo puede asegurar que los miembros del equipo sigan las prácticas, las conviertan en hábitos y no vuelvan a las viejas costumbres.
Rastreador: Un rastreador hace un seguimiento de las métricas de progreso del equipo y habla con cada miembro del equipo para identificar los obstáculos y encontrar soluciones. El rastreador calcula las métricas que indican lo bien que lo está haciendo el equipo, como los gráficos de velocidad y burndown, o el equipo utiliza un tablero digital de scrum o kanban que las calcula automáticamente.

Métodos y técnicas

Los métodos y las técnicas son las prácticas de XP. Se dividen en tres grupos principales: ingeniería de software, entorno de trabajo y gestión de proyectos. Empecemos por las prácticas relacionadas con la ingeniería de software.

Ingeniería de software

Programación en parejas: En XP, se escribe el código en parejas sentados en una máquina. Usted y su pareja hablan entre sí mientras analizan, implementan y prueban la función en la que están trabajando. La programación en parejas es especialmente eficaz para producir código con menos defectos, a la vez que resulta atractiva, divertida y agotadora.

Diez minutos de construcción: Se espera que el servidor de integración continua construya todo el proyecto – incluyendo la ejecución de todas las pruebas automatizadas – en diez minutos como máximo. Este límite sirve para que las pruebas sean escasas y malignas, es decir, para que se centren en el proyecto. Programación basada en pruebas: En XP, usted implementa sus características utilizando el enfoque de «primero las pruebas», también llamado desarrollo dirigido por pruebas (TDD):

escribes una prueba que falla;
entonces, escribe el código de producción para hacer que la prueba pase;
si es necesario, refactoriza el código de producción para hacerlo más limpio y fácil de entender

El TDD aporta varias ventajas.

En primer lugar, la retroalimentación. Si es difícil escribir una prueba, el diseño que vas a hacer o que has heredado, es probablemente demasiado complejo, y tienes que simplificarlo. En segundo lugar, TDD permite a los programadores confiar en el código que escriben, y crea un ritmo agradable y cíclico en el que el siguiente paso está siempre claro. Por último, pero no menos importante, el uso de TDD desde el principio garantiza una cobertura del código del 100%. El conjunto de pruebas se convierte entonces en una verdadera red de seguridad para futuros cambios, fomentando la refactorización del código y creando un círculo virtuoso de calidad. Diseño incremental: La práctica del diseño incremental significa que hay que invertir en el diseño de la aplicación todos los días, buscando oportunidades para eliminar duplicidades y hacer pequeñas mejoras llegando al mejor diseño posible para lo que el sistema necesita hoy. Integración continua: En XP, usted integra su trabajo al repositorio principal compartido muchas veces al día, activando una construcción automática de todo el sistema. Integrar tan pronto y tan a menudo como sea posible reduce drásticamente el coste de la integración, ya que hace menos probable que se produzcan conflictos de fusión y lógicos. También expone los problemas de entorno y de dependencia. Código compartido (propiedad colectiva): XP promueve el código compartido, o propiedad colectiva: cada desarrollador es responsable de todo el código. Fomenta el intercambio de información, reduce el factor de autobombo del equipo y aumenta la calidad general de cada módulo si tenemos en cuenta el principio de diversidad. Código base único: La base de código única también se conoce como «desarrollo basado en el tronco». Significa que sólo hay una única fuente de verdad. Así, en lugar de desarrollar de forma aislada durante largos periodos de tiempo, se fusionan las contribuciones al tronco único de forma temprana y frecuente. Las banderas de características ayudan a mantener restringido el uso de las mismas mientras no estén completas. Despliegue diario: Desplegar a producción al menos una vez al día es una consecuencia lógica de la integración continua:. En realidad, hoy en día, muchos equipos van más allá y practican el despliegue continuo. Es decir, cada vez que alguien se fusiona con la línea principal, la aplicación se despliega a producción. Código y pruebas: Esta práctica significa que el código fuente -incluyendo las pruebas- es el único artefacto permanente de un proyecto de software. Dedicar esfuerzos a generar otros tipos de artefactos, incluida la documentación, suele ser un desperdicio porque no genera valor real para el cliente. Si necesita otros artefactos o documentos, esfuércese por generarlos a partir del código de producción y las pruebas. Análisis de la causa raíz: Siempre que un defecto se cuele en producción, no te limites a corregirlo. Asegúrese de entender qué lo causó en primer lugar, por qué usted y sus compañeros de equipo no pudieron evitar el deslizamiento. A continuación, tome medidas para asegurarse de que no vuelva a ocurrir.

Ambiente de trabajo

Sentarse juntos: En XP, los equipos prefieren trabajar juntos en un espacio abierto. Esta práctica favorece la comunicación y el sentido de pertenencia en un equipo. Equipo completo: Todos los que son necesarios para el éxito del proyecto forman parte del equipo de XP. Esto es altamente contextual – diferente para cada equipo – y dinámico, puede cambiar dentro de un equipo. Espacios de trabajo informativos: Un espacio de trabajo informativo utiliza el espacio físico del equipo para mostrar información que permita a cualquiera conocer, de un vistazo, el progreso del proyecto. La forma de hacerlo puede variar, desde notas y gráficos físicos hasta pantallas que muestren tableros Kanban y cuadros de mando de un software de gestión de proyectos. Trabajo energizado: En XP, se trabaja sólo mientras se puede hacer trabajo energizado. Las horas de trabajo deben limitarse a 40 a la semana, como máximo.

Gestión de proyectos

Historias: Los requisitos del usuario se escriben en un formato conocido como historias de usuario. Una historia de usuario tiene un nombre corto y descriptivo y también una breve descripción de lo que se va a implementar. Slack: Cuando se planifica un ciclo, se añaden tareas menores que el equipo puede abandonar en caso de que lo necesite. Siempre se pueden añadir más historias si el equipo se excede. Ciclos (trimestrales y semanales): El desarrollo en XP ocurre en dos ciclos principales: el ciclo semanal y el ciclo trimestral. Más sobre esto en la siguiente sección. Reuniones clave, ciclos, cadencias de entrega: El desarrollo en XP funciona en dos ciclos principales: el ciclo semanal y el ciclo trimestral. Inicialmente, Kent Beck recomendaba un ciclo de dos semanas, pero lo cambió en la segunda edición de su libro. Ciclo semanal: El ciclo semanal es el «pulso» de un proyecto XP. El ciclo comienza con una reunión en la que el cliente elige qué historias quiere implementar durante la semana. Además, el equipo revisa su trabajo, incluyendo el progreso de la semana pasada, y piensa en cómo mejorar su proceso. Ciclo trimestral: Cada trimestre, el equipo reflexiona e identifica oportunidades de mejora en su proceso. El cliente elige uno o más temas para ese trimestre, junto con las historias de estos temas.

¿Cómo empezar con XP?

Las habilidades técnicas y los hábitos de XP pueden ser difíciles de aprender. Algunas de las prácticas pueden resultar extrañas para los programadores que no están acostumbrados a ellas. Para empezar con XP, los equipos pueden adoptar una práctica principal a la vez. Para decidir por dónde empezar, decida cuál es el próximo objetivo que quiere alcanzar. Elija la práctica que se alinee con ese objetivo. Por ejemplo, si su equipo necesita construir un sentido de confianza, tanto en el código como en los otros miembros del equipo, comience con la programación en pares y el TDD. Si necesitas eliminar el riesgo asociado a depender demasiado de miembros específicos del equipo, adopta la propiedad colectiva del código.

Más información

La programación extrema explicada: Abrazar el cambio
¿Qué es la programación por parejas?
¿Qué es la metodología Scrum?
¿Qué es la metodología Ágil?

Una cuestión que suele rondar por la cabeza de los equipos es el coste de la adopción de las prácticas de XP: esto es cierto sólo a (muy) corto plazo, y los beneficios a medio y largo plazo superarán con creces los costes.

Ir eXtremo con XP – el Ágil de los Desarrolladores.

La mayoría de los marcos y metodologías ágiles se centran en la gestión de proyectos o productos y en la organización de las personas y el trabajo.

XP es único en el sentido de que pone de relieve las buenas prácticas que otras metodologías ágiles dejan como ejercicio para el usuario. Ese es usted. Significa que XP es compatible con otras metodologías y nos atrevemos a decir que adoptar un marco ágil sin utilizar también XP no es óptimo. Eso es porque sin las prácticas que le ayuden a entregar valor a un ritmo constante y sostenible, su código será cada vez menos complaciente con el cambio y finalmente terminará en un atolladero no susceptible de cambio. Así que pásate a eXtreme y empieza a adoptar XP. Es el Ágil de los desarrolladores el que mantendrá a todos ágiles.

¿Qué es la programación extrema (XP) y sus valores, principios y prácticas?

Agile 101

Introducción a la programación extrema (XP)