UNIVERSIDAD PRIVADA CIENCIAS ADMINISTRATIVAS Y TECNOLOGICAS

UCATEC

METODOLOGIA XP O PROGRAMACION EXTREMA

Integrantes: Alcira Luque Monje

Deimar Alex Ramirez Vargas
Américo Lovera Garcia
Juan Daniel Paco Vasques
Osmar Quintero Peredo

Docente: Jancarla Vargas Flores

COCHABAMBA-BOLIVIA
Contenido
1. ¿Qué es la metodología XP?.................................................................................................3
3. Características de la metodología XP...................................................................................3
4. Diferencias entre la metodología XP y otras........................................................................3
4.1. Diferencias entre la metodología XP y ágil.......................................................................3
4.2. Diferencias entre la metodología XP y Scrum...................................................................4
5. ¿Cuándo deberías implementar la programación extrema?................................................4
8. Metodología de programación extrema XP..........................................................................6
8.1. Equipo..............................................................................................................................6
8.1.1. El cliente ejerce así su responsabilidad........................................................................6
8.1.2. Los programadores y su marco de acción.....................................................................6
8.1.3. Los testers amplían su rol en la xp................................................................................6
8.1.4. El tracker o encargado de seguimiento........................................................................6
8.1.5. El coach y su labor clave...............................................................................................6
8.1.6. El manager XP responde así a este método..................................................................6
8.2. Fases.................................................................................................................................7
8.2.1. Planificación.................................................................................................................7
8.2.2. Diseño...........................................................................................................................7
8.2.3. Codificación..................................................................................................................8
8.2.4. Pruebas.........................................................................................................................8
8.2.5. Lanzamiento.................................................................................................................8
8.3. Documentación................................................................................................................8
8.4. Ciclo de vida.....................................................................................................................9
8.5. ¿Cuáles son las 12 prácticas de la programación extrema?............................................10
8.6. Aplicación de la metodología XP....................................................................................11
9. Conclusión..........................................................................................................................11
1. ¿Qué es la metodología XP?
Es un conjunto de técnicas que dan agilidad y flexibilidad en la gestión de proyectos.
También es conocida como Programación Extrema (Extreme Programming) y se centra
crear un producto según los requisitos exactos del cliente. De ahí, que le involucre al
máximo durante el método de gestión del desarrollo del producto.
El uso de esta metodología supone, para muchos teóricos, una aproximación a la calidad
óptima del producto. Pues durante el ciclo de vida del software, ocurren cambios
naturales. Es más, cuantos más cambios, puede que más cerca estemos del mejor
resultado que espera nuestro cliente. Por eso, este cambio constante en el proyecto se
llega a considerar como favorable. Y si podemos aplicar una manera dinámica de
gestionarlos, mejor. Esta forma es conocida como metodología XP.
2. ¿Quién desarrolló la programación extrema?
Los orígenes de XP se remontan a fines de la década de 1990, cuando Kent Beck la creó
para gestionar el desarrollo de un sistema de software de nómina para Chrysler llamado
Proyecto C3. El objetivo al implementar la programación extrema era (y sigue siendo)
eliminar la resistencia a cambiar el código en un proyecto de desarrollo. En los métodos
de desarrollo de software más tradicionales, es muy común que el código no se cambie
una vez que está escrito (excepto para la depuración). Con la programación extrema, en
cambio, el código se examina con tanto detalle que los desarrolladores pueden decidir
modificarlo por completo luego de una sola iteración.

3. Características de la metodología XP
 Comunicación constante entre el cliente y el equipo de desarrollo.
 Respuesta rápida a los cambios constantes.
 La planificación es abierta con un cronograma de actividades flexible.
 El software que funciona está por encima de cualquier otra documentación.
 Los requisitos del cliente y el trabajo del equipo del proyecto son los principales
factores de éxito del mismo.

4. Diferencias entre la metodología XP y otras

4.1. Diferencias entre la metodología XP y ágil

Esta metodología XP está dentro de las denominadas metodologías ágiles. Sin embargo,
tiene sus peculiaridades.
Pues al mismo tiempo que la metodología Agile recoge las buenas prácticas de un
marco de trabajo específico. En ella, hay unos roles de equipo definidos y unas
iteraciones que se van repitiendo cada semana o 3-5 semanas.
La metodología XP se centra en la comunicación con todos los involucrados en el
proyecto, así como la reutilización del código ya desarrollado y la realimentación.
 4.2. Diferencias entre la metodología XP y Scrum
