1. UNIVERSIDAD NACIONAL DE TRUJILLO SEDE VALLE
JEQUETEPEQUE
FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS
ESCUELA PROFESIONAL DE INFORMATICA
METODLOGIAS ÁGILES PARA EL DESARROLLO DE SOFTWARE:
PROGRAMACIÓN EXTREMA XP (EXTREME PROGRAMMING)
GÁLVEZ ALCALDE, NILS
GONZALES HORNA, CHRISTIAN
TIRADO TORRES, JORDY

2. INDICE
DEDICATORIA
INTRODUCCIÓN
MARCO TEORICO
CAPITULO I: ¿QUÉ ES PROGRAMACION ESTREMA XP (EXTREME PROGRAMMING)?
1. METODOLOGIA AGIL
2. DIFERENCIAS ENTRE METODLOGIAS AGILES Y NO AGILES
3. XP-EXTREME PROGRAMMIN XP
4. HISTORIA
5. OBJETIVOS DE XP
6. LA FILOSOFIA XP
7. VALORES XP
7.1. COMINICACION
7.2. SIMPLICIDAD
7.3. FEEDBACK
7.4. CORAJE
8. COSTE DEL CAMBIO
9. CICLO DE VIDA XP
EXPLORACION
PLANIFICACION
ITERACIONES POR ENTREGAS
PRODUCCION
MANTENIMIENTO
MUERTE
10. PRINCIPIOS DE XP
10.1 RÁPIDA RETROALIMENTACIÓ
10.2 ASUMIR LA SIMPLICIDAD
10.3 CAMBIOS INCREMENTALES
10.4 ACEPTAR EL CAMBIO
10.5 TRABAJO DE CALIDAD
10.6 OTROS PRINCIPIOS
5
6
7
7
7
8
9
9
10
10
11
11
11
12
12
12
14
14
14
14
14
15
15
15
15
15
15
16
16
16
CAPITULO II: FACES DE LA METODOLOGIA XP
1. PLANEACION
1.1. HISTORIAS DE USUARIO.
1.2. VELOCIDAD DEL PROYECTO.
1.3. ITERACIONES.
1.4. ENTREGAS PEQUEÑAS.
16
16
17
17
17
18
2

3. 2.
3.
4.
1.5.
1.6.
1.7.
1.8.
DISEÑO
2.1.
2.2.
2.3.
2.4.
2.5
2.6
REUNIONES.
ROLES EN XP.
TRASLADO DEL PERSONAL.
AJUSTE A XP.
SIMPLICIDAD EN EL DISEÑO.
METÁFORA DEL SISTEMA.
TARJETAS CRC.
SPIKE SOLUTION.
NO SOLUCIONAR ANTES DE TIEMPO
REFACTORIZACIÓN
DESARROLLO
3.1. CLIENTE SIEMPRE PRESENTE.
3.2. CODIFICAR PRIMERO LA PRUEBA.
3.3. PROGRAMACION EN PAREJAS
3.4. INTEGRACIÓN SECUENCIAL.
3.5. INTEGRACIONES FRECUENTES.
PRUEBAS
4.1. PRUEBAS UNITARIAS
4.2. PRUEVAS DE ACEPTACIÓN
4.3. CUANDO SE ENCUENTRA UN ERROR
CAPITULO III: EJMPLO CASO PRACTICO
DESCRIPCION DEL NEGOCIO
HERRAMIENTAS EMPLEADAS
1. CODIFICACION
CLIENTE SIEMPRE PRESENTE
EL CODIGO SE ESCRIBE SIGUIENDO ESTANDARES
CODIFICAR PRIMERO LA PRUEBA
TODA LA PRODUCCIÓN DE CODIGO DEBE SER HECHA EN PAREJAS
NO TRABAJAR HORAS EXTRAS
2. DISEÑO
SIMPLICIDAD
TARJETAS CRC
SPIKE SOLUTION (SOLUCIONE RÁPIDA)
REFACTORIZACION
3. PLANEACIÓN
HISTORIA DE USUARIO
VELOCIDAD DEL PROYECTO
DIVISION EN ITERACIONES
ENTREGAS PEQUEÑAS
18
18
18
19
19
19
20
20
20
20
21
21
21
21
22
22
22
22
23
23
23
23
23
24
24
24
24
24
25
25
25
25
25
26
26
27
27
29
29
29
3

4. PLAN DE ENTREGAS
4. PRUEBAS
PRUEBAS UNITARIAS
PRUEBAS DE ACEPTACIÓN
CONCLUCIONES
REFERENCIAS
29
30
30
30
31
32
4

5. Dedicamos este trabajo al esfuerzo de nuestros
padres para darnos la mejor educación, y hacen
posible que nosotros seamos mejores personas en
la sociedad.
5

6. INTRODUCCION
Las metodologías agiles tienen un origen reciente en el entorno de la ingeniería de software
comparada con las mitologías pesadas. Su origen está ligado a los constantes inconvenientes que
se presentaban en proyectos con algunas características, en los cuales la utilización de las
metodologías pesadas era motivo de fracaso.
En la década de los 90, surge XtremeProgramming, mejor conocida como XP, una nueva
metodología catalogada entre las agiles por sus aportes al manifiesto ágil. Su creador, Kent Beck se
convirtió en el padre de la programación extrema.
6

