Computacin y Sistemas

XP (eXtreme Programming - Programacin extrema)

1. Introduccin
Dentro de los mtodos de desarrollo gil, quiz el que
tiene ms popularidad es el mtodo de Programacin
extrema (o eXtreme Programming desarrollado por Kent
Benck).
La mayora de los programadores tienen cierta tendencia
en embeberse en cuestiones tcnicas, hablar de lenguajes
de programacin, de tcnicas de programacin, de
entornos de desarrollo o de editores de recursos. Pero se
nos pasan por alto temas muy importantes que nos afectan
tanto o ms que las cuestiones mencionadas, como es la
ingeniera de software, la manera en que debemos de hacer nuestro software.
2. Orgenes
Kent Beck, su autor, es un programador que ha trabajado en mltiples empresas y que
actualmente lo hace como programador en la conocida empresa automovilstica DaimlerChrysler.
Con sus teoras ha conseguido el respaldo de gran parte de la industria del software y el rechazo
de otra parte.
3. Definicin
Se basa en una serie de reglas y principios que se han ido gestando a lo largo de toda la historia
de la ingeniera del software. Usadas conjuntamente proporcionan una nueva metodologa de
desarrollo software que se puede englobar dentro de las metodologas ligeras, que son aqullas
en la que se da prioridad a las tareas que dan resultados directos y que reducen la burocracia
que hay alrededor tanto como sea posible.
La programacin extrema, dentro de las metodologas giles, se puede clasificar dentro de las
evolutivas.
Una de las caractersticas de eXtreme Programming es que muchos de, si no todos, sus
ingredientes son de sobra conocidos dentro de la rama de la ingeniera del software desde hace
tiempo, incluso desde sus comienzos. Los autores de han seleccionado los que han
considerados como los mejores y han profundizado en sus relaciones y en cmo se refuerzan
unos a otros. El resultado ha sido una metodologa nica y compacta.
4. Valores
El proceso de desarrollo descrito en la seccin anterior est fundamentado en una serie de
valores y principios que lo guan. Los valores representan aquellos aspectos que los autores de
XP han considerado como fundamentales para garantizar el xito de un proyecto de desarrollo
de software. Los cuatro valores de XP son:
1. comunicacin,
2. simplicidad,
3. realimentacin y
4. coraje
Los partidarios de la programacin extrema dicen que son los necesarios para conseguir diseos
y cdigos simples, mtodos eficientes de desarrollo software y clientes contentos. Los valores
deben ser intrnsecos al equipo de desarrollo. De los cuatro valores, quizs el que llame ms la
atencin es el de coraje. Detrs de este valor encontramos el lema "si funciona, mejralo", que
choca con la prctica habitual de no tocar algo que funciona, por si acaso. Aunque tambin es
cierto que tenemos las pruebas unitarias, de modo que no se pide a los desarrolladores una
heroicidad, sino slo coraje.
Algunas voces, adems, aaden un quinto valor: la humildad. Y es que con la que comparticin
de cdigo, la refactorizacin y el trabajo en equipo tan estrecho una buena dosis de humildad
siempre ser de agradecer.

Marco Aurelio Porro Chulli

Computacin y Sistemas

5. Principios
Los principios fundamentales se apoyan en los valores y tambin son cuatro. Se busca
1. realimentacin veloz,
2. modificaciones incrementales,
3. trabajo de calidad y
4. asuncin de simplicidad.
Los principios suponen un puente entre los valores (algo intrnseco al equipo de desarrollo) y las
prcticas, que se vern, y que estn ms ligadas a las tcnicas que se han de seguir.
6. Caractersticas
La programacin extrema
da por supuesto que es
imposible prever todo
antes de comenzar a
programar; es imposible o
si lo fuera es demasiado
costoso e innecesario, ya
que muchas veces se
gasta demasiado tiempo y
recursos en cambiar la
documentacin de la
planificacin para que se
parezca al cdigo.
Para evitar esto, XP
intenta implementar una
forma de trabajo donde se
adapte fcilmente a las
circunstancias.
Bsicamente consiste en
trabajar estrechamente con el cliente, haciendo pequeas iteraciones (mini-entregas), cada dos
semanas, donde no existe mas documentacin que el cdigo en si; cada versin contiene las
modificaciones necesarias segn el cliente vaya retroalimentando el sistema (por eso es
necesaria la disponibilidad del cliente durante todo el desarrollo).
Para suplir la falta de requisitos, casos de uso, y dems herramientas; XP utiliza historias de
usuarios, la historia de usuario es una frase corta que representa alguna funcin que realizara el
sistema. Cada historia de usuario no puede demorar en desarrollarse ms de una semana, si as
lo requiera, debe segmentarse.
Es requisito para XP definir un estndar en el tipo de codificacin, esto hace que los
programadores tengan definido ya el estilo de programacin y no que cada uno programe a su
estilo.
Los programadores trabajan en parejas (dos por cada maquina) intercambindose en el tipeo,
esta interesante forma de trabajar tiene ventajas como:
Detectar mas fcilmente los errores de programacin (el programador libre
controla al que tipea)
El programador poco experimentado aprende del que mas lo esta.
Si una pareja consigue desarrollar algn trozo de cdigo reutilizable, se
comunica mas fcilmente a los otros programadores.
El testing en cada iteracin es ms que importante; de eso se trata este paradigma de
programacin, corregir mientras se programa. De esta forma se van cubriendo todos los baches
que cada versin padezca.

