I - Fundamentos de Extreme Programming (X.

P)
II - Planificacin del proyecto
III - Diseo
IV - Codificacin
V - Pruebas y bibliografia

Fundamentos de Extreme Programming (X.P).

La programacin extrema es una metodologa reciente (alrededor de 5 aos) utilizada
en el desarrollo de software. La filosofa de X.P es satisfacer al completo las
necesidades del cliente, por eso, lo integra como una parte ms del equipo de
desarrollo.
X.P fue inicialmente creada para el desarrollo de aplicaciones dnde el cliente no tiene
una concepcin clara de las funcionalidades que tendr la aplicacin que se
desarrollar. Este desconocimiento podra provocar un cambio constante en los
requisitos que debe cumplir la aplicacin por lo que es necesaria una metodologa gil
como X.P que se adapta a las necesidades del cliente y dnde la aplicacin se va
revisando constantemente.
X.P est diseada para el desarrollo de aplicaciones que requieren un grupo de
programadores pequeo, dnde la comunicacin sea ms factible que en grupos de
desarrollo grandes. La comunicacin es un punto importante y debe realizarse entre los
programadores, los jefes de proyecto y los clientes.
Las principales caractersticas de esta metodologa son las siguientes:

Comunicacin: Los programadores estn en constante comunicacin con los

clientes para satisfacer sus requisitos y responder rpidamente a los cambios de
los mismos. Muchos problemas que surgen en los proyectos se deben a que
despus de concretar los requisitos que debe cumplir el programa no hay una
revisin de los mismos, pudiendo dejar olvidados puntos importantes.
Simplicidad: Codificacin y diseos simples y claros. Muchos diseos son tan
complicados que cuando se requiere mantenimiento o ampliacin resulta
imposible hacerlo y se tienen que desechar y partir de cero.
Realimentacin (Feedback): Mediante la realimentacin se ofrece al cliente la
posibilidad de conseguir un sistema adecuado a sus necesidades. Se le va
mostrando el proyecto a tiempo para sugerir cambios y poder retroceder a una
fase anterior para redisearlo a su gusto.
Tenacidad: Se debe ser tenaz para cumplir los tres puntos anteriores. Hay que
tener valor para comunicarse con el cliente y enfatizar algunos puntos a pesar
de que esto pueda dar sensacin de ignorancia por parte del programador; hay
que ser decidido para mantener un diseo simple y no optar por lo que pudiera
parecer mejor o un camino ms fcil y por ltimo hay que enfatizar que la
realimentacin ser efectiva.

1 Fase: Planificacin del proyecto.

Historias de usuario: El primer paso de cualquier proyecto que siga la

metodologa X.P es definir las historias de usuario con el cliente.
Las historias de usuario tienen la misma finalidad que los casos de uso pero con
algunas diferencias: Constan de 3 4 lneas escritas por el cliente en un
lenguaje no tcnico sin hacer mucho hincapi en los detalles; no se debe hablar
ni de posibles algoritmos para su implementacin ni de diseos de base de
datos adecuados, etc.
Son utilizadas para estimar tiempos de desarrollo de la parte de la aplicacin
que describen. Tambin se utilizan en la fase de pruebas, para verificar si la
aplicacin cumple con lo que especifica la historia de usuario.
Cuando llega la hora de implementar una historia de usuario, el cliente y los
desarrolladores se renen para concretar y detallar lo que tiene que hacer dicha
historia.
El tiempo de desarrollo ideal para una historia de usuario es entre 1 y 3
semanas.

Release planning: Tras definir las historias de usuario es necesario crear un plan
de publicaciones, en ingls "Release planning", donde se indiquen las historias
de usuario que se implementarn para cada versin de la aplicacin y las fechas
en las que se publicarn dichas versiones.
Un "Release planning" es una planificacin donde los desarrolladores y clientes
establecen los tiempos de implementacin ideales de las historias de usuario, la
prioridad con la que sern implementadas y las historias de usuario que sern
implementadas en cada versin del programa.

