UNIVERSIDAD NACIONAL DE TRUJILLO

FACULTAD DE INGENIERA
E.A.P INGENIERIA DE SISTEMAS
Sede Valle Jequetepeque

METODLOGIAS GILES PARA EL DESARROLLO DE SOFTWARE:

PROGRAMACIN EXTREMA XP (EXTREME PROGRAMMING)

AUTORES:
CEDRON FLORIAN, Alessandra Mirella
CHOLAN CABANILLAS, Maguin Alfredo
DAVILA VICENCIO, Mara Raysa
NORIEGA CHAFLOQUE, Cesar Gustavo
TERAN CRUZ, Juan Gerardo

DOCENTE:
Ing. Mg. JUAN PEDRO SANTOS FERNNDEZ

GUADALUPE- PER
2015

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

Dedicamos este trabajo al esfuerzo de nuestros

padres para darnos la mejor educacin, y hacen
posible que nosotros seamos mejores personas
en la sociedad.

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

INTRODUCCION

Las metodologas agiles tienen un origen reciente en el entorno de la ingeniera de software

comparada con las mitologas pesadas. Su origen est ligado a los constantes inconvenientes
que se presentaban en proyectos con algunas caractersticas, en los cuales la utilizacin de
las metodologas pesadas era motivo de fracaso.
En la dcada de los 90, surge Xtreme Programming, mejor conocida como XP, una nueva
metodologa catalogada entre las agiles por sus aportes al manifiesto gil. Su creador, Kent
Beck se convirti en el padre de la programacin extrema.

CAPTULO I:
MARCO TERICO

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

1.1.METODOLOGA GIL
A principios de la dcada del 90, surgi un enfoque que fue bastante revolucionario
para su momento ya que iba en contra de toda creencia de que mediante procesos
altamente definidos se iba a lograr obtener software en tiempo, costo y con la
requerida calidad. El enfoque fue planteado por primera vez por Martin y se dio a
conocer en la comunidad de Ingeniera de Software con el nombre de RAD o Rapid
Application Development. RAD consista en un entorno de desarrollo altamente
productivo, en el que participaban grupos pequeos de programadores utilizando
herramientas que generaban cdigo en forma automtica tomando como entradas
sintaxis de alto nivel. En general, se considera que este fue uno de los primeros hitos
en pos de la agilidad en los procesos de desarrollo.

La historia de las Metodologas giles y su apreciacin como tales en la comunidad

de la Ingeniera de Software tiene sus inicios en la creacin de una de las metodologas
utilizada como arquetipo: XP - eXtreme Programming, que nace de la mente de Kent
Beck, tomando ideas recopiladas junto a Ward Cunningham.

Durante 1996, Beck es llamado por Chrysler como asesor del proyecto Chrysler
Comprehensive Compensation (C3) payroll system. Dada la poca calidad del sistema
que se estaba desarrollando, Beck decide tirar todo el cdigo y empezar de cero
utilizando las prcticas que l haba ido definiendo a lo largo del tiempo. El sistema,
que administra la liquidacin de aproximadamente 10.000 empleados, y consiste de
2.000 clases y 30.000 mtodos, es puesto en operacin en Mayo de 1997 casi
respetando el calendario propuesto. Como consecuencia del xito de dicho proyecto,
Kent Beck dio origen a XP iniciando el movimiento de metodologas giles al que se
anexaran otras metodologas surgidas mucho antes que el propio Beck fuera
convocado por Chrysler.

Es as como que este tipo de metodologas fueron inicialmente llamadas

metodologas livianas, sin embargo, an no contaban con una aprobacin pues se
le consideraba por muchos desarrolladores como meramente intuitiva. Luego, con el
2

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

pasar de los aos, en febrero de 2001, tras una reunin

celebrada en Utah-EEUU, nace formalmente el trmino gil aplicado al desarrollo
de software. En esta misma reunin participan un grupo de 17 expertos de la industria
del software, incluyendo algunos de los creadores o impulsores de metodologas de
software con el objetivo de esbozar los valores y principios que deberan permitir a
los equipos desarrollar software rpidamente y respondiendo a los cambios que
puedan surgir a lo largo del proyecto. Se pretenda ofrecer una alternativa a los
procesos de desarrollo de software tradicionales, caracterizados por ser rgidos y
dirigidos por la documentacin que se genera en cada una de las actividades
desarrolladas.

Tras esta reunin se cre The Agile Alliance, una organizacin, sin nimo de lucro,
dedicada a promover los conceptos relacionados con el desarrollo gil de software y
ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida
fue el Manifiesto gil, un documento que resume la filosofa gil.

1.2.DIFERENCIAS ENTRE METODOLOGIAS AGILES Y NO AGILES

La Tabla N 1 recoge esquemticamente las principales diferencias de las