Scrum es otro tipo común de metodología ágil gestionada por un Scrum master. Al igual
que la programación extrema, organiza sprints basados en historias de usuarios para
desarrollar funciones nuevas de productos o de software. Sin embargo, el método XP es
mucho más rígido que el método Scrum, ya que tiene reglas y pautas estrictas que
promueven intercambios constantes entre desarrolladores y clientes. Además, puedes
aplicar Scrum para cualquier proceso que requiera iteración y aportes del cliente,
mientras que solo usarías la programación extrema para la programación.

5. ¿Cuándo deberías implementar la programación extrema?

Como la programación extrema se centra en el desarrollo de software, suele ser

implementada solamente por los equipos de ingeniería. Incluso los equipos de software,
suelen usarla únicamente para determinadas configuraciones. Para obtener el máximo
beneficio de la programación extrema, recomendamos usarla en los siguientes casos:
Para gestionar un equipo más pequeño. Debido a su naturaleza altamente colaborativa,
la programación extrema funciona mejor en equipos pequeños de menos de diez
personas.
Si estás constantemente en contacto con tus clientes. La programación extrema
incorpora los requisitos de los clientes a lo largo del proceso de desarrollo y también se
basa en ellos para las pruebas y aprobaciones.
Si trabajas con un equipo flexible que pueda aceptar el cambio (sin resentimientos).
Dada su propia naturaleza, la programación extrema a menudo requerirá que todo el
equipo deseche todo su arduo trabajo. Algunas reglas también permiten que algunos
miembros del equipo realicen cambios en cualquier momento, lo que supondría un
problema si los demás compañeros del equipo se lo toman como algo personal.
Si dominas los aspectos técnicos de la codificación. La programación extrema no es
para principiantes ya que necesitas poder trabajar e implementar cambios rápidamente.
6. Variables de XP
XP define cuatro variables para proyectos de software y son:
6.1. Coste
XP nos propone que juguemos todas las partes implicadas en el proyecto hasta que el
valor que alcancen las cuatro variables sea el correcto para todas las partes: “Si quieres
más calidad en menos tiempo tendrás que aumentar el equipo e incrementar el coste”.
6.2. Tiempo
Siempre se quiere entregar el trabajo más rápido, por tanto probar menos, codificar más
rápido y peor, sin hacer planteamientos maduros, esto repercutiría en la confianza de los
clientes, al entregarle trabajos con fallos.
 6.3. Calidad
Con la calidad suele suceder un fenómeno extraño: frecuentemente un proyecto que
tratemos de aumentar la calidad conduce a que el proyecto pueda realizarse en menos
tiempo, siempre con unos márgenes obviamente. Cuando un equipo de desarrollo se
acostumbra a realizar pruebas intensivas, se siguen estándares de codificación, poco a
poco se comenzara a andar más rápido y más seguro, por tanto más preparados para
futuros cambios, sin estrés y así sucesivamente.
6.4. Ámbito
El ámbito del proyecto, suele ser conveniente que sea establecida por el equipo de
desarrollo. Es una variable muy importante que nos va a decir dónde vamos a llegar con
nuestro software, que problemas vamos a resolver y cuales vamos a dejar para
siguientes versiones.
Y es que los requisitos nunca son claros al principio y el mismo desarrollo del software
hace cambiar los requisitos. Por tanto, el ámbito debe de ser dúctil, podremos jugar con
él, si el tiempo para el lanzamiento es limitado, siempre habrá cosas que pudramos
diferir para siguientes versiones.
Además, con el agravante de que estas cuatro variables no guardan una relación tan
directa como en principio pueda parecer. El incremento del número de programadores
no repercutirá de manera lineal en el tiempo de desarrollo del proyecto.
7. Valores de la metodología XP
La metodología XP es desarrollada en base a cinco valores fundamentales, cuyo
objetivo fundamental es que el equipo de desarrolladores trabaje con la mentalidad
conjunta para colaborar y crear un producto de alta calidad, dichos valores son:
7.1. Simplicidad
La clave de la programación XP siempre será comenzar por la solución más simple,
codificar las necesidades de hoy, no las futuras. Se simplifica el diseño para agilizar el
desarrollo y que sea sencillo el mantenimiento. Para que se conserve la simplicidad se
debe mantener la refactorización del código, para así preservar el código simple a
medida que crezca.
7.2. Comunicación
Se refiere a la buena interacción interna entre los miembros del equipo de
desarrolladores y con los clientes. Su objetivo es romper las barreras entre negocio y
desarrollo, para ello promueve que todos los requisitos sean comunicados y trabajados
en equipo y no a través de documentación.
7.3. Feedback
Al integrar al cliente en el proyecto se puede tener su opinión sobre el estado de este en
tiempo real. Los ciclos cortos de presentación de resultados permiten minimizar el
riesgo de tener que hacer nuevamente partes que no cumplen con las expectativas del
cliente y ayuda a los programadores a centrarse en las tareas importantes.
7.4. Respeto
Importante para que el equipo trabaje eficientemente y de buen rendimiento, va desde
que un desarrollador no haga cambios que afecten negativamente el trabajo de un
compañero hasta la forma en que se llega al cliente. Se manifiesta el respecto en varias
formas, todas importantes para mejor autoestima del equipo que lleva el mayor ritmo de
trabajo.
7.5. Valentía
Se tiene cuando se diseña un programa para hoy y no se deja para mañana, al igual que
reconocer los errores a penas se detectan. Nadie en el equipo puede intentar minimizar
su responsabilidad en un error cometido, pues esto implica que se deja de centrar en
otras cosas e impide que avance el resto, bajando la productividad.