7. Marco Teórico
En esta parte del documento se hace una presentación teórica de XP como metodología de
desarrollo y de los principios teóricos que inspiraron esta metodología.
Se inicia don una descripción de general de metodologías agiles, documento q sirve como punto
de partida para las metodologías que reciben el mismo nombre. Prosiguiendo con una
conceptualización importante sobre XP como metodología de desarrollo, la cual costa de los
valores, principios y el alcance de la misma.
Finalmente se entra en detalle con cada una de las etapas de desarrollo (planeación, diseño,
codificación y pruebas) describiendo cada uno de los aspectos que la componen.
CAPÍTULO I: ¿QUÉ ES PROGRAMACION EXTREMA XP (EXTREME PROGRAMMING)?
1. Metodología ágil
A principios de la década del ’90, surgió un enfoque que fue bastanterevolucionario para
su momento ya que iba en contra de toda creencia de quemediante 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
Ingeniería de Software con el nombrede RAD o Rapid ApplicationDevelopment. RAD
consistía en un entorno dedesarrollo altamente productivo, en el que participaban grupos
pequeños deprogramadores utilizando herramientas que generaban código en
formaautomática 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 Metodologías Ágiles y su apreciación como tales en la comunidad de la
Ingeniería de Software tiene sus inicios en la creación de una de las metodologías utilizada
como arquetipo: XP - eXtremeProgramming, 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
ComprehensiveCompensation (C3) payrollsystem. Dada la poca calidad del sistema que se
estaba desarrollando, Beck decide tirar todo el código y empezar de cero utilizando las
prácticas que él había ido definiendo a lo largo del tiempo. El sistema, que administra la
liquidación de aproximadamente 10.000 empleados, y consiste de 2.000 clases y 30.000
métodos, es puesto en operación 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 metodologías ágiles al que se anexarían otras metodologías
surgidas mucho antes que el propio Beck fuera convocado por Chrysler.
Es así como que este tipo de metodologías fueron inicialmente llamadas “metodologías
livianas”, sin embargo, aún no contaban con una aprobación pues se le consideraba por
muchos desarrolladores como meramente intuitiva. Luego, con el pasar de los años, en
febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace formalmente el término
7

8. “ágil” aplicado al desarrollo de software. En esta misma reunión participan un grupo de 17
expertos de la industria del software, incluyendo algunos de los creadores o impulsores de
metodologías de software con el objetivo de esbozar los valores y principios que deberían
permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que
puedan surgir a lo largo del proyecto. Se pretendía ofrecer una alternativa a los procesos
de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la
documentación que se genera en cada una de las actividades desarrolladas.
Tras esta reunión se creó The Agile Alliance, una organización, 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 filosofía “ágil”.
2. DIFERENCIAS ENTRE METODOLOGIAS AGILES Y NO AGILES
La Tabla Nº 1 recoge esquemáticamente las principales diferencias de las metodologías
ágiles con respecto a las tradicionales (“no ágiles”). Estas diferencias que afectan no sólo al
proceso en sí, sino también al contexto del equipo así como a su organización.
Tener metodologías diferentes para aplicar de acuerdo con el proyecto que se desarrolle
resulta una idea interesante. Estas metodologías pueden involucrar prácticas tanto de
metodologías ágiles como de metodologías tradicionales. De esta manera podríamos tener
una metodología para cada proyecto, la problemática sería definir cada una de las
prácticas, y en el momento preciso definir parámetros para saber cuál usar.
Es importante tener en cuenta que el uso de un método ágil no es para todos. Sin
embargo, una de las principales ventajas de los métodos ágiles es su peso inicialmente
ligero y por eso las personas que no estén acostumbradas a seguir procesos encuentran
estas metodologías bastante agradables.
8

9. 3. XP- eXtremeProgramming
XP es la primera metodología ágil y la que le dio conciencia al movimiento actual de
metodologías á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 práctica que de su experiencia sabía que trabajaba bien.
Entonces, Beck decidió girar todas las perillas al máximo para ver que ocurría. Así fue
como dio inicio a XP.
XP es una metodología ágil centrada en potenciar las relaciones interpersonales como
clave para el éxito en el desarrollo de software, promoviendo el trabajo en equipo,
preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de
trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo,
comunicación 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 técnico. A continuación presentaremos las características esenciales de XP
organizadas en los tres apartados siguientes: historias de usuario, roles, proceso y
prácticas.
4. Historia
La Programación Extrema, como proceso de creación de software diferente al
convencional, nace de la mano de Kent Beck (gurú de la XP y autor de los libros más
influyentes sobre el tema).
Chrysler Corporationhacía tiempo que estaba desarrollando una aplicación de nóminas,
pero sin demasiado éxito por parte de la gente que tenía en el proyecto. El verano de
1996, Beck entró en nómina en la compañía y se le pidió de hacer esta aplicación como
trabajo. Es en esta aplicación cuando nace la Programación Extrema como tal.
Beck reconoció que el proceso (o metodología) de creación de software o la carencia de
este era la causa de todos los problemas y llegó a la conclusión 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 tenían que acomodar al cambio a realizar.
Él tenía varias ideas de metodologías para la realización de programas que eran cruciales
para el buen desarrollo de cualquier sistema.
Las ideas primordiales de su sistema las comunicó en la revista C++ Magazine en una
entrevista que ésta le hizo el año 1999. En ésta decía que él estaba convencido que la
mejor metodología era un proceso que enfatizase la comunicación dentro del equipo, que
9

