Tras realizar una introducción sobre las Metodologías Ágiles, en esta segunda entrada me centraré en repasar Extreme Programming, también conocida como XP o Programación Extrema. Todo desde un enfoque teórico, y pensado para aquellas personas que se acercan por primera vez a este concepto o han oído hablar alguna vez sobre ello pero quieren profundizar un poco más.

 

Antes de nada, lo siento, Extreme Programming no está patrocinado por RedBull, no consiste en programar saltando en paracaídas, ni pasar trabajando toda la noche anterior para llegar a tiempo a la entrega de un proyecto.

 

Sin embargo, veréis que la idea detrás de este concepto hace honor a su nombre: si a lo largo de todos los años que llevamos construyendo software hemos aprendido a cómo hacerlo bien ¿por qué no aplicar todos estos buenos hábitos al extremo?

 

El objetivo principal de esta metodología es tener contento al cliente. Y para ello se basa en principios como la entrega continua de software, ser flexibles a los cambios, realizar un trabajo en equipo efectivo, y que sea auto organizado.

 

Todo proyecto XP se sustenta sobre cinco pilares:

  • Simplicidad: a la hora de diseñar y construir software se debe seguir el principio KISS (Keep It Simple, Stupid!). Es decir, tenemos que hacer solo lo necesario y no más para cubrir las necesidades del cliente. Hay que evitar pensar en requisitos que no existen, y tal vez nunca aparezcan. Se debe maximizar el valor del producto con el menor esfuerzo posible, y realizar el trabajo má simple que funcione.
  • Comunicación: todos los componentes del equipo deben trabajar en conjunto, y por lo que este aspecto es muy importante. Todos los miembros deben conocer el estado actual del proyecto, cómo funciona cada parte, y ayudarse cuando es necesario. Debe primar la comunicación cara a cara frente a la documentación extensiva del proyecto. Esta comunicación también implica a los stakeholders y clientes.
  • Valentía: Siempre se debe decir la verdad respecto al progreso del proyecto y las estimaciones. No debe haber excusas por haber fallado. Ningún miembro debe tener miedo ya que no trabajan solos si no en equipo. Y lo que puede ser más complicado, hay que adaptarse al cambio y enfrentarlo.
  • Feedback: Es un punto muy importante, y requiere de la mayor comunicación posible con el cliente y los stakeholders. Esta información es muy valiosa ya que permite descubrir nuevos requisitos, y cambios para realizar iteraciones. Esta retroalimentación puede provenir además del mismo equipo de desarrollo, que encuentre problemas durante su trabajo. Es muy importante generar solo aquel feedback que el equipo pueda manejar y no más.
  • Respeto: Es la clave del éxito de esta metodología. Para ello el equipo de trabajo se basa en una jerarquía plana, dónde nadie es mejor que nadie y todos los miembros aportan valor al proyecto.

 

Además de estos pilares fundamentales, se recomienda seguir los siguientes doce principicos de la XP:

 

1. Planificación del juego

El cliente y el equipo de desarrollo trabajan comúnmente en planificar el producto. Se debe realizar una sesión larga de planificación al inicio del proyecto, y sesiones cortas tras cada iteración. La primera sesión determina las reglas del juego (con qué frecuencia se harán las entregas, cómo se va a organizar el equipo, cuándo se harán las reuniones, etc.). En cada sesión se deben planificar las características y funcionalidades del proyecto, estas estarán representadas como User Stories, que, de una forma menos formal, indican lo que debe hacer el software. La redacción de estas User Stories deben responder a las preguntas: quién, qué, y por qué. Se deben realizar estimaciones para la siguiente iteración, y se deben priorizar las Stories y decidir cuándo lanzar cada característica.

 

2. Entregas pequeñas

De forma tan frecuente como sea posible. Hay que proporcionar valor al cliente cuanto antes para obtener nuevo feedback.

 

3. Metáfora del sistema

Tiene que poder ser posible explicar el funcionamiento de la aplicación a gente sin conocimientos técnicos en unos 15 segundos.

 

4. Diseño simple

Se debe diseñar solo lo que es requerido por el cliente. La cosa más simple que funcione.

 

5. Testeo continuo

Se debe aplicar Test Driven Development (TDD). Hay que realizar test simples, y automatizados. Primero escribir los test a pasar, y después la funcionalidad con la que pasar esos tests. Se debe pasar la batería de tests tras cada modificación para comprobar que todo sigue funcionando correctamente. Existen dos tipos de test: tests de aceptación, en los que desde el punto de vista del cliente se comprueba que las características requeridas funcionan, y test unitarios, que comprueban las funcionalidades a bajo nivel.

 

6. Refactorización

Consiste en reestructurar frecuentemente el diseño interno del software sin cambiar su comportamiento. La intención es limpiar el código y hacerlo más escalable, mantenible y legible.

 

7. Programación por parejas

Lleva el Code Review al extremo. Para ello los programadores programan por parejas. De esta forma se consiguen varias ventajas: revisar el código en tiempo de escritura (dos cabezas piensan mejor que una), reducir la frustración al hacer frente dificultades en el código, compartir conocimiento (los menos expertos aprenden de los que más saben), reducir el impacto sobre la pérdida de un integrante del equipo, y comunicar el estado de todas las etapas del proyecto. La idea es ir rotando las parejas, para que todos los integrantes pasen por todas las partes del proyecto.

 

8. Propiedad colectiva del código

El proyecto es responsabilidad de todo el equipo, no de miembros individuales. El código es de todos, y si falla todos son igual de culpables.

 

9. Integración continua

Combinar el código frecuentemente permite encontrar problemas más rápidamente. Ya que, si el creador no lo ha encontrado, podrá hacerlo otro compañero.

 

10. Semana de 40 horas

Si alguien necesita más de 40 horas en una semana, es que algo del proyecto va mal y hay que arreglarlo.

 

11. Cercano al cliente

El cliente tiene un papel fundamental durante el desarrollo, y es necesario que esté envuelto en cada etapa para proporciona feedback y resolver las dudas del equipo.

 

12. Estándares de programación

Se deben marcar unos estándares a la hora de codificar. Cómo llamar a las variables, a las funciones, como estructurar el código, etc. Esto contribuye a que el código sea más legible y fácil de mantener por todos los integrantes, y favorece a la propiedad colectiva.

 

Además de estos principios, XP propone una serie de reglas, pero entre ellas podemos destacar algunas como: proporcionar un espacio de trabajo dedicado al equipo, mover a los integrantes entre distintas especialidades, o arreglar aquellas cosas en las que XP falla con nuestro equipo.

 

Como se puede observar, esta metodología implica aplicar las buenas prácticas de la programación al extremo, con el fin de poder adaptar cambios de forma más rápida y gastando menos recursos. Estas prácticas se pueden aplicar también en otras metodologías, y es posible que algunas de ellas no puedan ser aplicadas en todos los proyectos, o que no funcionen con todos los equipos, es por eso por lo que hay que adaptar estas prácticas a cada caso particular.