Despus de un "Release planning" tienen que estar claros estos cuatro factores:
los objetivos que se deben cumplir (que son principalmente las historias que se
deben desarrollar en cada versin), el tiempo que tardarn en desarrollarse y
publicarse las versiones de la aplicacin, el nmero de personas que trabajarn
en el desarrollo y cmo se evaluar la calidad del trabajo realizado.
Iteraciones. Todo proyecto que siga la metodologa X.P se ha de dividir en
iteraciones de aproximadamente 3 semanas de duracin. Al comienzo de cada
iteracin los clientes deben seleccionar las historias de usuario definidas en el
"Release planning" que sern implementadas. Tambin se seleccionan las
historias de usuario que no pasaron el test de aceptacin que se realiz al
terminar la iteracin anterior.
Estas historias de usuario son divididas en tareas de entre 1 y 3 das de
duracin cada una y sern asignadas a los programadores.
Velocidad del proyecto. La velocidad del proyecto es una medida que representa
la rapidez con la que se desarrolla el mismo; estimarla es muy sencillo: basta
con contar el nmero de historias de usuario que se pueden implementar en
una iteracin; de esta forma, se sabr el cupo de historias que se pueden
desarrollar en las distintas iteraciones.

Con la velocidad del proyecto controlaremos si todas las tareas se pueden

desarrollar en el tiempo dispuesto para la iteracin. Es conveniente reevaluar esta

medida cada 3 4 iteraciones y si se aprecia que no es adecuada hay que negociar
con el cliente un nuevo "Release Planning".

Programacin por pares. La metodologa X.P aconseja la programacin en

parejas pues incrementa la productividad y la calidad del software desarrollado.
El trabajo en pareja involucra a dos programadores trabajando en el mismo
equipo; mientras uno codifica haciendo hincapi en la calidad de la funcin o
mtodo que est implementando, el otro analiza si ese mtodo o funcin es
adecuado y est bien diseado. De esta forma se consigue un cdigo y diseo
con gran calidad.

Reuniones diarias. Es necesario que los desarrolladores se renan diariamente y

expongan sus problemas, soluciones e ideas de forma conjunta. Las reuniones
tienen que ser fluidas y todo el mundo debe tener voz y voto.

2 Fase: Diseo.

Diseos simples: La metodologa X.P sugiere que hay que conseguir diseos
simples y sencillos. Hay que procurar hacerlo todo lo menos complicado posible
para conseguir un diseo fcil de entender e implementar que a la larga costar
menos tiempo y esfuerzo desarrollar.

Glosarios de trminos: Usar una correcta especificacin de los nombres de

clases, mtodos y propiedades ayudar a comprender el diseo y facilitar
futuras ampliaciones y la reutilizacin del cdigo.
Riesgos: Si surgen problemas potenciales durante el diseo, X.P sugiere utilizar
una pareja de desarrolladores para que investiguen y reduzcan al mximo el
riesgo que supone ese problema.
Funcionalidad extra: Nunca se debe aadir funcionalidad extra al programa
aunque se piense que en un futuro ser utilizada. Slo el 10% de la misma es
utilizada lo que demuestra que el desarrollo de funcionalidad extra es un
desperdicio de tiempo y recursos.
Refactorizar. Consiste en mejorar el cdigo modificando su estructura sin alterar
su funcionalidad. Refactorizar supone revisar de nuevo la codificacin para
procurar optimizar su funcionamiento.

Es muy comn reutilizar cdigo ya creado que suele contener funcionalidades

que no sern utilizadas y diseos obsoletos; esto es un grave error porque
puede generar cdigo inestable y mal diseado; por este motivo, es necesario
refactorizar cuando se va a reutilizar cdigo.
Tarjetas C.R.C. El uso de las tarjetas C.R.C (Class, Responsabilities and
Collaboration) permiten al programador centrarse y apreciar el desarrollo
orientado a objetos olvidndose de los malos hbitos de la programacin
procedural clsica.

Las tarjetas C.R.C representan objetos; la clase a la que pertenece el objeto se

puede escribir en la parte de arriba de la tarjeta, en una columna a la izquierda se
pueden escribir las responsabilidades u objetivos que debe cumplir el objeto y a la
derecha, las clases que colaboran con cada responsabilidad.