metodologas giles con respecto a las tradicionales (no giles). Estas diferencias
que afectan no slo al proceso en s, sino tambin al contexto del equipo as como a
su organizacin.

Tener metodologas diferentes para aplicar de acuerdo con el proyecto que se

desarrolle resulta una idea interesante. Estas metodologas pueden involucrar
prcticas tanto de metodologas giles como de metodologas tradicionales. De esta
manera podramos tener una metodologa para cada proyecto, la problemtica sera
definir cada una de las prcticas, y en el momento preciso definir parmetros para
saber cul usar.

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

Es importante tener en cuenta que el uso de un mtodo

gil no es para todos. Sin embargo, una de las principales ventajas de los mtodos
giles es su peso inicialmente ligero y por eso las personas que no estn
acostumbradas a seguir procesos encuentran estas metodologas bastante agradables.

1.3.EXTREME PROGRAMMING(XP)

XP es la primera metodologa gil y la que le dio conciencia al movimiento actual de

metodologas giles. De la mano de Kent Beck, XP ha conformado un extenso grupo
de seguidores en todo el mundo, disparando una gran cantidad de libros a los que dio
comienzo el mismo Beck en. Inclusive Addison-Wesley ha creado una serie de libros
denominada The XP Series.

La imagen mental de Beck al crear XP era la de perillas en un tablero de control. Cada

perilla representaba una prctica que de su experiencia saba que trabajaba bien.
Entonces, Beck decidi girar todas las perillas al mximo para ver que ocurra. As
fue como dio inicio a XP.

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

XP es una metodologa gil centrada en potenciar las

relaciones interpersonales como clave para el xito en el desarrollo de software,
promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los
desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin
continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos
los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar
los cambios. XP se define como especialmente adecuada para proyectos con
requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico. A
continuacin presentaremos las caractersticas esenciales de XP organizadas en los
tres apartados siguientes: historias de usuario, roles, proceso y prcticas.

1.4.HISTORIA
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 tena varias ideas de metodologas para la realizacin de programas que eran

cruciales para el buen desarrollo de cualquier sistema.

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

Las ideas primordiales de su sistema las comunic en

la revista C++ Magazine en una entrevista que sta le hizo el ao 1999. En sta deca
que 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.
Este hecho, lleg a molestar a buena parte de la comunidad que intentaba discutir
sobre temas de programacin. Fue tanta esta molestia que naci el fenmeno XP Free
Zone (zona libre de XP) en determinadas webs como peticin de no hablar de
Programacin Extrema en ella.

La discusin sobre temas de diseo de modelos de programacin sobre los cambios

recientes se hizo tema difcil porque la mayora de la actividad fue relacionada con la
Programacin Extrema. Eventualmente, y debido a sto, la mayora de la gente que
sola discutir sobre los temas de diseo de modelos de programacin fue apartndose
de este ambiente para discutir sus ideas en otros ambientes ms "reservados". La
comunidad empez a referirse a estos sitios como a Salas Wiki (Wards Wiki).

1.5.OBJETIVOS DE XP

Los objetivos de XP son muy simples: la satisfaccin del cliente. Esta metodologa
trata de dar al cliente el software que l necesita y cuando lo necesita. Por tanto,
debemos responder muy rpido a las necesidades del cliente, incluso cuando los
cambios sean al final de ciclo de la programacin.

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

Potenciar al mximo el trabajo en grupo. Tanto los jefes de proyecto, los clientes y
desarrolladores, son parte del equipo y estn involucrados en el desarrollo del
software.
EstablecerlasmejoresprcticasdeIngenieradeSoftwareenlosdesarrollodeproyectos.
Mejorar la productividad de los proyectos.
Garantizarla Calidad del Software desarrollando, haciendo que este supere las
expectativas del cliente.
Asumir que con cierta planificacin, codificacin y pruebas se puede decidir si se est
siguiendo un camino correcto o equivocado, evitando retroceder cuando sea
demasiado tarde.

1.6.CARACTERSTICAS
Metodologa basada en prueba y error para obtener un software que funcione
realmente.
Fundamentada en Principios.
Expresada en forma de 12 Prcticas (conjunto completo, complementndose
unas a otras).Las cuales son conocidas pero su novedades juntarlas.
Est orientada hacia quien produce y usa el software (el cliente participa muy
activamente)
Reduce el coste del cambio en todas las etapas del ciclo de vida del sistema.
Combinalasquehandemostradoserlasmejoresprcticasparadesarrollarsoftware
, y las lleva al extremo.
Cliente bien definido.
Los requisitos pueden cambiar.

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

1.7.LA FILOSOFA DE XP

XP es una metodologa gil para pequeos y medianos equipos, desarrollando

software cuando los requerimientos son ambiguos o rpidamente cambiantes.