8. Metodología de programación extrema XP

8.1. Equipo

8.1.1. El cliente ejerce así su responsabilidad

Los clientes son los responsables de definir los objetivos del proyecto, así como de
conducir su gestión. Marcan las necesidades y las prioridades en el proyecto.

8.1.2. Los programadores y su marco de acción

Como especialistas en las actividades que ayudarán a cumplir los objetivos, los
programadores serán los encargados de delimitar duraciones y estimar tiempos. Por lo
que planificarán el proyecto, con respecto a los requisitos acordados con los clientes.

8.1.3. Los testers amplían su rol en la xp

El Tester o encargado de Pruebas amplía su marco de ejecución, pues su comunicación
con el cliente será vital para alinear resultados con requisitos estimados.

8.1.4. El tracker o encargado de seguimiento

Su objetivo será que en todo momento haya un control y un por qué se realiza cada
cosa. También la comunicación y relación constante con el cliente es clave. Definirá los
hitos o puntos de control en la planificación, en función de los objetivos del cliente y las
estimaciones de tiempos de ejecución de tareas del equipo de programadores.

8.1.5. El coach y su labor clave

Los Coach realizan una tarea fundamental: el asesoramiento y orientación continuo
tanto para el equipo de trabajo como para los clientes. Son la guía del proyecto, para que
todos sepan bien qué, cómo y cuándo hacerlo.
 8.1.6. El manager XP responde así a este método
El responsable de coordinas comunicaciones entre las distintas partes, ofrecer y
gestionar los recursos necesarios. De tener una idea general del funcionamiento del
proyecto y su estado en todo momento.

8.2. Fases

8.2.1. Planificación
Las historias de usuario a menudo se escriben en tarjetas de tipo “post-it” para poder
pegarlas sobre algún tipo de tablero o panel en las paredes. De este modo se facilita el
debate sobre cómo organizarlas y la planificación. Al tratarse de tarjetas de un tamaño
reducido, no se puede escribir mucho, lo que obliga a pensar y resumir muy bien el
objetivo Según la identificación de las historias de usuario, se priorizan y se
descomponen en mini-versiones. La planificación se va a ir revisando. Cada dos
semanas aproximadamente de iteración, se debe obtener un software útil, funcional,
listo para probar y lanzar.

8.2.2. Diseño
En este paso se intentará trabajar con un código sencillo, haciendo lo mínimo
imprescindible para que funcione. Se obtendrá el prototipo. Además, para el diseño del
software orientado a objetos, se crearán tarjetas CRC (Clase-Responsabilidad-
Colaboración).

 Diseños simples: La metodología X.P sugiere que hay que conseguir diseños
simples y sencillos.
 Glosarios de términos: Usar glosarios de términos y una correcta especificación
de los nombres de métodos y clases ayudará a comprender el diseño y facilitará
sus posteriores ampliaciones y la reutilización del código.
 Riesgos: Si surgen problemas potenciales durante el diseño, X.P sugiere utilizar
una pareja de desarrolladores para que investiguen y reduzcan al máximo el
riesgo que supone ese problema.
 Funcionalidad extra: Nunca se debe añadir funcionalidad extra al programa,
aunque se piense que en un futuro será utilizada
  Refactorizar. Refactorizar es mejorar y modificar la estructura y codificación de
