Este documento presenta un resumen de la metodología de desarrollo de software conocida como Programación Extrema (XP). Describe que XP se originó en los años 90 para hacer frente a los problemas de los enfoques tradicionales de desarrollo de software. Se caracteriza por ciclos de desarrollo cortos, integración continua, retroalimentación del cliente, pruebas automatizadas y trabajo en equipo. Su creador fue Kent Beck y se ha aplicado principalmente a proyectos con requisitos cambiantes y equipos pequeños.

1. 0
INSTITUTO POLITÉCNICO NACIONAL
Unidad ProfesionalInterdisciplinaria de Ingenieríay Ciencias Sociales y
Administrativas
Metodología XP
Integrantes
*Angeles Flores Mara Eunice
Angeles Pacheco Erick
Ortega Herrera Erick Osvaldo
Rodríguez Montiel Moisés Ulises
Ronces Vázquez Ernesto Iván
*(Coordinador)
Fecha: 09 de marzo del 2017

2. 1
Índice
Introducción........................................................................................................................................... 2
Extreme Programming ........................................................................................................................ 2
Antecedentes......................................................................................................................................... 3
Extreme programming (XP) ................................................................................................................. 3
Razón de creación .................................................................................................................................. 3
Metodologías ágiles............................................................................................................................ 3
Contexto Histórico.................................................................................................................................. 4
Fundador............................................................................................................................................... 6
Kent Beck........................................................................................................................................... 6
Organismos Involucrados........................................................................................................................ 6
Estructura.............................................................................................................................................. 6
Ventajas................................................................................................................................................. 8
Desventajas............................................................................................................................................ 9
Beneficios .............................................................................................................................................. 9
Operación.............................................................................................................................................. 9
Evolución..............................................................................................................................................10
Perspectiva...........................................................................................................................................11
Evaluación de la factibilidad ...............................................................................................................11
Comunidad del proyecto....................................................................................................................11
Administración orientada a pruebas....................................................................................................12
Retrospectiva....................................................................................................................................12
Aprendizaje continúo.........................................................................................................................12
Conclusiones.........................................................................................................................................12
Bibliografía............................................................................................................................................13

3. 2
Introducción
Extreme Programming
XP (Extreme Programming) es una metodología utilizada para desarrollar software de alta
calidad de la manera más rápida posible y con el mayor beneficio para el cliente. Se
caracteriza por tener ciclos de desarrollo extremadamente breves, integración constante,
retroalimentación continua por parte del cliente, pruebas automatizadas regulares y enfoque
de equipo.
Los equipos de programación extrema utilizan una forma simple de planificación y
seguimiento para decidirqué se debe hacer y predecir cuándo se llevará a cabo el proyecto.
Centrados en el valor del negocio, el equipo produce el software en una serie de pequeñas
emisiones totalmente integradas que pasan todas las pruebas que el cliente haya definido.
La programación extrema trata sobre la responsabilidad del equipo en todo el código, para
la codificación en un patrón coherente, de modo que todo el mundo pueda leer el código de
todos, acerca de mantener el sistema en funcionamiento y su integración todo el tiempo.
El trabajo fundamental se publicó por Kent Beck en 1999, y tomó el nombre de
Programación Extrema por las prácticas reconocidas en el desarrollo de software y por la
participación del cliente en niveles extremos. Éste método, tiene principios los cuales son
buenas prácticas a tener presente en el desarrollo del software.

4. 3
Antecedentes
Extreme programming (XP)
Hace algunas décadas, la industria de software buscaba técnicas de desarrollo que
pudieran reducir Ios riesgos en Ios proyectos, y hacerla más productiva. Para atender esta
demanda, en el año de 1968, fue creada la línea de investigación de Ingeniería de Software.
Desde entonces, surgieron incontables técnicas que buscaban mejorar el rendimiento de
Ios proyectos, el primer esfuerzo en ese sentido fue la creación del proceso de desarrollo
de software en cascada.
En la década de 1990, algunos profesionales de software propusieron nuevos procesos de
desarrollo, más orientados en los aspectos humanos de los proyectos. En el año de 2001,
diecisiete profesionales expertos se reunieron para discutir sus prácticas de desarrollo,
estableciendo principios comunes y alternativas para agilizar el desarrollo, hasta entonces,
excesivamente basados en documentaciones y formalismos. Surgen las metodologías
ágiles.
De entre las metodologías ágiles destacamos la Extreme Programming (XP), creada por
Kent Beck el año de 1997 en un proyecto para Chrysler. Una metodología eficiente, que
gracias a una serie de principios y buenas prácticas, posibilitan a Ios desarrolladores
trabajar de forma ágil, sin dejar de lado Ios aspectos como el coste y la calidad de software.
Razón de creación
Metodologías ágiles
En la década de 1990, Ios problemas con los proyectos y la insatisfacción con los enfoques
pesados de desarrollo de software llevaron algunos desarrolladores a proponer nuevos
métodos.
El término de Metodologías Ágiles se hizo popular cuando diecisiete especialistas en
desarrollo de software, presentaron los métodos Extreme Programming (XP), Scrum,
Feature Driven Development FDD, entre otros, y establecieron principios comunes
compartidos por todos. El resultado fue la creación de la Alianza Ágiles (Agile Alliance) y el
establecimiento del Manifiesto Ágil o Agile Manifiesto, en el año de 2004. Las metodologías
ágiles varían en sus prácticas y en sus fases, sin embargo, comparten algunas
características, tales como: desarrollo iterativo e incremental, comunicación y reducción de
productos intermediarios y de la documentación extensiva.