A diferencia de los procesos tradicionales para desarrollar software, XP asume el

cambio como algo natural, y que, indefectiblemente, en alguna etapa de un proyecto
sucede. En XP se realiza el software que el cliente solicita y necesita, en el momento
que lo precisa, alentando a los programadores a responder a los requerimientos
cambiantes que plantea el cliente en cualquier momento. Esto es posible porque est
diseado para adaptarse en forma

inmediata a los cambios, con bajos costos

asociados, en cualquier etapa del ciclo de vida. En pocas palabras, XP abraza el

cambio.

1.8.VALORES EN XP
Para poder implementar las prcticas que presenta XP hay que conocer cules son los
valores principales que hacen a esta mitologa. Estos valores son:
Comunicacin.
Simplicidad.
Feedback.
Coraje.

1.8.1. Comunicacin

Uno de los valores ms importantes en XP es la comunicacin. La mala comunicacin

no surge por casualidad en un proyecto y pueden aparecer muchas circunstancias que
hagan que esta falle; un programador le da malas noticias al gerente y este lo castiga,
un cliente le dice al programador algo importante y este no le presta atencin.
8

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

En cualquiera de los casos la comunicacin es un factor importante en cualquier tipo

de proyecto. En XP se trata de mantener una buena comunicacin mediante un
conjunto de prcticas que no se pueden realizar sin tener una buena comunicacin en
el equipo. Muchas de estas prcticas hacen corto circuito si no hay buena
comunicacin como en el caso de los testing unitarios, programacin por pares, el
uso de estndares o la estimacin de las tareas. Trabajar en espacios abiertos hace que
la comunicacin mejore al contrario de otras metodologas en las cuales los
programadores trabajan en espacios reducidos.

La comunicacin con el cliente es de vital importancia en XP y es por este motivo

que el cliente es integrado al equipo. De esta forma, cualquier duda sobre los
requerimientos puede ser evacuada inmediatamente. Adems, se planifica con el
cliente y este puede estar al tanto del avance del proyecto.

XP ha sido diseada para minimizar el grado de documentacin como forma de

comunicacin, haciendo nfasis en la interaccin personal. De esta manera se puede
avanzar rpidamente y de forma efectiva, realizando solo la documentacin necesaria.

1.8.2. Simplicidad

La simplicidad es el segundo valor que se utiliza en esta metodologa. XP apuesta a

realizar algo simple hoy y destinar un poco ms de esfuerzo para realizar un cambio
en el futuro, a realizar algo ms complicado hoy y no utilizarlo nunca.
XP propone una regla muy simple: hacer algo que funcione de la manera ms
sencilla. En el caso de tener que aadir nueva funcionalidad al sistema se deben
examinar todas las posibles alternativas y seleccionar la ms sencilla. En otras
ocasiones se hace uso del refactoring1 que permite mantener el cdigo en
funcionamiento pero mucho ms simple y organizado.

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

Otra regla muy importante es: realizar solo lo

necesario. Con esto se pretende agregar nueva funcionalidad que cumpla con los
objetivos actuales sin necesidad de preocuparse por futuros requerimientos. Esto hace
que se progrese de manera ms segura y rpida en el proyecto.

1.8.3. Feedback

Brindar un feedback correcto y preciso hace que se pueda mantener una buena
comunicacin y conocer el estado actual del proyecto.
El feedback trabaja a diferentes escalas de tiempo. Uno es el feedback que se realiza
minuto a minuto. Cuando un cliente escribe sus stories1 los programadores realizan
la estimacin de cada una de ellas y el cliente puede obtener inmediatamente el
feedback sobre la calidad de dichas stories.
El otro tipo de feedback que se realiza es a travs de pequeas entregas del sistema.
De esta manera, el cliente est al tanto del avance del proyecto. Adems, el sistema
es puesto en produccin en menor tiempo, con lo cual los programadores saben si
realizaron un buen trabajo y si sus decisiones fueron acertadas.

1.8.4. Coraje

Obviamente cada uno de los valores antes mencionados tiene una gran interaccin
entre ellos. Como se ve en la siguiente figura la comunicacin, la simplicidad y el
feedback forman el coraje, el cual se convierte en el objetivo de XP. Uno de los lemas
de XP menciona: Si no trabajas al tope de tu capacidad, alguien ms lo est haciendo
y si no llegas a tiempo se comer tu almuerzo.

Esto hace, a que por ejemplo, se tenga el coraje de modificar el cdigo en cualquier
momento por cualquier miembro del equipo sabiendo que no se afectar el correcto
funcionamiento del sistema.

10

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

El coraje tambin es poder realizar cambios cuando

algo no funciona del todo bien, disear e implementar solo lo necesario para el
presente, pedir ayuda o reducir el alcance de una entrega si el tiempo no alcanza.