10. la implementación fuera sencilla, que el usuario tenía que estar muy informado e
implicado y que la toma de decisiones tenía que ser muy rápida y efectiva.
Los autores (o mejor dicho, los propulsores como el propio Kent Beck, Ward Cunningham
o Ron Jeffries entre otros) de la Programación Extrema, fueron a la web Portland
PatternRepositoryy empezaron a hablar de ella y promocionarla, de lo que era y cómo
realizarla. Estos propulsores de la XP hablaban de ella en cada ocasión que tenían y en
cada página que, poco o mucho hablara de temas de programación.
Este hecho, llegó a molestar a buena parte de la comunidad que intentaba discutir sobre
temas de programación. Fue tanta esta molestia que nació el fenómeno XP Free
Zone(zona libre de XP) en determinadas webs como petición de no hablar de
Programación Extrema en ella.
La discusión sobre temas de diseño de modelos de programación sobre los cambios
recientes se hizo tema difícil porque la mayoría de la actividad fue relacionada con la
Programación Extrema. Eventualmente, y debido a ésto, la mayoría de la gente que solía
discutir sobre los temas de diseño de modelos de programación fue apartándose de este
ambiente para discutir sus ideas en otros ambientes más "reservados". La comunidad
empezó a referirse a estos sitios como a Salas Wiki (Wards Wiki).
5. Objetivos de XP
Los objetivos de XP son muy simples: la satisfacción del cliente. Esta metodología trata de
dar al cliente el software que él necesita y cuando lo necesita. Por tanto, debemos
responder muy rápido a las necesidades del cliente, incluso cuando los cambios sean al
final de ciclo de la programación.
Potenciar al máximo el trabajo en grupo. Tanto los jefes de proyecto, los clientes y
desarrolladores, son parte del equipo y están involucrados en el desarrollo del software.
EstablecerlasmejoresprácticasdeIngenieríadeSoftwareenlosdesarrollodeproyectos.
Mejorar la productividad de los proyectos.
Garantizarla Calidad del Software desarrollando, haciendo que este supere las
expectativas del cliente.
Asumir que con cierta planificación, codificación y pruebas se puede decidir si se está
siguiendo un camino correcto o equivocado, evitando retroceder cuando sea demasiado
tarde.
6. La filosofía de XP
XP es una metodología ágil para pequeños y medianos equipos, desarrollando software
cuando los requerimientos son ambiguos o rápidamente 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 ynecesita, en el momento que lo precisa,
10

11. alentando a los programadores a responder a los requerimientos cambiantesque plantea
el cliente en cualquier momento. Esto es posible porque está diseñado para adaptarse en
formainmediata a los cambios, con bajos costos asociados, en cualquier etapa del ciclo de
vida. En pocas palabras, XP“abraza” el cambio.
7. Valores en XP
Para poder implementar las prácticas que presenta XP hay que conocer cuáles son los
valores principales que hacen a esta mitología. Estos valores son:




7.1
Comunicación.
Simplicidad.
Feedback.
Coraje.
Comunicación
Uno de los valores más importantes en XP es la comunicación. La mala comunicación 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 atención.
En cualquiera de los casos la comunicación es un factor importante en cualquier tipo de
proyecto. En XP se trata de mantener una buena comunicación mediante un conjunto de
prácticas que no se pueden realizar sin tener una buena comunicación en el equipo.
Muchas de estas prácticas hacen corto circuito si no hay buena comunicación como en el
caso de los testing unitarios, programación por pares, el uso de estándares o la estimación
de las tareas. Trabajar en espacios abiertos hace que la comunicación mejore al contrario
de otras metodologías en las cuales los programadores trabajan en espacios reducidos.
La comunicación 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. Además, se planifica con el cliente y este puede
estar al tanto del avance del proyecto.
XP ha sido diseñada para minimizar el grado de documentación como forma de
comunicación, haciendo énfasis en la interacción personal. De esta manera se puede
avanzar rápidamente y de forma efectiva, realizando solo la documentación necesaria.
7.2
Simplicidad
La simplicidad es el segundo valor que se utiliza en esta metodología. XP apuesta a realizar
algo simple hoy y destinar un poco más de esfuerzo para realizar un cambio en el futuro, a
realizar algo más complicado hoy y no utilizarlo nunca.
XP propone una regla muy simple: “hacer algo que funcione de la manera más sencilla”. En
el caso de tener que añadir nueva funcionalidad al sistema se deben examinar todas las
11

12. posibles alternativas y seleccionar la más sencilla. En otras ocasiones se hace uso del
refactoring1 que permite mantener el código en funcionamiento pero mucho más simple y
organizado.
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 más segura y rápida en
el proyecto.
7.3
Feedback
Brindar un feedback correcto y preciso hace que se pueda mantener una buena
comunicación 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
estimación 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 través de pequeñas entregas del sistema. De
esta manera, el cliente está al tanto del avance del proyecto. Además, el sistema es puesto
en producción en menor tiempo, con lo cual los programadores saben si realizaron un
buen trabajo y si sus decisiones fueron acertadas.
7.4
Coraje
Obviamente cada uno de los valores antes mencionados tiene una gran interacción entre
ellos. Como se ve en la siguiente figura la comunicación, 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 más 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 código en cualquier
momento por cualquier miembro del equipo sabiendo que no se afectará el correcto
funcionamiento del sistema.
El coraje también es poder realizar cambios cuando algo no funciona del todo bien,
diseñar 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 estén presentes.
8. 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
12

