UNIVERSIDAD NACIONAL DE SAN

AGUSTÍN
FACULTAD DE INGENIERÍA CIVIL
ESCUELA PROFESIONAL DE INGENIERÍA CIVIL

”METODOLOGÍA DE XP ADAPTABLE A PMBOK”

DOCENTE:
ING. KARINA ARIAS CALLUARI

INTEGRANTES:

CARDENAS LOPEZ, JOSUE BENJAMIN

LIZARVE MAMANI, JOHAN FABRICIO
MAMANI AGUILAR, FLOR DE MARIA ROSARIO
MAYTA PINTO, JHULINO ANDRE
RAMOS VILCA, LAURA ADRIANA

AREQUIPA-PERU

2021
ÍNDICE

1. Metodologı́a XP 2
1.1. Herramientas De La Metodologı́a XP . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Historias de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2. Tareas de Ingenierı́as (Task Card) . . . . . . . . . . . . . . . . . . . . . . 4
1.1.3. Pruebas de Aceptación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.4. Tarjetas CRC (Clase-Responsabilidades-Colaboradores) . . . . . . . . . . 5
1.1.5. Roles de la metodologı́a XP . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.6. Fases de XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.7. Prácticas de la metodologı́a XP . . . . . . . . . . . . . . . . . . . . . . . 8

2. Adaptabilidad entre metodologı́as 9

2.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Metodologı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Conclusiones y Recomendaciones 12

BIBLIOGRAFÍA 14

1
1. Metodologı́a XP
El método XP o Extreme Programming fue diseñado para desarrollo de software, con-
sistiendo en un conjunto de prácticas que permiten la resolución de problemas de entrega,
centrándose en los requisitos del cliente para conseguir un producto de buena calidad en poco
tiempo [Rodrı́guez Vázquez and Diaz Varela, 2018].
XP se usa principalmente en proyectos de software, normalmente de pequeño tamaño, aun-
que se puede utilizar en proyectos más extensos con la división de éstos. XP se fundamenta
en los valores de comunicación continua con el cliente, simplicidad, retroalimentación con el
cliente, valentı́a como actitud frente al cambio, y respeto de todos los miembros del equipo
hacia el mismo objetivo de calidad del proyecto. Dicho equipo incluirá como miembros el pro-
gramador, el cliente, los encargados de pruebas y seguimiento, el entrenador, el consultor, y el
gestor [Rodrı́guez Vázquez and Diaz Varela, 2018].

Figura 1: Ciclo de vida ideal de XP [Rodrı́guez Vázquez and Diaz Varela, 2018].

La ventaja de su uso es que permite acortar los procesos tradicionales, tiene entre sus prin-
cipios básicos la comunicación, que afecta a la calidad de los proyectos debido a que se consigue
generar una retroalimentación con los interesados, este hecho ayuda a definir el proyecto y me-
jorar la calidad, otros aspectos importantes son la adaptación al cambio, la mejora continua,
reducir plazos de desarrollo y exposición a riesgos que puedan afectar negativamente al proyec-
to. En vez de entregar todo lo que pueda desear en una fecha lejana en el futuro, este proceso
proporciona el software que se requiere en ese momento [Rodrı́guez Vázquez and Diaz Varela,
2018].
La programación Extrema (XP), promueve el desarrollo basado en la Simplicidad y la
Adaptabilidad. El proceso definido por XP también es iterativo e incremental, lo que sugiere
que en cada ciclo, principalmente, en los ciclos de entregas, iteración y desarrollo, se realizan
actividades de gestión, como se muestra en la siguiente figura [Contreras et al., 2011].

2
 Figura 2: Proceso de XP [Contreras et al., 2011].

El proceso de XP cuenta, con un conjunto de buenas prácticas que hacen parte de sus
principios metodológicos.

Figura 3: Prácticas de XP [Contreras et al., 2011].