Si no hay coraje en un proyecto no se puede clasificar como extremo y es necesario

que los otros tres valores estn presentes.

1.9.COSTE DEL CAMBIO

Una de las suposiciones establecidas en la industria del software es que el coste de

los cambios en un programa crece exponencialmente con el tiempo. XP propone que
si el sistema que empleas hace que el coste del software aumente con el tiempo debes
de actuar de forma diferente a cmo lo haces. XP propugna que esta curva ha perdido
validez y con una combinacin de buenas prcticas de programacin y tecnologa es
posible lograr que la curva sea la contraria, por tanto se pretende conseguir esto:
Si decidimos aceptar el cambio debemos de desarrollar para basarnos en dicha curva,
pero cmo se consigue dicha curva?, no existe una forma mgica desde luego hay
varias medidas que nos ayudan a conseguirla.

Disear lo ms sencillo que sea posible, para hacer slo lo imprescindible en un

momento dado, la simplicidad del cdigo y los test continuos hace que los cambios
sean posibles tan a menudo como sea necesario.
La programacin orientada a objetos es una tecnologa clave para el mantenimiento
del software, cada mensaje a un objeto es una oportunidad de cambio sin necesidad
de cambiar el cdigo existente, esto no quiere decir que no puedas tener flexibilidad
sin programar orientado al objeto y el caso contrario que haya programas orientados
a objetos que nadie quera tocar, slo se dice que el programar orientado a objetos
reduce el costo del cambio.

11

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

En vez de tomar grandes decisiones al principio y

pocas posteriormente, podemos idear una aproximacin para desarrollar software en
la que se tomen decisiones rpidamente, pero estas decisiones apoyadas por pruebas
y que te preparan para mejorar el diseo del software cuando aprendas una mejor
manera de disearlo.
He odo a muchos programadores (entre los que me incluyo) decir: Hasta que no he
terminado el programa no lo he entendido ahora lo hara con esta jerarqua y que esta
clase herede de esta otra, dejemos pues abierta la puesta a esta posibilidad.

1.10. CICLO DE VIDA DE XP

El ciclo de vida de XP consiste bsicamente de seis fases: Exploracin, Planificacin,

Iterations to Release, Produccin, Mantenimiento y Muerte.

Exploracin

En esta fase los clientes realizan las story cards que desean que estn para la primera
entrega. Cada story describe una de las funcionalidades que el programa tendr. Al
12

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

mismo tiempo el equipo de desarrollo se familiariza

con las herramientas, la tecnologa y las prcticas a ser utilizadas durante el proyecto.
En algunos casos se utiliza un prototipo para testear la nueva tecnologa y explorar
algunos aspectos de la arquitectura a ser implementada. La duracin de esta fase
puede extenderse desde unas pocas semanas a varios meses dependiendo de la
adaptacin del equipo de desarrollo.

Planificacin

El objetivo de esta fase es fijar la prioridad de cada una de las stories y se establece
cual va a ser el contenido de la primera entrega. Los programadores estiman cuanto
esfuerzo requiere cada story y se establece el cronograma. La duracin del calendario
para la entrega del primer release no suele superar los dos meses. Duracin de la fase
de planificacin en s no toma ms de dos das.

Iteraciones por entregas

Esta fase incluye varias iteraciones del sistema antes de la entrega del primer relase.
El calendario es dividido en un nmero iteraciones de tal manera de que cada iteracin
tome de una a cuatro semanas de implementacin. En la primera iteracin se crea un
sistema que abarca los aspectos ms importantes de la arquitectura global. Esto se
logra seleccionando las stories que hagan referencia a la construccin de la estructura
de todo el sistema.

El cliente decide que stories van a ser implementadas para cada iteracin. Adems,
se realizan los test funcionales, realizados por el cliente, al final de cada iteracin. Al
final de la ltima iteracin el sistema est listo para ser puesto en produccin.

13

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

Produccin

La fase de produccin requiere realizar muchos ms chequeos y testing antes que el

sistema sea entregado al cliente. En esta fase aparecen nuevos cambios y se tiene que
decidir si sern incorporados o no en dicha entrega. Durante esta fase suele suceder
que las iteraciones se aceleren de tres a una semana. Las ideas pospuestas y las
sugerencias son documentadas para luego ser implementadas ms adelante, por
ejemplo, en la fase de mantenimiento.

Luego que el primer release es creado, el proyecto debe mantener el sistema en

produccin corriendo mientas se trabaja en las nuevas iteraciones.

Mantenimiento

En esta fase por lo general se necesita un esfuerzo extra de los programadores para
satisfacer los requerimientos del cliente. Por este motivo la velocidad de desarrollo
suele disminuir una vez que el sistema es puesto en produccin. A raz de esto se
requiere incorporar nuevos integrantes al equipo y cambiar la estructura del equipo.