13. sistema que empleas hace que el coste del software aumente con el tiempo debes de
actuar de forma diferente a cómo lo haces. XP propugna que esta curva ha perdido validez
y con una combinación de buenas prácticas de programación y tecnología 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
¿cómo se consigue dicha curva?, no existe una forma mágica desde luego hay varias
medidas que nos ayudan a conseguirla.
Diseñar lo más sencillo que sea posible, para hacer sólo lo imprescindible en un momento
dado, la simplicidad del código y los test continuos hacen que los cambios sean posibles
tan a menudo como sea necesario.
La programación orientada a objetos es una tecnología clave para el mantenimiento
delsoftware, cada mensaje a un objeto es una oportunidad de cambio sin necesidad de
cambiar elcódigo existente, esto no quiere decir que no puedas tener flexibilidad sin
programar orientadoal objeto y el caso contrario que haya programas orientados a objetos
que nadie quería tocar,sólo se dice que el programar orientado a objetos reduce el costo
del cambio.
En vez de tomar grandes decisiones al principio y pocas posteriormente, podemosidear
una aproximación para desarrollar software en la que se tomen decisiones
rápidamente,pero estas decisiones apoyadas por pruebas y que te preparan para mejorar
el diseño delsoftware cuando aprendas una mejor manera de diseñarlo.
He oído a muchos programadores (entre los que me incluyo) decir: “Hasta que no
heterminado el programa no lo he entendido ahora lo haría con esta jerarquía y que esta
claseherede de esta otra”, dejemos pues abierta la puesta a esta posibilidad.
13

14. 9. Ciclo de Vida de XP
El ciclo de vida de XP consiste básicamente de seis fases: Exploración, Planificación,
IterationstoRelease, Producción, Mantenimiento y Muerte.
Exploración
En esta fase los clientes realizan las storycards que desean que estén para la primera
entrega. Cada story describe una de las funcionalidades que el programa tendrá. Al mismo
tiempo el equipo de desarrollo se familiariza con las herramientas, la tecnología y las
prácticas a ser utilizadas durante el proyecto. En algunos casos se utiliza un prototipo para
testear la nueva tecnología y explorar algunos aspectos de la arquitectura a ser
implementada. La duración de esta fase puede extenderse desde unas pocas semanas a
varios meses dependiendo de la adaptación del equipo de desarrollo.
Planificación
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 duración del calendario para la
entrega del primer release no suele superar los dos meses. Duración de la fase de
planificación en sí no toma más de dos días.
Iteraciones por entregas
Esta fase incluye varias iteraciones del sistema antes de la entrega del primer release. El
calendario es dividido en un número iteraciones de tal manera de que cada iteración tome
de una a cuatro semanas de implementación. En la primera iteración se crea un sistema
que abarca los aspectos más importantes de la arquitectura global. Esto se logra
seleccionando las stories que hagan referencia a la construcción de la estructura de todo
el sistema.
El cliente decide que stories van a ser implementadas para cada iteración. Además, se
realizan los test funcionales, realizados por el cliente, al final de cada iteración. Al final de
la última iteración el sistema está listo para ser puesto en producción.
Producción
La fase de producción requiere realizar muchos más chequeos y testing antes que el
sistema sea entregado al cliente. En esta fase aparecen nuevos cambios y se tiene que
decidir si serán 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 más adelante, por ejemplo, en la fase
de mantenimiento.
14

15. Luego que el primer release es creado, el proyecto debe mantener el sistema en
producción 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 producción. A raíz 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
más cambios en la arquitectura, el diseño o el código y aquí es cuando se realiza la
documentación correspondiente. Esta fase aparece también, cuando el sistema no da los
resultados deseados o se vuelve demasiado caro para seguir siendo desarrollado.
10. Principios de XP
Los cuatro valores mencionados anteriormente – comunicación, simplicidad, feedback y
coraje – nos brindan un estándar para obtener buenos resultados. Sin embargo, los
valores son muy vagos a la hora de ayudarnos a decidir que prácticas utilizar. Para ello se
necesita destilar estos valores en principios que puedan ser utilizados.
10.1 Rápida Retroalimentación
En la práctica el tiempo transcurrido entre una acción y su feedback es crítico. Tener una
rápida retroalimentación nos permite interpretarla, aprender de ella y poner en práctica lo
asimilado lo antes posible.
10.2 Asumir la Simplicidad
Este es uno de los principios más difíciles de llevar a la práctica. Casi siempre se planifica
para el futuro y se diseña 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.
10.3 Cambios Incrementales
Realizar grandes cambios en una sola oportunidad no es una buena solución. Cada
problema debe ser resuelto con una serie de cambios pequeños para poder atacar dicho
problema mucho más en profundidad.
15

16. 10.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 más
precisos.
10.5 Trabajo de Calidad
Uno de los objetivos más 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.
10.6 Otros Principios
Además de los principios antes mencionados surgen algunos otros de menor
trascendencia que pueden ayudar a tomar buenas decisiones en situaciones específicas.










