HISTORIA

XP es una abreviación en inglés que significa programación extrema, esta metodología es una
de las primeras en aparecer y es una de las mas exitosas en estos tiempos.

Inició por los años 90, es una de las pioneras en la parte de las metodologías ágiles, la persona
que lidera es Kent Beck, él es uno de los organizadores del manifiesto ágil.

XP ya tiene variantes, una de ellas es el IXP o llamada XP industrial que es una variante para
organizaciones más grandes.

XP

Xp es una de las pioneras de las metodologías ágiles. ¿Qué quiere decir una metodología ágil?
Es una metodología que te permite adaptar el proyecto a las distintas condiciones de trabajo,
es muy usada por las empresas ya que gestionan sus proyectos de una manera más flexible y
eficaz aumentando su productividad con unos costos más reducidos.

----------------------

DEFINICIÓN

Una vez explicado que es una metodología ágil podemos explicar que es el xp,

en definición la metodología xp es una metodología ágil usada para el desarrollo de un

software, para esta metodología es clave potenciar las relaciones interpersonales mediante el
trabajo en equipo, propiciando un buen clima de trabajo para obtener el éxito en el desarrollo
del software.

Prácticamente consiste en acoplarse a una serie de reglas que ocurren en el contexto de

cuatro actividades estructurales: planeación, diseño, codificación y pruebas, estas reglas son
los requerimientos de los clientes.

Esta metodología se basa en las necesidades del cliente para poder brindarles un muy buen
producto de buena calidad en el menor tiempo posible.

Cabe recalcar que es muy importante la comunicación fluida entre todos los participantes.

XP se adecua para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un
alto riesgo técnico.

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.

EL OBJETIVO PRINCIPAL es el desarrollo y gestión de proyectos con eficacia, flexibilidad y

control.

NOTA: El XP se basa en las interacciones cortas, de aproximadamente una semana, en las que
el equipo de trabajo reducido (máximo 12 personas) ejecuta unas tareas concretas. Una vez
finalizado el período, se hace el test y se evalúan los resultados obtenidos.

VALORES
EL XP Incorpora cinco valores que son fundamentales para afrontar este tipo de metodología.

Cualquier grupo de trabajo que quiera implementar XP tiene que cultivar esos valores, tiene
que practicarlos

1) La comunicación
Tiene que ser constante entre todos los participantes del proyecto, sea la persona que
es el líder del proyecto, sea el cliente, etc tiene que haber una comunicación eficaz
entre todos.

La comunicación con el cliente tiene que ser fundamental, recordemos que el cliente
es una parte esencial de la metodología xp, por eso debe haber una comunicación
constante pues el proyecto se basa netamente en que él sea parte del equipo de
desarrollo y que vea cómo se está trabajando el software que al final va hacer utilizado
por él y sus empleados, la empresa u organización.

Aquí a nivel profesional hay que quitarse esa parte de que a mi me da miedo hablar en
público o mejor me quedo callado y no pregunto, porque por lo menos en ingeniería
de software o en lo que es el ámbito informático si usted no hace las preguntas en el
momento adecuado es probable que vaya directo a un fracaso en el proyecto de
software. (Establezcamos una comunicación eficaz)

2) Simplicidad: Como decía Einstein que lo más difícil es lograr volver simple a lo
complejo, tiene toda la razón, entre más simple o fácil se vean las cosas será más fácil
para la persona que lo esté utilizando. Si bien es cierto que nosotros elaboramos el
proyecto, tenemos que dar facilidades a la persona que va a usar nuestro programa o
proyecto ya que quizá no sepa mucho de tecnología, es por eso que el diseño que se
haga tiene que ser algo fácil, simple y sencillo.
Por lo tanto lo que la simplicidad busca es agilizar el desarrollo del proyecto, facilitar el
mantenimiento y usar un método simple y ágil.

3) Retroalimentación: podemos aprender de los errores, del nuevo proyecto, para

finalmente sacar nuestras conclusiones.

4) Valentía: Todas las metodologías ágiles rompen el esquema, y al hacerlo siempre está
el miedo al cambio, por la valentía significa asumir retos, ser valiente ante los
problemas y afrontarlos