5. 4
Koscianski y Suenes describen los conceptos clave del Manifiesto Ágil de la siguiente
forma:
 Individuos e interacciones en vez de procesos y herramientas
 Software ejecutable en vez de documentación
 Colaboración del cliente en vez de negociación de contratos
 Respuestas rápidas a los cambios en vez de seguir los planes.
El Manifiesto Ágil no rechaza los procesos y las herramientas, la documentación, la
negociación de contratos o la planificación, pero Simplemente muestra que estos tienen
una importancia secundaria cuando son comparados con los elementos humanos del
proyecto (desarrolladores y clientes) y la rápida disponibilidad de un software ejecutable,
de acuerdo con la necesidad del cliente.
La metodología XP se considera una metodología leve de desarrollo de software. Esta es
clasificada como un sistema de prácticas que la comunidad de desarrolladores de software
viene evolucionando para resolver los problemas de entrega de software de calidad
rápidamente, y poder alcanzar las necesidades de negocio que son cambiantes. Esta surgió
a partir de ideas de Kent Beck y Ward Cunningham y fue utilizada por primera vez en un
proyecto piloto en marzo de 1996, del cual el propio Beck formaba parte. Lo de Extreme del
nombre de la metodología se debe al hecho de que emplea al extremo, las buenas prácticas
de la Ingeniería de Software.
La XP no se aplica a todos los tipos de proyectos, siendo más apropiada para los proyectos
con equipos pequeños o medianos, de dos a doce personas. Sin embargo, algunos
defienden su uso en grandes proyectos, ya que al dividirlos en subproyectos
Independientes se realiza de forma más efectiva la tarea. Los proyectos largos deben ser
partidos en una secuencia de mini proyectos de auto contenidos, con una duración de una
a tres semanas.
La XP es un proceso de desarrollo de software apropiado para los siguientes proyectos:
 Con requisitos que son vagos y que cambian con frecuencia.
 Desarrollo de sistemas orientados a objeto.
 Equipos pequeños.
Contexto Histórico
La Programación Extrema, como proceso de creación de software diferente al
convencional, nace de la mano de Kent Beck.

6. 5
Chrysler Corporation hací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.
En aquel entonces la metodología más utilizada por las empresas desarrolladoras de
software era el método de patrones, el cual se basaba en evitar la reiteración en la
búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente, por lo
cual quedaba descartada la parte creativa de los diseños de software haciéndolo algunas
veces ineficiente.
Beck 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 en el año 1999. En ella decía que él estaba convencido que la
mejor metodología era un proceso que enfatizará la comunicación dentro del equipo, que
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 Pattern
Repository y 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 oportunidad 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 esto, 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".