Aceptar la responsabilidad
Adaptación local
Comunicación abierta y honesta
Enseñar conocimientos
Experimentos concretos
Jugar para ganar
Mediciones honestas
Pequeña inversión inicial
Trabajar con los instintos de las personas
Viajar liviano
CAPITULO II: FACES DE LA METODOLOGIA XP
1. PLANEACIÓN
La planeación es la etapa inicial de todo proyecto en XP. En este punto se comienza a
interactuar con el cliente y el resto del grupo de desarrollo para descubrir los
requerimientos del sistema. En este punto se identifican el número y tamaño de las
iteraciones al igual que se plantean ajustes necesarios a la metodología según las
características del proyecto.
En este apartado se tendrán en cuenta ocho elementos, los cuales son los
siguientes:
 Historias De Usuario.
 Velocidad Del Proyecto.
 Iteraciones.
16

17. 




Entregas Pequeñas.
Reuniones.
Roles En XP.
Traslado Del Personal.
Ajuste A XP.
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 pequeños textos en los
que el cliente describe una actividad que realizará el sistema; la redacción de los mismos
se realiza bajo la terminología del cliente, no del desarrollador, de forma que sea clara y
sencilla, sin profundizar en detalles.
Las historias de usuario también 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
implementación de cada una de las mismas.
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 iteración. Esta medida se calcula totalizando el
número de historias de usuario realizadas en una iteración. Para la iteración
siguiente se podrá (teóricamente) implementar el mismo número de historias de
usuario que en la iteración anterior.
Cabe recordar que la velocidad del proyecto ayuda a determinar la cantidad de historias
que se pueden implementar en las siguientes iteraciones, aunque no de manera
exacta.
1.3. Iteraciones
Por lo general, los proyectos constan de más de tres etapas, las cuales toman el nombre
de iteraciones, de allí se obtiene el concepto de metodología iterativa.
Para cada iteración se define un módulo o conjunto de historias que se van a
implementar. Al final de la iteración se obtiene como resultado la entrega del módulo
correspondiente, el cual debe haber superado las pruebas de aceptación que establece
el cliente para la verificar el cumplimiento de los requisitos. Las tareas que no se
realicen en una iteración son tomadas en cuenta para la próxima iteración, donde se
define, junto al cliente, si se deben realizar o si deben ser removidas de la planeación del
sistema.
17

18. 1.4. Entregas pequeñas
La duración de una iteración varía entre una y tres semanas, al final de la cual habrá una
entrega de los avances del producto, los cuales deberán ser completamente
funcionales. Estas entregas deben caracterizarse por ser frecuentes.
1.5. Reuniones
El planeamiento es esencial para cualquier tipo de metodología, es por ello que XP
requiere de una revisión continua del plan de trabajo. A pesar de ser una metodología
que evita la documentación exagerada, es muy estricta en la organización del trabajo.
1.6. Roles en XP
El jefe de proyecto tiene como responsabilidad la dirección y organización de las
reuniones que se realizan durante el proyecto.
El usuario o cliente determina qué se va a construir en el sistema, además
de decidir el orden en que se entregarán cada segmento del proyecto.
En el grupo de los programadores se encuentran además los diseñadores y los
analistas. Los programadores son quienes construyen el sistema y realizan las
pruebas correspondientes a cada módulo o unidad de código.
El tester o quien realiza las pruebas, colabora en la realización de las pruebas de
aceptación y es quien muestra los resultados de las mismas.
El rastreador (tracker) tiene como tarea observar la realización del sistema.
Varias veces por semana cuestiona a los integrantes del equipo para anotar
sus logros y avances.
1.7. Traslado del personal
Al mover el personal se evitan problemas relacionados con la pérdida 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 programación en parejas se convierte en una herramienta muy importante para lograr
el objetivo del traslado de personal sin que se pierda el rendimiento.
18

19. Figura 2: rotación de parejas.
1.8. Ajuste a XP
Todos los proyectos tienen características específicas por lo cual XP puede ser
modificado para ajustarse bien al proyecto en cuestión. 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.
2. DISEÑO
En XP solo se diseñan aquellas historias de usuario que el cliente ha seleccionado para la
iteración actual por dos motivos: por un lado se considera que no es posible tener un diseño
completo del sistema y sin errores desde el principio. El segundo motivo es que
dada la naturaleza cambiante del proyecto, el hacer un diseño muy extenso en las fases
iniciales el proyecto para luego modificarlo, se considera un desperdicio de tiempo.
Los aspectos que se tratarán a continuación son:






Simplicidad En El Diseño.
Metáfora Del Sistema.
Tarjetas Crc.
SpikeSolution.
No Solucionar Antes De Tiempo.
Refactoring.
2.1. Simplicidad En El Diseño
Una de las partes más importantes de la filosofía XP es la simplicidad en todos
los aspectos. Se considera que un diseño sencillo se logra más rápido y se
implementa en menos tiempo, por lo cual esto es lo que se busca. La idea es que se
19

