Extreme Programming

Introducción

Tal y como lo define Kent Beck, eXtreme Programming (XP) es un método ágil para el desarrollo de software muy útil a la hora de abordar proyectos con requisitos vagos o cambiantes. Es especialmente útil si se aplica a equipos de desarrollo pequeños o medianos. Se ajusta muy bien a los cambios pues es un método adaptativo. Propone desarrollar el código de forma que su diseño, arquitectura y codificación permitan incorporar modificaciones y añadir una funcionalidad nueva sin demasiado impacto en la calidad del mismo. Por otro lado está muy orientado hacia las personas, tanto a las que están creando el proyecto como a los usuarios finales. Desarrollando de la manera que propone XP se obtienen resultados rápidamente. Al trabajar con pequeñas iteraciones, se pueden conseguir con frecuencia comentarios del cliente, que tiene como resultado que el producto final cubra ampliamente sus expectativas y necesidades. Muchas de las prácticas que propone este método de programación no son en absoluto nuevas; lo novedoso de XP reside en su propuesta de aplicar las prácticas de forma simultánea y que se realimenten entre ellas. Algunas son técnicas que se han aplicado con éxito anteriormente y han resultado valiosas. El catálogo de prácticas de XP sigue evolucionando a lo largo de los años, poco a poco, se han ido incorporando más prácticas.

Orígenes

XP empezó a gestarse como método en los años 80 con Kent Beck y Ward Cunningham cuando trabajaban en un proyecto utilizando SmallTalk, que es un lenguaje de programación orientado al público en general y no sólo a informáticos especializados. La filosofía de este lenguaje se basa en elementos como la programación en parejas, refactorización, adaptación al cambio, integración frecuente, desarrollo iterativo, pruebas constantes, y sobre todo, una frecuente comunicación con el cliente. Algunos autores afirman que XP es la cultura de trabajo de SmallTalk ampliada a otros entornos de programación. Se fueron incorporando más prácticas entre las que cabe destacar el desarrollo dirigido por pruebas, Test Driven Development (TDD). Kent Beck publicó el libro Extremed Programming Explained en 1999 en el que incorporaba a las prácticas puramente de programación, numerosos conceptos de Scrum para fortalecer así la convivencia del desarrollo de software con algunos conceptos de gestión de equipos. En el año 2004 publicó la segunda edición del libro anterior para reflejar esta constante evolución. Para XP las pruebas son la base de la construcción y propone que sean los desarrolladores los que escriban las pruebas a medida que van construyendo el código y se realice una integración continua, de forma que el software creado tenga gran estabilidad. Las pruebas automáticas se realizan de forma constante para poder detectar los fallos con la mayor rapidez posible. Antes de cada iteración se planifica el trabajo que va a realizarse y a continuación se realizan de forma simultánea el análisis, el desarrollo, el diseño y las pruebas de código.

Ciclo de vida

En numerosas ocasiones se atribuye el fracaso de los proyectos a la poca definición de requisitos, o a un mal diseño de la arquitectura de un sistema al inicio del proyecto. El método de XP propone potenciar estas actividades, la forma de trabajar es definiendo los requisitos, arquitectura y diseño cada día, y no en un periodo de tiempo determinado y acotado. XP apuesta por simultanear las fases y llevarlas a cabo en paralelo para que, de este modo se vaya adaptando el producto y el sistema a las necesidades según van surgiendo. Cada semana se realiza un ciclo completo o iteración en la que se aborda algo de cada una de las fases tradicionales de un desarrollo software, trabajando con las historias de usuario, que son requisitos que dan valor al cliente. Cada semana se planifica en qué historias trabajar y se llevan a cabo de forma completa con su análisis, diseño, pruebas y desarrollo. Al final de la semana se podrá mostrar al cliente el resultado de la funcionalidad obtenida para que pueda formarse una opinión sobre ella.

Planificación

Las historias más prioritarias se implementarán en primer lugar. Por otra parte, el equipo planificará al inicio de cada semana la manera de abordar la siguiente iteración de forma detallada. De igual manera, el equipo organizará cada día el trabajo para esa jornada. En resumen, se planifica al inicio del proyecto, de cada iteración y aún más detalladamente, todos los días.

Análisis

