"Ao de la Diversificacin Productiva y del Fortalecimiento de la Educacin"

UNIVERSIDAD NACIONAL DE
TRUJILLO
ESCUELA ACADMICO PROFESIONAL DE INGENIERA DE
SISTEMAS
TEMA:
PROGRAMACIN EXTREMA

ALUMNOS:
Alcalde Moncada Jhonatan
Campos Cabanillas Walter Wilmer
De Pirola Chvez Luis Alberto
Ulfe Isla Jos Alberto

CURSO:
Ingeniera de Software Aplicada a Objetos

CICLO:
VIII

Guadalupe Per
2015

UNIVERSIDAD NACIONAL DE TRUJILLO

Contenido
Captulo I Introduccin y Resea Histrica..................................................................7
Introduccin....................................................................................................... 8
Resumen.......................................................................................................... 11
Abstract........................................................................................................... 12
1.

Resea Histrica......................................................................................... 13

2.

Conceptos Generales.................................................................................... 15

3.

Definicin.................................................................................................. 15

4.

Posturas a favor y en contra..........................................................................16

5.

Principios Bsicos........................................................................................ 16
5.1.

Retroalimentacin a escala fina................................................................16

5.2.

Proceso continuo en lugar de por lotes.......................................................18

5.3.

Entendimiento compartido......................................................................19

5.4.

Bienestar del programador......................................................................20

Captulo II Fases de la metodologa XP.....................................................................22

1.

Proceso de desarrollo.................................................................................... 23

2.

Interaccin con el cliente............................................................................... 23

3.

Historia de Usuario...................................................................................... 23
3.1.

En la primera fase................................................................................. 23

3.2.

En la segunda fase................................................................................. 24

4.

Planificacin del proyecto.............................................................................. 25

5.

Diseo, desarrollo, pruebas............................................................................26

6.

Metfora.................................................................................................... 27

7.

Fases de la metodologa XP............................................................................29

8.

7.1.

Fase: Planificacin del proyecto...............................................................29

7.2.

Fase: Diseo......................................................................................... 31

7.3.

Fase: Codificacin................................................................................. 32

7.4.

Fase: Pruebas....................................................................................... 32

Valores de la metodologa XP.........................................................................34

8.1.

Simplicidad.......................................................................................... 34

8.2.

Comunicacin....................................................................................... 35

8.3.

Retroalimentacin................................................................................. 35

METODOLOGOGA XP

8.4.
9.

Coraje o valenta................................................................................... 36

Ventajas y Desventajas de la Metodologa XP....................................................36

10.

Inconvenientes......................................................................................... 36

11.

Herramientas empleadas en XP...................................................................37

11.1.

JAVA............................................................................................... 37

11.2.

NETBeans........................................................................................ 37

11.3.

JUnit............................................................................................... 37

11.4.

JasperReport e IReport.......................................................................37

11.5.

PostgreSQL...................................................................................... 38

12.

Tablas Comparativas de las Metodologas SCRUM y XP..................................38

12.1.

Semejanzas....................................................................................... 38

12.2.

Diferencias........................................................................................ 39

13.

Personas que intervienen en la Metodologa XP..............................................39

Captulo III Conclusiones....................................................................................... 54

14.

Conclusiones........................................................................................... 55

ndice de tablas
TABLA 1. PUNTOS A FAVOR Y EN CONTRA......................................................................16
TABLA 2. PRUEBAS DE ACEPTACIN..............................................................................17
TABLA 3. HISTORIA DE USUARIO...................................................................................25
TABLA 4. VENTAJAS Y DESVENTAJAS DE LA METODOLOGA XP.....................................36
TABLA 5. COMPARACIN ENTRE METODOLOGAS........................................................39

ndice de figuras
FIGURA 1....................................................................................................................... 21
FIGURA 2....................................................................................................................... 21
FIGURA 3....................................................................................................................... 28
FIGURA 4....................................................................................................................... 33
FIGURA 5....................................................................................................................... 34

Captulo I
Introduccin y Resea Histrica
Introduccin
En las dos ltimas dcadas las notaciones de modelado y posteriormente las herramientas
pretendieron ser las "balas de plata" para el xito en el desarrollo de software, sin embargo,
las expectativas no fueron satisfechas. Esto se debe en gran parte a que otro importante
elemento, la metodologa de desarrollo, haba sido postergado. De nada sirven buenas
notaciones y herramientas si no se proveen directivas para su aplicacin. As, esta dcada
ha comenzado con un creciente inters en metodologas de desarrollo. Hasta hace poco el
proceso de desarrollo llevaba asociada un marcado nfasis en el control del proceso
mediante una rigurosa definicin de roles, actividades y artefactos, incluyendo modelado y
documentacin detallada. Este esquema "tradicional" para abordar el desarrollo de software
ha demostrado ser efectivo y necesario en proyectos de gran tamao (respecto a tiempo y
recursos), donde por lo general se exige un alto grado de ceremonia en el proceso. Sin
embargo, este enfoque no resulta ser el ms adecuado para muchos de los proyectos
actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir
drsticamente los tiempos de desarrollo pero manteniendo una alta calidad. Ante las
dificultades para utilizar metodologas tradicionales con estas restricciones de tiempo y
flexibilidad, muchos equipos de desarrollo se resignan a prescindir del buen hacer de la
ingeniera del software, asumiendo el riesgo que ello conlleva. En este escenario, las
metodologas giles emergen como una posible respuesta para llenar ese vaco
metodolgico. Por estar especialmente orientadas para proyectos pequeos, las
metodologas giles constituyen una solucin a medida para ese entorno, aportando una
elevada simplificacin que a pesar de ello no renuncia a las prcticas esenciales para
asegurar la calidad del producto.
Las metodologas giles son sin duda uno de los temas recientes en ingeniera de software
que estn acaparando gran inters. Prueba de ello es que se estn haciendo un espacio
destacado en la mayora de conferencias y workshops celebrados en los ltimos aos. Es tal

su impacto que actualmente existen 4 conferencias internacionales de alto nivel y

especficas sobre el tema1. Adems ya es un rea con cabida en prestigiosas revistas
internacionales. En la comunidad de la ingeniera del software, se est viviendo con
intensidad un debate abierto entre los partidarios de las metodologas tradicionales
(referidas peyorativamente como "metodologas pesadas") y aquellos que apoyan las ideas
emanadas del "Manifiesto gil"2. La curiosidad que siente la mayor parte de ingenieros de
software, profesores, e incluso alumnos, sobre las metodologas giles hace prever una
fuerte proyeccin industrial. Por un lado, para muchos equipos de desarrollo el uso de
metodologas tradicionales les resulta muy lejano a su forma de trabajo actual considerando
las dificultades de su introduccin e inversin asociada en formacin y herramientas. Por
otro, las caractersticas de los proyectos para los cuales las metodologas giles han sido
especialmente pensadas se ajustan a un amplio rango de proyectos industriales de desarrollo
de software; aquellos en los cuales los equipos de desarrollo son pequeos, con plazos
reducidos, requisitos voltiles, y/o basados en nuevas tecnologas.

Proceso : conjunto de actividades ordenadas para lograr una serie de objetivos

Proceso Pesado :
* Fuerte dependencia de planificaciones
* Se establecen actividades
* Se establecen artefactos
* Se establecen herramientas y notaciones
* ESTAMOS MUY CONTROLADOS

Como contraposicin: Metodologa gil

Caractersticas:

A los individuos y su interaccin por encima de los procesos y las herramientas

El software que funciona por encima de la documentacin exhaustiva
La colaboracin con el cliente por encima la negociacin contractual
La respuesta al cambio por encima seguimiento de un plan

Resumen
* Estamos menos controlado
* Preparados para el cambio
* Cliente forma parte del equipo
* Pocos artefactos
* Ms importante software funcionando que documentacin

