Hoy me apetece hablar de la metodología XP (eXtreme Programming). Personalmente, me gusta porque es de las primeras metodologías ágiles con la que tuve contacto, allá por el año 1999. Al igual que en otras metodologías ágiles, es una metodología adaptativa y centrada en las personas. XP agrega buenas prácticas que abarcan más allá de la gestión de proyectos definiendo aspectos más técnicos y cercanos al desarrollo software. El autor o precursor de esta metodología fue Kent Beck, y está basada en 5 valores fundamentales:
- Respeto: todos los miembros del equipo muestran respeto por el trabajo de cada uno de los demás.
- Simplicidad: la he puesto en segundo lugar, porque aunque en teoría leeréis que lo simple y la búsqueda de lo simple es la base de XP, me niego a verlo por detrás del respeto.
- Comunicación: cada una de las tareas del equipo se consideran una forma de comunicación, desde el código, pruebas unitarias, etc.
- Feedback: XP fue una de las primeras metodologías en incorporar el feedback del cliente. De hecho, el cliente se considera parte del equipo de trabajo.
- Valor: se refiere principalmente al valor o valentía necesarios para realizar algunas de las prácticas ágiles que XP incorpora. Como el comenzar a programar lo antes posible, o valentía para que el código sea refactorizado y no haya deuda técnica desde el principio, etc.
Como metodología, XP es muy ligera, o más bien podríamos decir, poco estructurada («ligera» podría considerarse como un término despectivo en el mundo del desarrollo del software). Lo que sí hace XP es incorporar una serie de técnicas o buenas prácticas. Algunas prácticas fundamentales de XP:
- Programación por parejas: es el punto más controvertido, ya que propone que sean dos personas las que se dediquen a programar. Una persona escribiendo y otra revisando (se pueden alternar). De todas formas, el código se discute antes y durante la escritura. Aquí se practica el famoso «cuatro ojos ven mejor que dos».
- Desarrollo por iteraciones: el código se construye mediante iteraciones que van sumando valor o funcionalidad al resultado final.
- Simplicidad: el axioma «KISS» (Keep It Simple, Stupid), se aplica con regularidad.
- Refactorización: el código se refactoriza regularmente para que la calidad de código sea notoria, y se evite la deuda técnica. Recordemos que refactorizar, tal y como hemos indicado ya en este blog, nos puede llevar a la refactoritis, una enfermedad de la que ya hemos hablado anteriormente en este mismo blog.
Calidad y software 