Programación extrema, ¿Qué es? y ¿Cuándo utilizarla?

Ahora que constantemente vemos noticias «sorprendentes» sobre programadores en Twitter acostados junto a sus puestos de trabajo, no para de sorprenderme el revuelo que se monta con esto y las «manipulaciones e interpretaciones» sobre como debería ser el trabajo.

Horario flexible, teletrabajo 100%, sin presión ninguna… desayuno gratis y fiestas pagadas en la oficina los viernes por la tarde… Ah se me olvidaba!!! Un billar o un futbolín cerca por si me estreso.

Nada más lejos de la realidad; si el proyecto no sale, la empresa no cobra y si la empresa no cobra, tú tarde o temprano y tus sueños estáis en la calle, así de fácil y así de sencillo. No es lo ideal vivir y trabajar así, pero a veces es totalmente necesario; bien porque se negoció mal en la fase comercial y se aceptaron fechas imposibles, bien porque no se estimó correctamente la complejidad, el alcance o por otro medio millar de razones.

Llevo desde el año 1995 en este negocio y he visto muchas cosas, aunque la verdad, nunca paro de sorprenderme. Los proyectos idílicos existen sí, pero no es lo normal. Lo normal es que haya presión porque vivimos en un mundo competitivo donde todos luchan por sobrevivir e igual que un obrero tiene presión por construir una casa en un tiempo récord, un equipo de desarrollo lo tiene por el mismo motivo.

No quiero entrar en el tema generacional, que tambien, pero o entendemos que el dinero no crece de los árboles o lo mejor es que nos dediquemos a otra cosa… si es que existe algo en lo que nos paguen mucho por trabajar poco y vivir sin ninguna presión.

Dicho lo cual, diré que cíclicamente aparece un proyecto Killer en mi vida, es en lo que me he especializado por razones que no vienen al caso; en sacar cosas que parecen imposibles… y no suele haber dos escenarios iguales, aunque si pueden tener algunas similitudes. Variables como la tecnología, el ecosistema, el reclutamiento especializado, el equipo de desarrollo que gestionamos o la predisposición del cliente a ayudar en la meta común, son fundamentales.

El mundo AGILE o Predictivo es amplio y nos dan mucha herramientas para aplicar en función del caso (tambien combinarlas), pero en ocasiones, no hay más remedio que ir hacia lo disruptivo y aplicar las técnica más extremas. Este es el caso de XP, que aunque es cierto que siempre y por experiencia la he usado con variaciones, es sin duda la única vía para las situaciones más complejas a la hora de abordar un proyecto complejo con la máxima presión y todo en tu contra.

Hoy voy a explicar el deber ser de XP, pero en cualquier caso, y como todo método o metodología, debemos tomar de él lo que nos vale o lo que nos interesa y adaptarlo a nuestra situación. Nunca ahí que aplicar un método o metodología 100%, porque seguro que algo haremos mal y esto nos lastrará.

Sin más… empecemos:

Definición de XP

La Programación Extrema (XP) es un marco ágil de desarrollo de software que tiene como objetivo producir un software de mayor calidad, y una mayor calidad de vida para el equipo de desarrollo. XP es el más específico de los marcos ágiles en cuanto a las prácticas de ingeniería adecuadas para el desarrollo de software.

Cuando es aplicable Las características generales en las que XP es apropiado fueron descritas por Don Wells en: www.extremeprogramming.org:

• Requisitos de software que cambian dinámicamente
• Riesgos causados por proyectos de tiempo fijo que utilizan nuevas tecnologías
• Equipo de desarrollo ampliado, pequeño y ubicado en el mismo lugar
• La tecnología que se utiliza permite realizar pruebas funcionales y unitarias automatizadas
• Debido a la especificidad de XP cuando se trata de su conjunto completo de prácticas de ingeniería de software, hay varias situaciones en las que es posible que no desee practicar completamente XP.

While you can’t use the entire XP framework in many situations, that shouldn’t stop you from using as many of the practices as possible given your context.

Valores

Los cinco valores de XP son la comunicación, la sencillez, la retroalimentación, el valor y el respeto, y se describen con más detalle a continuación.

Comunicación