5) RESPETO: Significa mantener un trato de forma cordial.

Es muy importante, ya que es un valor que todos debemos poner en práctica siempre,
ya sea entre los miembros del equipo, con el cliente, etc.
El respeto hace referencia a que haya respeto entre los miembros del equipo, esto es
fundamental para que funcione bien el equipo de trabajo y para que al final el equipo
de trabajo tenga confianza unos entre otros, que las ideas sean respetadas, que
cuando un compañero propone como hacer algo pues todos escuchen y tengan una
empatía con las ideas del resto del equipo.
--------------------------------------
 CARACTERISTICAS:

Metodología basada en prueba y error: Se realizan pruebas constantemente, para

después realizar la corrección de todos los errores antes de añadir una nueva
funcionalidad. Se aconseja escribir el código de la prueba antes de la codificación.

Desarrollo iterativo e incremental: se trata de añadir pequeñas mejoras, unas tras

otras.

Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo

por dos personas en un mismo puesto. Se supone que de esta manera la calidad del
código escrito será mejor ya que es revisado y discutido entre ambos mientras se
escribe.

Frecuente integración del equipo de programación con el cliente o usuario. Se

recomienda que un representante del cliente trabaje junto al equipo de desarrollo.

Refactorización del código, es decir, rescribir ciertas partes del código para aumentar
su legibilidad y mantenibilidad, pero sin modificar su comportamiento. Las pruebas
han de garantizar que en la refactorización no se ha introducido ningún fallo.

Propiedad del código compartido: en vez de dividir la responsabilidad en el desarrollo

de cada módulo en grupos de trabajo distintos, este método promueve el que todo el
personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes
pruebas de regresión garantizan que los posibles errores serán detectados.

Simplicidad en el código: es la mejor manera de que las cosas funcionen. La

programación extrema apuesta que es mejor hacer algo simple y tener un poco de
trabajo extra para cambiarlo si se requiere después, que realizar algo complicado y
quizás nunca sea utilizado.
La simplicidad y la comunicación son muy complementarias, ya que con más
comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto
más simple es el sistema, menos tendrá que comunicar sobre éste.

Rápida respuesta a cambios- En caso observamos cambios en los requisitos del

cliente, esta metodología busca soluciones rápidas.

GUPO PEQUEÑO Y MUY INTEGRADO DE 2 A12 PERSONAS - Se considera al equipo de

proyecto como el principal factor de éxito del proyecto ADEMÁS ES UN EQUIPO CON
UNA FORMACIÓN ELEVADA Y CON UNA AMPLIA CAPACIDAD DE APRENDER.

CICLO DE VIDA
Los ciclos de vida 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 esta conformado con una serie de fases:
Fase de exploración: Consta en entender lo que el cliente necesita,
además el usuario determina que funcionalidades va a tener el sistema
elaborado.
Fase de Planificación:
Aquí se hace una proforma y una estimación de los costos, además se
coordina el plan de entrega.
Fase de Iteraciones:
Cabe recalcar que todo el proyecto se divide en iteraciones de un tiempo
máximo de 3 semanas y se detalla cada tarea a realizar.
utilizadas para medir el progreso del proyecto. Una iteración terminada
sin errores es una medida clara de avance
Fase de Producción:
El usuario decide si se pone en ejecución el proyecto o chechea si hacen
falta funcionalidades. La fase de producción requiere de pruebas adicionales
y revisiones de rendimiento antes de que el sistema sea trasladado al
entorno del cliente. 
Fase de mantenimiento
La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su
estructura.

Fase de muerte
Esta fase se da cuando el cliente no tiene más requerimientos por incluir dentro del sistema.
Esto requiere que las necesidades del cliente se satisfagan. Se genera la documentación final
del sistema y no se realizan más cambios en la arquitectura. También puede ocurrir cuando el
proyecto no cumple las expectativas del cliente o no hay dinero para cubrir el proyecto.

FASES DEL PROCESO DE DESARROLLO

Ahora pasaremos a explicar el proceso de desarrollo de software que maneja XP, aquí podremos
encontrar 4 fases principales:

Estas fases trabajan como un ciclo, todas las fases están integradas y cada vez que hacen ese
giro realizan una entrega, que es el incremente de software, que es como un avance, y
nuevamente se sigue trabajando para construir el siguiente incremento.

Comenzaremos explicando la fase de Planificación:

● Todo proyecto que siga la metodología XP lo primero que tiene que

hacer es reunir o recolectar las historias de Usuario, y se preguntarán que son
las historias de usuario, pues las Historias de usuario: son las descripciones del
proyecto que el cliente nos brinda, ósea es la explicación del cliente, como
desea su programa, es una breve descripción del comportamiento del sistema.
y para conseguirlo es muy importante saber escuchar, es un pilar muy
importante, y como ya se había mencionado las historias de usuario, son
requerimientos que provee el usuario (osea el cliente) para el proyecto, son
como requisitos para que se puedan cumplir, en sí es información necesaria
para realizar todo el proyecto y que se pueda diseñar el software que al final se
va implementar.

Estas historias de usuario, es como una breve narración, nada del otro mundo
y por lo general se hace en una hoja o en un post it, y ahí se dice lo que el
cliente quiere para que se desarrolle el software. Prácticamente es una frase.

Ejm: yo como facturador del sistema quiero poder ingresar un nuevo cliente. Yo
como cliente… PERO también, existen historias escritas por el equipo de
trabajo, donde detallan funcionalidades internas del software. Y cada historia
tiene un valor y una prioridad (urgente normal o baja) y a ellas se les asigna un
costo en tiempo.

En esta fase resalta más la práctica de los 5 valores antes mencionados, sobre
todo el valor que es la comunicación, una comunicación asertiva tanto con el
cliente como con todo el grupo de trabajo en el momento de establecer esas
historias de usuario, manteniendo el respeto, esa valentía de poder afrontar los
procesos, etc.

Creación de las pruebas de aceptación, quiere decir que antes de colocar la

primera línea de código para el proyecto se tiene que pensar que pruebas debe
superar ese código. Osea es pensar antes de actuar.

Aquí también vemos el plan de iteracción, en este plan se ven los diferentes
avances del proyecto. Aquí definimos el plazo del proyecto hasta su
lanzamiento, también se pueden ver otros factores como la velocidad del
proyecto y la división del grupo de trabajo(para realizar la programación en
pareja), osea en la planificación en si se define todo lo que se va hacer en
adelante y hasta el final del proyecto y todo lo que se va necesitar implementar
o requerir para realizar este proyecto.
Diseño:
La metodología sugiere ser diseño simple y sencillo, ¿porque diseño simple?
pues para hacerlo menos complicado y seguir con el diseño más fácil y
entendible.

Aquí podemos encontrar dos casos, uno es cuando encontramos una historia
de usuario muy simple, o lo otro es cuando es usuario solicita algo más
complicado, en este caso el programador tal vez ya lo ha aplicado en otras
partes y sabe cómo desarrollarla, cuanto tiempo se demorará.

O si en todo caso ya hay algo pre construido o utilizar un módulo que va a

traer y se va a acoplar entonces usted construye un diseño simple con una
tarjeta que se llama cRC( clase, responsabilidad y colaborador) (aquí se
determina que clases van a involucrarse dentro de esa funcionalidad, software
orientado a objetos), y aquí vemos como se desarrolla la funcionalidad, todo
orientada a objetos, y aquí encontramos a las clases, cuales van a estar ahí y
todo lo demás. (aquí se aplica el valor de la simplicidad)

Pero si nos afrontamos a la elaboración de un diseño más complejo, aquí se

construye un prototipo (una versión inicial de algo), donde el cliente se puede
llevar una primera idea de cómo quedaría el interfaz de su proyecto.
Generalmente es algo visual.

Aquí podremos encontrar al rediseño, ya que al ser una metodología ágil

siempre tratan de entregar un producto lo más rápido posible, es por eso que el
diseño no es que sean muy elaborado. Por eso se da el rediseño, para obtener
una mejora continua y un mejor interfaz.

Codificación:
● Aquí cuando llegamos a la codificación podemos darnos cuenta si es
que faltó algo en el diseño o no, en todo caso si es que hay algo por modificar.
De ser así, lo agregamos o lo modificamos.