20. haga el diseño más sencillo que cumpla con los requerimientos de las historias de
usuario.
2.2. Metáfora Del Sistema
Es muy importante dentro del desarrollo de la metáfora 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.3. Tarjetas de clase, responsabilidad, colaboración (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 diseñar el sistema por medio de las tarjetas CRC como
máximo dos personas se ponen de pie adicionando o modificando las tarjetas,
prestando atención a los mensajes que éstas se transmiten mientras los demás
miembros del grupo que permanecen sentados, participan en la discusión obteniendo
así lo que puede considerarse un diagrama de clases preliminar.
2.4. Soluciones puntuales (SpikeSolution)
Se trata de una pequeña aplicación completamente desconectada del proyecto con la
cual se intenta explorar el problema y propone una solución potencial. Puede ser burda
y simple, siempre que brinde la información suficiente para enfrentar el problema
encontrado.
2.5. No Solucionar Antes De Tiempo
Los desarrolladores tienden a predecir las necesidades futuras e implementarlas
antes. Según mediciones, esta es una práctica ineficiente, concluyendo que tan solo el
10% de las soluciones para el futuro son utilizadas, desperdiciando tiempo de
desarrollo y complicando el diseño innecesariamente.
En XP sólo se analiza lo que se desarrollará en la iteración actual, olvidando por
completo cualquier necesidad que se pueda presentar en el futuro, lo que
supone uno de los preceptos más radicales de la programación extrema.
20

21. 2.6. Refactorización (Refactoring)
La refactorización en el código pretende conservarlo tan sencillo y fácil de mantener
como sea posible. En cada inspección que se encuentre alguna redundancia,
funcionalidad no necesaria o aspecto en general por corregir, se debe rehacer esa
sección de código con el fin de lograr las metas de sencillez tanto en el código en
sí mismo como en la lectura y mantenimiento.
3. DESARROLLO
El desarrollo es un proceso que se realiza en forma paralela con el diseño y la cual está
sujeta a varias observaciones por parte de XP consideradas controversiales por
algunos expertos tales como la rotación de los programadores o la programación en parejas.
A continuación una descripción de los siguientes temas:





Cliente Siempre Presente.
Codificar Primero La Prueba.
Integración.
Secuencial.
Integraciones Frecuentes.
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, debería 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.
3.2. Codificar Primero La Prueba
Una de las ventajas de crear una prueba antes que el código es que permite identificar
los requerimientos de dicho código. En otras palabras, al escribir primero las
pruebas se encuentran de una forma más sencilla y con mayor claridad todos los casos
especiales que debe considerar el código a implementar. De esta forma el
desarrollador sabrá con completa certeza en qué momento ha terminado, ya que
habrán pasado todas las pruebas.
21

22. 3.3. Programación En Parejas
Cuando se trabaja en parejas se obtiene un diseño de mejor calidad y un código
más organizado y con menores errores que si se trabajase solo, además de la
ventaja que representa contar con un compañero que ayude a solucionar
inconvenientes en tiempo de codificación, los cuales se presentan con mucha
frecuencia.
Se recomienda que mientras un miembro de la pareja se preocupa del método que se
está escribiendo el otro se ocupe de cómo encaja éste en el resto de la clase.
3.4. Integración Secuencial
Uno de los mayores inconvenientes presentados en proyectos de software tiene que
ver con la integración, sobre todo si todos los programadores son dueños de todo el
código. 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 del código no se solucionan los
problemas presentados por la comunicación entre clases.
3.5. Integraciones Frecuentes
Se deben hacer integraciones cada pocas horas y siempre que sea posible no
debe transcurrir más un día entre una integración y otra. De esta forma se
garantiza surjan problemas como que un programador trabaje sobre versiones
obsoletas de alguna clase.
Es evidente que entre más se tarde en encontrar un problema más costoso será
resolverlo y con la integración frecuente se garantiza que dichos problemas se
encuentre más rápido o aún mejor, sean evitados por completo.
4. PRUEBAS
Del buen uso de las pruebas depende el éxito de otras prácticas, tales como la propiedad
colectiva del código y la refactorización. Cuando se tienen bien implementadas las pruebas
no habrá temor de modificar el código del otro programador en el sentido que si se daña
alguna sección, las pruebas mostrarán el error y permitirán encontrarlo. Uno de los
elementos que podría obstaculizar que un programador cambie una sección de código
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.
22

23. Según XP se debe ser muy estricto con las pruebas. Sólo se deberá liberar una
nueva versión 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.
4.1. Pruebas Unitarias
Estas pruebas se aplican a todos los métodos no triviales de todas las clases del
proyecto con la condición que no se liberará ninguna clase que no tenga asociada su
correspondiente paquete de pruebas. Uno de los elementos más importantes en
estas es que idealmente deben ser construidas antes que los métodos mismos,
permitiéndole al programador tener máxima 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 código será de mejor calidad.
4.2. Pruebas de Aceptación
Las pruebas de aceptación, también llamadas pruebas funcionales son supervisadas
por el cliente basándose 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 más pruebas de aceptación, de las cuales deberán
determinar los casos de prueba e identificar los errores que serán corregidos.
Las pruebas de aceptación son pruebas de caja negra, que representan un resultado
esperado de determinada transacción con el sistema.
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
cuál fue y dónde 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.
CAPITULO III: EJEMPLO DE CASO PRÁCTICO
Descripción del negocio:
Se trata de un mini mercado en formato de autoservicio con un capital de aproximadamente
quince millones de pesos el cual atiende a una población alrededor de 550 familias ubicado en la
zona de Altos de Llano Grande cerca al Parque Industrial en la ciudad de Pereira.
Al momento de iniciar el proyecto, el negocio contaba con una caja registradora convencional la
cual no ofrecía las funcionalidades que requería el cliente, por lo cual se acordó desarrollar un
23

24. software que desempeñara las funcionalidades de un sistema POS (Point Of Sale) con elementos
de administración de inventario que cumpliera las necesidades específicas del cliente.
Herramientas Empleadas
Se optó por seleccionar herramientas libres para el desarrollo de la aplicación. Por un lado se
empleó JAVA como herramienta de desarrollo mientras que como motor de base de datos se
decidió por PostgreSQL.
1. CODIFICACIÓN
Entre los elementos más importantes que menciona XP referentes a la codificación están:
• Cliente siempre presente
• El código se escribe siguiendo estándares
• Toda la producción de código debe ser hecha en parejas
• No trabajar horas Extras
• Codificar primero la prueba
Cliente siempre presente
En el caso de este proyecto, el cliente no podía desplazarse a ninguno de los lugares
de trabajo de los desarrolladores dado que debía estar al frente de su negocio.
Por tal motivo se debió implementar una estrategia de comunicación distinta, en la
cual los programadores podían llamar vía telefónica al cliente en el momento que
requirieran solucionar cualquier duda.
Si bien esta estrategia no fue igual de efectiva que haber tenido al usuario
acompañando el desarrollo, fue suficiente para lograr una buena comunicación con el
cliente.
El código se escribe siguiendo estándares.
La estandarización del código fue asumida desde el mismo momento en que se inició
la codificación.
En el caso de este proyecto se aplicaron todos los estándares con gran éxito debido a
dos motivos. En primer lugar, la herramienta empleada para desarrollar facilitaba el
aplicar dichos estándares y en segundo, que los mismos venían siendo empleados
desde antes por el equipo de desarrollo.
Codificar primero la prueba
¿Se trata de codificar SIEMPRE una prueba antes que el código, o solo aquellas clases
encargadas de realizar la lógica del negocio? Debido que XP no tiene una respuesta clara a
esta inquietud el grupo de desarrollo optó por probar solo aquellas clases que ejecutan la
24

25. lógica del negocio, que en definitiva son las más importantes y de las cuales se debe tener
garantía de estar muy bien construidas.
Toda la producción de código debe ser hecha en parejas
El no contar con una sede permanente complicó seriamente el cumplimiento del objetivo
de programar en parejas.
En XP se tiene como salvedad para trabajar en parejas que uno o ambos de los
programadores sean expertos en la herramienta que se está empleando. En el caso de
ambos desarrolladores, tenían conocimientos elevados sobre todas las herramientas que
se emplearon, por lo cual el nivel de autonomía fue superior.
No trabajar horas Extras
El plantearse trabajar horas extras después de una jornada completa de desarrollo sugiere
más una pérdida de tiempo que una recuperación de los atrasos del proyecto. En el caso
de este proyecto no se trabajaron horas extras debido a que se tuvo la precaución de
plantear plazos amplios en las entregas con el fin de considerar cualquier posible
inconveniente que surgiera en la implementación.
2. DISEÑO
Entre los elementos más importantes que menciona XP referentes al diseño están:
•Simplicidad
•Las tarjetas CRC
•El Refactoring
•SpikeSolution
SIMPLICIDAD
En lo que respecta a la sencillez del diseño, se acogió la recomendación de XP, sólo
invirtiendo el tiempo exclusivamente necesario en elaboración de diagramas y diseño de
interfaz gráfica.
TARJETAS CRC
Una de las principales piezas de diseño empleada en el proyecto fueron las tarjetas CRC
que no sólo sirvieron como columna vertebral de este, sino que también fueron la base del
modelo Entidad Relación, elaborado para modelar la base de datos. Cada Tarjeta CRC se
convirtió en un objeto, sus responsabilidades en métodos públicos y sus colaboradores en
llamados a otras clases.
En el proceso de elaboración de las tarjetas CRC los dos miembros del equipo estuvieron
presentes manipulándolas, de modo tal que tanto el diseño fue producto de la
participación de los dos desarrolladores.
25

26. Tabla 1: Venta
SPIKE SOLUTION (SOLUCIÓN RÁPIDA)
Para implementar las pruebas tal como XP las recomienda se debió recurrir a una librería
especialmente diseñada para tal fin, JUnit. El estudio de esta fue encargado a uno de
losdesarrolladores, el cual destinó aproximadamente ocho horas a su estudio, al término
de las cuales en un periodo no mayor a dos horas capacitó en el empleo de la librería al
otro desarrollador. Por otro lado, se requirió de una herramienta que permitiera crear
reportes impresos de calidad de una forma sencilla. La mejor solución encontrada fue
JasperReport, la cual fue estudiada en el transcurso de la primera iteración por un
desarrollador, al término del cual se compartió la información al otro desarrollador tal
como en el caso anterior, sin que retrasara sus demás responsabilidades con el proyecto.
REFACTORIZACIÓN
Al transcurrir el desarrollo de la aplicación, se revisó constantemente el diseño de la
misma surgiendo situaciones que no fueron tomadas en cuenta al comienzo del proyecto
en el diseño general. Como salida a estos problemas se optó por la refactorización de las
partes afectadas, buscando las soluciones más convenientes y sencillas, conservando la
simplicidad del código. Aunque estos cambios fueron extensos, en ningún momento se
convirtieron en cuellos de botella.
26

27. 3. PLANEACIÓN
En la planeación se tendrán en cuenta varios elementos, los cuales son los siguientes.
•
•
•
•
•
Historias de usuario
Velocidad del proyecto
División de Iteraciones
Entregas Pequeñas
Plan de entregas
HISTORIA DE USUARIO
Si bien el cliente no fue quien escribió personalmente las historias de usuario, fue él quien
diseñó su contenido y dirigió la redacción de las mismas.
Desde el punto de vista del nivel de detalle, se siguió la directiva en el sentido de no
profundizar ni en descripciones ni en procesos, manteniéndolas de esta forma breve y
clara.
Una vez recolectadas todas las historias de usuario, se hizo una reunión del equipo de
trabajo donde se plantearon los tiempos necesarios para su implementación, los cuales
resultaron en estimaciones inusualmente aproximadas de los tiempos de desarrollo en
comparación con los realmente requeridos.
Finalmente desde el punto de vista del número de historias de usuario, se obtuvo un total
de veintiuno. Considerando por un lado la recomendación de que no sean menos de 20 ni
más de 80.
27

28. FIGURA 3: Historia de Usuario 1
FIGURA 3: Historia de Usuario 2
28

29. VELOCIDAD DEL PROYECTO
El número de historias de usuario realizadas por iteración no fue una buena medida de la
velocidad del proyecto debido que no todas tenían el mismo nivel de dificultad y por tanto
el mismo requerimiento de horas de desarrollo.
Tabla 2°: Velocidad del Proyecto
DIVISIÓN EN ITERACIONES
El proyecto fue dividido en 4 iteraciones, por consiguiente se obtuvo un total de cuatro
entregas para las cuales se desarrollaron partes de la aplicación completamente
funcionales.
La primera iteración se refirió al módulo de POST mientras las demás iteraciones se
relacionaron con la manipulación de inventarios.
En la planeación de iteraciones se tomaron dos semanas como período, excepto en la
última, la cual sólo se fijó para una semana, ya que se redujo la carga de obligaciones
externas al proyecto.
ENTREGAS PEQUEÑAS
Debido a que las iteraciones tenían una duración de 15 días, fue al término de este plazo
que se realizaron entregas, las cuales siempre fueron funcionales, lo que quiere decir que
al momento de la entrega estaban en condiciones de ser puestas en funcionamiento en las
instalaciones del cliente. Esto representó un éxito en el desarrollo del proyecto ya que
mantenía el interés del cliente en continuarlo debido a que estaba viendo resultados en el
corto plazo.
PLAN DE ENTREGAS
1. Se realizaron tres reuniones iníciales.
2. La tarea de escoger las historias fue realizada por el grupo en conjunto,
incluyendo al cliente, lo cual no generó problemas en las entregas de los
módulos funcionales.
29

30. 3. La clasificación de las historias no fue realizada estrictamente por su grado de
importancia en el proyecto. Sólo se optó por desarrollar el módulo de servicio
al cliente en la primera iteración, por tratarse de la actividad más importante
en el negocio.
4. Para aproximar el tiempo que demoraría cada iteración, se tomó como
medida dos semanas. Cada semana constaba de cuatro días (lunes, martes,
jueves y viernes)en los que se trabajaban cuatro horas sin distracciones.
4. PRUEBAS
Pruebas unitarias
El carácter obligatorio de la escritura de las pruebas antes del desarrollo de los métodos
del sistema implica un proceso de diseño previo. Esto se considera una ventaja ya que se
destina tiempo en la construcción de la prueba, pero al realizar la codificación del método,
éste resultaba de manera casi inmediata. También se destaca la autonomía que deben
tener dichas pruebas a la hora de su ejecución, lo que implicaba la manipulación de la base
de datos y la recuperación de su estado inicial al finalizar la prueba.
Pruebas de aceptación
Tres elementos permitieron al grupo de desarrollo diseñar las pruebas de aceptación. En
primer lugar el tipo de sistema implementado era suficientemente sencillo y conocido por
todos los miembros del equipo de desarrollo, en segundo lugar las reuniones de las cuales
se obtuvieron las historias de usuario fueron grabadas en audio y video y en tercer lugar el
cliente aceptó el delegar esta función de diseño de las pruebas debido que su
disponibilidad de tiempo, como ya es mencionada en otros apartados del documento, se
lo impidió.
30

31. CONCLUCIONES
Ninguna práctica funciona bien por si sola (con la excepción de las pruebas). Requieren las otras
prácticas para equilibrarse.
La XP brinda no solo ventajas en cuanto a rapidez, sino que promueve habilidades sociales como la
comunicación, el trabajo en equipo y disciplina.
En XP la comunicación es vital tanto entre el grupo de desarrollo como con el cliente, el cual debe
formar parte del equipo para mantener una comunicación fluida y poder de esta forma, evacuar
cualquier tipo de duda que surja con los requerimientos.
Es claro que no existe una metodología única para garantizar el éxito de cualquier proyecto de
desarrollo de software, y esto aplica también a XP. Toda metodología requiere de cierta
adaptación al proyecto, al cliente y a la idiosincrasia de la empresa desarrolladora.
XP propone una metodología á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 también del cliente. La aplicabilidad de ésta metodología
a cada proyecto debería ser analizada en cada caso, teniendo en cuenta el tamaño y tipo de
proyecto, así como sus ventajas y desventajas.
31

32. REFERENCIAS
ECHEVERRY TOBÓN, Luis Miguel y DELGADO CARMONA, Luz Elena. Caso Práctico de la Mitología
Ágil XP al Desarrollo de Software: 2007
AMARO CALDERON, Sarah Damaris y VALVERDE REBAZA, Jorge Carlos. Metodologías Ágiles: 2007
Programación Extrema
CALERO SOLIS, Manuel. Una Explicación de la Programación Extrema (XP): 2003
CALABRIA, Luis y PIRIZ, Pablo. Metodología XP: 2003
32