3 Fase: Codificacin.
Como ya se dijo en la introduccin, el cliente es una parte ms del equipo de
desarrollo; su presencia es indispensable en las distintas fases de X.P. A la hora de
codificar una historia de usuario su presencia es an ms necesaria. No olvidemos que
los clientes son los que crean las historias de usuario y negocian los tiempos en los que
sern implementadas. Antes del desarrollo de cada historia de usuario el cliente debe
especificar detalladamente lo que sta har y tambin tendr que estar presente
cuando se realicen los test que verifiquen que la historia implementada cumple la
funcionalidad especificada.
La codificacin debe hacerse ateniendo a estndares y patrones de codificacin ya
creados. Programar bajo estndares mantiene el cdigo consistente y facilita su
comprensin y la escalabilidad.
Crear test que prueben el funcionamiento de los distintos cdigos implementados nos
ayudar a desarrollar dicho cdigo. Crear estos test antes nos ayuda a saber qu es
exactamente lo que tiene que hacer el cdigo a implementar y sabremos que una vez
implementado pasar dichos test sin problemas ya que dicho cdigo ha sido diseado
para ese fin. Se puede dividir la funcionalidad que debe cumplir una tarea a programar
en pequeas unidades, de esta forma se crearn primero los test para cada unidad y a
continuacin se desarrollar dicha unidad, as poco a poco conseguiremos un desarrollo
que cumpla todos los requisitos especificados.
Como ya mencionamos, X.P opta por la programacin en pareja ya que permite un
cdigo ms eficiente y con una gran calidad.
X.P sugiere un modelo de trabajo usando repositorios de cdigo dnde las parejas de
programadores publican cada pocas horas sus cdigos implementados y corregidos
junto a los test que deben pasar. De esta forma el resto de programadores que
necesiten cdigos ajenos trabajarn siempre con las ltimas versiones. Para mantener
un cdigo consistente, publicar un cdigo en un repositorio es una accin exclusiva
para cada pareja de programadores.
X.P tambin propone un modelo de desarrollo colectivo en el que todos los
programadores estn implicados en todas las tareas; cualquiera puede modificar o
ampliar una clase o mtodo de otro programador si es necesario y subirla al repositorio
de cdigo. El permitir al resto de los programadores modificar cdigos que no son
suyos no supone ningn riesgo ya que para que un cdigo pueda ser publicado en el
repositorio tiene que pasar los test de funcionamiento definidos para el mismo.
La optimizacin del cdigo siempre se debe dejar para el final. Hay que hacer que
funcione y que sea correcto, ms tarde se puede optimizar.

X.P afirma que la mayora de los proyectos que necesiten ms tiempo extra que el
planificado para ser finalizados no podrn ser terminados a tiempo se haga lo que se
haga, aunque se aadan ms desarrolladores y se incrementen los recursos. La
solucin que plantea X.P es realizar un nuevo "Release planning" para concretar los
nuevos tiempos de publicacin y de velocidad del proyecto.

4 Fase: Pruebas. Uno de los pilares de la metodologa X.P es el uso de test para
comprobar el funcionamiento del cdigo que estamos desarrollando.
El uso de los test en X.P es el siguiente:

Se deben crear los test con frameworks especficos para tests (JUnit, por
ejemplo para Java).
Hay que someter a test las distintas clases del sistema omitiendo los mtodos
ms triviales.
Se deben crear los test que se aplicarn a una clase/mtodo antes de
implementarla; en el apartado anterior se explic la importancia de crear antes
los test que el cdigo.

Un punto importante es crear test que no tengan ninguna dependencia del cdigo que
en un futuro evaluar. Hay que crear los test abstrayndose del futuro cdigo, de esta
forma aseguraremos la independencia del test respecto al cdigo que evala.
Como se coment anteriormente los distintos test se deben subir al repositorio de
cdigo acompaados del cdigo que verifican. Ningn cdigo puede ser publicado en el
repositorio sin que haya pasado su test de funcionamiento, de esta forma, aseguramos
el uso colectivo del cdigo (explicado en el apartado anterior).
El uso de los test es adecuado para observar la refactorizacin. Los test permiten
verificar que un cambio en la estructura de un cdigo no tiene porqu cambiar su
funcionamiento. Para finalizar, un nuevo concepto.

Test de aceptacin: Los test mencionados anteriormente sirven para evaluar

las distintas tareas en las que ha sido dividida una historia de usuario. Para
asegurar el funcionamiento final de una determinada historia de usuario se
deben crear "Test de aceptacin"; estos test son creados y usados por los
clientes para comprobar que las distintas historias de usuario cumplen su
cometido.

Bibliografa.

http://www.extremeprogramming.org
[NEWK, 2002] NEWKIRK, J. "La programacin extrema en la prctica". Ed.
Pearson Education, Madrid, 2002.
[STEP, 2003] STEPHENS, M., ROSENBERG,D. "Extreme programming
refactored: the case against X.P". Ed. Berkeley, California, 2003.