● La codificación tiene una característica peculiar, que es la de

programación por pareja basado en ese dicho que dice que dos cabezas
piensan mejor que una,

Es por ello que las actividades a realizar las tienen que afrontar los dos
programadores al mismo tiempo, no es que los dos se parten el trabajo no sino,
ambos realizan el mismo proyecto con su diseño previamente elaborado y
cuando ya lo tengan terminado ellos se reúnen y hacen unas pruebas y
deciden cuál de las dos es la que se va a entregar, o en todo caso deciden
fusionarla y construyen un proyecto más elaborado y ese es el que se va a
entregar al cliente, ahí se practica lo que se conoce como la prueba unitaria,
esta prueba es una prueba que te asegura que esta completamente
desarrollada y que esta lista para ser presentada al cliente.

XP tiene una parte muy fuerte en la parte de pruebas entonces yo se basa

mucho en las pruebas, cuando esa pareja ya decide que esa funcionalidad está
completa que ha pasado todas las pruebas entonces se pasa a una parte de
integración, porque las funcionalidades que trabajaron esas dos personas, esa
pareja, debe unirse con la funcionalidad de la otra pareja y de la otra y la
cantidad de parejas que existen en el equipo de desarrollo y todas deben
unirse y deben funcionar juntas entonces ahí está la parte de la integración
continua de todas las funcionalidades y ahí cuando ya todas están juntas las
que conforman este pequeño incremento que vamos a lanzar en este primer
archivo

● lo más esencial de esta fase es la programación en parejas, es lo que

caracteriza mucho a la metodología xp, es muy importante el hecho de que dos
parejas trabajen en un solo ordenador codificando, esto hace mucho más
productiva la manera de trabajar.

Pruebas:
● En conclusión se hacen test en diferentes partes del código para verificar
que no haya redundancia de datos, cabe recalcar que las pruebas o test se
tiene que realizar en un ambiente real y te permiten detectar un error lo más
pronto posible.

Si al llegar a la fase de pruebas no se ha logrado los estándares

correspondientes tendríamos que volver a realizar todo desde la planificación.

● Ejm yo entrego los datos del cliente , luego el sistema cuando consulte,
me tiene que aparecer ese cliente.

entonces se hace la prueba de aceptación global se mira si todas las

funcionalidades en conjunto funcionan bien porque a veces una funcionalidad
social solita funciona perfecto pero cuando usted la una y con otra entonces ya
empiezan AA pelear entre ellas por los recursos empiezan a haber problemas
entonces hay que hacer esas pruebas de integración que todo funcione bien y
debe pasar el incremento todo ese conjunto de funcionalidades la prueba de
aceptación si ya pasa la prueba de aceptación entonces si ya se le entrega el
cliente se hace el lanzamiento de ese incremento del software y se calcula la
velocidad del proyecto ya cuando yo llego y entregó el primer incremento
entonces ya veo cuanto me demore haciendo este giro hago una
retroalimentación de mi trabajo y del software porque ya lo voy entendiendo ya
voy creando las funcionalidades de él y entonces yo vuelvo a recalcular la
velocidad del proyecto entonces le dice al cliente vea nos demoramos tanto
aquí y el siguiente incremento tiene más funcionalidades o son un poco más
complejas nos vamos a demorar más entonces el proyecto al final va a
demorarse tanto tiempo en integrarse entonces cada vez que se termina un
incremento se hace esa retroalimentación y se vuelve a calcular la velocidad
del proyecto y el tiempo de entrega esa planeación en el tiempo de cómo se irá
desarrollando ese proyecto

LANZAMIENTO
● Es cuando ya el proyecto está terminado y va a ser entregado al cliente.

ROLES
PROGRAMADOR(PROGRAMER)
Como todos conocemos, simplemente es aquella persona que
escribe el código y realiza las pruebas unitarias, las pruebas
unitarias son pruebas, como su propio nombre lo dice, osea que
ciertas unidades de códigos van hacer probadas una a la vez para
ver su funcionalidad.
En concreto el programador es el responsable de las decisiones
técnicas, es también el responsable de construir el sistema, de
diseñar, programar y realizar las pruebas