Como se aprecia en la figura anterior, estas buenas prácticas se consideran como un sis-
tema interrelacionado, en el cual cada componente se complementa con otros para garantizar
productos adecuados a los requerimientos de usuario [Contreras et al., 2011].
Si representamos los costes de los cambios a lo largo del calendario de un proyecto para
las tradicionales vs ágiles se tendrı́a algo parecido a lo dibujado en la figura 5.2. En las fases
iniciales del proyecto hay un coste mayor en las ágiles porque se están haciendo periódicamente
pequeños incrementos de software funcional mientras que las tradicionales están todavı́a en las
fases de toma de requisitos y diseño que apenas generan costes al hacer cambios. Sin embargo, se
observa que el coste en las tradicionales se empieza a disparar en la mitad del proyecto porque ya
hay mucho código realizado y cuanto más se acerque el final, el coste generado por los cambios
será mayor. Sin embargo, el coste en las ágiles tiene una curva con una pendiente mucho más
suave y, si fuera un proyecto realizado idealmente, serı́a casi una constante [Garcı́a Rodrı́guez,
2015].

3
 Figura 4: Costes de los cambios según las metodologı́as Tradicionales VS Ágiles
[Garcı́a Rodrı́guez, 2015]

1.1. Herramientas De La Metodologı́a XP

1.1.1. Historias de Usuario
Las Historias de Usuario representan una breve descripción del comportamiento del sistema,
se realizan por cada caracterı́stica principal del sistema y son utilizadas para cumplir estimacio-
nes de tiempo y el plan de lanzamientos, ası́ mismo reemplazan un gran documento de requisitos
y presiden la creación de las pruebas de aceptación. Cada historia de usuario debe ser lo sufi-
cientemente comprensible y delimitada para que los programadores puedan implementarlas en
unas semanas. La Plantilla a utilizarse para la elaboración de las historias de usuario se muestra
en la sigguiente figura y cada uno de sus componentes se explica a continuación.[Letelier and
Penadés, 2006].

Figura 5: Plantilla para historias de usuario [Meléndez Valladarez et al., 2016]

1.1.2. Tareas de Ingenierı́as (Task Card)

Una Historia de Usuario se descompone en varias tareas de ingenierı́a, las cuales describen
las actividades que se realizarán en cada historia de usuario, ası́ mismo las tareas de ingenierı́a se

4
vinculan más al desarrollador, ya que permite tener un acercamiento con el código[Ferreira Es-
cutia, 2013].
La Plantilla a utilizarse para la elaboración de las tareas de ingenierı́a se muestra en la
figura 6 y cada uno de sus componentes.

Figura 6: Plantilla para tareas de ingenierı́a [Meléndez Valladarez et al., 2016]

1.1.3. Pruebas de Aceptación

Segun [Chiluisa Pallo and Loarte Cajamarca, 2014], las Pruebas de Aceptación son de vital
importancia para el éxito de una iteración y el comienzo de la siguiente, con lo cual el cliente
puede conocer el avance en el desarrollo del sistema y a los programadores lo que les resta por
hacer, además permite una retroalimentación para el desarrollo de las próximas historias de
usuarios a ser entregadas. Estas son comúnmente llamadas Pruebas del Cliente, por lo que son
realizadas por el encargado de verificar si las historias de usuarios de cada iteración cumplen
con la funcionalidad esperada. La Plantilla a utilizarse para la elaboración de las pruebas de
aceptación se muestra en la Figura 7 y a continuación se definen cada uno de los componentes

Figura 7: Plantilla para pruebas de aceptación [Meléndez Valladarez et al., 2016]

1.1.4. Tarjetas CRC (Clase-Responsabilidades-Colaboradores)

Las Tarjetas CRC (Clase-Responsabilidades-Colaboradores), permiten conocer que clases
componen el sistema y cuales interactúan entre sı́. Se dividen en tres secciones: Nombre de la
Clase, Responsabilidades y Colaboradores[Chiluisa Pallo and Loarte Cajamarca, 2014].

5
 Figura 8: Plantilla para las tarjetas CRC [Meléndez Valladarez et al., 2016]

1.1.5. Roles de la metodologı́a XP

1.1.5.1 Programador
Es el Responsable de implementar las historias de usuario por el cliente. Además, estima el
tiempo de desarrollo de cada historia de usuario para que el cliente pueda asignarle prioridad
dentro de la iteración. Cada iteración incorpora nueva funcionalidad de acuerdo a las prioridades
establecidas por el cliente. El Programador también es responsable de diseñar y ejecutar los
test de unidad del código que ha implementado o modificado[Meléndez Valladarez et al., 2016].

