Una Explicación De La Programación Extrema (XP)

Una explicación de la programación extrema (XP)

V Encuentro usuarios xBase 2003 MADRID

Manuel Calero Solís.

http://www.apolosoftware.com/

Introducción

La mayoría de los programadores tenemos cierta tendencia en embebernos en

cuestiones técnicas, hablar de lenguajes de programación, de técnicas de programación, de

entornos de desarrollo o de editores de recursos. Pero se nos pasan por alto temas muy

importantes que nos afectan tanto o más que las cuestiones mencionadas, como es la

ingeniería de software, la menera en que debemos de hacer nuestro software. Alrededor de

cómo hacer software hay una gran numero de autores teorías, propuestas, etc, etc., voy a

tratar de presentaros una nueva disciplina de desarrollo de software, la programación extrema.

1. ¿Que es la programación extrema (XP)?

XP (eXtreme Programing) nace como nueva disciplina de desarrollo de software hace

aproximadamente unos seis años, y ha causado un gran revuelo entre el colectivo de

programadores del mundo. Kent Beck, su autor, es un programador que ha trabajado en

múltiples empresas y que actualmente lo hace como programador en la conocida empresa

automovilística DaimlerChrysler. Con sus teorías ha conseguido el respaldo de gran parte de la

industria del software y el rechazo de otra parte.

La programación extrema se basa en la simplicidad, la comunicación y el reciclado

continuo de código, para algunos no es mas que aplicar una pura lógica.

2. Problemas del desarrollo de software.

¿ Cuales son los principales problemas a la hora de desarrollar nuestro software ?

Seguro que cualquiera de vosotros se ha topado alguna vez con alguno de estos problemas:

·Retrasos en la planificación: llegada la fecha de entregar el software éste no esta

disponible.

·Sistemas deteriorados: el software se ha creado pero después de un par de año el coste

de su mantenimiento es tan complicado que definitivamente se abandona su

producción.

·Tasa de defectos: el software se pone en producción pero los defectos son tantos que

nadie lo usa.

·Requisitos mal comprendidos: el software no resuelve los requisitos planificados

inicialmente.

·Cambios de negocio: el problema que resolvía nuestro software ha cambiado y nuestro

software no se ha adaptado.

·Falsa riqueza: el software hace muchas cosas técnicamente muy interesantes y divertidas,

pero no resuelven el problema de nuestro cliente, ni hace que éste gane mas dinero.

·Cambios de personal: después de unos años de trabajo los programadores comienzan a

odiar el proyecto y lo abandonan.

XP trata de evitar estos riesgos en nuestro desarrollo de software.

3. ¿ En que consiste XP ? Sus objetivos.

Los objetivos de XP son muy simples: la satisfacción del cliente. Esta metodología trata

de dar al cliente el software que él necesita y cuando lo necesita. Por tanto, debemos

responder muy rápido a las necesidades del cliente, incluso cuando los cambios sean al final

de ciclo de la programación.

El segundo objetivo es potenciar al máximo el trabajo en grupo. Tanto los jefes de

proyecto, los clientes y desarrolladores, son parte del equipo y están involucrados en el

desarrollo del software.

3.1. Las cuatro variables.

XP define cuatro variables para proyectos de software: coste, tiempo, calidad y ámbito.

Además de estas cuatro variables, Beck propone que sólo tres puedan ser establecidas

por las fuerzas externas (jefes de proyecto y clientes), mientras que el valor de la cuarta

variable debe ser establecido por los programadores en función de las otras tres.

Pongámonos en un episodio diario de desarrollo.

El jefe de proyecto: “Quiero estos requisitos realizados para el día 1 de mes próximo,

con lo que contáis con el equipo actual. ¡Ah ya sabéis que la calidad es lo primero!”

Todos sabemos qué es lo primero que salta por la ventana en estos casos: “la calidad”,

¿ Por qué ? Porqué nadie es capaz de trabajar bien cuando se le somete a mucha presión.

XP nos propone que juguemos todas las partes implicadas en el proyecto hasta que el

valor que alcancen las cuatro variables sea el correcto para todas las partes: “Si quieres mas

calidad en menos tiempo tendrás que aumentar el equipo e incrementar el coste”.

Además con el agravante de que estas cuatro variables no guardan una relación tan

directa como en principio pueda parecer. El incremento del número de programadores no

repercutirá de manera lineal en el tiempo de desarrollo del proyecto, siendo de todos conocido

el dicho: “nueve mujeres no pueden tener un hijo en un mes”.

Con la calidad suele suceder un fenómeno extraño: frecuentemente un proyecto que

tratemos de aumentar la calidad conduce a que el proyecto pueda realizarse en menos tiempo,

siempre con unos márgenes obviamente. Es verdad que cuando un equipo de desarrollo se

acostumbra a realizar pruebas intensivas, se siguen estándares de codificación, poco a poco

se comenzara a andar mas rápido y mas seguro, por tanto mas preparados para futuros

cambios, sin estrés y así sucesivamente.

Frente a esto existe la tentación de entregar el trabajo mas rápido, por tanto probar

menos, codificar más rápido y peor, sin hacer planteamientos maduros, esto repercutirá en la

confianza de nuestros clientes, al entregarle trabajos con fallos. Esta es una apuesta a muy

corto plazo y suele ser una invitación al desastre, conduce a la desmoralización del equipo, y

con ello a la larga a la ralentización del proyecto y la perdida de tiempo que habríamos

conseguido en un principio.

La cuarta variable, el ámbito del proyecto, suele ser conveniente que sea establecida

por el equipo de desarrollo. Es una variable muy importante que nos va a decir donde vamos a

llegar con nuestro software, que problemas vamos a resolver y cuales vamos a dejar para

siguientes versiones. Cuantas veces hemos escuchado “Los clientes no nos pueden decir lo

que quieren. Cuando le damos lo que nos piden no les gusta”. Y es que los requisitos nunca

son claros al principio y el mismo desarrollo del software hace cambiar los requisitos. Por tanto

el ámbito debe de ser dúctil, podremos jugar con el, si el tiempo para el lanzamiento es

limitado, siempre habrá cosas que pudramos diferir para siguientes

...