Para que el análisis se mantenga actualizado durante todo el proyecto, los clientes y las personas que están construyendo el proyecto debe estar en comunicación constante; pues en el momento en que un desarrollador tenga dudas sobre cómo implementar un requisito, debe poder preguntar al cliente. A su vez, se debe trabajar en estrecha colaboración con los responsables de pruebas y de diseño gráfico para que no quepa ambigüedad en los requisitos.

Diseño y codificación

XP propone trabajar de manera que, tanto el diseño como la arquitectura se creen de forma incremental. De esta manera, se mejora el diseño y la arquitectura poco a poco y de forma constante.

Control de versiones

Por otra parte, los desarrolladores deben utilizar un sistema de control de versiones para la gestión de la configuración y mantener actualizado su entorno de desarrollo y otras prácticas como son usar estándares de código, prácticas de integración, etc. Cabe decir que XP propone constantemente técnicas para acercarse a la excelencia técnica. Una de estas prácticas más conocidas es TDD, que permite realizar de manera simultánea el diseño, las pruebas, la arquitectura y la codificación.

Pruebas

Es uno de los pilares sobre los que se fundamenta XP. Deben llevarse a cabo a todos los niveles y todos los implicados en un proyecto deben contribuir a su elaboración. Los desarrolladores construyen el código a la vez que lo prueban, ya que utilizando TDD se están realizando pruebas completas de código. Por su parte, los usuarios realizan pruebas de aceptación. En ocasiones, una parte del equipo está dedicado a realizar pruebas más amplias y completas, de otra manera, el mismo equipo de desarrollo se encargaría de ellas. Prácticas como la programación en parejas contribuyen al aseguramiento permanente de la calidad de lo que se está desarrollando.

Despliegue

La forma de construir el producto con XP hace posible que, al terminar cada semana, el software obtenido pueda ser puesto en producción, pues la funcionalidad comprometida está asegurada. Aunque esto no significa que se realicen entregas frecuentemente al cliente, éstas se realizarán siguiendo un plan de entregas establecido.

¿Dónde aplicar XP?

Ocurre en ocasiones que las condiciones de entorno de trabajo, la organización o el tipo de proyecto no facilitan aplicar la práctica que XP propone. La aplicación de XP da por hecho que existe una predisposición por parte de las personas implicadas en un proyecto y sin la cual, es imposible que se adopten sus prácticas con éxito. A fin de cuentas, la aplicación de las prácticas de XP depende más de las personas implicadas que del tipo de proyecto. Existen una serie de premisas, como exponen Shore y Warden en el libro The Art of Agile Development, que deben cumplirse para poder trabajar de esta manera.

• Apoyo de los responsable de la empresa. La disposición del entorno de trabajo es muy difícil de llevar a cabo sin el apoyo de los responsables de la empresa donde se trabaja.
• Compromiso del equipo. Si el equipo al completo no confía en la potencia de XP, la recomendación es que no debe aplicarse.
• Cercanía del equipo. Muchas de las prácticas que XP recomienda llevan implícito que el equipo trabaje junto.
• Cliente cercano. Es imprescindible el trabajar de forma cercana con el cliente y poder consultarle cualquier duda relacionada con la funcionalidad que se esté desarrollando. Puede delegarse esta responsabilidad a otra persona con capacidad para tomar este tipo de decisiones. A este embajador del cliente se le llama Proxy.
• Tamaño correcto del equipo. La recomendación habitual es que el equipo completo esté compuesto por no más de 12 personas. En el caso de equipos muy grandes es necesario buscar el modo de escalar la aplicación de XP.
• Aplicar todas las prácticas. XP está concebido de manera que se ha tratado de eliminar todo aquello que es superfluo. Sabiendo esto, se debe tener cautela a la hora de decidir dejar de aplicar algunas de sus prácticas y el impacto en el resultado final.

Los Valores

Estos son los 5 valores que guían el desarrollo en XP:

• Comunicación. La comunicación entre los desarrolladores y a su vez con el cliente, es la mejor forma de evitar la mayoría de problemas y errores. Hay muchas formas de comunicarse, como un código simple y bien escrito que permita que cualquier desarrollador pueda entender el código desarrollado por otro miembro del equipo. Por otra parte a la hora de resolver un problema, siempre es mejor pensar la solución entre muchos que individualmente.
• Simplicidad. No es sencillo construir un sistema sencillo y que cumpla exactamente con los requisitos establecidos. Muchas veces la forma de simplificar un sistema es mediante ensayo y error. Construir de forma sencilla disminuye la cantidad de código y aumenta su calidad.
• Feedback. Se entiende como una combinación de comentarios, reacciones, sugerencias, opiniones, etc. Es necesario poder conocer siempre cómo de cerca está el producto que se está construyendo de lo que realmente se necesita. Además de la imprescindible comunicación con el cliente, otra herramienta para obtener información sobre el sistema, son los test automáticos que ayudan a revisar el estado del código y facilitan la detección de posibles fallos producidos por cambios.
• Coraje. Se necesita valentía para comunicarse clara y eficazmente con el cliente y con los compañeros y afrontar sin miedo los cambios en el proyecto. Y por supuesto es necesario ser valiente para aplicar algunas de las prácticas que XP propone ya que, en ocasiones, puede haber quien dude de su utilidad.
• Respeto. Los cuatro valores anteriores llevan implícito el respeto. Es indispensable el respeto mutuo, valorando el trabajo de los demás y sus aportaciones.

Los Principios

Llevar al trabajo del día a día los valores anteriores no es algo trivial ya que se trata de conceptos demasiado abstractos. Para ello, XP propone algunos principios útiles para un mejor desarrollo.

• Humanidad. El software lo desarrollan personas y es importante tener presente que los factores humanos son la clave para crear un software de calidad.
• La Economía. El producto que se cree debe ser rentable tanto a corto como a largo plazo, debe producir beneficios.
• El beneficio mutuo. Uno de los principales principios de XP y de los más difíciles de poner en práctica. Propone pensar siempre en el beneficio de todas las partes implicadas en un desarrollo.
• La auto-semejanza. Buscar soluciones similares en diferentes contextos. Los patrones de la forma de trabajo deben repetirse adaptándolos a la situación en la que estemos.
• La mejora continua. Pensar constantemente en qué se puede hacer mejor mañana. Para ello, es necesario el feedback del cliente, el análisis del resultado de las pruebas y la experiencia del propio equipo.

La diversidad. Dos enfoques diferentes sobre cómo hacer un diseño debe verse como una oportunidad de aprender y mejorar y no como un problema en absoluto.

• La reflexión. Un equipo habitualmente piensa en cómo está trabajando y por qué está haciéndolo de esa manera para tratar de mejorar.
• El flujo. XP propone abordar simultáneamente todas las actividades del desarrollo y todas sus prácticas están basadas en que este flujo en el trabajo existe.
• Oportunidad. Donde hay un problema, hay una oportunidad para mejorar. Precisamente, todas las prácticas de XP son eficaces para tratar los problemas tradicionales del desarrollo de software.
• Redundancia. Si existe algún aspecto crítico se deben buscar varias soluciones diferentes, de forma que si una fallase, podría funcionar otra alternativa buscada.
• Los fallos. El cometer fallos es algo tremendamente útil si se aprende de ellos.
• La calidad. El trabajar con un alto nivel de calidad aumenta la eficiencia y la productividad, no se trata simplemente de un factor económico.
• Pequeños pasos. Se pueden realizar numerosas y productivas pequeñas iteraciones. Si se da un paso equivocado, se podrá rectificar rápidamente.
• Aceptar la responsabilidad. Será cada persona la que, responsablemente, desarrolle la mayor cantidad de trabajo de la mejor manera posible.

Las Prácticas

Las prácticas son, ni más ni menos que la manera en que los equipos trabajan en su día a día. La adopción de unas u otras prácticas variará en función de la situación en la que se apliquen. Kent Beck clasifica las prácticas en dos bloques: prácticas primarias y prácticas corolario. Para aplicar las segundas es necesario tener cierta experiencia en la aplicación de las primarias.

Prácticas primarias

Estas prácticas ayudan directamente a mejorar el desarrollo de software.