El desarrollo de software es intrínsecamente un deporte de equipo que se basa en la comunicación para transferir el conocimiento de un miembro del equipo a todos los demás. XP subraya la importancia del tipo de comunicación adecuado: la discusión cara a cara con la ayuda de una pizarra blanca u otro mecanismo de dibujo.

Simplicidad

Simplicidad significa «¿qué es lo más sencillo que puede funcionar?». Se trata de evitar el despilfarro y hacer sólo lo absolutamente necesario, como mantener el diseño del sistema lo más sencillo posible para que sea más fácil de mantener, soportar y revisar. La simplicidad también significa abordar sólo los requisitos que conoces; no intentes predecir el futuro.

Retroalimentación

Mediante la retroalimentación constante sobre sus esfuerzos anteriores, los equipos pueden identificar áreas de mejora y revisar sus prácticas. La retroalimentación también ayuda al diseño simple. El equipo construye algo, recoge comentarios sobre su diseño e implementación, y luego ajusta su producto de cara al futuro.

Coraje

Kent Beck definió la valentía como «la acción eficaz frente al miedo» (Extreme Programming Explained P. 20). Esta definición muestra una preferencia por la acción basada en otros principios para que los resultados no sean perjudiciales para el equipo. Se necesita valor para plantear cuestiones organizativas que reducen la eficacia del equipo. Se necesita valor para dejar de hacer algo que no funciona y probar otra cosa. Necesitas valor para aceptar y actuar en base a la retroalimentación, incluso cuando es difícil de aceptar.

Respetar

Los miembros de tu equipo deben respetarse mutuamente para poder comunicarse entre sí, proporcionar y aceptar comentarios que honren vuestra relación, y trabajar juntos para identificar diseños y soluciones sencillas.

Prácticas

El núcleo de XP es el conjunto interconectado de prácticas de desarrollo de software que se enumeran a continuación. Si bien es posible hacer estas prácticas de forma aislada, muchos equipos han encontrado que algunas prácticas refuerzan las otras y deben hacerse en conjunto para eliminar completamente los riesgos que a menudo se enfrentan en el desarrollo de software.

Las Prácticas XP han cambiado un poco desde que se introdujeron inicialmente. Las doce prácticas originales se enumeran a continuación. Si desea más información sobre cómo se describieron originalmente estas prácticas, puede visitar http://ronjeffries.com/xprog/what-is-extreme-programming/.

• El juego de la planificación
• Pequeños lanzamientos
• Metáfora
• Diseño simple
• Pruebas
  Refactorización
• Programación por parejas
• Propiedad colectiva
• Integración continua
• 40 horas semanales
• Cliente in situ
• Estándar de codificación

A continuación se presentan las descripciones de las prácticas tal y como se describen en la segunda edición de Extreme Programming Explained Embrace Change. Estas descripciones incluyen mejoras basadas en las experiencias de muchos que practican la programación extrema y reflejan un conjunto de prácticas más práctico.

Sentarse juntos

Dado que la comunicación es uno de los cinco valores de XP, y la mayoría de la gente está de acuerdo en que la conversación cara a cara es la mejor forma de comunicación, haga que su equipo se siente junto en el mismo espacio sin barreras para la comunicación, como las paredes de los cubículos.

Equipo completo

Un grupo interdisciplinario de personas con los roles necesarios para un producto forman un equipo completo. Esto significa que tanto las personas que tienen una necesidad como todas las que desempeñan algún papel en la satisfacción de esa necesidad trabajan juntas a diario para lograr un resultado específico.

Espacio de trabajo informativo

Organice el espacio de su equipo para facilitar la comunicación cara a cara, permitir que las personas tengan algo de privacidad cuando lo necesiten y hacer que el trabajo del equipo sea transparente para los demás y para las partes interesadas fuera del equipo. Utiliza los radiadores de información para comunicar activamente información actualizada.

Trabajo enérgico

Se es más eficaz en el desarrollo de software y en todo el trabajo de conocimiento cuando se está concentrado y libre de distracciones.