7. 6
Fundador
Kent Beck
Kent Beck es ingeniero de software estadounidense, uno de los creadores de las
metodologías de desarrollo de software de programación extrema y el desarrollo guiado por
pruebas Test-Driven Development o también llamados metodología ágil. Beck fue uno de
los 17 firmantes originales del Manifiesto Ágil en 2001.
Autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change
(1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que
éstos, la programación extrema se diferencia de las metodologías tradicionales
principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los
defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto
natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de
adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una
aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del
proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.
Organismos Involucrados
Chrysler Corporation, es un fabricante estadounidense de automóviles de lujo con sede
en Auburn Hills, en el estado de Míchigan. Chrysler se organizó por primera vez en 1925
bajo el nombre Chrysler Corporation. Hasta 1998, Chrysler Corporation cotizó en el New
York Stock Exchange con el símbolo "C".
Estructura
La metodología se da con cinco reglas: planeación, gestión, diseño, codificación y
pruebas. La metodología se llevará a cabo con las iteraciones de estas.
En la planeación se lleva a cabo la escritura de las “user stories” (historias de usuario); la
planificación del lanzamiento que crea el horario de lanzamiento; hacer lanzamientos
frecuentes; el proyecto se divide en iteraciones y la planeación de iteraciones inicia cada
iteración.

8. 7
Las historias de usuario tienen el mismo propósito que los casos de estudio. Son utilizadas
para la creación de estimaciones de tiempo que serán utilizadas en la junta de planeación
de lanzamiento. Las historias de usuario son escritas por los clientes, son las cosas que el
sistema necesita que haga por ellos. Estas historias no necesitan estar tan detalladas, solo
que expliquen las ideas principales.
Al mismo tiempo que las historias de usuario son creadas se tiene que dar una Metáfora
del Sistema, una idea general para evitar problemas técnicos o de diseños.
La junta de planificación es usada para la creación del plan de lanzamiento. El plan de
lanzamiento es creado en una junta de planificación de lanzamiento. El plan de lanzamiento
especificará cuáles historias serán implementadas en cada lanzamiento del sistema. La
esencia de esta junta es estimar el tiempo de desarrollo para cada historia de usuario en
términos de semanas ideales (no distracciones, trabajos extras, solo enfocarse en el
proyecto).
Al tener un plan de lanzamiento se inicia el proceso de las iteraciones. Las iteraciones
comienzan con una planificación de iteraciones, cada una de ellas. Se escogen historias de
usuario para dar un orden en cómo van a ser resueltas. También se seleccionan pruebas
de aceptación fallidas para ser resueltas. Las historias de usuario y las pruebas fallidas son
divididas en tareas de programación. Los desarrolladores tienen que aceptar las tareas a
realizar; por consiguiente, se estimará cuanto tiempo se tardará en realizar dichas tareas.
Cada tarea debe de ser estimada a 1, 2 o 3 días de programación ideal. Si hay tareas que
son muy cortas para un día, júntalas. Y si hay tareas que se pueden tardar más de 3 días,
divídelas. Funciona igual con las iteraciones, si es muy poco agrega más tarea. Es
necesario que no se dejen de lado iteraciones importantes por andar realizando otras.
Ahora que se tiene un plan para la iteración pasamos al desarrollo. El desarrollo comienza
con la clásica junta de todos los días. El propósito de la junta es mejorar la comunicación
del equipo; comunicar problemas, soluciones y promueve la concentración del equipo.
Definidas las tareas a realizar se puede pasar a lo que se denominará como “el Propietario
de Código Colectivo” (collective code Ownership). Comenzamos creando tarjetas que
describirán el sistemas a realizar, si el sistema es complicado se vuelve a diseñar. Teniendo
definidas las tareas con las tarjetas que los describen se pasa a crear una unidad de prueba.
Se aprovecha tiempo al diseñar primero la prueba, ayuda a dar un mejor enfoque del código.
Ayuda a analizar las verdaderas necesidades que se tienen que hacer. Teniendo ya el
programa base empieza la parte entretenida, la programación en pares. Todo el código que
será enviado a producción es creado por dos personas en una sola computadora. Como
son dos personas en una máquina los dos van analizando el código y tanto como uno como
el otro pueden detectar errores que se presenten, como dice el dicho “dos cabezas piensan
mejor que una”.

9. 8
Los desarrolladores tienen que ir comentando el código hecho en el “depósito de código”
(code repository) cada pocas horas. La integración continua presentada por la acción
anterior ayuda a evitar o detectar problemas.
Después de crear el código viene el momento de la verdad, probarlo. Para tener un mejor
desarrollo es necesario un sistema de pruebas. Un sistema de pruebas es una herramienta
que te ayuda a analizar a fondo tu programa; mostrando los pasos del programa y las
acciones que estos hacen.
Al realizar todas las pruebas y pasarlas se acaba de realizar una nueva versión del
software. La última versión pasa al área de pruebas de aceptación, donde el verdadero
cliente dará la aprobación del software. Cabe recordar que el área de pruebas es la parte
fundamental del proyecto, es donde se puede observar los verdaderos avances del
proyecto. No porque suene corta o sencilla significa que sea de poca importancia.
Con el visto bueno del cliente hay que prepararse para el lanzamiento y la implementación
del nuevo software
Ventajas
● Da lugar a una programación sumamente organizada, debido a que el código es
escrito por varias personas.
● Ocasiona eficiencias en el proceso de planificación y pruebas, gracias a los
ambientes de prueba.
● Al ser el código evaluado periódicamente y por varias personas, se cuenta con una
tasa de errores muy pequeña.
● Propicia la satisfacción del programador.
● Fomenta la comunicación entre los clientes y los desarrolladores, al interactuar estos
de forma personal y de manera constante.
● Facilita los cambios, gracias a la evaluación continua de las versiones.
● Permite ahorrar mucho tiempo y dinero, al dejar atrás las antiguas formas de
documentación y diseño.
● Puede ser aplicada a cualquier lenguaje de programación.
● Sustituye los antiguos modelos UML, con descripciones simples de un trabajo de un
sistema.
● La XP es mejor utilizada en la implementación de nuevas tecnologías.
● Se consiguen productos usables con mayor rapidez, debido a que se entregan
versiones de manera continua.
● No se requiere integración final, debido a que el proceso es continuo.
● Se consiguen productos más fiables y robustos.

10. 9
● Las necesidades del cliente son atendidas con mayor exactitud, ya que este tendrá
un representante que supervise al equipo de desarrollo.
● Gracias al “refactoring” es más fácil el modificar los requerimientos del usuario.
Desventajas
● Solo es recomendable usarla en proyectos a corto plazo.
● En caso de fallar, las comisiones son muy altas.
● Requiere de un rígido ajuste a los principios de XP.
● Puede no siempre ser más fácil que el desarrollo tradicional.
● Es difícil de documentar el proyecto, debido a los constantes cambios en las
versiones.
● Es más complicado medir los avances del proyecto, pues es muy complicado el uso
de una medida estándar.
● Debido al uso de la técnica del pair-programing la gente duda de la eficacia del XP.
Beneficios
● El cliente tiene el control sobre las prioridades, lo que ayuda a evitar requisitos no
comprendidos.
● Se pueden hacer pruebas continuas durante el proyecto, lo que evita que obtener
sistemas deteriorados o con defectos.
● La XP es útil en la implementación de nuevas tecnologías donde los requerimientos
cambian rápidamente.
● Obtienes una increíble capacidad de respuesta ante imprevistos.
● Evita problemas de retrasos y desviaciones haciendo versiones cortas del programa
o builds
● Se anima al contacto y la interacción de los participantes debido a que el cliente
entabla una comunicación cara a cara con los desarrolladores.
Operación
XP usa un enfoque orientado a objetos como paradigma preferido de desarrollo, por lo que
engloba un conjunto de reglas y prácticas que ocurren en el contexto de cuatro actividades
estructurales que son:
1. Planeación

11. 10
2. Diseño
3. Codificación
4. Pruebas
1. Planeación
Aquí se recaban requerimientos que permite a los miembros técnicos del equipo XP
entender el contexto del negocio para el software y que tengan sensibilidad de la salida y
características principales y funcionalidades requeridas.
Las ideas del usuario son tomadas para modelar los requisitos. Los clientes y
desarrolladores trabajan en conjunto para ver de qué forma pueden agrupar las ideas en la
siguiente entrega que se desarrollará.
Conforme avanza el trabajo, los clientes pueden agregar ideas, cambiar el valor de una ya
existente, descomponerlas o eliminarlas.
2. Diseño
El diseño que utiliza XP es mantenerlo sencillo. Utiliza tarjetas CRC como un mecanismo
eficaz para pensar en el software en un contexto OO. Estas tarjetas identifican y organizan
las clases que son relevantes para el incremento actual de software.
3. Codificación
XP trabaja por parejas durante la codificación en una estación de trabajo con el objetivo
de crear código para una idea. Cuando los programadores terminan el trabajo, su código
se va integrando con el de los demás. En ocasiones existe un equipo de integración
encargado de esto. En caso de que no lo haya, los mismos programadores se encargan de
integrar su trabajo con el de los demás. La estrategia de integración continúa ayuda a
encontrar los errores de manera rápida y eficaz.
4. Pruebas
Para asegurar la calidad del software se hacen pruebas unitarias antes de que comience
la codificación. Estas pruebas deben implementarse con el uso de una estructura que
permita automatizarlas.
Evolución
En 1989, Cunningham formó un equipo que usaba los principios y muchas prácticas que
después adoptaría XP, mientras trabajaba para la compañía “Wyatt Software”. Sin
embargo, se reconoce a Kent Beck como el que articuló esta propuesta y le dio nombre
propio. Este nuevo paradigma tiene sus orígenes durante el proyecto C3 en 1996, el cual

12. 11
consistió en un desarrollo a largo plazo para reescribir el sistema de nómina de Daimler-
Chrysler.
Según Joshua Kerievsky IXP es la evolución orgánica de XP. Está imbuida del espíritu
minimalista, centrado en el cliente y orientado a las pruebas que tiene XP. IXP difiere sobre
todo de la XP original en su mayor inclusión de las gerencias, el papel más amplio de los
clientes y en sus prácticas técnicas actualizadas.
Perspectiva
La perspectiva que tiene la metodología XP se va enfocando a la industria, en la
simplificación del proceso de planificación e integración continua, en determinar límites de
XP (¿Cuándo se debe seguir?, ¿Cuál es su límite de integrantes?).
Sin embargo, con la evolución que tuvo a IXP trata de procurar al cliente, incluye de mejor
manera a las gerencias además de tener técnicas más actualizadas.
Las prácticas que lleva a cabo IXP son:
● Evaluación de la factibilidad
● Comunidad del proyecto
● Calificación del proyecto
● Administración orientada a pruebas
● Retrospectivas
● Aprendizaje continuo
Evaluación de la factibilidad
1. Existe un ambiente apropiado de desarrollo.
2. El equipo estará constituido por los participantes adecuados.
3. La organización tiene un programa de calidad distintivo y apoya la mejora continua.
4. La cultura organizacional apoyará los nuevos valores de un equipo ágil.
5. La comunidad extendida del proyecto estará constituida de modo apropiado.
Comunidad del proyecto
Los miembros de la comunidad y sus papeles deben definirse de modo explícito, al igual
que deben establecer los mecanismos para su comunicación y coordinación entre los
integrantes.

13. 12
Administración orientada a pruebas
Requiere criterios medibles para evaluar el estado del proyecto y su avance. Esta
administración establece una serie de destinos y luego define mecanismos para determinar
si se han alcanzado o no.
Retrospectiva
Después de entregar un incremento del software, el equipo realiza una revisión técnica
especializada, esta revisión examina los temas, eventos y lecciones aprendidas a lo largo
del incremento.
Aprendizaje continúo
Los miembros del equipo son invitados a aprender nuevos métodos y técnicas que
conduzcan a una calidad más alta del producto.
Conclusiones
Con lo visto anteriormente podemos concluir que la metodología XP es una herramienta
ágil al tener un proceso en el cual se busca separar el trabajo e irlo revisando
constantemente en busca de errores. Tiene dos objetivos principales, el cubrir las
necesidades del cliente y generar el máximo trabajo en equipo.
En cuanto a IXP, lo único en que ha mejorado es en la perspectiva de procurar al cliente y
su uso por las técnicas actualizadas.
Los principios de previsibilidad y adaptabilidad, distribución del trabajo y su enfoque en
métodos ágiles, hacen de la metodología XP una buena opción a seguir.
Utiliza al extremo las buenas prácticas de ingeniería del software, haciendo que como
disciplina de desarrollo de software se base en los valores de simplicidad, comunicación,
retroalimentación y valor.
Se enfoca en todo el equipo, porque es recomendable que cada miembro del equipo tenga
un rol en el cual desenvolverse, teniendo como finalidad cumplir los objetivos del proyecto.
El equipo se debe mantener con suficiente retroalimentación para que puedan ver dónde
están y llevar a cabo así las prácticas de su situación particular.
Cuando se desarrolla un proyecto se debe de tener planteado cómo será y cuánto durará.
Seguido de esto, en el diseño y codificación, se prueba y corrige el programa hasta pasar
las pruebas que el cliente haya dispuesto, llegando a la prueba de aceptación, que es
cuando el cliente aprueba o no la implementación del software generado.

14. 13
Bibliografía
● Anónimo. (2012). Detalles de Metodología Xp. Recuperado de:
http://www.extremeprogramming.org
● Anónimo. (2013). Extreme Programming: A Gentle Introduction. Recuperado de:
http://www.extremeprogramming.org
● Calderón Amaro. (2013). Metodologías Ágiles. Recuperado de:
http://seccperu.org/files/Metodologias%20Agiles.pdf
● Castillo Oswaldo, Figueroa Daniel, Sevilla Héctor. (2013). Programación Extrema.
Recuperado de: http://programacionextrema.tripod.com/index.htm
● Martinez Noriega Raúl. (2015). Curso de Ingeniería de Software. Recuperado de:
http://bit.ly/2lNy6us
● Roger S. Pressman. (2010). Ingeniería del Software Un enfoque Práctico. University
of Connecticut. Séptima edición.
● Wells, Don. "Extreme Programming By Don Wells". Extremeprogramming.org. N.p.,
2017. Web. 7 Mar. 2017.