METODOLOGÍA XP

1. INTRODUCCIÓN

HISTORIA

La programación extrema o eXtreme Programming (de ahora en adelante, XP)

es una metodología de desarrollo de la ingeniería de software formulada
por Kent Beck, autor del primer libro sobre la materia, Extreme Programming
Explained: Embrace Change (1999). Es el más destacado de los procesos
ágiles de desarrollo de software.

Chrysler Corporation hacía tiempo que estaba desarrollando una aplicación de

nóminas, pero sin demasiado éxito por parte de la gente que tenía en el
proyecto. El verano de 1996, Beck entró en nómina en la compañía y se le pidió
de hacer esta aplicación como trabajo. Es en esta aplicación cuando nace la
Programación Extrema como tal.

Beck reconoció que el proceso (o metodología) de creación de software o la

carencia de este era la causa de todos los problemas y llegó a la conclusión
que para proporcionar un proceso que fuera flexible era necesario realizar
ciertos cambios en la estructura o manera de hacer de los programadores, los
cuales se tenían que acomodar al cambio a realizar.

El tenía varias ideas de metodologías para la realización de programas que

eran cruciales para el buen desarrollo de cualquier sistema.

Las ideas primordiales de su sistema las comunicó en la revista C++

Magazine en una entrevista que ésta le hizo el año 1999. En ésta decía que él
estaba convencido que la mejor metodología era un proceso que enfatizase la
comunicación dentro del equipo, que la implementación fuera sencilla, que el

Página 1
usuario tenía que estar muy informado y implicado y que la toma de decisiones
tenía que ser muy rápida y efectiva.

Al igual que éstos, la programación extrema se diferencia de las metodologías

tradicionales principalmente en que pone más énfasis en la adaptabilidad que
en la previsibilidad. Los defensores de la XP consideran que los cambios de
requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable
del desarrollo de proyectos.

Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier

punto de la vida del proyecto es una aproximación mejor y más realista que
intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos
después en controlar los cambios en los requisitos.

Se puede considerar la programación extrema como la adopción de las mejores

metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el
proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

Elegir un proceso ágil de desarrollo es uno de los mayores problemas en un

proyecto de software. Una metodología que permita lograr un código sin
errores, con alta funcionabilidad, manteniendo a cliente al tanto del proyecto y
en plazos de tiempo cómodos, siempre han sido objetivos ideales que en todo
proyecto se pretende alcanzar. La Metodología de “Programación Extrema”
(XP) propone la manera de alcanzar esos objetivos.

Esta Metodología consiste en un conjunto de prácticas, fundamentadas en

valores que deben de mantener los participantes de proyecto que, a manera de
trabajo en grupo, pretende lograr como producto final un software con un muy
alto grado de calidad.

Página 2
A los largos de los años la aplicación de esta metodología ha dado los mejores
resultados, las etapas que plantea han sido llevadas al extremo, en muchos
lugares del mundo, y en diversos ámbitos de la actividad humana donde se ha
necesitado diseñar un sistema informático.

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.

Pero las etapas que recomienda seguir esta metodología se plantean de

manera sencilla pero a la vez son estrictas, y se inspiran en la total participación
de los involucrados.

Página 3
2. CARACTERÍSTICAS

 Desarrollo iterativo e incremental, pequeñas mejoras, unas tras otras.

 Pruebas unitarias continuas frecuentemente repetidas y automatizadas,

incluyendo pruebas de regresión. Se aconseja escribir el código de la
prueba antes de la codificación.

 Programación en parejas se recomienda que las tareas de desarrollo se

lleven a cabo por dos personas en un mismo puesto. Se supone que la
mayor calidad del código escrito de esta manera el código es revisado y
discutido, mientras se escribe es más importante que la posible pérdida de
productividad inmediata.

Página 4
 Frecuente integración del equipo de programación con el cliente o usuario:
Se recomienda que un representante del cliente trabaje junto al equipo de
desarrollo.

 Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer

entregas frecuentes.

 Refactorización del código, es decir, rescribir ciertas partes del código para
aumentar su legibilidad y mantenibilidad pero sin modificar su
comportamiento. Las pruebas han de garantizar que en la refactorización
no se ha introducido ningún fallo.

 Propiedad del código compartida, en vez de dividir la responsabilidad en el

desarrollo de cada módulo en grupos de trabajo distintos, este método
promueve el que todo el personal pueda corregir y extender cualquier parte
del proyecto. Las frecuentes pruebas de regresión garantizan que los
posibles errores serán detectados

 Simplicidad en el código, es la mejor manera de que las cosas funcionen.

Cuando todo funcione se podrá añadir funcionalidad si es necesario. La
programación extrema apuesta que es más sencillo hacer algo simple y
tener un poco de trabajo extra para cambiarlo si se requiere, que realizar
algo complicado y quizás nunca utilizarlo.

 La simplicidad y la comunicación son extraordinariamente complementarias.

Con más comunicación resulta más fácil identificar qué se debe y qué no se
debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar
sobre éste, lo que lleva a una comunicación más completa, especialmente
si se puede reducir el equipo de programadores.

Página 5
PROGRAMADOR:

 Pieza básica en desarrollos XP.

 Más responsabilidad que en otros modos de desarrollo.
 Responsable sobre el código.
 Responsable sobre el diseño (refactorización, simplicidad).
 Responsable sobre la integridad del sistema (pruebas).
 Capacidad de comunicación.
 Acepta críticas (código colectivo).

CLIENTE:

 Pieza básica en desarrollos XP.

 Define especificaciones.
 Influye sin controlar.
 Confía en el grupo de desarrollo.
 Define pruebas funcionales.

Página 6
ENCARGADO DE PRUEBAS

 Apoya al cliente en la preparación/realización de las pruebas funcionales.

 Ejecuta las pruebas funcionales y publica los resultados.

ENCARGADO DE SEGUIMIENTO (TRACKER):

 Recoge, analiza y publica información sobre la marcha del proyecto sin

afectar demasiado el proceso.
 Supervisa el cumplimiento de las estimaciones en cada iteración.
 Informa sobre la marcha de la iteración en curso.
 Controla la marcha de las pruebas funcionales, de los errores reportados,
de las responsabilidades aceptadas y de las pruebas añadidas por los
errores encontrados.

ENTRENADOR (COACH):

 Experto en XP.
 Responsable del proceso en su conjunto.
 Identifica las desviaciones y reclama atención sobre las mismas.
 Guía al grupo de forma indirecta (sin dañar su seguridad ni confianza).
 Interviene directamente si es necesario.
 Atajar rápidamente el problema.

CONSULTOR:

 Apoya al equipo XP en cuestiones puntuales.

Página 7
 JEFE DEL PROYECTO:

 Favorece la relación entre usuarios y desarrolladores.

 Confía en el equipo XP.
 Cubre las necesidades del equipo XP.
 Asegura que alcanza sus objetivos.

3. VENTAJAS Y DESVENTAJAS:

 VENTAJAS:

a. Programación organizada.
b. Menor taza de errores.
c. Satisfacción del programador.
d. Solución de errores de programas.
e. Versiones nuevas
f. Implementa una forma de trabajo donde se adapte fácilmente a las
circunstancias.

 DESVENTAJAS:

a. Es recomendable emplearlo solo en proyectos a corto plazo.

b. Altas comisiones en caso de fallar.
c. Imposible prever todo antes de programar.
d. Demasiado costoso e innecesario.

Página 8