Muerte

Esta ltima fase se acerca una vez que el cliente no tiene ninguna story a ser
implementada. Los requerimientos del sistema deben ser satisfechos en otros aspectos
como ser la performance o la confiabilidad del mismo. Esta es la etapa en la cual no
hay ms cambios en la arquitectura, el diseo o el cdigo y aqu es cuando se realiza
la documentacin correspondiente. Esta fase aparece tambin, cuando el sistema no
da los resultados deseados o se vuelve demasiado caro para seguir siendo
desarrollado.

14

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

1.11. Principios de XP
Los cuatro valores mencionados anteriormente comunicacin, simplicidad,
feedback y coraje nos brindan un estndar para obtener buenos resultados. Sin
embargo, los valores son muy vagos a la hora de ayudarnos a decidir que prcticas
utilizar. Para ello se necesita destilar estos valores en principios que puedan ser
utilizados.

1.11.1. Rpida Retroalimentacin

En la prctica el tiempo transcurrido entre una accin y su feedback es crtico. Tener

una rpida retroalimentacin nos permite interpretarla, aprender de ella y poner en
prctica lo asimilado lo antes posible.

1.11.2. Asumir la Simplicidad

Este es uno de los principios ms difciles de llevar a la prctica. Casi siempre se

planifica para el futuro y se disea para poder rehusar. En lugar de esto XP dice que
hay que hacer un buen trabajo para las necesidades actuales y confiar en nuestra
habilidad para solucionar problemas futuros.

1.11.3. Cambios Incrementales

Realizar grandes cambios en una sola oportunidad no es una buena solucin. Cada
problema debe ser resuelto con una serie de cambios pequeos para poder atacar
dicho problema mucho ms en profundidad.

15

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

1.11.4. Aceptar el Cambio

En XP el cambio es asimilado como algo habitual e inevitable. La mejor estrategia es

aquella que preserva la mayor cantidad de opciones mientras resuelve los problemas
ms precisos.

1.11.5. Trabajo de Calidad

Uno de los objetivos ms importantes en XP es realizar un producto de buena calidad.

Si cada integrante realiza su trabajo de la mejor manera posible se puede asegurar la
calidad del producto.

1.11.6. Otros Principios

Adems de los principios antes mencionados surgen algunos otros de menor

trascendencia que pueden ayudar a tomar buenas decisiones en situaciones
especficas.
Aceptar la responsabilidad
Adaptacin local
Comunicacin abierta y honesta
Ensear conocimientos
Experimentos concretos
Jugar para ganar
Mediciones honestas
Pequea inversin inicial
Trabajar con los instintos de las personas
Viajar liviano

16

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

CAPITULO II:
FACES DE LA
METODOLOGIA
XP

17

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

2.1.FASE PLANEACIN
La planeacin es la etapa inicial de todo proyecto en XP. En este punto se comienza
interactuar con el cliente y el resto del grupo de desarrollo para descubrir los
requerimientos del sistema. En este punto se identifican el nmero y tamao de
las iteraciones al igual que se plantean ajustes necesarios a la metodologa segn
las caractersticas del proyecto.
En este apartado se tendrn en cuenta ocho elementos, los cuales son los
siguientes:
Historias De Usuario.
Velocidad Del Proyecto.
Iteraciones.
Entregas Pequeas.
Reuniones.
Roles En XP.
Traslado Del Personal.
Ajuste A XP.

Figura 3. El juego de Planificacin

Fuente: (info-ab.uclm.es, 2002)

18

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

2.1.1. Historias de usuario

Las historias de usuario son utilizadas como herramienta para dar a conocer
los requerimientos del sistema al equipo de desarrollo. Son pequeos textos en
los que el cliente describe una actividad que realizar el sistema; la redaccin de
los mismos se realiza bajo la terminologa del cliente, no del desarrollador, de forma
que sea clara y sencilla, sin profundizar en detalles.

Las historias de usuario tambin son utilizadas para estimar el tiempo que el
equipo de desarrollo tomar para realizar las entregas. En una entrega se puede
desarrollar una o varias historias de usuario, esto depende del tiempo que demore
la implementacin de cada una de las mismas.

2.1.2. Velocidad del proyecto

Es una medida de la capacidad que tiene el equipo de desarrollo para evacuar las
historias de usuario en una determinada iteracin. Esta medida se calcula totalizando
el nmero de historias de usuario realizadas en una iteracin. Para la iteracin
siguiente se podr (tericamente) implementar el mismo nmero de historias
de usuario que en la iteracin anterior.

2.1.3.

Iteraciones