Trabajar con energía significa tomar medidas para asegurarse de estar física y mentalmente en un estado de concentración. Esto significa no trabajar en exceso (ni dejar que otros trabajen en exceso). También significa mantenerse sano, y mostrar respeto a tus compañeros de equipo para mantenerlos sanos.

Programación por parejas

La programación en parejas significa que todo el software de producción es desarrollado por dos personas sentadas en la misma máquina. La idea detrás de esta práctica es que dos cerebros y cuatro ojos son mejores que un cerebro y dos ojos. Se consigue una revisión continua del código y una respuesta más rápida a los problemas persistentes que pueden detener a una persona en seco.

Los equipos que han utilizado la programación por parejas han descubierto que mejora la calidad y que, en realidad, no se tarda el doble de tiempo porque son capaces de resolver los problemas más rápidamente y se centran más en la tarea que tienen entre manos, creando así menos código para lograr lo mismo.

Historias

Describen lo que el producto debe hacer en términos significativos para los clientes y usuarios. Estas historias pretenden ser descripciones breves de las cosas que los usuarios quieren poder hacer con el producto y que pueden utilizarse para planificar y servir de recordatorio para conversaciones más detalladas cuando el equipo se ponga a realizar esa historia en particular.

Ciclo semanal

El ciclo semanal es sinónimo de iteración. En el caso de XP, el equipo se reúne el primer día de la semana para reflexionar sobre el progreso hasta la fecha, el cliente elige las historias que quiere que se entreguen en esa semana y el equipo determina cómo abordará esas historias. El objetivo para el final de la semana es tener características probadas que realicen las historias seleccionadas.

La intención de este periodo de entrega es producir algo que se pueda mostrar al cliente para obtener su opinión.

Ciclo trimestral

El ciclo trimestral es sinónimo de lanzamiento. El propósito es mantener el trabajo detallado de cada ciclo semanal en el contexto del proyecto global. El cliente establece el plan general para el equipo en términos de características deseadas dentro de un trimestre en particular, lo que proporciona al equipo una visión del bosque mientras están en los árboles, y también ayuda al cliente a trabajar con otras partes interesadas que pueden necesitar alguna idea de cuándo estarán disponibles las características.

Recuerde que cuando se planifica un ciclo trimestral la información sobre cualquier historia en particular está a un nivel relativamente alto, el orden de entrega de la historia dentro de un ciclo trimestral puede cambiar y las historias incluidas en el ciclo trimestral pueden cambiar. Si puedes revisar el plan semanalmente después de cada ciclo semanal, puedes mantener a todos informados tan pronto como esos cambios se hagan evidentes para mantener las sorpresas al mínimo.

Slack

La idea detrás de la holgura en términos de XP es añadir algunas tareas o historias de baja prioridad en sus ciclos semanales y trimestrales que pueden ser abandonadas si el equipo se retrasa en tareas o historias más importantes. Dicho de otro modo, hay que tener en cuenta la variabilidad inherente a las estimaciones para asegurarse de que se tiene una buena oportunidad de cumplir con las previsiones.

Construcción en diez minutos

El objetivo de la construcción de diez minutos es construir automáticamente todo el sistema y ejecutar todas las pruebas en diez minutos. Los fundadores de XP sugirieron un marco de tiempo de 10 minutos porque si un equipo tiene una construcción que tarda más que eso, es menos probable que se ejecute con frecuencia, introduciendo así un mayor tiempo entre errores.

Esta práctica anima a su equipo a automatizar su proceso de construcción para que sea más probable que lo haga de forma regular y para utilizar ese proceso de construcción automatizado para ejecutar todas sus pruebas.

Esta práctica apoya la práctica de la Integración Continua y es apoyada por la práctica del Desarrollo Primero la Prueba.

Integración continua

La integración continua es una práctica en la que los cambios de código se prueban inmediatamente cuando se añaden a una base de código mayor. La ventaja de esta práctica es que se pueden detectar y solucionar los problemas de integración antes.

La mayoría de los equipos temen el paso de la integración del código debido al descubrimiento inherente de conflictos y problemas que resultan. La mayoría de los equipos adoptan el enfoque «Si duele, evítalo todo lo posible».

Los practicantes de XP sugieren «si duele, hazlo más a menudo«.