Estadsticas : mtodo que ms popularidad ha alcanzado de las metodologas giles

Se basa en la suposicin de que es posible desarrollar software de gran calidad a
pesar, o incluso como consecuencia del cambio continuo
Asume que con un poco de planificacin, un poco de codificacin y unas pocas
pruebas se puede decidir si se est siguiendo un camino acertado o equivocado,
evitando as tener que echar marcha atrs demasiado tarde.

Valores que inspiran XP

Simplicidad: La simplicidad consiste en desarrollar slo el sistema que realmente se

necesita. Implica resolver en cada momento slo las necesidades actuales. Los
costos y la complejidad de predecir el futuro son muy elevados, y la mejor forma de
acertar es esperar al futuro. Con este principio de simplicidad, junto con la
comunicacin y el feedback resulta ms fcil conocer las necesidades reales

Feedback: Una metodologa basada en el desarrollo incremental iterativo de

pequeas partes, con entregas y pruebas frecuentes y continuas, proporciona un
flujo de retro-informacin valioso para detectar los problemas o desviaciones.
De esta forma fallos se localizan muy pronto.
La planificacin no puede evitar algunos errores, que slo se evidencian al
desarrollar el sistema.
La retro-informacin es la herramienta que permite reajustar la agenda y los
planes.

Coraje:
Implica saber tomar decisiones difciles.
Reparar un error cuando se detecta
Mejorar el cdigo siempre que tras el feedback y las sucesivas iteraciones se
manifieste susceptible de mejora
Tratar rpidamente con el cliente los desajustes de agendas para decidir qu partes y
cundo se van a entregar

Comunicacin: XP pone en comunicacin directa y continua a clientes y

desarrolladores. El cliente se integra en el equipo para establecer prioridades y
resolver dudas. De esta forma ve el avance da a da, y es posible ajustar la agenda y
las funcionalidades de forma consecuente

Resumen
El desarrollo de software no es una tarea fcil. Prueba de ello es que existen numerosas
propuestas metodolgicas que inciden en distintas dimensiones del proceso de desarrollo.
Por una parte tenemos aquellas propuestas ms tradicionales que se centran especialmente
en el control del proceso, estableciendo rigurosamente las actividades involucradas, los
artefactos que se deben producir, y las herramientas y notaciones que se usarn. Estas
propuestas han demostrado ser efectivas y necesarias en un gran nmero de proyectos, pero
tambin han presentado problemas en otros muchos. Una posible mejora es incluir en los
procesos de desarrollo ms actividades, ms artefactos y ms restricciones, basndose en
los puntos dbiles detectados. Sin embargo, el resultado final sera un proceso de desarrollo
ms complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el
proyecto. Otra aproximacin es centrarse en otras dimensiones, como por ejemplo el factor
humano o el producto software. Esta es la filosofa de las metodologas giles, las cuales
dan mayor valor al individuo, a la colaboracin con el cliente y al desarrollo incremental
del software con iteraciones muy cortas. Este enfoque est mostrando su efectividad en
proyectos con requisitos muy cambiantes y cuando se exige reducir drsticamente los
tiempos de desarrollo pero manteniendo una alta calidad. Las metodologas giles estn
revolucionando la manera de producir software, y a la vez generando un amplio debate
entre sus seguidores y quienes por escepticismo o convencimiento no las ven como
alternativa para las metodologas tradicionales. En este trabajo se presenta resumidamente
el contexto en el que surgen las metodologas giles, sus valores, principios y
comparaciones con las metodologas tradicionales. Adems se describe con mayor detalle
Programacin Extrema (eXtreme Programming, XP) la metodologa gil ms popular en la
actualidad.
Palabras Clave:

Procesos de software, Metodologas giles, Programacin Extrema

(eXtreme Programming)

Abstract
The development of software is not an easy task. The proof for that is the fact that there are
many methodological proposals that affect different dimensions of the development
process. On one hand, we can find more traditional proposals, which are specially centred
in the control of the process by rigorously setting the involved activities, the devices that
are due to produce, and the tools and annotations that will be used. These proposals have
demonstrated to be effective and necessary in a great number of projects, but also they have
presented problems in others. A possible improvement for that is to include more activities,
devices and restrictions in the development processes, which is based on the weak points
that were detected. Nevertheless, the final result would be a more-complex process of
development which can even limit the own ability of the equipment to develop the project.
Another approach is focusing in other dimensions, for example the human factor or the
software product. This is the philosophy of the agile methodologies, which give greater
value to the individual, to the collaboration with the client and the incremental development
of software with very short iterations. This approach is presenting its effectiveness in
projects with changing requirements and when it is demanded to reduce drastically the
times of development but maintaining a high quality. The agile methodologies are
revolutionizing the way to produce software and, at the same time, they are generating an
considerable debate between their followers and the ones that, by scepticism or conviction,
do not see them as an alternative for traditional methodologies. In this work it is briefly
presented the context in which the agile methodologies emerge, their values, principles and
comparisons with traditional methodologies. In addition, it is described in detail the most
popular agile methodology at the present time: eXtreme Programming.
Key-words: Software process; agile methods; eXtreme Programming

1. Resea Histrica
La programacin extrema, como proceso de creacin de software diferente al
convencional, nace de la mano de Kent Beck (gur de la XP y autor de los libros ms
influyentes sobre el tema).
Chrysler Corporation haca tiempo que estaba desarrollando una aplicacin de nminas,
pero sin demasiado xito por parte de la gente que tena en el proyecto. El verano de
1996, Beck entr en nmina en la compaa y se le pidi de hacer esta aplicacin como
trabajo. Es en esta aplicacin cuando nace la Programacin Extrema como tal.
Beck reconoci que el proceso (o metodologa) de creacin de software o la carencia de
este era la causa de todos los problemas y lleg a la conclusin 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 tenan que acomodar al cambio a
realizar.
l estaba convencido que la mejor metodologa era un proceso que enfatizase la
comunicacin dentro del equipo, que la implementacin fuera sencilla, que el usuario
tena que estar muy informado e implicado y que la toma de decisiones tena que ser
muy rpida y efectiva.
Los autores (o mejor dicho, los propulsores como el propio Kent Beck, Ward
Cunningham o Ron Jeffries entre otros) de la Programacin Extrema, fueron a la web
Portland Pattern Repository y empezaron a hablar de ella y promocionarla, de lo que era
y cmo realizarla. Estos propulsores de la XP hablaban de ella en cada ocasin que
tenan y en cada pgina que, poco o mucho hablara de temas de programacin.
Beck invit a Ron Jeffries al proyecto para ayudar a desarrollar y perfeccionar estos
mtodos. Jeffries partir de entonces actu como un entrenador para inculcar las
prcticas, hbitos en el equipo C3.
La informacin sobre los principios y prcticas detrs de XP se difundi al resto del
mundo a travs de discusiones en el wiki original, WikiWikiWeb de Cunningham.
Varios colaboradores discuten y se expandieron en las ideas, y algunas metodologas
spin-off resultado. Adems, se han explicado los conceptos XP, desde hace varios aos,

con

un

mapa

del

sistema

de

hipertexto

en

el

sitio

web

en

XP

"http://www.extremeprogramming.org" alrededor de 1999.

Beck edit una serie de libros sobre XP, empezando por su propia Programacin
Extrema Explicada, difundiendo sus ideas a una mucho ms grande, pero muy
receptivo, audiencia. Los autores de la serie pasaron por diversos aspectos que asisten a
XP y sus prcticas.

2. Conceptos Generales
Las metodologas giles (como por ejemplo XP, SCRUM, DSDM, Crystal, etc.) forman
parte del movimiento de desarrollo gil de sotfware, que se basan en la adaptabilidad de
cualquier cambio como medio para aumentar las posibilidades de xito de un proyecto.
De forma que una metodologa gil es la que tiene como principios que:

Los individuos y sus interacciones son ms importantes que los procesos y las

herramientas.
El software que funciona es ms importante que la documentacin exhaustiva.
La colaboracin con el cliente en lugar de la negociacin de contratos.
La respuesta delante del cambio en lugar de seguir un plan cerrado.

Se puede decir que, este movimiento empez a existir a partir de febrero de 2001,
cuando se reunieron los representantes de cada una de estas metodologas y terminaron
poniendo en comn sus ideas en una declaracin conjunta.
3. Definicin
La programacin extrema es una metodologa de desarrollo ligera (o gil) basada en
una serie de valores y de prcticas de buenas maneras que persigue el objetivo de
aumentar la productividad a la hora de desarrollar programas.
Este modelo de programacin se basa en una serie de metodologas de desarrollo de
software en la que se da prioridad a los trabajos que dan un resultado directo y que
reducen la burocracia que hay alrededor de la programacin.
Una de las caractersticas principales de este mtodo de programacin, es que sus
ingredientes son conocidos desde el principio de la informtica. Los autores de XP han
seleccionado aquellos que han considerado mejores y han profundizado en sus
relaciones y en cmo se refuerzan los unos con los otros. El resultado de esta seleccin
ha sido esta metodologa nica y compacta. Por esto, aunque no est basada en
principios nuevos, s que el resultado es una nueva manera de ver el desarrollo de
software.

El objetivo que se persegua en el momento de crear esta metodologa era la bsqueda

de un mtodo que hiciera que los desarrollos fueran ms sencillos. Aplicando el sentido
comn.
4. Posturas a favor y en contra
Tabla 1. Puntos a favor y en contra
A favor

En contra

X.P. slo funcionar con gente buena, es Los programadores tienen un acusado
decir, profesionales que son capaces de sentimiento de posesin del cdigo y esta
hacer un buen diseo, sencillo y a la vez postura no encaja con la filosofa de X.P.
fcilmente ampliable.
Tambin se ve un fuerte sentimiento para
Por otro lado se ha de recalcar que XP no respectar las 40 horas semanales, y X.P. no
ha

inventado

ningn

mtodo

nuevo, lo garantiza.

sencillamente ha recogido mtodos ya

existentes y los ha agrupado, y ha Los jefes de proyecto tambin expresan su
comprobado que funcionen.

recelo

con

este

mtodo

tan

poco

tradicional.
Fuente: (Elaboracin propia, 2014)
5. Principios Bsicos
La programacin extrema se basa en 12 principios bsicos agrupados en cuatro
categoras:
5.1. Retroalimentacin a escala fina
5.1.1. El principio de pruebas
Se tiene que establecer un periodo de pruebas de aceptacin del programacin
(llamada tambin periodo de caja negra) donde se definirn las entradas al
sistema y los resultados esperados de estas entradas. Es muy recomendable
automatizar estas pruebas para poder hacer varias simulaciones del sistema del
sistema en funcionamiento. Para hacer estas simulaciones automatizadas, se
puede utilizar Ambientes de Prueba (Unit testing frameworks).

Tabla 2. Pruebas de Aceptacin

Caso de Prueba
Nmero Caso de Prueba:
Descripcin:

Nmero Historia de Usuario:

Condiciones de ejecucin:
Entradas:
Resultado esperado:
Evaluacin:
Fuente: (Elaboracin propia, 2014)
5.1.2. Proceso de planificacin
En esta fase, el usuario tendr que escribir sus necesidades, definiendo las
actividades que realizar el sistema. Se crear un documento llamado Historias
del usuario (User Stories). Entre 20 y 80 historias (todo dependiendo de la
complejidad del problema) se consideran suficientes para formar el llamado
Plan de Liberacin, el cual define de forma especfica los tiempos de entrega
de la aplicacin para recibir retroalimentacin por parte del usuario.
Son muy importantes y tienen que ser una constante las reuniones peridicas
durante esta fase de planificacin. Estas pueden ser a diario, con todo el equipo
de desarrollo para identificar problemas, proponer soluciones y sealar
aquellos puntos a los que se les ha de dar ms importancia por su dificultad o
por su punto crtico.
5.1.3. El cliente en el sitio
Se le dar poder para determinar los requerimientos, definir la funcionalidad,
sealar las prioridades y responder las preguntas de los programadores. Esta
fuerte interaccin cara a cara con el programador disminuye el tiempo de
comunicacin y la cantidad de documentacin, junto con los altos costes de su
creacin y mantenimiento.
5.1.4. Programacin en parejas
Uno de los principios ms radicales y en el que la mayora de gerentes de
desarrollo pone sus dudas. Requiere que todos los programadores XP escriban

su cdigo en parejas, compartiendo una sola mquina. De acuerdo con los

experimentos, este principio puede producir aplicaciones ms buenas, de
manera consistente, a iguales o menores costes.
5.2. Proceso continuo en lugar de por lotes
5.2.1. Integracin continua
Permite al equipo hacer un rpido progreso implementando las nuevas
caractersticas del software. En lugar de crear builds (o versiones) estables de
acuerdo a un cronograma establecido, los equipos de programadores XP
pueden reunir su cdigo y reconstruir el sistema varias veces al da. Esto
reduce los problemas de integracin comunes en proyectos largos y estilo
cascada.
5.2.2. Refactorizacin
Permite a los equipos de programadores XP mejorar el diseo del sistema a
travs de todo el proceso de desarrollo. Los programadores evalan
continuamente el diseo y recodifican lo necesario. La finalidad es mantener
un sistema enfocado a proveer el valor de negocio mediante la minimizacin
del cdigo duplicado y/o ineficiente.
5.2.3. Entregas pequeas
Colocan un sistema sencillo en produccin rpidamente que se actualiza de
forma rpida y constante permitiendo que el verdadero valor de negocio del
producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las
2 o 3 semanas como mximo.
5.3. Entendimiento compartido
5.3.1. Diseo simple
Se basa en la filosofa de que el mayor valor de negocio es entregado por el
programa ms sencillo que cumpla los requerimientos. Simple Design se
enfoca en proporcionar un sistema que cubra las necesidades inmediatas del
cliente, ni ms ni menos. Este proceso permite eliminar redundancias y
rejuvenecer los diseos obsoletos de forma sencilla.

5.3.2. Metfora
Desarrollada por los programadores al inicio del proyecto, define una historia
de cmo funciona el sistema completo. XP estimula historias, que son breves
descripciones de un trabajo de un sistema en lugar de los tradicionales
diagramas y modelos UML (Unified Modeling Language). La metfora
expresa la visin evolutiva del proyecto que define el alcance y propsito del
sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboracin) tambin
ayudarn al equipo a definir actividades durante el diseo del sistema. Cada
tarjeta representa una clase en la programacin orientada a objetos y define sus
responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases
(cmo se comunica con ellas).
5.3.3. Propiedad colectiva del cdigo
Un cdigo con propiedad compartida. Nadie es el propietario de nada, todos
son el propietario de todo. Este mtodo difiere en mucho a los mtodos
tradicionales en los que un simple programador posee un conjunto de cdigo.
Los defensores de XP argumentan que mientras haya ms gente trabajando en
una pieza, menos errores aparecern.
5.3.4. Estndar de codificacin
Define la propiedad del cdigo compartido as como las reglas para escribir y
documentar el cdigo y la comunicacin entre diferentes piezas de cdigo
desarrolladas por diferentes equipos. Los programadores las han de seguir de
tal manera que el cdigo en el sistema se vea como si hubiera estado escrito
por una sola persona.
5.4. Bienestar del programador
5.4.1. La semana de 40 horas
La programacin extrema sostiene que los programadores cansados escriben
cdigo de menor cualidad. Minimizar las horas extras y mantener los
programadores frescos, generar cdigo de mayor calidad.
Fuente: (Elaboracin propia, 2014)