1.1.5.2 Cliente
Determina la funcionalidad que se pretende en cada iteración y define las prioridades de
implementación según el valor de negocio que aporta cada historia. El Cliente también es
responsable de diseñar y ejecutar los test de aceptación[Meléndez Valladarez et al., 2016].

1.1.5.3 Encargado de seguimiento (Tracker)

Una de las tareas más importante del tracker, consiste en seguir la evolución de las estima-
ciones realizadas por los programadores y compararlas con el tiempo real de desarrollo. De esta
forma, puede brindar información estadı́stica en lo que refiere a la calidad de las estimaciones
para que puedan ser mejoradas[Meléndez Valladarez et al., 2016].

1.1.5.4 Encargado de pruebas (Tester)

Es el Encargado de ejecutar las pruebas regularmente, difunde los resultados dentro del
equipo y es también el responsable de las herramientas de soporte para pruebas[Meléndez Va-
lladarez et al., 2016].

1.1.5.5 Entrenador (Coach)

Es Responsable del proceso en general. Se encarga de iniciar y de guiar a las personas del
equipo en poner en marcha cada una de las prácticas de la metodologı́a XP[Meléndez Valladarez
et al., 2016].

1.1.5.6 Consultor
Es un Miembro externo del equipo con un conocimiento especı́fico en algún tema necesario
para el proyecto. Guı́a al equipo para resolver un problema especı́fico[Meléndez Valladarez et al.,

6
2016].

1.1.5.7 Gestor (Big Boss)

Es el vı́nculo entre el cliente y programadores. Experto en tecnologı́a y labores de gestión.
Construye el plantel del equipo, obtiene los recursos necesarios y maneja los problemas que se
generan. Administra a su vez las reuniones (planes de iteración, agenda de compromisos, etc).
Su labor fundamental es de coordinación[Meléndez Valladarez et al., 2016].

1.1.6. Fases de XP
1.1.6.1 Planeación
En esta fase la metodologı́a XP hace referencia a un dialogo entre las partes involucradas
en el proyecto. El proyecto inicia con la recopilación de historias de los usuarios la cuál serán
evaluadas por los programadores.[Joskowicz, 2008]
Las historias de los usuarios son descripciones cortas realizadas por el cliente y el plan
de entregas establece que las historias descritas deben estar agrupadas para conformar una
entrega y el orden respectivo, también está el plan de iteraciones la cual indica que las historias
escogidas para cada entrega son desarrolladas y probadas en el ciclo de iteración.[Joskowicz,
2008]

1.1.6.2 Diseño
La Metodologı́a XP hace especial énfasis en los diseños simples y claros. Los conceptos más
importantes de diseño en esta metodologı́a según Joskowicz [2008] , son los siguientes:

Simplicidad, Un diseño simple se implementa más rápidamente que uno complejo. Por
ello XP propone implementar el diseño más simple posible que funcione.

Soluciones “Spike”, Cuando aparecen problemas técnicos, o cuando es difı́cil de estimar el

tiempo para implementar una historia de usuario, pueden utilizarse pequeños programas
de prueba (llamados “Spike”), para explorar diferentes soluciones.

Recodificación (“Refactoring”), Consiste en escribir nuevamente parte del código de un

programa, sin cambiar su funcionalidad, a los efectos de crear lo más simple, conciso y
entendible. Las metodologı́as de XP sugieren re codificarcada vez que sea necesario.

Metáforas, XP sugiere utilizar este concepto como una manera sencilla de explicar el
propósito del proyecto, ası́ como guiar la estructura del mismo. Una buena metáfora debe
ser fácil de comprender para el cliente y a su vez debe tener suficiente contenido como
para que sirva de guı́a a la arquitectura del proyecto

1.1.6.3 Codificación
Disponibilidad del Cliente: Uno de los requerimientos de XP es tener al cliente disponible
durante todo el proyecto, no solamente como apoyo a los desarrolladores, sino formando
parte del grupo. Es fundamental que los clientes se involucren para que pueda desarro-
llarse un proyecto con la metodologı́a XP.
Al comienzo del proyecto,este debe proporcionar las historias de usuarios, pero dado que
estas historias son expresamente cortas y de “alto nivel”, no contienen los detalles nece-
sarios para realizar el desarrollo del código. Estos detalles deben ser proporcionados por

7
 el cliente, y discutidos con los desarrolladores, durante la etapa de desarrollo. [Joskowicz,
2008]