CLIENTE (CUSTOMER)
El cliente elabora los requerimientos, es el que va a encargar el trabajo va
a escribir las historias de usuario y va a priorizar las tareas a realizar.

ENTRENADOR (COUCH)
Es el responsable del equipo en XP, ósea se encarga de que este
siga el proceso correctamente.
Podemos decir que él es: el líder del equipo - toma las decisiones
importantes, es también el principal responsable del proceso y
tiende a estar en un segundo plano a medida que el equipo
madura. Asesora al resto de componentes del equipo y marcan
el rumbo del proyecto.
RASTREADOR (TRACKER)
Es el que mide el progreso del proyecto y lo compara con lo
estimado.
Es la persona que monitorear el progreso del desarrollo del
proyecto, verificando que esto se de en el tiempo estimado y
detectar a tiempo los problemas ocurridos.
En simples palabras se encarga del seguimiento del proyecto.
PROBADOR (TESTER)
Él se va a encargar de verificar si las pruebas unitarias van a estar
bien oh no, algo parecido que el programador, solo que el
probador va a difundir de cierta manera los resultados
obtenidos.
La calidad del producto final depende en gran medida de su
trabajo.

MANAGER (BIGBOSS)
Es la persona más cercana entre el cliente y los programadores es
Dentro de sus responsabilidades está obtener todos los recursos
necesarios para la realización del proyecto.
-Ejm: Todas las herramientas que el equipo de desarrollo necesita
para poder empezar a trabajar.
- Además se encarga de administrar las reuniones y su principal
labor pues es la coordinación del equipo y la coordinación del
proyecto.

ACTIVIDADES
Codificar: Es la única actividad de la que no podremos prescindir. Sin
código fuente no hay programa, aunque hay gente que cuenta que existe
software en producción del que se perdió el código fuente. Por tanto,
necesitamos codificar y plasmar nuestras ideas a través del código. En una
programación en PX en pareja el código expresa tu interpretación del
problema, así podemos utilizarlo para comunicar, para hacer mías tus ideas, y
por tanto para aprender y mejorar.

Hacer pruebas: Bueno las pruebas nos indican básicamente el verificar

si nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que
pudiese originar un fallo en nuestro sistema entonces significa que has
acabado por completo.
No debemos de escribir tan solo una prueba para ver que funciona y salir
corriendo, debemos de pensar en todas las posibles pruebas para nuestro
código. Programar y probar es más rápido que sólo programar. Puedes ganar
media hora de productividad sin hacer pruebas, pero perderás mucho tiempo
en la Depuración.
Las pruebas deben de ser sensatas y valientes. No podemos hacer
pruebecillas que no testen a fondo el sistema, esos agujeros que vamos
dejando nos esperan para cuando pasemos de nuevo por allí y volveremos a
caer dentro.

Escuchar: Sabemos que los programadores no lo conocemos todo, y

sobre todo muchas cosas que las personas de negocios piensan que son
interesantes. Si ellos pudieran programarse su propio software ¿para qué nos
querrían? Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo
deseado, y tenemos que preguntar a quién necesita la información.
Tenemos que escuchar a nuestros clientes, cuáles son los problemas de su
negocio, debemos de tener una escucha activa explicando lo que es fácil y
difícil de obtener, y teniendo siempre en cuenta que la realimentación entre
ambos nos ayudan a todos a entender los problemas.

Diseñar: El Diseño crea una estructura que organiza la lógica del sistema,

un buen diseño permite que el sistema crezca conforme lo vamos
desarrollando. Los diseños deben de ser sencillos, si alguna parte del sistema
es de desarrollo complejo, divídela en varias. Si hay fallos en el diseño o malos
diseños, estos deben de ser corregidos cuanto antes.
En Resumen:
Tenemos que codificar porque sin código no hay programas, tenemos que
hacer pruebas porque sin pruebas no sabemos si hemos acabado de codificar,
tenemos que escuchar, porque si no escuchamos no sabemos que codificar ni
probar, y tenemos que diseñar para poder Codificar, probar y escuchar
indefinidamente.

DEPURACION: es el proceso de identificar y corregir errores de programación.

El proyecto en si consta de 10 a 15 ciclos oh iteraciones y cada ciclo consta de

fases