códigos ya creados sin alterar su funcionalidad.
 Tarjetas C.R.C. El uso de las tarjetas C.R.C (Class, Responsabilities and
Collaboration) permiten al programador centrarse y apreciar el desarrollo
orientado a objetos olvidándose de los malos hábitos de la programación
procedural clásica.

8.2.3. Codificación
La codificación debe hacerse ateniendo a estándares de codificación ya creados.
Programar bajo estándares mantiene el código consistente y facilita su comprensión y
escalabilidad. Crear test que prueben el funcionamiento de los distintos códigos
implementados nos ayudará a desarrollar dicho código
A la hora de codificar no seguimos la regla de X.P que aconseja crear test de
funcionamiento con entornos de desarrollo antes de programar. Nuestros test los
obtendremos de la especificación de requisitos ya que en ella se especifican las pruebas
que deben pasar las distintas funcionalidades del programa, procurando codificar
pensando en las pruebas que debe pasar cada funcionalidad.

8.2.4. Pruebas
Se deben realizar pruebas automáticas continuamente. Al tratarse normalmente de
proyectos a corto plazo, este testeo automatizado y constante es clave. Además, el
propio cliente puede hacer pruebas, proponer nuevas pruebas e ir validando las mini-
versiones.
Hay que someter a tests las distintas clases del sistema omitiendo los métodos más
triviales.
Se deben crear los test que pasarán los códigos antes de implementarlos; en el apartado
anterior se explicó la importancia de crear antes los test que el código.
Un punto importante es crear test que no tengan ninguna dependencia del código que en
un futuro evaluará. Hay que crear los test abstrayéndose del futuro código, de esta forma
aseguraremos la independencia del test respecto al código que evalúa.

8.2.5. Lanzamiento
Este punto, significa que hemos probado todas las historias de usuario o mini-versiones
con éxito, ajustándonos a los requerimientos de los clientes. Tenemos un software útil y
podemos incorporarlo en el producto
La fase de Lanzamiento es importante porque es el momento en que el software se pone
en uso real y se expone a los usuarios finales. Durante esta fase, el equipo de desarrollo
debe asegurarse de que el software se ha probado adecuadamente y que se han abordado
todos los errores y problemas conocidos. También es importante que el equipo de
desarrollo esté disponible para solucionar cualquier problema que pueda surgir después
del lanzamiento.
 8.3. Documentación
Dentro de Extreme Programming encontramos dos tipos de planificacion las cuales son
documentadas.

 Planificación de la Entrega

Es una práctica en donde el Cliente presenta las características deseadas a los

programadores, y los programadores estiman la dificultad. Teniendo las estimaciones de
costo, y sabiendo la importancia de las características, el Cliente establece un plan para
el proyecto. Los planes iniciales de entregas son necesariamente imprecisos: ni las
prioridades ni las estimaciones son sólidas, y tampoco sabremos qué tan rápido trabaja
el equipo hasta que empiece a trabajar. Sin embargo, incluso el primer plan de entrega
es lo suficientemente preciso como para tomar decisiones, y el equipo XP revisa de
forma regular el plan.

 Planificación de la Iteración

Es la práctica en donde el equipo establece el rumbo cada un par de semanas. Los

equipos XP construyen software en iteraciones de dos semanas, y entregan software útil
al finalizar cada iteración. Durante la Planificación de la Iteración, el Cliente presenta
las características deseadas para las siguientes dos semanas. Los programadores las
descomponen en tareas, y estiman su costo (a un nivel de detalle más fino que durante la
Planificación de la Entrega). El equipo entonces se compromete a terminar ciertas
características basándose en la cantidad de trabajo que pudieron terminar en la iteración
anterior.

8.4. Ciclo de vida

El ciclo de vida de XP se enfatiza en el carácter iterativo e incremental del desarrollo,

una iteración de desarrollo es un período de tiempo en el que se realiza un conjunto de
funcionalidades determinadas que en el caso de XP corresponden a un conjunto de
historias de usuarios.
Las iteraciones son relativamente cortas ya que se piensa que entre más rápido se le
entreguen desarrollos al cliente, más retroalimentación se va a obtener y esto va a
representar una mejor calidad del producto a largo plazo. 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.
El ciclo de vida de XP fomenta la integración continua, ya que requiere que los
miembros del equipo trabajen casi constantemente, cada hora o todos los días. Sin
embargo, el ciclo de vida completo se estructura de la siguiente manera:

 Extraer trabajos sin finalizar de las historias de usuarios

  Priorizar los elementos más importantes
 Comenzar con la planificación iterativa
 Incorporar un plan realista
 Mantener una comunicación constante con todas las partes interesadas y