Uso de Estándares: XP promueve la programación basada en estándares, de manera que

sea fácilmente entendible por todo el equipo, y que facilite la re-codificación. [Joskowicz,
2008]

Programación Dirigida por las Pruebas (“Test-Driven Programming”): En las metodo-

logı́as tradicionales, la fase de pruebas, incluyendo la definición de los test, es usualmente
realizada sobre el final del proyecto, o el final del desarrollo de cada módulo. La meto-
dologı́a XP propone un modelo inverso, primero se escribe los test que el sistema debe
pasar. Luego, el desarrollo debe ser el mı́nimo necesario para pasar las pruebas previa-
mente definidas. Las pruebas a los que se refiere esta práctica, son las pruebas unitarias,
realizados por los desarrolladores. La definición de estos test al comienzo, condiciona o
“dirige” el desarrollo. [Joskowicz, 2008]

1.1.6.4 Pruebas
Pruebas Unitarias: Todos los módulos deben de pasar las pruebas unitarias antes de ser
liberados o publicados. Por otra parte, como se mencionó anteriormente, las pruebas
deben ser definidas antes de realizar el código (“Test-Driven Programmming”). Que todo
código liberado pase correctamente las pruebas unitarias, es lo que habilita que funcione
la propiedad colectiva del código. [Joskowicz, 2008]

Detección y Corrección de Errores: Cuando se encuentra un error (“Bug”),éste debe ser

corregido inmediatamente, y se deben tener precauciones para que errores similares no
vuelvan a ocurrir. Asimismo, se generan nuevas pruebas para verificar que el error haya
sido resuelto. [Joskowicz, 2008]

Pruebas de Aceptación: Son creadas en base a las historias de usuarios, en cada ciclo
de la iteración del desarrollo. El Cliente debe especificar uno o diversos escenarios para
comprobar que una historia de usuario ha sido correctamente implementada. Asimismo,
en caso de que fallen varias pruebas, deben indicar el orden de prioridad de resolución.
Una historia de usuario no se puede considerar terminada hasta que pase correctamente
todas las pruebas de aceptación. [Joskowicz, 2008]

1.1.7. Prácticas de la metodologı́a XP

En Tobón and Carmona [2007], la Metodologı́a Extreme Programmming o XP, está referida
al desarrollo de software cuando los requerimientos son ambiguos o rápidamente cambiantes
asumiéndolos como algo natural, por lo que los programadores deben responder a estos cambios
cuando el cliente lo solicite.
XP se basa en la comunicación continúa entre todos los participantes, la simplicidad en las
soluciones implementadas y coraje para enfrentar los cambios. Esta Metodologı́a recomienda a
seguir las siguientes prácticas, según Tobón and Carmona [2007]:

Comunicación: Conversación continúa entre el equipo de desarrollo y el cliente, para

implementar cambios lo antes posible.

Entregas pequeñas: Entrega en versiones operativas.

Diseño simple: Diseñar lo más posible, pero con la funcionalidad requerida.

8
 Pruebas: Se realizan pruebas unitarias por parte de los programadores y pruebas de
aceptación por parte del cliente.

Cliente in-situ: El Cliente debe estar presente para el equipo de desarrollo.

Refactorización (Refactoring): Eliminar códigos duplicados para facilitar los posteriores

cambios.

Programación en parejas: Se realiza para contar con menor tasa de errores, mejor diseño
y mayor satisfacción de los programadores.

Integración contı́nua: Cuando un fragmento de código esté listo, puede ser integrado al
sistema.

Estándares de programación: Está dada por normas definidas por los desarrolladores para
tener un código legible.

Juego de planificación: Desde el comienzo del desarrollo se requiere que el grupo y el

cliente tengan una visión general del proyecto. En el transcurso del mismo se realizan
diferentes reuniones, con el fin de organizar las tareas e ideas que surgen tanto por parte
del cliente como del equipo

Propiedad colectiva del código: El Código no es conocido por una sola persona del grupo
del trabajo, esto facilita implementar cambios al programa por parte de otros integrantes
del grupo.

Utilización de metáforas del sitema: Para mejorar el entendimiento de los elementos del
sistema por parte del equipo de desarrollo se acude a la utilización de metáforas, como
una forma de universalizar el lenguaje del sistema.