El razonamiento detrás de ese enfoque es que si se experimentan problemas cada vez que se integra el código, y se tarda en encontrar dónde están los problemas, tal vez se debería integrar más a menudo para que si hay problemas, sean mucho más fáciles de encontrar porque hay menos cambios incorporados en la construcción.

Esta práctica requiere un poco de disciplina adicional y depende en gran medida de Ten Minute Build y Test First Development.

Programar primero las pruebas

En lugar de seguir el camino normal de desarrollar código -> escribir pruebas -> ejecutar pruebas

La práctica de la Programación Primero las Pruebas sigue el camino de:

Escribir una prueba automatizada que falla -> ejecutar una prueba que falla -> desarrollar código para que la prueba pase -> ejecutar la prueba -> repetir

Al igual que con la integración continua, la programación basada en las pruebas reduce el ciclo de retroalimentación para que los desarrolladores identifiquen y resuelvan los problemas, disminuyendo así el número de errores que se introducen en la producción.

Diseño incremental

La práctica del diseño incremental sugiere que se haga un poco de trabajo por adelantado para comprender la perspectiva general adecuada del diseño del sistema, y que luego se entregue a los detalles de un aspecto particular de ese diseño cuando se entreguen características específicas. Este enfoque reduce el coste de los cambios y permite tomar decisiones de diseño cuando es necesario basándose en la información más actualizada disponible.

La práctica de la refactorización figuraba originalmente entre las 12 principales, pero se incorporó a la práctica del diseño incremental. La refactorización es una práctica excelente para mantener el diseño simple, y uno de los usos más recomendados de la refactorización es eliminar la duplicación de procesos.

Roles

Aunque la Programación Extrema especifica prácticas particulares para su equipo, no establece realmente roles específicos para las personas de su equipo.

Dependiendo de la fuente que leas, no hay ninguna orientación, o hay una descripción de cómo los roles que se encuentran típicamente en los proyectos más tradicionales se comportan en los proyectos de Programación Extrema. He aquí los cuatro roles más comunes asociados a la Programación Extrema:

El cliente

El papel del cliente es responsable de tomar todas las decisiones de negocio en relación con el proyecto, incluyendo:

• ¿Qué debe hacer el sistema (qué características se incluyen y qué logran)?
• ¿Cómo sabemos si el sistema está terminado (cuáles son nuestros criterios de aceptación)?
• ¿Cuánto tenemos que gastar (cuál es la financiación disponible, cuál es el argumento comercial)?
• ¿Qué debemos hacer a continuación (en qué orden entregamos estas características)?

Se espera que el cliente de XP participe activamente en el proyecto e, idealmente, que forme parte del equipo.

Se supone que el Cliente XP es una sola persona, sin embargo la experiencia ha demostrado que una sola persona no puede proporcionar adecuadamente toda la información relacionada con el negocio de un proyecto. El equipo debe asegurarse de que se obtiene una imagen completa de la perspectiva empresarial, pero debe contar con algún medio para tratar los conflictos en esa información, de modo que se pueda obtener una dirección clara.

El desarrollador

Debido a que XP no tiene mucha necesidad de definir roles, todos en el equipo (con la excepción del cliente y un par de roles secundarios que se enumeran a continuación) son etiquetados como desarrolladores. Los desarrolladores son responsables de realizar las historias identificadas por el cliente. Debido a que los diferentes proyectos requieren una combinación diferente de habilidades, y debido a que el método XP se basa en un equipo interdisciplinario que proporciona la combinación adecuada de habilidades, los creadores de XP no sintieron la necesidad de una mayor definición de roles.

El rastreador

Algunos equipos pueden tener un rastreador como parte de su equipo. A menudo se trata de uno de los desarrolladores que dedica parte de su tiempo cada semana a desempeñar este papel adicional. El propósito principal de este rol es llevar un registro de las métricas relevantes que el equipo considere necesarias para seguir su progreso e identificar áreas de mejora. Las métricas clave que su equipo puede seguir incluyen la velocidad, las razones de los cambios en la velocidad, la cantidad de horas extras trabajadas y las pruebas aprobadas y fallidas.

Esta función no es obligatoria para el equipo y, por lo general, sólo se establece si el equipo determina que es realmente necesario hacer un seguimiento de varias métricas.