Marco Aurelio Porro Chulli

Computacin y Sistemas

El cdigo no es de nadie, todo el equipo puede manipular el cdigo que existe, de esta forma
cada pareja puede mejorar cada seccin de cdigo que utiliza, esto requiere de un testing del
mismo y la re-implementacin en el sistema general.
Cada dos semanas se entrega una versin al cliente, que lo verifica, realiza el feedback y se
contina el desarrollo; este ciclo continua hasta que el sistema cumpla con las expectativas del
cliente, acto que concluir el proyecto.
No existe documentacin del proyecto (para mi, el taln de Aquiles de este modelo) lo que mas
se acerca a la documentacin son las historias de usuario, pero al concluir el proyecto se
descartan. Inclusive se recomienda hacer dos secciones, una con todas las historias de usuario
que faltan desarrollar, y otra donde se archiven las concluidas, esto aproximara el estado de
avance del proyecto.
7. El Proceso de Desarrollo Extremo
La programacin extrema parte del caso habitual de una compaa que desarrolla software,
generalmente software a medida, en la que hay diferentes roles:
un equipo de gestin
un equipo de desarrolladores
los clientes.
La relacin con el cliente es totalmente diferente a lo que se ha venido haciendo en las
metodologas tradicionales que se basan fundamentalmente en una fase de captura de requisitos
previa al desarrollo y una fase de validacin posterior al mismo.
Interaccin con el cliente
En
la
programacin
extrema al cliente no slo
se le pide que apoye al
equipo de desarrollo, en
realidad podramos decir
que es parte de l. Su
importancia es capital a la
hora de abordar las
historias de los usuarios y
las
reuniones
de
planificacin,
como
veremos ms adelante.
Adems, ser tarea suya
realimentar al equipo de
desarrolladores despus
de cada iteracin con los
problemas con los que se
ha encontrado, mostrando
sus
prioridades,
expresando
sus
sensaciones.
Existirn
mtodos como pruebas de aceptacin que ayudarn a que la labor del cliente sea lo ms
fructfera posible.
En resumen, el cliente se encuentra mucho ms cercano al proceso de desarrollo. Se elimina la
fase inicial de captura de requisitos y se permite que stos se vayan definiendo de una forma
ordenada durante el tiempo que dura el proyecto. El cliente puede cambiar de opinin sobre la
marcha y a cambio debe encontrarse siempre disponible para resolver dudas del equipo de
desarrollo y para detallar los requisitos especificados cuando sea necesario.

Marco Aurelio Porro Chulli

Computacin y Sistemas

El proceso de captura de requisitos de XP gira entorno a una lista de caractersticas que el

cliente desea que existan en el sistema final. Cada una de estas caractersticas recibe el nombre
de historias de usuarios y su definicin consta de dos fases:
En la primera fase el cliente describe con sus propias palabras las caractersticas y el
responsable del equipo de desarrollo le informa de la dificultad tcnica de cada una de ellas y por
lo tanto de su coste. A travs del dilogo resultante el cliente deja por escrito un conjunto de
historias y las ordena en funcin de la prioridad que tienen para l. En este momento ya es
posible definir unos hitos y unas fechas aproximadas para ellos.
La segunda fase consiste en coger las primeras historias que sern implementadas (primera
iteracin) y dividirlas en las tareas necesarias para llevarlas a cabo. El cliente tambin participa,
pero hay ms peso del equipo de desarrollo, que dar como resultado una planificacin ms
exacta. En cada iteracin se repetir esta segunda fase para las historias planificadas para ella.
Este proceso es una de las principales diferencias con las metodologas tradicionales. Aunque
las historias de usuarios guardan cierta relacin con otras tcnicas como los casos de uso de
UML, su proceso de creacin es muy diferente. En lo que al cliente se refiere no se le exige que
especifique exactamente lo que quiere al principio con un documento de requisitos de usuario.
La parte que se mantiene con este documento es que es el cliente el que tiene que escribir lo
que quiere, no se permite que alguien del equipo de desarrolladores lo escriba por l.
Como se ha comentado, son los desarrolladores los que se encargan de catalogar las historias
de los usuarios y asignarles una duracin. Para ello se sigue una norma simple: las historias de
usuarios deberan poder ser abordables en un espacio de tiempo de entre una y tres semanas
de programacin ideal. Historias de los usuarios que requieran menos tiempo de implementacin
son agrupadas, mientras que aqullas que necesiten ms tiempo deben ser modificadas o
divididas. Una semana de programacin ideal es una semana (cinco das de trabajo) de
desarrollo por parte de un desarrollador sin interferencias de otras partes del proyecto. Al hacer
la planificacin se aplica un factor de correccin medido de proyectos anteriores para ajustar
este tiempo ideal al real.
Las historias de los usuarios se plasmarn en tarjetas, lo que facilitar que el cliente pueda
especificar la importancia relativa entre las diferentes historias de usuario, as como la tarea de
los desarrolladores que podrn catalogarlas convenientemente. El formato de tarjeta adems es
muy provechoso a la hora de realizar pruebas de aceptacin.
Planificacin del proyecto
Es probablemente en
este punto donde nos
debamos enfrentar a la
planificacin de entregas
(release planning) donde
planificaremos
las
distintas
iteraciones.
Para ello existen una
serie de reglas que hay
que seguir para que las
tres partes implicadas en
este proceso (equipo de
gestin, equipo de
desarrollo y cliente)
tengan voz y se sientan
parte de la decisin
tomada, que al fin y al
cabo debe contentar a
todos.