Test del cliente: El Cliente con la ayuda de los desarrolladores, propone sus propias
pruebas para validar las mini-versiones.

40 horas por semana: Se debe de trabajar un máximo de 40 horas por semana.

2. Adaptabilidad entre metodologı́as

2.1. Roles
Existen diferentes roles en ambas metodologı́as que intervienen en el proyecto a trabajar, el
siguiente cuadro se hace una comparativa entre estos.

Figura 9: Integración de Roles. Elaboración propia.

9
2.2. Metodologı́a
Dentro de las metodologı́as para la dirección de proyectos se encuentra la guı́a del cuerpo
de conocimiento de la gestión de proyectos (PMBOK®), que puede ser aplicada a proyectos
de desarrollo de software [Contreras et al., 2011].
XP ya cuenta con actividades y prácticas de gestión de proyectos, sin embargo estas pueden
ser complementadas o sustituidas por los procesos de la guı́a del PMBOK®. Estas practicas,
también pueden ser clasificadas en prácticas de gestión y practicas de ingenierı́a, como en las
siguientes; el trabajo de máximo 40 horas semanales, el juego de la planificación y la rotación
de personal en la programación por parejas [Contreras et al., 2011].
Dentro de las 14 practicas de XP, se encuentra el Juego de planificación, que como se muestra
en la figura 7, esta actividad se realiza permanentemente en cada uno de los ciclos del proceso.
Esto implica el desarrollo y seguimiento de planes de entregas, de iteraciones, y de pruebas
[Contreras et al., 2011].

Figura 10: El juego de Planificación en XP [Contreras et al., 2011].

2.3. Procesos
Como se sabe en el PMBOK existen diferentes tipos de procesos repartidos en la Áreas
de Conocimiento, que constituyen el flujo de trabajo para llevar a cabo un proyecto en sus
diferentes fases, lo mismo ocurre con XP en el caso de sus fases y actividades necesarias para
la iteración y obtención de valor en sus entregables incrementales y a corto plazo. La siguiente
tabla muestra la integración de las actividades y procesos de ambas metodologı́as.

10
 Figura 11: Integración entre las metodologı́as PMBOK VS XP [Garcı́a Rodrı́guez, 2015].

Los procesos descritos por la guı́a del PMBOK® son genéricos, lo cual implica que en la
adaptación a proyectos de desarrollo de software, solo se utilice un subgrupo de los procesos
primarios de acuerdo a las necesidades y alcance que vaya a suplir el proyecto. Las actividades
de gestión incluyen la planificación del alcance del proyecto de software, dentro de este grupo
de procesos está la construcción de la estructura de desglose del trabajo EDT. La EDT se
constituye en uno de los factores crı́ticos de éxito para la gestión del proyecto de software
debido a que a partir de ella se emprenden gran parte de los procesos de gestión, como es la
estimación de costos, presupuesto de costos, gestión de personal, gestión de riesgos entre otros.
Para la construcción de la EDT se pueden considerar dos enfoques: El primer enfoque basado
en la gestión integral del proyecto de software y el segundo enfoque basado en la gestión del
producto software [Contreras et al., 2011].
La captura de requerimientos iniciales, debe ser desarrollada en paralelo a la planificación de
alcance, la cual contempla asuntos como la decisión del número de iteraciones que se requieren
para construir un producto software, dado que la mayorı́a de metodologı́as de desarrollo de
software son iterativas e incrementales. Solo en el caso de una metodologı́a tipo cascada, los
procesos técnicos se iniciarı́an una vez terminado el total del proceso de planificación [Contreras

11
et al., 2011].
Entonces se puede proponer una estrategia de integración en uno de los factores más crı́ticos
de la gestión de proyectos de software, la EDT. Para un proyecto con XP, se puede utilizar como
plantilla para el EDT, la siguiente estructura.

Figura 12: EDT para un proyecto con XP [Contreras et al., 2011].

El paquete de actividades rotulado como “diseño arquitectónico preliminar”, debe ser eje-
cutado en paralelo o previamente a las actividades de planificación dado que estas actividades
dependen de la planificación de pequeñas entregas y del número de iteraciones por cada en-
trega. Debido a que en XP las entregas deben ser pequeñas y frecuentes, las duraciones de las
iteraciones que conforman la entrega, debe ser de igual manera cortas, por lo que es probable
que en la EDT no sea necesario definir los paquetes de actividades de ultimo nivel, por lo tan-
to la descomposición solo llegarı́a a las iteraciones, sabiendo que en cada iteración se realizan
una o varias actividades relacionadas con modelado, redacción y procesamiento de historias de
usuario, diseño, implementación, pruebas de unidad y pruebas de aceptación [Contreras et al.,
2011].