El entrenador

Si su equipo está comenzando a aplicar XP, puede encontrar útil incluir un Entrenador en su equipo. Este es usualmente un consultor externo o alguien de otra parte de su organización que ha usado XP antes y es incluido en su equipo para ayudar a ser mentor de los otros miembros del equipo en las Prácticas de XP y para ayudar a su equipo a mantener su autodisciplina.

El principal valor del coach es que ha pasado por ello antes y puede ayudar a su equipo a evitar los errores que la mayoría de los equipos nuevos cometen.

Ciclo de vida

Para describir XP en términos de un ciclo de vida, probablemente sea más apropiado retomar el concepto de Ciclo Semanal y Ciclo Trimestral.
En primer lugar, hay que empezar describiendo los resultados deseados del proyecto haciendo que los clientes definan un conjunto de historias. A medida que se van creando estas historias, el equipo estima el tamaño de cada una de ellas. Esta estimación del tamaño, junto con el beneficio relativo estimado por el cliente, puede proporcionar una indicación del valor relativo que el cliente puede utilizar para determinar la prioridad de las historias.

Si el equipo identifica algunas historias que no puede estimar porque no comprende todas las consideraciones técnicas implicadas, puede introducir un pico para realizar una investigación centrada en esa historia en particular o en un aspecto común de varias historias. Los picos son breves plazos de tiempo que se reservan para investigar un aspecto concreto del proyecto. Los picos pueden producirse antes de que comiencen las iteraciones regulares o junto con las iteraciones en curso.

A continuación, todo el equipo se reúne para crear un plan de lanzamiento que todos consideren razonable. Este plan de lanzamiento es una primera aproximación a las historias que se entregarán en un trimestre o lanzamiento concreto. Las historias entregadas deben basarse en el valor que aportan y en consideraciones sobre cómo las distintas historias se apoyan entre sí.

A continuación, el equipo se lanza a una serie de ciclos semanales. Al principio de cada ciclo semanal, el equipo (incluido el cliente) se reúne para decidir qué historias se realizarán durante esa semana. A continuación, el equipo divide esas historias en tareas que deben completarse en esa semana.
Al final de la semana, el equipo y el cliente revisan los progresos realizados hasta la fecha y el cliente puede decidir si el proyecto debe continuar o si se ha aportado suficiente valor.

Los Orígenes

XP se utilizó por primera vez en el programa Chrysler Comprehensive Compensation (C3), que se inició a mediados de los 90 y se convirtió en un proyecto XP cuando Kent Beck se incorporó al proyecto para mejorar el rendimiento del sistema. Acabó añadiendo al equipo a un par de personas más, entre ellas Ron Jeffries, y cambiando la forma en que el equipo enfocaba el desarrollo. Este proyecto ayudó a poner de relieve la metodología XP y los diversos libros escritos por personas que participaron en el proyecto ayudaron a difundir el conocimiento y la adaptación de este enfoque.

Principales contribuciones

La principal contribución de XP al mundo del desarrollo de software es una colección interdependiente de prácticas de ingeniería que los equipos pueden utilizar para ser más eficaces y producir un código de mayor calidad. Muchos equipos que adoptan el enfoque ágil comienzan utilizando un marco diferente y cuando identifican la necesidad de prácticas de ingeniería más disciplinadas adoptan varias, si no todas, las prácticas de ingeniería propugnadas por XP.

Una contribución adicional, e igualmente importante, de XP es el enfoque en la excelencia de las prácticas. El método prescribe un pequeño número de prácticas absolutamente esenciales y anima a los equipos a realizar esas prácticas lo mejor posible, casi hasta el extremo. De ahí viene el nombre. No porque las prácticas en sí mismas sean necesariamente radicales (aunque algunos consideran que algunas de ellas son bastante extremas), sino porque los equipos se centran continuamente en mejorar su capacidad para realizar esas pocas prácticas.

Enlaces

• Extreme Programming: A gentle introduction. By Don Wells
• Extreme Programming Explained – Embrace Change 2nd Edition by Kent Beck
• Extreme Programming Pocket Guide by Chromatic