Por lo general, los proyectos constan de ms de tres etapas, las cuales toman el
nombre de iteraciones, de all se obtiene el concepto de metodologa iterativa. Para
cada iteracin se define un mdulo o conjunto de historias que se van a implementar.
Al final de la iteracin se obtiene como resultado la entrega del mdulo
correspondiente, el cual debe haber superado las pruebas de aceptacin que
establece el cliente para la verificar el cumplimiento de los requisitos. Las tareas
que no se realicen en una iteracin son tomadas en cuenta para la prxima
iteracin, donde se define, junto al cliente, si se deben realizar o si deben ser
removidas de la planeacin del sistema.

19

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

2.1.4. Entregas pequeas

La duracin de una iteracin vara entre una y tres semanas, al final de la cual habr
una entrega de los avances del producto, los cuales debern ser completamente
funcionales. Estas entregas deben caracterizarse por ser frecuentes.

2.1.5. Reuniones

El planeamiento es esencial para cualquier tipo de metodologa, es por ello que XP

requiere de una revisin continua del plan de trabajo. A pesar de ser una metodologa
que evita la documentacin exagerada, es muy estricta en la organizacin del
trabajo.

2.1.6. Roles en XP

Programador
El programador escribe las pruebas unitarias y produce el cdigo del sistema.
Debe existir una comunicacin y coordinacin adecuada entre los
programadores y otros miembros del equipo.

Cliente
El cliente escribe las historias de usuario y las pruebas funcionales para validar
su implementacin. Adems, asigna la prioridad a las historias de usuario y
decide cules se implementan en cada iteracin centrndose en aportar mayor
valor al negocio. El cliente es slo uno dentro del proyecto pero puede
corresponder a un interlocutor que est representando a varias personas que se
vern afectadas por el sistema.

20

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

Encargado de pruebas (Tester)

El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales.
Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es
responsable de las herramientas de soporte para pruebas.

Encargado de seguimiento (Tracker)

El encargado de seguimiento proporciona realimentacin al equipo en el
proceso XP. Su responsabilidad es verificar el grado de acierto entre las
estimaciones realizadas y el tiempo real dedicado, comunicando los resultados
para mejorar futuras estimaciones.
Tambin realiza el seguimiento del progreso de cada iteracin y evala si los
objetivos son alcanzables con las restricciones de tiempo y recursos presentes.
Determina cundo es necesario realizar algn cambio para lograr los objetivos
de cada iteracin.

Entrenador (Coach)
Es responsable del proceso global. Es necesario que conozca a fondo el
proceso XP para proveer guas a los miembros del equipo de forma que se
apliquen las prcticas XP y se siga el proceso correctamente.

Consultor
Es un miembro externo del equipo con un conocimiento especfico en algn
tema necesario para el proyecto. Gua al equipo para resolver un problema
especfico.

Gestor (Big boss)

Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje
efectivamente creando las condiciones adecuadas. Su labor esencial es de
coordinacin.

21

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

2.1.8. Traslado del personal

Al mover el personal se evitan problemas relacionados con la prdida de

conocimiento y cuellos de botella. En la medida que todos los programadores
entienden todas las partes del programa se evita que unos tengan una carga de trabajo
muy alta mientras que otros no tengan mucho trabajo por hacer.

La programacin en parejas se convierte en una herramienta muy importante para

lograr el objetivo del traslado de personal sin que se pierda el rendimiento.

Figura 2: rotacin de parejas.

2.1.9. Ajuste a XP

Todos los proyectos tienen caractersticas especficas por lo cual XP puede ser
modificado para ajustarse bien al proyecto en cuestin. Al iniciar el proyecto
se debe aplicar XP tal como es, sin embargo no se debe dudar en modificar
aquellos aspectos en que no funcione. Eso no quiere decir que los desarrolladores
pueden hacer lo que se les antoje. Antes de implementarse un cambio, este debe
ser discutido y aprobado por el grupo.

22

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

2.2. FASE DISEO

En XP solo se disean aquellas historias de usuario que el cliente ha seleccionado para

la iteracin actual por dos motivos: por un lado se considera que no es posible tener un
diseo completo del sistema y sin errores desde el principio. El segundo motivo
es que dada la naturaleza cambiante del proyecto, el hacer un diseo muy extenso en
las fases iniciales el proyecto para luego modificarlo, se considera un desperdicio de
tiempo.

Los aspectos que se tratarn a continuacin son:

Simplicidad En El Diseo.
Metfora Del Sistema.
Tarjetas Crc.
Spike Solution.
No Solucionar Antes De Tiempo.
Refactoring.

Figura 4. Planificacin y diseo en XP.

Fuente: (info-ab.uclm.es, 2002)
23

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

2.2.1. Simplicidad En El Diseo

Una de las partes ms importantes de la filosofa XP es la simplicidad en