Figura
Figura21

Fuente: (Elaboracin propia, 2015)

Captulo II
Fases de la metodologa XP

1. Proceso de desarrollo
La programacin extrema parte del caso habitual de una compaa que desarrolla
software, normalmente a medida, en la que hay diferentes roles: un equipo de gestin (o
diseo), uno de desarrollo y los clientes finales. La relacin entre el equipo de diseo,
los que desarrollan el software y clientes es totalmente diferente al que se ha producido
en las metodologas tradicionales, que se basaba en una fase de captura de los requisitos
previa al desarrollo, y de una fase de validacin posterior al mismo.
2. Interaccin con el cliente
En este tipo de programacin el cliente pasa a ser parte implicada en el equipo de
desarrollo. Su importancia es mxima en el momento de tratar con los usuarios y en
efectuar las reuniones de planificacin. Tiene un papel importante de interaccin con el
equipo de programadores, sobre todo despus de cada cambio, y de cada posible
problema localizado, mostrando las prioridades. En este tipo de programacin existirn
pruebas de aceptacin de la programacin que ayudarn a que su labor sea lo ms
provechosa posible.
Al fin y al cabo, el cliente se encuentra mucho ms cerca del proceso de desarrollo. Se
elimina la fase inicial de recopilacin de requerimientos, y se permite que stos se
vayan cogiendo a lo largo del proyecto, de una manera ordenada. De esta forma se
posibilita que el cliente pueda ir cambiando de opinin sobre la marcha, pero a cambio
han de estar siempre disponibles para solucionar las dudas del equipo de desarrollo.
3. Historia de Usuario
En XP aparece un nuevo concepto llamado Historia de usuario. Se trata de una lista
de caractersticas que el cliente necesita que existan en el producto final. Estas constan
de dos fases.
3.1. En la primera fase
El cliente describe con sus propias palabras las caractersticas y, es el responsable
del equipo, el encargado de informarlo de las dificultades tcnicas de cada una de
ellas y de su coste. A consecuencia de este dilogo, el cliente deja por escrito un
conjunto de historias y las ordena en funcin de la prioridad que tienen para l. De
esta manera ya es posible definir unas fechas aproximadas para ellos.

3.2. En la segunda fase

El cliente coger las primeras historias a implementar y las dividir en trabajos a
realizar. El cliente tambin participa, pero hay ms peso por parte del equipo de
desarrolladores, esto dar como resultado una planificacin ms exacta. Este
mtodo se repetir para cada historia.
A diferencia de otras tcnicas, como puede ser UML, en el caso de XP, se exige que
sea el cliente el encargado de escribir los documentos con las especificaciones de lo
que realmente quiere, como un documento de requisitos de usuario.
En esta fase, el equipo tcnico ser el encargado de catalogar las historias del cliente
y asignarles una duracin. La norma es que cada historia de usuario tiene que poder
ser realizable en un espacio entre una y tres semanas de programacin. Las que
requieran menos tiempo sern agrupadas, y las que necesiten ms sern modificadas
o divididas.
Finalmente decir que las historias de los usuarios sern escritas en tarjetas, lo que
facilitar que el cliente pueda especificar la importancia relativa entre las diferentes
historias de usuario, as como el trabajo de los programadores que podrn
catalogarlas correctamente. Este formato tambin es muy til en el momento de las
pruebas de aceptacin.

Tabla 3. Historia de Usuario

Historia de Usuario
Nmero: 1
Usuario: Autor
Modificacin de Historia Nmero:
Prioridad
en
Negocio:

Nombre: Enviar artculo

Iteracin Asignada: 2
Alta Puntos Estimados:

(Alta/Media/Baja)
Riesgos en Desarrollo:
Descripcin

Puntos Reales:

Se introducen los datos del artculo (ttulo, fichero adjunto, resumen, tpicos) y de los
autores (nombre, e-mail, afiliacin). Uno de los autores debe indicarse como autor de
contacto. El sistema confirma la correcta recepcin del artculo enviando un e-mail al
autor de contacto con un userid y password para que el autor pueda posteriormente
acceder al artculo.
Observaciones:
Fuente: (Elaboracin propia, 2015)
4. Planificacin del proyecto
En este punto se tendr que elaborar la planificacin por etapas, donde se aplicarn
diferentes iteraciones. Para hacerlo ser necesaria la existencia de reglas que se han de
seguir por las partes implicadas en el proyecto para que todas las partes tengan voz y se
sientan realmente partcipes de la decisin tomada.
Las entregas se tienen que hacer cuanto antes mejor, y con cada iteracin, el cliente ha
de recibir una nueva versin. Cuanto ms tiempo se tarde en introducir una parte
esencial, menos tiempo se tendr para trabajar con ella despus. Se aconseja muchas
entregas y muy frecuentes. De esta manera un error en la parte inicial del sistema tiene
ms posibilidades de detectarse rpidamente.
Una de las mximas a aplicar es, los cambios, no han de suponer ms horas de
programacin para el programador, ya que el que no se termina en un da, se deja para
el da siguiente.
Se ha de tener asumido que en el proceso de planificacin habrn errores, es ms, sern
comunes, y por esto esta metodologa ya los tiene previstos, por lo tanto se establecern

mecanismos de revisin. Cada tres o cinco iteraciones es normal revisar las historias de
los usuarios, y renegociar la planificacin.
Cada iteracin necesita tambin ser planificada, es lo que se llama planificacin
iterativa, en la que se anotarn las historias de usuarios que se consideren esenciales y
las que no han pasado las pruebas de aceptacin. Estas planificaciones tambin se harn
en tarjetas, en las que se escribirn los trabajos que durarn entre uno y tres das.
Es por esto que el diseo se puede clasificar como continuo. Aade agilidad al proceso
de desarrollo y evita que se mire demasiado hacia delante, desarrollando trabajos que
an no han estado programados.
Este tipo de planificacin en iteraciones y el diseo iterativo, hace que aparezca una
prctica que no exista en la programacin tradicional. Se trata de las discusiones diarias
informales, para fomentar la comunicacin, y para hacer que los desarrolladores tengan
tiempo de hablar de los problemas a los que se enfrentan y de ver cmo van con sus
trabajos.
5. Diseo, desarrollo, pruebas
El desarrollo es la parte ms importante en el proceso de la programacin extrema.
Todos los trabajos tienen como objetivo que se programen lo ms rpidamente posible,
sin interrupciones y en direccin correcta.
Tambin es muy importante el diseo, y se establecen los mecanismos, para que ste
sea revisado y mejorado de manera continuada a lo largo del proyecto, segn se van
aadiendo funcionalidades al mismo.
La clave del proceso de desarrollar XP es la comunicacin. La mayora de los
problemas en los proyectos son por falta de comunicacin en el equipo.
6. Metfora
En XP, aparece un nuevo concepto llamado Metfora. Su principal objetivo es mejorar
la comunicacin entre todos los integrantes del equipo, al crear una visin global y
comn de lo que se quiere desarrollar. La metfora tiene que ser expresada en trminos
conocidos por los integrantes del equipo, por ejemplo comparando el sistema que se
desarrollar con alguna cosa de la vida real.

Antes de empezar a codificar se tienen que hacer pruebas unitarias, es decir:

Cada vez que se quiere implementar una parte de cdigo, en XP, se tiene que escribir
una prueba sencilla, y despus escribir el cdigo para que la pase. Una vez pasada se
ampla y se contina. En XP hay una mxima que dice "Todo el cdigo que puede fallar
tiene que tener una prueba".
Con estas normas se obtiene un cdigo simple y funcional de manera bastante rpida.
Por esto es importante pasar las pruebas al 100%
Respecto a la integracin del software, en XP se ha de hacer una integracin continua,
es decir, cada vez se tienen que ir integrando pequeos fragmentos de cdigo, para
evitar que al finalizar el proyecto se tenga que invertir grandes esfuerzos en la
integracin final. En todo buen proyecto de XP, tendra que existir una versin al da
integrada, de manera que los cambios siempre se realicen en esta ltima versin.
Otra peculiaridad de XP es que cada programador puede trabajar en cualquier parte del
programa.
De esta manera se evita que haya partes "propietarias de cada programador". Por esto es
tan importante la integracin diaria.
Para terminar, otra peculiaridad que tiene la XP. La de fomentar la programacin en
parejas, es decir, hacer que los programadores no trabajen en solitario, sino que siempre
estarn con otra persona. Una pareja de programadores ha de compartir el teclado, el
monitor y el ratn. El principio fundamental de este hecho es realizar de manera
continua y sin parar el desarrollo de cdigo. Las parejas tienen que ir cambiando de
manera peridica, para hacer que el conocimiento se difunda en el grupo. Est
demostrado que de esta manera el trabajo es ms eficaz y tambin se consigue ms y
mejor cdigo.

Figura 3
Fuente: (Elaboracin propia, 2015)

7. Fases de la metodologa XP
7.1. Fase: Planificacin del proyecto
7.1.1. 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 o 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 usadas para estimar tiempos de desarrollo de la parte de la aplicacin

que describen.
Tambin se utilizan en la fase de pruebas, para verificar si el programa

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.

Similar a los Casos de Uso
Usadas para estimaciones de tiempo en la planificacin de las liberaciones
Usados en lugar del Documento de Requerimientos
Escritas por el Cliente en trminos del Cliente
Guan la creacin de Pruebas de Aceptacin

7.1.2. Release Planning

Despus de tener ya definidas las historias de usuario es necesario crear un
plan de publicaciones, en ingls "Release plan", donde se indiquen las historias
de usuario que se crearn para cada versin del programa y las fechas en las
que se publicarn estas versiones. Un "Release plan" 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 que sern implementadas en cada versin del programa.
Despus de un "Release plan" 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 del

programa.
El nmero de personas que trabajarn en el desarrollo.
Y Cmo se evaluar la calidad del trabajo realizado. (*Release plan:
Planificacin de publicaciones).

7.1.3. 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 que se asignarn a los programadores.
7.1.4. La velocidad del proyecto
Es una medida que representa la rapidez con la que se desarrolla el proyecto;
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. Usando la
velocidad del proyecto controlaremos que todas las tareas se puedan
desarrollar en el tiempo del que dispone la iteracin. Es conveniente reevaluar
esta medida cada 3 o 4 iteraciones y si se aprecia que no es adecuada hay que
negociar con el cliente un nuevo "Release Plan".
7.1.5. Programacin en Parejas
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.
7.1.6. 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 tiene que tener voz y voto.
7.2. Fase: Diseo
7.2.1. 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 fcilmente entendible e que se pueda implementar que a la larga costar
menos tiempo y esfuerzo desarrollar.
7.2.2. Glosarios de Trminos
Usar glosarios de trminos y una correcta especificacin de los nombres de
mtodos y clases ayudar a comprender el diseo y facilitar sus posteriores
ampliaciones y la reutilizacin del cdigo.
7.2.3. 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.
7.2.4. Funcionabilidad 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 implica
que el desarrollo de funcionalidad extra es un desperdicio de tiempo y
recursos.
7.2.5. Refactorizar
Refactorizar es mejorar y modificar la estructura y codificacin de cdigos ya
creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo
estos cdigos para procurar optimizar su funcionamiento. Es muy comn

rehusar cdigos ya creados que contienen funcionalidades que no sern usadas

y diseos obsoletos.
7.3. Fase: Codificacin
El cliente es una parte ms importante 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 de
codificacin ya creados. Programar bajo estndares mantiene el cdigo consistente
y facilita su comprensin y escalabilidad.
7.4. Fase: Pruebas
Uno de los pilares de la metodologa X.P es el uso de test para comprobar el
funcionamiento de los cdigos que vayamos implementando. El uso de los test en
X.P es el siguiente:
Se deben crear las aplicaciones que realizarn los test con un entorno de desarrollo
especfico para test.
Hay que someter a tests las distintas clases del sistema omitiendo los mtodos ms
triviales.
Se deben crear los test que pasarn los cdigos antes de implementarlos; 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.
Como se coment anteriormente los distintos test se deben subir al repositorio de
cdigo acompaados del cdigo que verifican.

Test de aceptacin. Los test mencionados anteriormente sirven para evaluar las
distintas tareas en las que ha sido dividida una historia de usuario.
Al ser las distintas funcionalidades de nuestra aplicacin no demasiado extensas, no
se harn test que analicen partes de las mismas, sino que las pruebas se realizarn
para las funcionalidades generales que debe cumplir el programa especificado en la
descripcin de requisitos.

Figura 4
Figura 4 Fases de la Metodologa
XP
Fuente: (Elaboracin propia, 2015)

Figura 5 Fases de la Metodologa

Figura 5XP segn Ian Sommerville
Fuente: (Elaboracin propia, 2015)

8. Valores de la metodologa XP
Los valores originales de la programacin extrema son: simplicidad, comunicacin,
retroalimentacin (feedback) y coraje. Un quinto valor, respeto, fue aadido en la
segunda edicin de Extreme Programming Explained. Los cinco valores se detallan a
continuacin:
8.1. Simplicidad
La simplicidad es la base de la programacin extrema. Se simplifica el diseo
para agilizar el desarrollo y facilitar el mantenimiento.
Un diseo complejo del cdigo junto a sucesivas modificaciones por parte de
diferentes desarrolladores hace que la complejidad aumente exponencialmente.
Para mantener la simplicidad es necesaria la refactorizacin del cdigo, sta es
la manera de mantener el cdigo simple a medida que crece.
Tambin se aplica la simplicidad en la documentacin, de esta manera el cdigo
debe comentarse en su justa medida, intentando eso s que el cdigo est autodocumentado. Para ello se deben elegir adecuadamente los nombres de las
variables, mtodos y clases. Los nombres largos no decrementan la eficiencia
del cdigo ni el tiempo de desarrollo gracias a las herramientas de
autocompletado y refactorizacin que existen actualmente.
Aplicando la simplicidad junto con la autora colectiva del cdigo y la
programacin por parejas se asegura que cuanto ms grande se haga el proyecto,
todo el equipo conocer ms y mejor el sistema completo.
8.2. Comunicacin
La comunicacin se realiza de diferentes formas. Para los programadores el
cdigo comunica mejor cuanto ms simple sea.
Si el cdigo es complejo hay que esforzarse para hacerlo inteligible. El cdigo
autodocumentado es ms fiable que los comentarios ya que stos ltimos pronto
quedan desfasados con el cdigo a medida que es modificado.
Debe comentarse slo aquello que no va a variar, por ejemplo el objetivo de una
clase o la funcionalidad de un mtodo. Las pruebas unitarias son otra forma de
comunicacin ya que describen el diseo de las clases y los mtodos al mostrar
ejemplos concretos de cmo utilizar su funcionalidad.

Los programadores se comunican constantemente gracias a la programacin por

