INSTITUTO DE EDUCACIÓN SUPERIOR TECNOLÓGICO PÚBLICO
“MANUEL SEOANE CORRALES”
EXTREME PROGRAMING (XP)
Docente: Mercado Prudencio, Gregorio
Integrantes:
• Suyo Navarro, Isabel Rosa
• Chávez Ventura, Hillary Marilyn
• Rico Hinojosa, Nayeli Diana
• Soto Elías, Paulo Cesar
Curso: Metodología de desarrollo de software
Lima - Perú
2021
ii
ÍNDICE
1 INTRODUCCIÓN............................................................................................................... 1
2 CONCEPTOS ...................................................................................................................... 1
2.1 HISTORIA ................................................................................................................... 1
2.2 DEFINICIÓN .............................................................................................................. 2
2.3 VALORES ................................................................................................................... 2
2.4 CARACTERÍSTICAS ................................................................................................ 3
2.5 CICLO DE VIDA ........................................................................................................ 4
2.5.1 ANÁLISIS ............................................................................................................. 4
2.5.2 DISEÑO ................................................................................................................ 5
2.5.3 DESARROLLO .................................................................................................... 5
2.5.4 PRUEBAS ............................................................................................................. 5
2.6 FASES DEL CICLO DE VIDA ................................................................................. 5
2.6.1 FASE DE EXPLORACIÓN.................................................................................. 5
2.6.2 FASE DE PLANIFICACIÓN ............................................................................... 5
2.6.3 FASE DE ITERACIONES .................................................................................... 5
2.6.4 FASE DE PRODUCCIÓN .................................................................................... 5
2.6.5 FASE DE MANTENIMIENTO ............................................................................ 5
2.6.6 FASE DE MUERTE ............................................................................................. 5
2.7 FASES DEL PROCESO DE DESARROLLO ......................................................... 6
2.7.1 PLANEACIÓN ..................................................................................................... 6
2.7.2 DISEÑO ................................................................................................................ 7
2.7.3 CODIFICACIÓN .................................................................................................. 9
2.7.4 PRUEBAS ........................................................................................................... 10
2.8 ROLES ....................................................................................................................... 11
2.9 ACTIVIDADES ......................................................................................................... 11
2.9.1 ESCUCHAR........................................................................................................ 11
2.9.2 CODIFICAR ....................................................................................................... 12
2.9.3 DISEÑAR............................................................................................................ 12
2.9.4 HACER PRUEBAS ............................................................................................ 12
2.10 VENTAJAS Y DESVENTAJAS .............................................................................. 12
2.10.1 VENTAJAS ......................................................................................................... 12
2.10.2 DESVENTAJAS ................................................................................................. 12
3 CONCLUSIÓN: ................................................................................................................ 13
4 BIBLIOGRAFIA ............................................................................................................... 13
iii
************************************************************
DEDICATORIA:
A mi profesor del curso de Metodología de Software,
por motivarnos a seguir creciendo como
profesionales y guiarnos en el desarrollo de este
trabajo.
************************************************************
1
1 INTRODUCCIÓN
Podemos observar que actualmente no se pude concebir un mundo sin las tecnologías de
información y comunicación, ya que estas están presentes en todos los ámbitos, ya sea en
la sociedad, en el trabajo, en el ámbito educativo, entre otros. Es por ello que hoy en día
se opte por brindar una educación de calidad a través de las tecnologías actuales para
obtener mejores resultados a futuro. Además del ámbito educativo, también lo usamos en
nuestro ámbito laboral, que nos permite tener una mayor eficacia.
Para lograr los objetivos planteados no solo se necesitan de las nuevas tecnologías, sino
también de nuevas metodologías, que permita una evaluación constante para obtener
mejoras todo el tiempo.
Entre las metodologías que existen actualmente se encuentran las metodologías
tradicionales, iterativas/evolutivas, las metodologías basadas en tecnologías web y las
metodologías ágiles.
Actualmente al hablar de desarrollo de software, estos se dirigen hacia el uso de
metodologías más flexibles con un enfoque simple, donde el cliente está presente en todo
el proceso de avance, estas son las metodologías ágiles, ya mencionadas anteriormente.
Una de las principales metodologías ágiles es la metodología de Programación Extrema
XP, esta garantiza al usuario herramientas más accesibles, sencillas y a la misma vez
dinámica. XP constituye un modelo de trabajo relacional, donde existe la conexión entre
el cliente y el desarrollador, lo que permite la construcción de un sistema de acuerdo a los
requerimientos establecidos por el cliente al comenzar el proyecto.
2 CONCEPTOS
EXTREME PROGRAMING (XP)
2.1 HISTORIA
Extreme Programing nace gracias a Kent Beck
aproximadamente en el año 1996, cuando
laboraba en Chrysler Corporation.
Kent tenía varias ideas de metodologías para la
realización de programas que eran cruciales para
el buen desarrollo de cualquier sistema, para ello
tomó de guía a las mejores prácticas que habían
sido utilizadas históricamente en la industria del
desarrollo de software,
2
Las ideas primordiales de sus sistemas las comunico en las revistas C++ Magazine
en una entrevista que esta le hizo el año 1999.
2.2 DEFINICIÓN
Es un enfoque de la ingeniería de software formulado por Kent Beck, además es
una metodología ágil usada para el desarrollo de un proyecto mediante la
elaboración de un software, el cual se desarrolla a través de un proceso iterativo,
permitiendo potenciar las relaciones interpersonales a través del trabajo en equipo
propiciando un buen clima de trabajo, esta metodología es idónea para proyectos
que están en constantes cambios.
Su objetivo principal es el desarrollo y gestión de proyectos con eficacia,
flexibilidad y control.
La XP se diferencia de las metodologías tradicionales principalmente en que pone
más énfasis en la adaptabilidad que en la previsibilidad.
2.3 VALORES
El XP incorpora cinco valores que son fundamentales para afrontar este tipo de
metodología:
1. COMUNICACIÓN
La comunicación es uno de los pilares principales para cualquier proyecto,
por lo que dentro de XP no hay falta de información entre el equipo, como
resultado, los procesos se vuelven más eficientes.
2. SIMPLICIDAD
Empezar con la solución más simple es clave en la programación XP. Esta
metodología pone el foco en codificar las necesidades de hoy, no las de un
futuro. Además, también se simplifica el diseño para agilizar el desarrollo
y facilitar el mantenimiento. Para conservar la simplicidad hay que
mantener la refactorización del código, así podremos preservar el código
simple a medida que va creciendo.
3. RETROALIMENTACIÓN
Las pruebas que se le realizan al software nos mantienen informados del
grado de fiabilidad del sistema.
3
4. CORAJE O VALENTIA
El coraje es la fuerza de voluntad que puede desarrollar una persona, sin
miedo al fracaso, para superar ciertos impedimentos y que a veces se
manifiesta como la tendencia a la acción. El coraje como valor sólo es
peligroso, pero junto con otros se hace poderoso. En XP se emplea para
decir la verdad sobre el progreso y las estimaciones. No se teme a nada
porque nunca se trabaja solo.
5. RESPETO
El respeto mutuo es fundamental para que un equipo pueda trabajar de
forma eficiente y ofrecer un buen rendimiento. Implica desde que un
desarrollador no realice modificaciones que puedan tener un impacto
negativo en el trabajo de un compañero hasta la forma de llegar al cliente.
El respeto se manifiesta de varias formas y todas son cruciales para una
mejor autoestima en el equipo, que lleva consigo un mayor ritmo de
producción.
2.4 CARACTERÍSTICAS
o METODOLOGÍA BASADA EN PRUEBA Y ERROR:
Elaboración de pruebas constantes, para luego pasar a la verificación de
los errores.
o DESARROLLO ITERATIVO E INCREMENTAL:
Las mejoras se van dando sucesivamente.
o PROGRAMACIÓN EN PAREJAS:
Lo más recomendable es que dos personas realicen las mismas tareas
ocupando el mismo puesto.
o FRECUENTE INTEGRACIÓN DEL EQUIPO DE
PROGRAMACIÓN CON EL CLIENTE O USUARIO
4
Se recomienda que el cliente o su representante trabaje junto con el equipo
de desarrollo.
o REFACTORIZACIÓN DEL CÓDIGO:
Reescribir ciertas partes del código para aumentar su legitimidad y
mantenibilidad.
o PROPIEDAD DEL CÓDIGO COMPARTIDO;
Se promueve la participación de todo el personal, para que puedan
modificar o extender cualquier parte del proyecto.
o SIMPLICIDAD EN EL CÓDIGO:
Es la mejor manera de que las cosas funcionen. Cuando todo funcione se
podrá añadir funcionalidad si es necesario.
o GRUPO PEQUEÑO Y MUY INTEGRADO DE 2 A 12 PERSONAS:
Caracterizados por su formación elevada y por su amplia capacidad de
aprender.
o RÁPIDA RESPUESTA A CAMBIOS
2.5 CICLO DE VIDA
Los ciclos de vida son relativamente cortos. Existe una fase de análisis inicial
orientada a programar las iteraciones de desarrollo y cada iteración incluye diseño,
codificación y pruebas, fases superpuestas de tal manera que no se separen en el
tiempo.
Dentro del ciclo de vida encontramos a:
2.5.1 ANÁLISIS
La etapa de análisis en el ciclo de vida del software corresponde al proceso a través
del cual se intenta descubrir qué es lo que realmente se necesita y se llega a una
comprensión adecuada de los requerimientos del sistema (las características que el
sistema debe poseer).
5
2.5.2 DISEÑO
Se estudian posibles opciones de implementación para el
software que hay que construir, así como decidir la
estructura general del mismo. El diseño es una etapa
compleja y su proceso debe realizarse de manera
iterativa.
2.5.3 DESARROLLO
En este ciclo se lleva a cabo la solución planteada.
2.5.4 PRUEBAS
Comprobar que el resultado obtenido sea el correcto.
2.6 FASES DEL CICLO DE VIDA
El ciclo de vida está conformado con una serie de fases:
2.6.1 FASE DE EXPLORACIÓN
Entender el requerimiento del cliente
2.6.2 FASE DE PLANIFICACIÓN
Realizar una estimación de costos, planificar la entrega del proyecto.
2.6.3 FASE DE ITERACIONES
Utilizadas para medir el progreso del proyecto. Una iteración terminada sin errores es
una medida clara de avance
2.6.4 FASE DE PRODUCCIÓN
La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes
de que el sistema sea trasladado al entorno del cliente.
2.6.5 FASE DE MANTENIMIENTO
La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios
en su estructura.
2.6.6 FASE DE MUERTE
Cuando el cliente no tiene más requerimientos por incluir dentro del sistema.
6
2.7 FASES DEL PROCESO DE DESARROLLO
2.7.1 PLANEACIÓN
- También llamada juego de planeación, este tipo de metodologías trata de
que el trabajo sea un poco más ameno y menos tedioso. Podemos decir que está
basado en juegos y hay diferentes estrategias por ejemplo hay una que se llama
pocker donde a través de unas cartas uno puede determinar qué tan complejo es la
parte de la funcionalidad que se está trabajando, si es una funcionalidad que
requiere mayor o menor tiempo, todo eso se hace también a través de juegos. Es
por ello que en metodología ágil se conoce mucho a la planeación como el juego
de la planeación y uno de sus pilares fundamentales es el escuchar, hay que saber
escuchar para poder desarrollar este tipo de juegos para hacer la planeación; así
como también el respeto, que es el otro valor que se maneja mucho en esta parte.
- La Creación de Historias de usuario, las cuales tienen unas características
que tienen que cumplir una estructura entonces siempre empiezan por yo y
entonces va el nombre del actor, la persona, entonces la función por ejemplo yo
como facturador o yo como cliente o yo como administrador entonces así es como
se va creando las historias de usuario.
Existen también la historia escrita por el cliente, la cual se ubica en una tarjeta
indexada con un cierto valor, hay otras historias que las escriben dos miembros
del equipo de trabajo porque ya son cosas como funcionalidades internas del
software que el cliente no tiene por qué conocer las entonces hay unas historias
que las construye el cliente y otras que las construye el equipo de trabajo y
entonces las que están escritas por el cliente, como son la persona a la cual estamos
tratando de resolver ese problema, de esas tienen un valor tienen una prioridad y
están indexadas con cierto valor.
- El equipo evalúa las historias y le asigna un costo (un tiempo), cada una
de esas funcionalidades tiene una complejidad única y tiene un costo en tiempo.
Por ende, se analiza y se entiende partiendo de esa experiencia que ya se tiene de
otros trabajos que ha desarrollado o en lo que se ha practicado en los diferentes
lenguajes.
7
Es así como se va asignando un tiempo y de acuerdo con el consenso se les
determina una prioridad en tiempo y también una prioridad en función general de
integración en todo el software. Cada funcionalidad es vital o es una funcionalidad
que es urgente o es una funcionalidad que tiene una prioridad normal o tiene una
prioridad baja; así mismo, no olvidar que para ellos el costo no es dinero sino
tiempo cuando una historia es muy costosa debe ser descompuesto se debe tratar
de dividirse en funcionalidades más pequeñas.
Entre los usuarios y el equipo se agrupa las historias en la siguiente entrega como
un compromiso, en la primera planeación se proyecta a afrontar una interacción y
en esa interacción se va a construir algunas funcionalidades. Todo esto, se hace
en consenso y es un compromiso que adquiere el grupo de trabajo con el cliente,
esa es la parte que se habla de la responsabilidad que tiene mucha fuerza en las
metodologías ágiles, que el equipo de trabajo se comprometa, que sienta esa
responsabilidad de cumplir al cliente.
Al terminar el primer ciclo, se vuelve a calcular la velocidad del proyecto, calcular
cuánto probablemente demore las otras funcionalidades que se va a afrontar en la
siguiente interacción, si se tiene que recalcular todo el cronograma del proyecto o
si se puede seguir manejando
Por todo lo anterior mencionado, las metodologías ágiles siempre son muy
flexibles en eso cada vez que se termine una fase, se debe realizar una revisión y
una retroalimentación y así poder replantear tiempo y funcionalidades y
modificar.
2.7.2 DISEÑO
Sigue rigurosamente el principio MS mantenerlo sencillo, se trata de no gastar
mucho tiempo porque el diseño no es algo con lo que el cliente pueda tener valor,
algo con lo que el cliente se pueda llevar, el diseño es algo que solamente le sirve
al equipo de desarrollo para afrontar la siguiente fase que es codificación, pero
8
eso no le da valor al cliente, entonces hay que tratar
de afrontarlo con la mayor rapidez, es algo de
equilibrio entre no pasarnos demasiado y dedicarle
solo lo justo al diseño, mantenerlo lo más sencillo
posible o sea que ese diseño no sea una
representación muy compleja que nos tome mucho
tiempo y que al cliente tenga que costarle una
capacitación para que el cliente la entienda. Por eso
debe ser simple por todos los lados, donde se vea y
tomarlo como una guía y no como una caja estricta
por donde tiene que construirse el diseño.
- Las tarjetas CRC: (Clase, responsabilidad, colaborador) es donde se determina
qué clases van a involucrarse dentro de esa funcionalidad, y por lo general se
utiliza un UML ( un diseño universal ), entonces se hace un diagrama de clases
de la funcionalidad, se determina responsabilidades tanto dentro del software
como también de quienes van a construir esa funcionalidad y también la parte
del colaborador entonces quiénes son las personas que están montados dentro
de esa funcionalidad que se va a construir. Por lo que, es aquí donde se ve muy
fuerte la parte de que es un paradigma orientado a objetos en clase,
responsabilidad y colaborar.
- La historia de usuario con diseños difíciles, se crea un prototipo funcional, aquel que
más funciona es el que crea la interfaz de usuario, donde se pueda crear de manera
muy rápida, colocando o cambiando colores para que el cliente se Imagine una pintura
de q va a quedar ese software, puede que cuando le des clic en el botón no haga nada
pero ya el cliente ve como queda y entonces así se puede obtener una
retroalimentación muy rápida de que sí que no que le cambia, que le falta, que le
sobra.
9
- El rediseño, no es una actividad que está dentro de la parte de codificación ya que si
se detecta algo que debe cambiarse se cambia y entre más rápido mejor. Por lo tanto,
es el proceso donde se cambia de tal forma que no altera el comportamiento del código
de forma externa, pero al mejorar esa estructura y la forma en la que se construye esto
agilice los procesos de construcción o que agilice el proceso para el cliente, buscando
de esta manera tener lo mejor tanto para el equipo de desarrollo como para el cliente
2.7.3 CODIFICACIÓN
No se inicia directo con la codificación sino a pruebas unitarias, es decir que hay dos fases
anteriores que es la planificación y el diseño, y antes de sentarse a codificar se piensa en
cómo se va a probar ese código que se va a crear. Es por ello que, en esta fase, se le ha
asignado a una pareja, esa funcionalidad no se sienta codificarla, sino que se sienta crear
las pruebas unitarias. Para lo cual, se usa muchas veces de ayuda al eclipse, que por lo
general lo genera de forma automática, o también existe otras herramientas como por
ejemplo el Enterprise architec para la parte del diseño de clases en Java y si se la lleva
por ejemplo a eclipse O A NetBeans, les ayudaba a crear todas las clases con el
constructor con el destructor, basándose en lo descrito en el diagrama de clases y ya las
generaba automáticamente entonces partiendo de esa estructura general. Con todo esto,
se puede ver todo lo que se puede hacer de forma automática a través de las herramientas
que existen, si bien es cierto, es más bonito si nosotros hacemos desde cero todo, pero eso
nos toma más tiempo y como las cosas son muy ágiles pues hay que utilizar todas las
herramientas que disponemos.
Una recomendación es usar todas las herramientas que le permiten hacer
automáticamente o en su defecto, construir primero la prueba antes de sentarse a colocar
la primera línea de código de esa expansión en proceso.
En conclusión, la codificación aquí en XP se orienta pruebas, primero se construye la
prueba y después se construye la funcionalidad, cabe señalar que la prueba garantiza
retroalimentación inmediata, por supuesto entre más rápido se detecte un error que existe
más barato será en tiempo y en dinero corregir. Dejar que un error pase hasta el cliente te
va a costar mucho en tiempo y en dinero.
La programación en parejas, dos personas que
trabajan juntas en una estación de trabajo con el
objeto de crear un código para una historia, se
dice que el hecho de que las personas trabajen
juntas en un mismo lugar hace que las cosas
fluyan mucho más fácil, con bastante
interacción y que estén hablando
constantemente. A medida que ellos vayan
terminando su trabajo, tiene que integrarse con
10
el trabajo de las otras personas, de las otras parejas, que están trabajando en otras
funcionalidades y eso se conoce como integración continua, y se prueba todo el sistema
en un conjunto.
2.7.4 PRUEBAS
- Creación de pruebas unitarias antes de que comience la codificación, hay que probar
con cierta estructura entonces se recomienda no hacer pruebas manuales y utilizar
pruebas automatizadas, de modo que se pueda ejecutar rápidamente y se pueda repetir
varias veces, que sea algo fácil, algo sencillo. También tiene que haber una estrategia
de pruebas de regresión, qué significa eso cada vez que se haga un incremento, se
tiene que probar todo el sistema hacia atrás. Si se hizo 3 incrementos antes del que
está haciendo ahorita, antes de entregar los que tienen que probar como ese
incremento se adapta con los anteriores, eso se llama una estrategia de pruebas de
regresión. De esta manera, se sigue probando todo otra vez, cada vez que se agregue
algo nuevo, es esta razón, por la cual se recomienda el uso de las pruebas
automatizadas, porque estás ejecutando muchas veces y por mucho tiempo, hasta que
por fin se entregue el software a cliente.
- A medida que se organiza en las pruebas individuales unitarias para cada
funcionalidad debe también hacerse un grupo de pruebas universal, lo que es probar
todo, que esta funcionalidad se adapte y encaje en las demás, porque todo sistema es
un grupo de elementos que funcionan coordinadamente para lograr un objetivo y eso
se hace a través del grupo de pruebas universales y los las pruebas de regresión y las
pruebas de integración, todo eso se trata es de garantizar de que todo conjunto está
funcionando en una forma bien estructurada y todo encaje con los demás.
- Las pruebas de aceptación XP, que también se llaman pruebas de cliente, son esas
pruebas, donde el cliente no tiene por qué saber cómo funciona por debajo del sistema,
pero necesita probar que las cosas que
necesite el sistema se las haga, por ejemplo, si
necesita un reporte, el sistema selo genere y se
ejecute. Aquí, el cliente prueba que en verdad
cumpla con eso que necesito, solo él puede
decir que un incremento se acepta y solo él
puede decir que si ya le sirve para irse al
trabajo. Se centra sobre todo en características
y en funcionalidades, lo que es visible, no lo
que es por debajo del tiempo esas son pruebas
unitarias que se hacen al interior del grupo de
desarrollo y no con el cliente.
11
2.8 ROLES
o PROGRAMADOR(PROGAMMER)
Produce el código del sistema. Es la esencia del equipo.
o CLIENTE(CUSTOMER)
Escribe las historias de usuario y las pruebas funcionales para validar su
implementación. Asigna la prioridad a las historias de usuario y decide
cuáles se implementan en cada iteración centrándose en aportar el mayor
valor de negocio.
o PROVADOR(TESTER)
Interpreta el pedido del cliente y ayuda al equipo de desarrollo a escribir
las pruebas funcionales. Ejecuta pruebas regularmente, difunde los
resultados en el equipo y es responsable de las herramientas de soporte
para pruebas.
o RASTREADOR (TRACKER)
Es el encargado de seguimiento. Proporciona realimentación al equipo.
Debe verificar el grado de acierto entre las estimaciones realizadas y el
tiempo real dedicado, comunicando los resultados para mejorar futuras
estimaciones.
o ENTRENADOR(COACH)
Responsable del proceso global. Guía a los miembros del equipo para
seguir el proceso correctamente.
o GESTOR (BIG BOSS)
Es el dueño de la tienda y el vínculo entre clientes y programadores. Su
labor esencial es la coordinación.
2.9 ACTIVIDADES
2.9.1 ESCUCHAR
Tenemos que escuchar a nuestros clientes, sus ideas, dudas y acoplar las
acotaciones del cliente hacia el proyecto a elaborar.
12
2.9.2 CODIFICAR
Plasmar nuestras ideas a través del código.
2.9.3 DISEÑAR
Los diseños deben de ser sencillos.
2.9.4 HACER PRUEBAS
Las pruebas nos indican si nuestro trabajo funciona correctamente.
2.10 VENTAJAS Y DESVENTAJAS
2.10.1 VENTAJAS
Buena relación con el cliente
Ausencia de trabajos de programación innecesarios
Software estable
Disminución a la tendencia de errores
Autogestión del tiempo
Adaptación rápida y eficiente a cambios
Código de comprensión sencilla
2.10.2 DESVENTAJAS
Mayor esfuerzo de trabajo
Implicación del cliente en el proceso
Requiere de mayor tiempo
Mayor precio
Requiere control de versiones
Autodisciplina en la aplicación
13
3 CONCLUSIÓN:
Después de haber analizado el tema, llegamos a la conclusión que:
• Esta metodología es muy útil y práctica ya que se adapta a diversas situaciones
de una manera rápida.
• Interacción constante con el cliente.
4 BIBLIOGRAFIA
[Link]
[Link]
[Link]