todos los aspectos. Se considera que un diseo sencillo se logra ms rpido
y se implementa en menos tiempo, por lo cual esto es lo que se busca. La idea es
que se haga el diseo ms sencillo que cumpla con los requerimientos de las
historias de usuario.

2.2.2. Metfora Del Sistema

Es muy importante dentro del desarrollo de la metfora darle nombres adecuados

a todos los elementos del sistema constantemente, y que estos correspondan
a un sistema de nombres consistente. Esto ser de mucha utilidad en fases
posteriores del desarrollo para identificar aspectos importantes del sistema.

2.2.3. Tarjetas de clase, responsabilidad, colaboracin (CRC cards)

La principal funcionalidad que tienen estas, es ayudar a dejar el pensamiento
procedimental para incorporarse al enfoque orientado a objetos.

En el proceso de disear el sistema por medio de las tarjetas CRC como

mximo dos personas se ponen de pie adicionando o modificando las tarjetas,
prestando atencin a los mensajes que stas se transmiten mientras los dems
miembros del grupo que permanecen sentados, participan en la discusin
obteniendo as lo que puede considerarse un diagrama de clases preliminar.

2.2.4. Soluciones puntuales (Spike Solution)

Se trata de una pequea aplicacin completamente desconectada del proyecto con
la cual se intenta explorar el problema y propone una solucin potencial. Puede ser
burda y simple, siempre que brinde la informacin suficiente para enfrentar el
problema encontrado.
24

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

2.2.5. No Solucionar Antes De Tiempo

Los

desarrolladores

implementarlas

tienden

predecir

las

necesidades

futuras

antes. Segn mediciones, esta es una prctica ineficiente,

concluyendo que tan solo el 10% de las soluciones para el futuro son utilizadas,
desperdiciando tiempo de desarrollo y complicando el diseo innecesariamente.

En XP slo se analiza lo que se desarrollar en la iteracin actual, olvidando por

completo cualquier necesidad que se pueda presentar en el futuro, lo que
supone uno de los preceptos ms radicales de la programacin extrema.

2.2.6. Refactorizacin (Refactoring)

La refactorizacin en el cdigo pretende conservarlo tan sencillo y fcil de

mantener como sea posible. En cada inspeccin que se encuentre alguna
redundancia, funcionalidad no necesaria o aspecto en general por corregir, se
debe rehacer esa seccin de cdigo con el fin de lograr las metas de sencillez
tanto en el cdigo en s mismo como en la lectura y mantenimiento.

2.3. FASE DESARROLLO

El desarrollo es un proceso que se realiza en forma paralela con el diseo y la cual est
sujeta a varias observaciones por parte de XP consideradas controversiales por
algunos expertos tales como la rotacin de los programadores o la programacin en
parejas.
A continuacin una descripcin de los siguientes temas:
Cliente Siempre Presente.
Codificar Primero La Prueba.
Integracin.
Secuencial.
Integraciones Frecuentes.
25

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

2.3.1. Cliente Siempre Presente

Uno de los requerimientos de XP es que el cliente est siempre disponible. No
solamente para solucionar las dudas del grupo de desarrollo, debera ser parte de
ste. En este sentido se convierte en gran ayuda al solucionar todas las dudas que
puedan surgir, especialmente cara a cara, para garantizar que lo implementado
cubre con las necesidades planteadas en las historias de usuario.

2.3.2. Codificar Primero La Prueba

Una de las ventajas de crear una prueba antes que el cdigo es que permite
identificar los requerimientos de dicho cdigo. En otras palabras, al escribir
primero las pruebas

se encuentran de una forma ms sencilla y con mayor

claridad todos los casos especiales que debe considerar el cdigo a implementar.
De esta forma el desarrollador sabr con completa certeza en qu momento ha
terminado, ya que habrn pasado todas las pruebas.

2.3.3. Programacin En Parejas

Cuando se trabaja en parejas se obtiene un diseo de mejor calidad y un
cdigo ms organizado y con menores errores que si se trabajase solo, adems
de la ventaja que representa contar con un compaero que ayude a solucionar
inconvenientes en tiempo de codificacin, los cuales se presentan con mucha
frecuencia.

Se recomienda que mientras un miembro de la pareja se preocupa del mtodo que

se est escribiendo el otro se ocupe de cmo encaja ste en el resto de la clase.

26

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

2.3.4. Integracin Secuencial

Uno de los mayores inconvenientes presentados en proyectos de software tiene

que ver con la integracin, sobre todo si todos los programadores son dueos de
todo el cdigo. Para saldar este problema han surgido muchos mecanismos,
como darle propiedad de determinadas clases a algunos desarrolladores, los
cuales son los responsables de mantenerlas actualizadas y consistentes. Sin
embargo, sumado al hecho que esto va en contra de la propiedad colectiva el
cdigo no se solucionan los problemas presentados por la comunicacin entre
clases.