parejas. La comunicacin con el cliente es fluida ya que el cliente forma parte
del equipo de desarrollo. El cliente decide qu caractersticas tienen prioridad y
siempre debe estar disponible para solucionar dudas.
8.3. Retroalimentacin
Al estar el cliente integrado en el proyecto, su opinin sobre el estado del
proyecto se conoce en tiempo real.
Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se
minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda
a los programador esa centrarse en lo que es ms importante. Considrense los
problemas que derivan de tener ciclos muy largos.
Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios
del cliente o malentendidos por parte del equipo de desarrollo.
El cdigo tambin es una fuente de retroalimentacin gracias a las herramientas
de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de
salud del cdigo. Ejecutar las pruebas unitarias frecuentemente permite
descubrir fallos debidos a cambios recientes en el cdigo.
8.4. Coraje o valenta
Muchas de las prcticas implican valenta. Una de ellas es siempre disear y
programar para hoy y no para maana. Esto es un esfuerzo para evitar
empantanarse en el diseo y requerir demasiado tiempo y trabajo para implementar
todo lo dems del proyecto. La valenta le permite a los desarrolladores que se
sientan cmodos con reconstruir su cdigo cuando sea necesario. Esto significa
revisar el sistema existente y modificarlo si con ello los cambios futuros se
implementaran ms fcilmente. Otro ejemplo de valenta es saber cundo desechar
un cdigo: valenta para quitar cdigo fuente obsoleto, sin importar cuanto esfuerzo
y tiempo se invirti en crear ese cdigo. Adems, valenta significa persistencia: un
programador puede permanecer sin avanzar en un problema complejo por un da
entero, y luego lo resolver rpidamente al da siguiente, slo si es persistente.

9. Ventajas y Desventajas de la Metodologa XP

Tabla 4. Ventajas y Desventajas de la Metodologa XP
Ventajas
Programacin organizada.

Desventajas
Es recomendable

emplearlo

solo

en

proyectos a corto plazo.

Altas comisiones en caso de fallar.

Menor taza de errores.

Satisfaccin del programador.
Fuente: (Elaboracin propia, 2015)
10. Inconvenientes

Es recomendable emplearla solo en proyectos a corto plazo.

En caso de fallar, las comisiones son muy altas.
Requiere de un rgido ajuste a los principios de XP.
Puede no siempre ser ms fcil que el desarrollo tradicional.

11. Herramientas empleadas en XP

A continuacin se detalla cada una de estas planteando los motivos por los cuales
fueron seleccionadas:
11.1.

JAVA

Se trata de un poderos y flexible lenguaje de programacin con el actual se puede

desarrollar desde aplicaciones para celulares hasta pginas web. Obviamente se
convierte en una herramienta ptima para desarrollar aplicativos de escritorio.
El primer motivo por el que se seleccion JAVA como herramienta de desarrollo, es el
amplio conocimiento que los programadores tienen del lenguaje. En segundo lugar
existe una API de pruebas desarrolladas para trabajar con JAVA especialmente diseada
para proyectos desarrollados con XP
11.2.

NETBeans

Es un IDE de licenciado libre para desarrollar aplicaciones en JAVA.

Si bien no es el nico IDE disponible para JAVA, a juicio de los programadores, es el
ms adecuado, por lo cual se convirti en la mejor eleccin. Por otro lado cuenta con
soporte para JUnit, herramienta seleccionada para realizar pruebas.

11.3.

JUnit

Es un API para realizar pruebas que fue diseado para ser empleado en JAVA. Un
aspecto importante es que cumple con la mayora de las recomendaciones realizadas por
XP en lo que a pruebas se refiere, de las cuales se destaca el permitir hacer pruebas
autnomas. Por otro lado, algunos autores lo recomiendan para desarrollar aplicaciones
en JAVA empleando XP.
11.4.

JasperReport e IReport

Es una combinacin de libreras de JAVA y software libre que permiten el diseo e

implementacin de reportes impresos. Entre las ventajas ms importantes se resalta
flexibilidad y facilidad de empleo
11.5.

PostgreSQL

Se caracteriza por estar entre los motores de base de datos ms estables y robustos,
razones que motivaron su eleccin.
12. Tablas Comparativas de las Metodologas SCRUM y XP
12.1.

Semejanzas

Es un Agile Manifiesto.
Existen una Interaccin de Usuario a Usuario.
Realizan los Proyectos en un Corto Periodo de Tiempo.
Trabajan en Equipo.

12.2.

Diferencias
Tabla 5. Comparacin entre Metodologas

SCRUM
XP(Programacin Extrema)
Las iteraciones de entregas son de 2 a 4 Las iteraciones de entrega son a 1 a 3
semanas.
Lo que se termina, funciona y este bien, se

semanas.
Las tareas q se van entregando a los

aparta y ya no se toca.

diferentes clientes son susceptibles a las

Cada miembro del Scrum Team trabaja de

modificaciones.
Los miembros del programan en pareja en

forma individual.
El Scrum Team trata de seguir el orden de

un proyecto XP.
El equipo de desarrollo sigue estrictamente

prioridad q marca el Product Owner en el

el orden de prioridad de las tareas definidas

Sprint Backlog pueden ser modificadas.

Est basada en la administracin del

por el cliente.
Se centra ms en la propia programacin o

proyecto.

creacin del producto.

Fuente: (Elaboracin propia, 2015)

13. Personas que intervienen en la Metodologa XP

Segn Kent Beck

La metodologa XP se encuentra en una frecuente integracin del equipo de programacin

con el cliente o usuario: se recomienda que un representante del cliente trabaje junto al
equipo de desarrollo. Los programadores se comunican constantemente gracias a la
programacin por parejas. La comunicacin con el cliente es fluida ya que el cliente forma
parte del equipo de desarrollo; el cliente decide qu caractersticas tienen prioridad y
siempre debe estar disponible para solucionar dudas.

Segn Ian Sommerville

En un proceso XP, los clientes estn fuertemente implicados en la especificacin y

establecimiento de prioridades de los requerimientos del sistema.
Los requerimientos no se especifican como una lista de funciones requeridas del sistema.
Ms bien, los clientes del sistema son parte del equipo de desarrollo y discuten escenarios
con otros miembros del equipo. Desarrollan conjuntamente una tarjeta de historia que

recoge las necesidades del cliente. El equipo de desarrollo intentara entonces implementar
ese escenario en una entrega futura del software.
La participacin del cliente se lleva a cabo a travs del compromiso a tiempo completo del
cliente en el equipo de desarrollo. Los representantes de los clientes participan en el
desarrollo y son los responsables de definir las pruebas de aceptacin del sistema.
Practicas Bsicas del XP
De forma aislada, cualquier prctica individual de Xp tiene poco sentido, pero en conjunto,
unas compensan las carencias que las otras puedan tener.
Nos dice que para evaluar Xp hay que mirar la gran foto, es decir, todo el conjunto de
prcticas:

El juego de la Planificacin - (Planning Game)

El alcance de la siguiente versin esta definido por las consideraciones de negocios

(prioridad de los mdulos, fechas de entrega) y estimaciones tcnicas (estimaciones de
funciones, consecuencias).

El objetivo del juego es maximizar el valor del software producido, La estrategia es poner
en produccin las caractersticas ms importantes lo antes posible, Las Piezas clave son las
Story Cards, Los Jugadores son los desarrolladores y el cliente y las Movidas son
Exploracin, Seleccin y Actualizacin.

Versiones Pequeas (Short Releases)

Un sistema simple se pone rpidamente en produccin. Peridicamente, se producen

nuevas versiones agregando en cada iteracin aquellas funciones consideradas valiosas para
el cliente

Metfora del Sistema (Metaphor)

Cada Proyecto es guiado por una historia simple de cmo funciona el sistema en general,
reemplaza a la arquitectura y debe estar en lenguaje comn, entendible para todos (Cliente
y Desarrolladores), esta puede cambiar permanentemente.

Diseo Simple (Simple Designs)

El sistema se disea con la mxima simplicidad posible (YAGNY - "No vas a necesitarlo"),
Se plasma el diseo en tarjetas CRC (Clase Responsabilidad - Colaboracin), no se
implementan caractersticas que no son necesarias, con esta tcnica, las clases descubiertas
durante el anlisis pueden ser filtradas para determinar qu clases son realmente necesarias
para el sistema.

Pruebas Continuas (Testing)