3. Conclusiones y Recomendaciones
En la Gestión del Alcance se busca determinar, documentar y gestionar las necesidades
y los requisitos de los interesados, para lograr los objetivos del proyecto. Para recopilar
los requisitos del proyecto el PMBOK propone herramientas como entrevistas, grupos
focales, talleres facilitados, técnicas grupales de creatividad, técnicas grupales de toma de
decisiones, etc.
Del análisis de las metodologı́as podemos concluir que estas tienen aplicación y utilidad
por sı́ solas en proyectos relacionados con desarrollo de software, proyectos iterativos,
innovadores o con ciclos repetitivos, por su flexibilidad, su gran predisposición a la acep-
tación de cambios y su énfasis en los rendimientos a lo largo de la vida del proyecto. En
particular XP resulta una metodologı́a claramente enfocada al desarrollo de software y
difı́cilmente aplicable a otros entornos.
Podemos ver que esta metodologı́a tiene ventajas como desventajas, entre las ventajas
tenemos satisfacción del cliente,programación ordenada, pero es muy costosa en algunos

12
casos se recomienda en proyectos solo de corto plazo y otra desventaja es que se requiere
una capacitación a todo el personal que hará el uso de la web al ser un software también
necesitará mantenimiento y monitoreo constante.

En el trabajo propuesto se ofrece una serie de recomendaciones que se pueden utilizar, las
actividades de gestión incluyen la planificación del alcance del proyecto de software, dentro
de este grupo de procesos está la construcción de la estructura de desglose del trabajo
EDT, considerando dos enfoques: El primer enfoque basado en la gestión integral del
proyecto de software y el segundo enfoque basado en la gestión del producto software. Se
propone el diseño de plantillas de EDT teniendo como enfoques la orientación a productos
de acuerdo a cada una de las metodologı́as de desarrollo de software.

13
 BIBLIOGRAFÍA

Adriana Paola Chiluisa Pallo and Byron Gustavo Loarte Cajamarca. Desarrollo e implantación
del sistema de control de inventarios y gestión de laboratorios para la de la facultad de
ciencias. B.S. thesis, Quito: EPN, 2014., 2014.

Mauricio Eduardo Rojas Contreras, Luis Alberto Esteban Villamizar, and Ailin Orjuela Duarte.
Modelo de integración de las actividades de gestión de la guı́a del pmbok, con las actividades
de ingenierı́a, en proyectos de desarrollo de software. Avances en Sistemas e Informática, 8
(2):97–106, 2011.

Rogelio Ferreira Escutia. Xp extreme programming. Avances en Sistemas e Informática, 2013.

Manuel José Garcı́a Rodrı́guez. Estudio comparativo entre las metodologı́as ágiles y las meto-
dologı́as tradicionales para la gestión de proyectos software. 2015.

José Joskowicz. Reglas y prácticas en xtreme programming, 2008.

Patricio Letelier and Mª Carmen Penadés. Métodologı́as ágiles para el desarrollo de software:
extreme programming (xp). 2006.

Sinthya Milena Meléndez Valladarez, Marı́a Elizabeth Gaitán, and Neldin Noel Pérez Reyes.
Sistema WEB de evaluación al desempeño Docente UNAN-Managua, empleando la meto-
dologı́a Agil Programación Extrema, en el II Semestre del 2015. PhD thesis, Universidad
Nacional Autonóma de Nicaragua, Managua, 2016.

Eva Rodrı́guez Vázquez and Emilio Rafael Diaz Varela. Integración de metodologı́as agiles en
la gestión del alcance y otras áreas de conocimiento de la dirección de proyectos. 2018.

Luis Miguel Echeverry Tobón and LE Delgado Carmona. Caso práctico de la metodologı́a ágil
XP al desarrollo de software. PhD thesis, Universidad Tecnológica de Pereira. Facultad de
Ingenierı́as Eléctrica . . . , 2007.

14