2.3.5. Integraciones Frecuentes

Se deben hacer integraciones cada pocas horas y siempre que sea posible
no debe transcurrir ms un da entre una integracin y otra. De esta forma
se garantiza surjan problemas como que un programador trabaje sobre versiones
obsoletas de alguna clase.

Es evidente que entre ms se tarde en encontrar un problema ms costoso ser

resolverlo y con la integracin frecuente se garantiza que dichos problemas se
encuentre ms rpido o an mejor, sean evitados por completo.

2.4. FASE PRUEBAS

Del buen uso de las pruebas depende el xito de otras prcticas, tales como la propiedad
colectiva del cdigo y la refactorizacin. Cuando se tienen bien implementadas las
pruebas no habr temor de modificar el cdigo del otro programador en el sentido que
si se daa alguna seccin, las pruebas mostrarn el error y permitirn encontrarlo. Uno
de los elementos que podra obstaculizar que un programador cambie una seccin
de cdigo funcional es precisamente hacer que esta deje de funcionar. Si se tiene un
grupo de pruebas que garantice su buen funcionamiento, este temor se mitiga en gran
medida.

27

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

Segn XP se debe ser muy estricto con las pruebas.

Slo se deber liberar una nueva versin si esta ha pasado con el cien por
ciento de la totalidad de las pruebas. En caso contrario se emplear el resultado
de estas para identificar el error y solucionarlo con mecanismos ya definidos.

2.4.1. Pruebas Unitarias

Estas pruebas se aplican a todos los mtodos no triviales de todas las clases del
proyecto con la condicin que no se liberar ninguna clase que no tenga asociada
su correspondiente paquete de pruebas. Uno de los elementos ms importantes
en estas es que idealmente deben ser construidas antes que los mtodos mismos,
permitindole al programador tener mxima claridad sobre lo que va a programar
antes de hacerlo, as como conocer cada uno de los casos de prueba que deber
pasar, lo que optimizar su trabajo y su cdigo ser de mejor calidad.

2.4.2. Pruebas de Aceptacin

Las pruebas de aceptacin, tambin llamadas pruebas funcionales son
supervisadas por el cliente basndose en los requerimientos tomados de las
historias de usuario. En todas las iteraciones, cada una de las historias de usuario
seleccionadas por el cliente deber tener una o ms pruebas de aceptacin, de las
cuales debern determinar los casos de prueba e identificar los errores que sern
corregidos.
Las pruebas de aceptacin son pruebas de caja negra, que representan un
resultado esperado de determinada transaccin con el sistema.

2.4.3. Cuando se Encuentra un Error

Al momento de encontrar un error debe escribirse una prueba antes de intentar
corregirlo. De esta forma tanto el cliente lograr tener completamente claro
cul fue y dnde se encontraba el mismo como el equipo de desarrollo podr
enfocar mejor sus esfuerzos para solucionarlo. Por otro lado se lograr evitar
volver a cometerlo.
28

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

CONCLUCIONES

Ninguna prctica funciona bien por si sola (con la excepcin de las pruebas). Requieren las
otras prcticas para equilibrarse.

La XP brinda no solo ventajas en cuanto a rapidez, sino que promueve habilidades sociales
como la comunicacin, el trabajo en equipo y disciplina.

En XP la comunicacin es vital tanto entre el grupo de desarrollo como con el cliente, el cual
debe formar parte del equipo para mantener una comunicacin fluida y poder de esta forma,
evacuar cualquier tipo de duda que surja con los requerimientos.

La programacin extrema se beneficia de la existencia de un gran nmero de herramientas

de software libre que permiten aplicarla con gran productividad.

XP propone una metodologa gil y concreta, aunque requiere de una nueva menara de
pensar, ver y hacer las cosas, tanto por parte de los gerentes (responsables de la rentabilidad
general del proyecto), como de los desarrolladores y tambin del cliente. La aplicabilidad de
sta metodologa a cada proyecto debera ser analizada en cada caso, teniendo en cuenta el
tamao y tipo de proyecto, as como sus ventajas y desventajas.

29

UNIVERSIDAD NACIONAL DE TRUJILLO

INGENIERIA DE SISTEMAS

Cedrn, Choln, Dvila, Noriega & Tern

REFERENCIAS

ECHEVERRY TOBN, Luis Miguel y DELGADO CARMONA, Luz Elena. Caso Prctico
de la Mitologa gil XP al Desarrollo de Software: 2007

AMARO CALDERON, Sarah Damaris y VALVERDE REBAZA, Jorge Carlos.

Metodologas giles: 2007

Programacin Extrema
CALERO SOLIS, Manuel. Una Explicacin de la Programacin Extrema (XP): 2003

CALABRIA, Luis y PIRIZ, Pablo. Metodologa XP: 2003

30