Los casos de prueba se escriben antes que el cdigo. Los desarrolladores escriben pruebas
unitarias y los clientes especifican pruebas funcionales.

Refactorizacin (Refactoring)

Es posible reestructurar el sistema sin cambiar su comportamiento, por ejemplo eliminando

cdigo duplicado, simplificando funciones, Mejorando el cdigo constantemente, si el
cdigo se esta volviendo complicado se debera modificar el diseo y volver a uno ms
simple. Refactoring (Modificar la forma del cdigo sin cambiar su funcionamiento).

Programacin por parejas (Pair Programming)

El cdigo es escrito por dos personas trabajando en el mismo computador. "Una sola
maquina con un teclado y un mouse"

Posesin Colectiva del Cdigo (Collective Code Ownership)

Nadie es dueo de un modulo. Cualquier programador puede cambiar cualquier parte del
sistema en cualquier momento, siempre se utilizan estndares y se excluyen los
comentarios, Los test siempre deben funcionar al 100% para realizar integraciones con todo
el cdigo permanentemente.

Integracin continua (Continuous Integration)

Los cambios se integran en el cdigo base varias veces por da. Todos lo casos de prueba se
deben pasar antes y despus de la integracin, se dispone de una maquina para la
integracin y se realizan test funcionales en donde participa el cliente.

Semana laboral de 40 horas (40-Hour Week)

Cada Trabajador trabaja no ms de 40 Horas por semana. Si fuera necesario hacer horas
extra, esto no debera hacerse dos semanas consecutivas. Sin hroes, esto hace que se
reduzca la rotacin del personal y mejora la calidad del producto.

Cliente en el Sitio (On Site Customer)

El equipo de desarrollo tiene acceso todo el tiempo al cliente, el cual esta disponible para
responder preguntas, fijar prioridades, etc. Esto no siempre se consigue; Un cliente muy
Junior no sirve y un cliente muy Snior no es disponible. "Lo ideal es un cliente Analista".

Estndares de Codificacin (Coding Standard)

Todo el cdigo debe estar escrito de acuerdo a un estndar de codificacin

Ciclo de Vida

El ciclo de vida de Xp se enfatiza en el carcter interactivo e incremental del desarrollo,

Segn una iteracin de desarrollo es un perodo de tiempo en el que se realiza un conjunto
de funcionalidades determinadas que en el caso de Xp corresponden a un conjunto de
historias de usuarios.
Las iteraciones son relativamente cortas ya que se piensa que entre ms rpido se le
entreguen desarrollos al cliente, ms retroalimentacin se va a obtener y esto va a
representar una mejor calidad del producto a largo plazo. Existe una fase de anlisis inicial
orientada a programar las iteraciones de desarrollo y cada iteracin incluye diseo,
codificacin y pruebas, fases superpuestas de tal manera que no se separen en el tiempo.
La siguiente figura muestra las fases en las que se subdivide el ciclo de vida Xp:

Ciclo de vida de eXtreme Programming

Ahora nos describen cada una de las fases en las que se subdivide el ciclo de vida de
eXtreme Programming:

Fase de la exploracin: En esta fase, los clientes plantean a grandes rasgos las historias de
usuario que son de inters para la primera entrega del producto. Al mismo tiempo el equipo
de desarrollo se familiariza con las herramientas, tecnologas y prcticas que se utilizarn
en el proyecto.
Se prueba la tecnologa y se exploran las posibilidades de la arquitectura del sistema
construyendo un prototipo. La fase de exploracin toma de pocas semanas a pocos meses,
dependiendo del tamao y familiaridad que tengan los programadores con la tecnologa.
Fase del planeamiento: se priorizan las historias de usuario y se acuerda el alcance del
release. Los programadores estiman cunto esfuerzo requiere cada historia y a partir de all
se define el cronograma. La duracin del cronograma del primer release no excede
normalmente dos meses. La fase de planeamiento toma un par de das. Se deben incluir
varias iteraciones para lograr un release. El cronograma fijado en la etapa de planeamiento
se realiza a un nmero de iteraciones, cada una toma de una a cuatro semanas en ejecucin.
La primera iteracin crea un sistema con la arquitectura del sistema completo. Esto es
alcanzado seleccionando las historias que harn cumplir la construccin de la estructura
para el sistema completo. El cliente decide las historias que se seleccionarn para cada
iteracin. Las pruebas funcionales creadas por el cliente se ejecutan al final de cada
iteracin. Al final de la ltima iteracin el sistema est listo para produccin.
Fase de produccin: requiere prueba y comprobacin extra del funcionamiento del sistema
antes de que ste se pueda liberar al cliente. En esta fase, los nuevos cambios pueden
todava ser encontrados y debe tomarse la decisin de si se incluyen o no en el release
actual. Durante esta fase, las iteraciones pueden ser aceleradas de una a tres semanas. Las
ideas y las sugerencias pospuestas se documentan para una puesta en prctica posterior por
ejemplo en la fase de mantenimiento. Despus de que se realice el primer release
productivo para uso del cliente, el proyecto de Xp debe mantener el funcionamiento del
sistema mientras que realiza nuevas iteraciones.

Fase de mantenimiento: requiere de un mayor esfuerzo para satisfacer tambin las tareas
del cliente. As, la velocidad del desarrollo puede desacelerar despus de que el sistema est
en la produccin. La fase de mantenimiento puede requerir la incorporacin de nueva gente
y cambiar la estructura del equipo.
Fase de muerte: Es cuando el cliente no tiene ms historias para ser incluidas en el
sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como
rendimiento y confiabilidad del sistema. Se genera la documentacin final del sistema y no
se realizan ms cambios en la arquitectura. La muerte del proyecto tambin ocurre cuando
el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto
para mantenerlo.

Actores y Responsabilidades de XP

Existen diferentes roles (actores) y responsabilidades en Xp para diferentes tareas y

propsitos durante el proceso:
Programador (Programmer)

Responsable de decisiones tcnicas

Responsable de construir el sistema
Sin distincin entre analistas, diseadores o codificadores
En Xp, los programadores disean, programan y realizan las pruebas

Cliente (Customer)

Es parte del equipo

Determina qu construir y cundo
Escribe tests funcionales para determinar cundo est completo un determinado
aspecto

Entrenador (Coach)

El lder del equipo - toma las decisiones importantes

Principal responsable del proceso

Tiende a estar en un segundo plano a medida que el equipo madura

Rastreador (Tracker)

Metric Man
Observa sin molestar
Conserva datos histricos

Probador (Tester)

Ayuda al cliente con las pruebas funcionales

Se asegura de que los tests funcionales se ejecutan

Artefactos

A continuacin describimos los artefactos de Xp, entre los que se encuentran: Historias de
Usuario, Tareas de Ingeniera y Tarjetas CRC.

Historia de usuario

Representan una breve descripcin del comportamiento del sistema, emplea terminologa
del cliente sin lenguaje tcnico, se realiza una por cada caracterstica principal del sistema,
se emplean para hacer estimaciones de tiempo y para el plan de lanzamientos, reemplazan
un gran documento de requisitos y presiden la creacin de las pruebas de aceptacin.

Historia de usuario
Numero:

Nombre Historia de usuario:

Modificacin de historia de Usuario (Nro. y Nombre:)

Usuario

Iteracin Asignada :

Prioridad en negocio

Puntos estimados :

(Alta / Media / Baja)

Riesgo en desarrollo :
(Alto / Medio / Bajo )

Descripcin:

Observaciones:

Puntos Reales:

Tabla No.1. Modelo propuesto para una historia de usuario