Marco Aurelio Porro Chulli

Computacin y Sistemas

La planificacin debe de seguir unas ciertas premisas. La primordial es que las entregas se
hagan cuanto antes y que con cada iteracin el cliente reciba una nueva versin. Cuanto ms
tiempo se tarde en introducir una parte esencial, menos tiempo habr para trabajar en ella
posteriormente. Se aconsejan muchas entregas y muy frecuentes. De esta forma, un error en
una parte esencial del sistema se encontrar pronto y, por tanto, se podr arreglar antes.
Sin embargo, los requisitos anteriores en cuanto a la planificacin no deben suponer horas extra
para el equipo de desarrollo. El argumento que se esboza es que lo que se trabaja de ms un
da, se deja de trabajar al siguiente. Diversas prcticas como las pruebas unitarias, la integracin
continua o el juego de la planificacin permiten eliminar los principales motivos por los que suele
ser necesario trabajar muchas horas extra.
Pero lo mejor de todo es que a la hora de planificar uno se puede equivocar. Es ms, todos
sabemos que lo comn es equivocarse y por ello la metodologa ya tiene previsto mecanismos
de revisin. Por tanto, es normal que cada 3 a 5 iteraciones se tengan que revisar las historias
de los usuarios y renegociar nuevamente la planificacin.
Hemos visto que al principio del proyecto se hace una planificacin en iteraciones que debe ser
retocada al cabo de unas cuantas iteraciones. A esto hay que aadir que en cada iteracin
tambin hay que realizar la planificacin de la misma, lo que ha venido a llamarse planificacin
iterativa. En la planificacin iterativa se especifican las historias de los usuarios cuya
implementacin se considera primordial y se aaden aqullas que no han pasado las pruebas de
aceptacin de anteriores iteraciones. La planificacin de una iteracin tambin hace uso de
tarjetas en las que se escribirn tareas, que durarn entre uno y tres das (la duracin la deben
decidir los propios desarrolladores).
Diseo, desarrollo y pruebas
El desarrollo es la pieza clave de todo el proceso de programacin extrema. Todas las tareas
tienen como objetivo que se desarrollo a la mxima velocidad, sin interrupciones y siempre en la
direccin correcta.
Tambin se otorga una gran importancia al diseo y establece que ste debe ser revisado y
mejorado de forma continua segn se van aadiendo funcionalidades al sistema. Esto se
contrapone a la prctica conocida como "Gran diseo previo" habitual en otras metodologas.
Los autores de XP opinan que este enfoque es incorrecto dado que a priori no se tiene toda la
informacin suficiente para disear todo el sistema y se limita la posibilidad del cliente de
cambiar de opinin respecto a las funcionalidades deseadas. Como veremos a continuacin a
cambio se establecen los mecanismos para ir remodelando el diseo de forma flexible durante
todo el desarrollo.
La clave del proceso de desarrollo de XP es la comunicacin. La gran mayora de los problemas
en los proyectos de desarrollo son provocados por falta de comunicacin en el equipo, as que
se pone un gran nfasis en facilitar que la informacin fluya lo ms eficientemente posible.
Es en este punto donde entra uno de los trminos estrella de la programacin extrema: la
metfora. El principal objetivo de la metfora es mejorar la comunicacin entre los todos
integrantes del equipo al crear una visin global y comn del sistema que se pretende
desarrollar. La metfora debe estar expresada en trminos conocidos para los integrantes del
grupo, por ejemplo comparando lo que se va a desarrollar con algo que se puede encontrar en la
vida real. Aunque tambin se incluye informacin sobre las principales clases y patrones que se
usarn en el sistema.

Marco Aurelio Porro Chulli