• Historias. Los requisitos del sistema deben escribirse en lenguaje del cliente y deben estar redactados de forma que reflejen pequeñas unidades de funcionalidad visible para el cliente.
• Ciclos semanales. Trabajar en iteraciones de una semana de forma que al iniciar cada semana el cliente elija las historias que haya que desarrollar y el equipo las divida en las tareas técnicas necesarias para llevarlas a cabo.
• Revisiones y planificaciones trimestrales. Se propone revisar el estado del equipo, del proyecto y los progresos, analizando si se mantienen los objetivos generales establecidos para el proyecto.
• Holgura. Se permite cierta holgura a la hora de realizar los planes para las iteraciones de forma que si surgen imprevistos, existan tareas que pueden dejar de realizarse sin ocasionar demasiado impacto.
• Sentarse juntos. La mejor forma de potenciar la comunicación es sentar al equipo de desarrollo en la misma sala y en un espacio abierto.
• El equipo completo. El equipo debe estar compuesto por personas que tengan todos los perfiles necesarios para abordar el desarrollo con éxito y deben sentirse miembros de un mismo equipo, en el que se incluyen clientes y usuarios.
• Puesto de trabajo con información. En el puesto de trabajo debe poderse consultar, el estado del proyecto y las tareas que hay que realizar.
• Energía en el trabajo o Ritmo sostenible. Se debe trabajar de forma que las personas sean productivas y estén centradas en su trabajo, con un ritmo de trabajo que se pueda mantener en el tiempo.
• Programación en parejas. El código lo escriben dos personas en una misma máquina. Esta práctica ayuda a alinear al equipo hacia el objetivo de la iteración y aumenta la calidad del software que se escribe. Lo ideal es que las parejas cambien con mucha frecuencia, por ejemplo, una vez al día. Programar en pareja supone un gran esfuerzo y no debe hacerse durante toda la jornada. Hay programadores que optan por revisiones de código como alternativa a la programación por parejas.
• Diseño incremental o evolutivo. Es una manera de que el diseño se enriquezca constantemente con las aportaciones y comentarios del cliente. Un equipo debe refactorizar su código con frecuencia para que el diseño mejore constantemente.
• Pruebas antes de programar. Es necesario escribir pruebas para comprobar que el código funcionará correctamente, evitando codificar en modo “Cowboy Coding”, es decir, dejándose llevar y de forma rápida.
• Integración continua. La integración del software con todos los cambios realizados debe realizarse cada dos horas aproximadamente para evitar los problemas de integrar a última hora.
• Construcción en diez minutos. El sistema debe poder compilarse y probarse en diez minutos de forma automática para poder hacer este proceso con frecuencia y así recibir comentarios y sugerencias sin que impacte en el ritmo del desarrollo.

Prácticas corolario

Como se ha comentado previamente, la aplicación de estas prácticas corolario debe realizarse cuando las prácticas primarias ya están incorporadas en la rutina de trabajo de un equipo, puesto que mal utilizadas, pueden desencadenar graves problemas.

• Participación real de los clientes. Toda persona afectada por el producto se considera parte del equipo y debe poder participar activamente en la planificación y en la elaboración de los requisitos.
• Despliegue incremental. Cuando se trabaja sobre un producto que ya existe, modificar primero algunas de sus funcionalidades y poco a poco ir modificando el resto.
• Negociar el alcance del contrato. En ocasiones es más útil negociar varios contratos de duración más corta y fijar de esta forma el alcance para cada uno de ellos.
• Pagar por funcionalidad. Si se paga por funcionalidad, se sabrá con precisión hacia dónde dirigir el desarrollo.
• Continuidad de los equipos. Un equipo de desarrollo debe mantenerse aunque se cambie de proyecto.
• Reducir los equipos. Un equipo será cada vez más productivo. Manteniendo la carga de trabajo, se podrá enviar a alguno de sus miembros a formar un nuevo equipo.
• Análisis de las causas. Cuando aparece un problema, se debe atacar a las causas que lo originaron.
• Código y pruebas. Son los elementos clave del proyecto que no se pueden dejar de mantener y mejorar nunca.
• Propiedad colectiva del código. Cualquier miembro del equipo debe ser capaz de modificar cualquier parte del código.
• Código base único. Si por algún motivo se necesita trabajar en paralelo al desarrollo principal, esto no debería prolongarse más de varias horas.
• Despliegue diario. Cada día debe ponerse el código desarrollado en producción para evitar un desfase entre la última versión de software y la de cada máquina local.