Estas deben proporcionar slo el detalle suficiente como para poder hacer razonable la
estimacin de cunto tiempo requiere la implementacin de la historia, difiere de los casos
de uso porque son escritos por el cliente, no por los programadores, empleando
terminologa del cliente. "Las historias de usuario son ms "amigables" que los casos de
uso formales".
Las Historias de Usuario tienen tres aspectos:
Tarjeta: en ella se almacena suficiente informacin para identificar y detallar la historia.
Conversacin: cliente y programadores discuten la historia para ampliar los detalles
(verbalmente cuando sea posible, pero documentada cuando se requiera confirmacin)
Pruebas de Aceptacin: permite confirmar que la historia ha sido implementada
correctamente.
Caso de prueba de Aceptacin
Cdigo:
Nombre:

Descripcin :

Condiciones de Ejecucin:

Historia de usuario (Nro. Y Nombre):

Entrada / pasos de ejecucin:

Resultado esperado:

Evaluacin de prueba:

Tabla No.2. Modelo propuesto para una prueba de aceptacin

Task Card

Tarea de Ingeniera
Nmero tarea

Nombre Tarea:

Historia de usuario (Nro. Y Nombre):

Tipo de Tarea:
Desarrollo

Puntos Estimados:
Correccin

Mejora

/Otra(especificar)

Fecha Inicio:

Fecha Fin:

Programador Responsable:
Descripcin

Modelo propuesto para una tarea de ingeniera

Tarjetas CRC (Clase Responsabilidad - Colaborador)

Estas tarjetas se dividen en tres secciones que contienen la informacin del nombre de la
clase, sus responsabilidades y sus colaboradores. En la siguiente figura se muestra cmo se
distribuye esta informacin.

Nombre de la Clase
Responsabilidades

Colaboradores

Modelo de tarjeta CRC

Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte. Las
responsabilidades de una clase son las cosas que conoce y las que realiza, sus atributos y
mtodos. Los colaboradores de una clase son las dems clases con las que trabaja en
conjunto para llevar a cabo sus responsabilidades.
En la prctica conviene tener pequeas tarjetas de cartn, que se llenarn y que son
mostradas al cliente, de manera que se pueda llegar a un acuerdo sobre la validez de las
abstracciones propuestas.
Los pasos a seguir para llenar las tarjetas son los siguientes:

Encontrar clases

Encontrar responsabilidades
Definir colaboradores
Disponer las tarjetas

Para encontrar las clases debemos pensar qu cosas interactan con el sistema (en nuestro
caso el usuario), y qu cosas son parte del sistema, as como las pantallas tiles a la
aplicacin (un despliegue de datos, una entrada de parmetros y una pantalla general, entre
otros). Una vez que las clases principales han sido encontradas se procede a buscar los
atributos y las responsabilidades, para esto se puede formular la pregunta Qu sabe la
clase? y Qu hace la clase? Finalmente se buscan los colaboradores dentro de la lista de
clases que se tenga.

Criticas a Extreme Programing

Algunas de las crticas recopiladas de Xp son:
Xp tiene muchas crticas especialmente contra la programacin por parejas por parte de
muchos programadores con gran sentimiento de posesin del cdigo, piensan que ellos son
los mejores conocedores de las herramientas y lenguajes que utilizan y que si alguien no lo
entiende es porque no sabe lo suficiente.
Tambin se critica el mito de las 40 horas semanales ya que es un lujo para las exigencias
del mercado.
Tambin hay crticas hacia Xp que dicen que solo puede funcionar con programadores muy
buenos, como Kent Beck, que son capaces de hacer un buen diseo, sencillo y fcilmente
extensible.
Xp es ms una filosofa de trabajo que una metodologa. Por otro lado ninguna de las
practicas defendidas por Xp son invencin de este mtodo, Xp lo que hace es ponerlas
todas juntas.
Xp est diseado para grupos de pequeos programadores, ms de 10 ya sera muy
complicado, y ms an para que estn en el mismo centro de trabajo.

Captulo III
Conclusiones y Recomendaciones
14. Conclusiones
No existe una metodologa universal para hacer frente con xito a cualquier proyecto de
desarrollo de software. Toda metodologa debe ser adaptada al contexto del proyecto
(recursos tcnicos y humanos, tiempo de desarrollo, tipo de sistema, etc. Histricamente,
las metodologas tradicionales han intentado abordar la mayor cantidad de situaciones de
contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en
proyectos pequeos y con requisitos muy cambiantes. Las metodologas giles ofrecen una
solucin casi a medida para una gran cantidad de proyectos que tienen estas caractersticas.
Una de las cualidades ms destacables en una metodologa gil es su sencillez, tanto en su
aprendizaje como en su aplicacin, reducindose as los costos de implantacin en un
equipo de desarrollo. Esto ha llevado hacia un inters creciente en las metodologas giles.
Sin embargo, hay que tener presente una serie de inconvenientes y restricciones para su
aplicacin, tales como: estn dirigidas a equipos pequeos o medianos (Beck sugiere que el
tamao de los equipos se limite de 3 a 20 como mximo, otros dicen no ms de 10
participantes), el entorno fsico debe ser un ambiente que permita la comunicacin y
colaboracin entre todos los miembros del equipo durante todo el tiempo, cualquier
resistencia del cliente o del equipo de desarrollo hacia las prcticas y principios puede
llevar al proceso al fracaso (el clima de trabajo, la colaboracin y la relacin contractual
son claves), el uso de tecnologas que no tengan un ciclo rpido de realimentacin o que no
soporten fcilmente el cambio, etc.
Falta an un cuerpo de conocimiento consensuado respecto de los aspectos tericos y
prcticos de la utilizacin de metodologas giles, as como una mayor consolidacin de los
resultados de aplicacin. La actividad de investigacin est orientada hacia lneas tales
como: mtricas y evaluacin del proceso, herramientas especficas para apoyar prcticas
giles, aspectos humanos y de trabajo en equipo. Entre estos esfuerzos destacan proyectos
como NAME12 (Network for Agile Methodologies Experience).

Es XP la metodologa que resalta por contar con la mayor cantidad de informacin

disponible y es con diferencia la ms popular.

15. Recomendaciones
Debe hacerse lo posible por no realizar modificaciones a XP demasiado drsticas ya que se
corre el riesgo de alterar la esencia de la metodologa.
Debe plantearse una estrategia para afrontar el diseo de datos en XP.
Se deben afijar una serie de reglas generales en la comunicacin con el cliente ya que por el
grado de informalidad que la metodologa presenta puede surgir diferencias que pongan en
peligro la culminacin exitosa del proyecto.
Debe hacerse una capacitacin al cliente sobre XP antes de iniciar el proyecto debido que
este hace parte del equipo de desarrollo.
Plantear una estrategia especial de refactoring para las bases de datos.
Tener un buen conocimiento de las herramientas para la implementacin antes de iniciar
dicha etapa.
Plantear como unidad de tiempo horas en lugar de das para la asignacin de tareas.
Considerar el internet y herramientas basadas en l como mecanismos de comunicacin
vlidos dentro de XP y discutir la necesidad de un nico sitio geogrfico de trabajo.
Hacer una experiencia realizando un mismo proyecto por dos grupos de desarrollo
independientes empleando una metodologa pesada y XP con el fin de comparar los
resultados obtenidos.
Emplear XP en un proyecto de mayor envergadura con el fin de evaluar el desempeo de la
metodologa en ese tipo de proyectos.

Bibliografa
Beck, Kent. 2002. Una explicacin de la Programacin extrema: aceptar el cambio. s.l. :
Addison-Wesley Iberoamericana Espanya, S.A., 2002.
James Newkirk, Robert C. Martin. 2002. La Programacin Extrema en la prctica. s.l. :
Addison-Wesley Iberoamericana Espanya, S.A., 2002.
Ron Jeffries, Ann Anderson, Chet Hendrickson, Ronald E. Jeffries. 2000. Extreme
Programming Installed. s.l. : Addison-Wesley Pub Co; 1 edicin, 2000.