empoderar al equipo
 Presentar el trabajo
 Recibir comentarios
 Regresar a la etapa de planificación iterativa y repetir si es necesario

8.5. ¿Cuáles son las 12 prácticas de la programación extrema?

Para perfeccionar aún más el proceso, la programación extrema también implementa un
conjunto de 12 prácticas a lo largo del proceso. Se basan en el Manifiesto ágil, pero se
adaptan a las necesidades de la programación extrema.

 El juego de planificación: La planificación XP se usa para guiar el trabajo. Los

resultados de la planificación deben ser los objetivos que pretendes alcanzar, los
plazos previstos y los pasos a seguir.
 Pruebas de clientes: Cuando finalices una función nueva, el cliente desarrollará
una prueba de aceptación para determinar si has cumplido con la historia de
usuario original.
 Pequeñas entregas: La programación extrema realiza entregas pequeñas y
periódicas para obtener información importante durante todo el proceso. A
menudo, las entregas se envían directamente a los clientes, aunque también
pueden enviarse internamente.
 Diseño simple: El sistema XP está diseñado para ser simple, producirá solo lo
necesario y nada más.
 Programación en parejas: Toda la programación la realizan simultáneamente dos
desarrolladores que se sientan físicamente uno al lado del otro. No hay trabajo
individual en la programación extrema.
 Desarrollo guiado por pruebas (TDD): Debido a que la programación extrema se
basa en los comentarios, se requieren pruebas exhaustivas. A través de ciclos
cortos, los programadores realizan pruebas automatizadas para luego reaccionar
de inmediato.
 Refactorización: Aquí es donde se deberá prestar especial atención a los detalles
más finos del código base, para eliminar los duplicados y asegurarse de que el
código sea coherente. De esta manera obtendrás diseños simples y de alta
calidad.
 Propiedad colectiva: Cualquier par de desarrolladores puede modificar el código
en cualquier momento, independientemente de que lo hayan desarrollado o no.
En la programación extrema, la codificación se realiza en equipo, y el trabajo de
todos se lleva a cabo según los estándares colectivos más altos.
  Integración continua: Los equipos de XP no esperan a que se completen las
iteraciones, sino que se integran constantemente. A menudo, un equipo de XP se
integrará varias veces al día.
 Ritmo de trabajo sostenible: La intensidad de los trabajos de XP requiere que se
establezca un ritmo de trabajo sostenible. Los equipos deben determinar cuánto
trabajo pueden producir a este ritmo por día y por semana, y usarlo para
establecer plazos de trabajo.
 Metáfora: La metáfora es, literalmente, una metáfora. Se decide en equipo y se
usa un lenguaje para expresar cómo debe funcionar el equipo. Por ejemplo,
somos hormigas trabajando en colectivo para construir el hormiguero.
 Estándares de codificación: Los equipos de XP siguen un estándar. De la misma
manera que un grupo de escritores necesita adoptar el tono de una marca para
que parezca que siempre está escribiendo una misma persona, los
desarrolladores de XP deben codificar de la misma manera unificada para que
parezca que el código esté escrito por un solo desarrollador.

8.6. Aplicación de la metodología XP

Un proyecto de desarrollo de software se aplica de forma efectiva y ágil cuando se
adapta a los cambios frecuentes y al ritmo de trabajo dinámico, para ello se debe contar
con herramientas digitales que le permitan al coach llevar las siguientes actividades:

 Organizar reuniones diarias.

 Armar listados de tareas.
 Realizar trabajos colaborativos de remotamente.
 Controlar los adelantos.
 Notificar a los miembros del equipo y mantener comunicación efectiva.

9. Conclusión
En conclusión, la programación extrema es una metodología ágil de desarrollo de
software que se enfoca en la entrega temprana y frecuente de software funcional, la
simplicidad y la retroalimentación constante.
Aunque la documentación en XP es mínima, esto no significa que no se documente
nada en absoluto, se documenta sólo lo necesario para comunicarse efectivamente con
los clientes y mantener al equipo en la misma página. XP se enfoca en la calidad del
software, la colaboración y el aprendizaje constante.
Sus prácticas y principios pueden ser de gran utilidad en proyectos de desarrollo de
software, especialmente aquellos que requieren cambios frecuentes y rápidos en los
requisitos.