EXTREME PROGRAMMING (XP)

ÍNDICE

PP.

INTRODUCCION 1

DEFINICIÓN DE XP COMO UNA METODOLOGÍA ÁGIL,

HISTORIA Y PRINCIPIOS BÁSICOS. 2

Marco histórico de la Programación Extrema 3

Principios básicos de la Programación Extrema 4

ELEMENTOS FAVORABLES DE LA METODOLOGÍA Y SUS

CARACTERÍSTICAS 7

Características de XP 8

ELEMENTOS EN EL PROCESO DE DESARROLLO DE XP 9

FASES DE LA METODOLOGÍA XP 10

1ª Fase: Planificación del proyecto. 10

2ª Fase: Diseño. 12

3ª Fase: Codificación. 13

4ª Fase: Pruebas. 15

CICLO DE VIDA, DEFINICION Y CARACTERISTICAS PARA UN

PROYECTO XP 16

CONCLUSIÓN 19

REFERENCIAS BIBLIOGRAFICAS 20

INTRODUCCIÓN

Las metodologías ágiles de desarrollo de software han despertado interés en los

últimos años debido a que proponen simplicidad y velocidad para crear sistemas. Los

programadores se concentran solamente en aquellas funciones que se necesitan

inmediatamente, entregándolas al cliente lo antes posible, obteniendo retroalimentación

constante y reaccionando rápidamente a los cambios en el negocio y la tecnología. Se

han hecho esfuerzos por analizar y clasificar éstas metodologías, las cuales han

aparecido en buen número y aparentemente no pararan de hacerlo en un futuro cercano.

Entre los ejemplos más conocidos de estas metodologías se encuentran los

siguientes: “Adaptive Software Development”, “Agile Modeling”, “Crystal”, “Dynamic

Systems Development Method”, “Extreme Programming”, “Feature-Driven

Development”, “Internet-Speed Development”, “Pragmatic Programming”, y “Scrum”.

La Programación Extrema ha sido entre todas las metodologías ágiles

nombradas anteriormente una de las más exitosas y controversiales de los tiempos

recientes. El presente trabajo presenta un resumen de las características más destacables

de esta metodología, incluyendo las fases de su ciclo de vida, elementos que intervienen

en la metodología y demás puntos de interés que definen a esta metodología.

1

DEFINICIÓN DE XP COMO UNA METODOLOGÍA ÁGIL, HISTORIA Y

PRINCIPIOS BÁSICOS.

XP es una “metodología ligera o ágil para el desarrollo de software eficiente y

altamente efectivo”. Existe una gran controversia en la definición de la programación

extrema, esta viene de la mano de la palabra metodología. Muchos consideran que no

puede ser denominada metodología porque elimina toda la parte burocrática

anteriormente asociada a las metodologías para el desarrollo de software

(documentación, diseños varios, y papeleos excesivos). Sin embargo, obviar que nos

proporciona una guía o un proceso repetitivo para el desarrollo de software sería obviar

lo que en sí es. Así pues, se puede tomar como bueno el consenso de denominarla como

metodología ligera (o ágil), debido a que elimina la “pesada” carga del papeleo a los

desarrolladores.

Básicamente, la programación extrema, busca dos objetivos claramente: hacer

un software bien (con calidad) y de la forma más rápida posible. De hecho estos son los

objetivos fundamentales de cualquier metodología aplicada al desarrollo de software y a

cualquier otra área en general. A pesar de esto, con las metodologías de desarrollo

actuales, el 70% de los proyectos fracasan y aproximadamente, también, el 70% de los

fallos no se deben a cuestiones técnicas, son debidos a cambios en la gestión o

problemas de comunicación.

Luego de analizado el problema, podemos buscar y ven en la programación

extrema la solución, o al menos un acercamiento. La programación extrema centra su

atención en la producción de software con una fuerte arquitectura, intentando sacar

productos al mercado rápidamente, con gran calidad y motivando al equipo de trabajo

para seguir mejorando esta tendencia.

Como metodología, la programación extrema, presenta muchos puntos comunes

con el desarrollo incremental, comenzando por el hecho de que el software desarrollado

con XP se realiza de forma incremental.

2

Marco histórico de la Programación Extrema

Esta metodología esta fundamentada en un paradigma de la programación, los

lenguajes orientados a objetos y en las metodologías que surgieron para ayudar en el

desarrollo de proyectos que utilizan este paradigma. Las metodologías anteriores a XP,

como ya hemos dicho, eran metodologías muy pesadas, debido a las necesidades de

documentación y de generación de una serie de elementos que realmente no prestan

utilidad.

La programación extrema es una metodología reciente (tiene alrededor de 14

años) en el desarrollo de software. Su filosofía es satisfacer las necesidades del cliente,

por eso lo integra como una parte más del equipo de desarrollo. 

La programación extrema surgió gracias a Kent Beck. Kent, había trabajado,

sobre todo, con Smalltalk, el primer lenguaje orientado a objetos que realmente se hizo

popular.

Siendo un amante de la orientación a objetos, Kent trabajó junto con Ward

Cunnigham intentando encontrar un acercamiento al desarrollo de software que

permitiese hacer las cosas más simples y de forma más eficiente.

Debido a sus investigaciones, Kent entró a formar parte en un proyecto de

DaimlerChrysler, que se denominó C3 (Chrysler Comprehensive Compensation),

dónde, debido a las necesidades del propio proyecto, se vio obligado a aplicar sus

investigaciones y a ponerlas en práctica, surgiendo lo que actualmente se conoce como

“Extreme Programming”.

El denominar a esta metodología “Extreme Programming” surge por el énfasis

de ésta en tener unas buenas prácticas y seguirlas constantemente, pero seguirlas de una

forma extrema, es decir, los principios de XP deben ser seguidos sin alejarse de ellos en

ningún momento, y cualquier otra práctica será ignorada.

Fue inicialmente creada para el desarrollo de aplicaciones dónde el cliente no

sabe muy bien lo que quiere, lo que provoca un cambio constante en los requisitos que

3

debe cumplir la aplicación. Por este motivo es necesaria una metodología ágil como XP

que se adapta a las necesidades del cliente y dónde la aplicación se va revaluando en

periodos cortos de tiempo. 

XP está diseñada para el desarrollo de aplicaciones que requieran un grupo de

programadores pequeño, dónde la comunicación sea más factible que en grupos de

desarrollo grandes. La comunicación es un punto importante y debe realizarse entre los

programadores, los jefes de proyecto y los clientes. 

Principios básicos de la Programación Extrema

XP propone una serie de principios que dirigen la metodología y los cuales se

describen brevemente a continuación:

Humanidad: el software es desarrollado por personas, por tal motivo, el factor humano

es la clave principal para entregar software de calidad. XP tiene como objetivo abordar

los objetivos de la gente y sus organizaciones, por lo que puede beneficiar a ambos.

Economía: Al producir software, también se debe producir valor para el negocio. Dos

aspectos de la economía son la clave para XP: valor actual y el valor de las opciones. La

primera dice que una moneda hoy, vale más que una moneda mañana, por lo que el

desarrollo de software más temprano, hace ganar dinero y hacerlo más tarde hace gastar

dinero, cuanto más pronto sea, mayor será la ganancia que dará.

Beneficio mutuo: cada actividad debe beneficiar a todas las personas y organizaciones

interesadas. Este es, quizás, el principio más importante de XP, y el más difícil de

cumplir. Siempre hay soluciones fáciles para cualquier problema, donde algunos ganan

y otros pierden. A menudo, estas soluciones son atajos tentadores. Sin embargo, son

siempre una pérdida neta, debido a que derriba las relaciones y deteriora el medio

ambiente de trabajo.

Auto-similitud: la naturaleza continuamente utiliza estructuras que son similares a sí

mismas, pero en varias escalas. El mismo principio debe aplicarse al desarrollo de

4

software: debemos ser capaces de volver a utilizar soluciones similares, en diferentes

contextos.

Mejora: la mejora continua es la clave para XP. La perfección no existe, pero debe

esforzarse continuamente por la perfección. En la práctica, en cada iteración del sistema

se mejora en calidad y funcionalidades, utilizando la información (feedback) del cliente,

a partir de pruebas automatizadas y del propio equipo.

Diversidad: Es muy cómodo cuando, en un equipo son todos iguales, pero estos

equipos no son eficaces. Los equipos deben incluir diferentes saberes, habilidades y

personalidades, para poder descubrir y resolver problemas.

Por supuesto, ser diferentes conduce a potenciales conflictos, que deben ser

gestionados y resueltos.

Tener diferentes opiniones y proponer soluciones diferentes es muy útil en el

desarrollo de software, siempre y cuando, sean capaces de gestionar los conflictos y

elegir la mejor alternativa.

Reflexión: un equipo eficaz no se limita a hacer su trabajo. Se preguntan cómo están

trabajando, y por qué están trabajando de esa manera. Tienen que analizar las razones

del éxito o el fracaso sin ocultar los errores, hacerlas explícitas y tratando de aprender

de ellas. Durante iteraciones trimestral y semanales, se debe tomar tiempo para

reflexionar acerca de cómo se está ejecutando el proyecto, y cuáles son las posibles

mejoras. Sin embargo, no se debe pensar demasiado.

Flujo: flujo significa desarrollar constantemente software útil, realizando todas las

actividades de desarrollo juntas. Las prácticas de XP suponen un flujo continuo de

actividades, no una secuencia de fases diferentes, con el lanzamiento del software sólo

después de la última. Sólo el flujo continuo permite la retroalimentación (feedback) para

asegurar que el sistema está evolucionando hacia la dirección correcta.

Oportunidad: los problemas deben ser vistos como una oportunidad de mejora.

Siempre se presentan problemas, pero para alcanzar la excelencia, no se puede

5

solamente corregir los problemas. Es necesario convertirlos en oportunidades de

aprendizaje y mejora. Por ejemplo, si no se pueden hacer planes a largo plazo, Una

solución sería el uso de ciclos de planificación trimestrales, y revisar los planes a largo

plazo, cada tres meses. Otro ejemplo, si el trabajo individual producido por un

desarrollador presenta muchos errores. En ese caso una solución posible es programar

de a pares.

Redundancia: problemas críticos y difíciles deben resolverse de varias maneras

diferentes. Así, si una solución falla, las otras van a prevenir un desastre. En estos casos,

el costo de la redundancia es fácilmente pagado. Los defectos de software deben ser

buscados, encontrados y corregidos de muchas maneras, (programación en parejas, las

pruebas (testeos) automatizadas, sentarse juntos, la participación real de los clientes,

etc.) Esto es redundante, ya que, muchas veces se encuentran muchos defectos.

Fallo: no ser capaces de lograr un éxito, es un fallo. Si no se sabe cómo poner en

práctica una historia, se debe tratar de implementar de tres o cuatro maneras diferentes.

Incluso si todas fallan, se habrá aprendido mucho. ¿Es útil el fracaso?

Sí, si enseña algo. Por lo tanto, no se debe temer al fracaso. Es mejor probar algo

y fallar, en lugar de demorar demasiado tiempo para una acción, tratando de hacer lo

correcto desde el principio.

Calidad: la calidad debe ser siempre la máxima posible. Aceptar una menor calidad no

produce un ahorro, ni un desarrollo más rápido. Por el contrario, la mejora de la calidad

produce necesariamente una mejora de otras características del sistema, como la

productividad y la eficiencia. Por otra parte, la calidad no es sólo un factor económico.

Los miembros del equipo deben estar orgullosos de su trabajo porque mejora la auto-

estima del equipo y la eficacia. No se debe confundir la calidad con el perfeccionismo,

sin embargo. Si se demora la acción en búsqueda de la máxima calidad, eso no es

promover realmente la calidad. Es mucho mejor intentar y fallar, y luego perfeccionar

aquellas soluciones imperfectas encontradas.

6

Pasos de Bebé: grandes cambios, preparados en un largo período de tiempo y hechos de

una vez, son peligrosos. Para proceder de manera iterativa, es mucho mejor hacerlo en

pasos de bebé, el menor paso que se puede apreciar en la dirección correcta. Por otra

parte, pasos de bebé no significa avanzar lentamente. Un equipo capaz de avanzar con

pasos de bebé puede dar un montón de ellos en poco tiempo, volviéndose rápido y con

alta capacidad de respuesta. Una de las razones detrás de los pasos del bebé es que un

pequeño paso en la dirección equivocada ocasiona pequeños daños, mientras que un

gran paso puede dañar severamente el proyecto.

Aceptación de la responsabilidad: la responsabilidad sólo puede ser aceptada. Es fácil

ordenar a los desarrolladores "Haz esto", o "Haz aquello", pero no funciona.

Inevitablemente, se le pedirá menos de lo que podría lograrse o, probablemente, más de

lo que puede ser logrado. De todos modos, la persona que recibe la orden decidirá si

tomará la responsabilidad y aceptará la orden, o no aceptar la responsabilidad y empezar

a pasar la pelota.

ELEMENTOS FAVORABLES DE LA METODOLOGÍA Y SUS

CARACTERÍSTICAS

A continuación se nombraran algunos de los elementos favorables de la metodología

XP: Primeramente, las pruebas unitarias en el código es una práctica generalmente

alentada y reconocida como un factor clave para obtener un software de alta calidad, si a

eso se le agrega la exigencia de XP de que se hagan constantemente, durante cada etapa

de codificación, quizás en el peor de los casos pudiera parecer un exceso. De manera

semejante, la integración continua es aceptada y recomendada para evitar catástrofes

ocasionadas por defectos no detectados a tiempo.

Se hace énfasis en la simplicidad y la refabricación, es encontrado como un factor

saludable en la práctica de programación, ya que normalmente se asocia el exceso de

código con una lógica deficiente, un diseño innecesariamente complejo, problemas para

el mantenimiento del sistema y un problema para encontrar defectos que demeritan la

calidad del producto.

7

También se puede ver como positivo el hecho de que, filosóficamente, XP tiene un

enfoque “extremadamente humano”, siendo este un aspecto que el resto del campo del

software debería tratar de usar siempre. Desde el lado del programador, como ejemplos

de este enfoque humano, tenemos la premisa de la semana de cuarenta horas, el alto

valor que se le da a la comunicación y el rol protagónico que toma el programador en la

etapa de planeación.

Por el lado del cliente también se percibe el enfoque humano, ya que tenemos su

presencia constante en las instalaciones del desarrollador, el dialogo que se fomenta

entre el cliente y el resto del equipo de programación, la declaración de que “escuchar al

cliente” es una de las cuatro actividades esenciales de la programación y el hecho de

que se le otorga el mayor peso en la planeación.

Características de XP

Esta metodología ofrece la posibilidad de cambiar los requisitos en cualquier

momento de la vida de un proyecto, ya que es adaptable a estos cambios.

Se centra en potenciar las relaciones interpersonales como clave para el éxito en

desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el

aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo.

Se realiza creando grupos pequeños y medianos de construcción de software en

donde los requisitos aún son muy ambiguos, cambian rápidamente o son de alto

riesgo.

Busca la satisfacción del cliente tratando de mantener durante todo el tiempo su

confianza en el producto.

Sugiere que el lugar de trabajo sea una sala amplia, si es posible sin divisiones (en el

centro los programadores, en la periferia los equipos individuales). Una ventaja del

espacio abierto es el incremento en la comunicación y el proporcionar una agenda

dinámica en el entorno de cada proyecto.

8

Es un proceso muy orientado a la implementación, en el que se genera poca

documentación y en que la funcionalidad exacta del sistema final no se define nunca

formal y contractualmente. Es por eso que este método es más aplicable para

desarrollos internos.

ELEMENTOS EN EL PROCESO DE DESARROLLO DE XP

Historias de usuario: Se trataría de “tarjetas” donde el cliente especifica requisitos

funcionales o no.  Dichos requisitos deberán ser entendibles e implementables en

unas pocas semanas. Cada tarea, terminará siendo una tarea de programación

asignada a un desarrollador durante una iteración.

Roles XP: Los roles habituales que componen un equipo XP serían:

Programador: Escribe código y realiza pruebas unitarias.

Cliente: Obvio, encarga el trabajo, escribe las historias de usuario y prioriza

tareas.

Tester: Escribe pruebas funcionales junto al cliente y, ejecuta y difunde los

resultado de las pruebas regularmente.

Tracker: Realiza el seguimiento de las distintas iteraciones, estimaciones frente a

tiempo real, para poder afinar las estimaciones.

Coach: Es el responsable del equipo XP, se encarga de que este siga el proceso

correctamente.

Consultor: Miembro externo experto en algún tema concreto al que acudir en

caso de problemas.

Gestor: Unión entre el cliente y el equipo de desarrollo. Sus labores son de

coordinación principalmente.

9

FASES DE LA METODOLOGÍA XP

1ª Fase: Planificación del proyecto.

Historias de usuario: El primer paso de cualquier proyecto que siga la

metodología X.P es definir las historias de usuario con el cliente. Las historias de

usuario tienen la misma finalidad que los casos de uso pero con algunas diferencias:

Constan de 3 ó 4 líneas escritas por el cliente en un lenguaje no técnico sin hacer mucho

hincapié en los detalles; no se debe hablar ni de posibles algoritmos para su

implementación ni de diseños de base de datos adecuados, etc. Son usadas para estimar

tiempos de desarrollo de la parte de la aplicación que describen. También se utilizan en

la fase de pruebas, para verificar si el programa cumple con lo que especifica la historia

de usuario. Cuando llega la hora de implementar una historia de usuario, el cliente y los

10

Xtre

me

Prog

ram

min

g

PLANIFICACION

HISTORIAS DE USUARIOS

RELEASE PLANNING

ITERACIONES

VELOCIDAD DEL PROYECTO

PROGRAMACION EN PAREJA

REUNIONES DIARIAS

DISEÑO

DISEÑOS SIMPLES

GLOSARIO DE TERMINOS

RIESGOS

FUNCIONALIDAD EXTRA

TARJETAS C.R.C.

CODIFICACION

PRUEBAS TEST DE ACEPTACION

desarrolladores se reúnen para concretar y detallar lo que tiene que hacer dicha historia.

El tiempo de desarrollo ideal para una historia de usuario es entre 1 y 3 semanas. 

Release planning: .Después de tener ya definidas las historias de usuario es

necesario crear un plan de publicaciones, en inglés "Release plan", donde se indiquen

las historias de usuario que se crearán para cada versión del programa y las fechas en las

que se publicarán estas versiones. Un "Release plan" es una planificación donde los

desarrolladores y clientes establecen los tiempos de implementación ideales de las

historias de usuario, la prioridad con la que serán implementadas y las historias que

serán implementadas en cada versión del programa. Después de un "Release plan"

tienen que estar claros estos cuatro factores: los objetivos que se deben cumplir (que son

principalmente las historias que se deben desarrollar en cada versión), el tiempo que

tardarán en desarrollarse y publicarse las versiones del programa, el número de personas

que trabajarán en el desarrollo y cómo se evaluará la calidad del trabajo realizado.

Iteraciones Todo proyecto que siga la metodología XP se ha de dividir en

iteraciones de aproximadamente 3 semanas de duración. Al comienzo de cada iteración

los clientes deben seleccionar las historias de usuario definidas en el "Release planning"

que serán implementadas. También se seleccionan las historias de usuario que no

pasaron el test de aceptación que se realizó al terminar la iteración anterior. Estas

historias de usuario son divididas en tareas de entre 1 y 3 días de duración que se

asignarán a los programadores. 

Velocidad del proyecto: La velocidad del proyecto es una medida que

representa la rapidez con la que se desarrolla el proyecto; estimarla es muy sencillo,

basta con contar el número de historias de usuario que se pueden implementar en una

iteración; de esta forma, se sabrá el cupo de historias que se pueden desarrollar en las

distintas iteraciones. Usando la velocidad del proyecto controlaremos que todas las

tareas se puedan desarrollar en el tiempo del que dispone la iteración. Es conveniente

reevaluar esta medida cada 3 ó 4 iteraciones y si se aprecia que no es adecuada hay que

negociar con el cliente un nuevo "Release Plan".

Programación en pareja: La metodología XP aconseja la programación en

parejas pues incrementa la productividad y la calidad del software desarrollado. El

11

trabajo en pareja involucra a dos programadores trabajando en el mismo equipo;

mientras uno codifica haciendo hincapié en la calidad de la función o método que está

implementando, el otro analiza si ese método o función es adecuado y está bien

diseñado. De esta forma se consigue un código y diseño con gran calidad. 

....... Reuniones diarias. Es necesario que los desarrolladores se reúnan diariamente y

expongan sus problemas, soluciones e ideas de forma conjunta. Las reuniones tienen

que ser fluidas y todo el mundo tiene que tener voz y voto. 

2ª Fase: Diseño.

....... Diseños simples: La metodología XP sugiere que hay que conseguir diseños

simples y sencillos. Hay que procurar hacerlo todo lo menos complicado posible para

conseguir un diseño fácilmente entendible e impleméntable que a la larga costará menos

tiempo y esfuerzo desarrollar. 

....... Glosarios de términos: Usar glosarios de términos y un 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. Sólo el 10% de la misma es utilizada,

lo que implica que el desarrollo de funcionalidad extra es un desperdicio de tiempo y

recursos. 

....... Refactorizar: es mejorar y modificar la estructura y codificación de códigos ya

creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo estos códigos

para procurar optimizar su funcionamiento. Es muy común rehusar códigos ya creados

que contienen funcionalidades que no serán usadas y diseños obsoletos. Esto es un error

12

porque puede generar código completamente inestable y muy mal diseñado; por este

motivo, es necesario refactorizar cuando se va a utilizar código ya creado. 

.......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.

......

.Las tarjetas C.R.C representan objetos; la clase a la que pertenece el objeto se

puede escribir en la parte de arriba de la tarjeta, en una columna a la izquierda se pueden

escribir las responsabilidades u objetivos que debe cumplir el objeto y a la derecha, las

clases que colaboran con cada responsabilidad. 

3ª Fase: Codificación.

.......Como ya se dijo en la introducción, el cliente es una parte más del equipo de

desarrollo; su presencia es indispensable en las distintas fases de XP. A la hora de

codificar una historia de usuario su presencia es aún más necesaria. No olvidemos que

los clientes son los que crean las historias de usuario y negocian los tiempos en los que

serán implementadas. Antes del desarrollo de cada historia de usuario el cliente debe

especificar detalladamente lo que ésta hará y también tendrá que estar presente cuando

se realicen los test que verifiquen que la historia implementada cumple la funcionalidad

especificada. 

.......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. Crear estos test antes nos ayuda a saber qué es

exactamente lo que tiene que hacer el código a implementar y sabremos que una vez

implementado pasará dichos test sin problemas ya que dicho código ha sido diseñado

para ese fin. Se puede dividir la funcionalidad que debe cumplir una tarea a programar

en pequeñas unidades, de esta forma se crearán primero los test para cada unidad y a

13

continuación se desarrollará dicha unidad, así poco a poco conseguiremos un desarrollo

que cumpla todos los requisitos especificados. 

.......Como ya se comentó anteriormente, XP opta por la programación en pareja ya que

permite un código más eficiente y con una gran calidad. 

.......XP sugiere un modelo de trabajo usando repositorios de código dónde las parejas

de programadores publican cada pocas horas sus códigos implementados y corregidos

junto a los test que deben pasar. De esta forma el resto de programadores que necesiten

códigos ajenos trabajarán siempre con las últimas versiones. Para mantener un código

consistente, publicar un código en un repositorio es una acción exclusiva para cada

pareja de programadores. 

.......XP también propone un modelo de desarrollo colectivo en el que todos los

programadores están implicados en todas las tareas; cualquiera puede modificar o

ampliar una clase o método de otro programador si es necesario y subirla al repositorio

de código. El permitir al resto de los programadores modificar códigos que no son suyos

no supone ningún riesgo ya que para que un código pueda ser publicado en el

repositorio tiene que pasar los test de funcionamiento definidos para el mismo. 

.......La optimización del código siempre se debe dejar para el final. Hay que hacer que

funcione y que sea correcto, más tarde se puede optimizar. 

.......XP afirma que la mayoría de los proyectos que necesiten más tiempo extra que el

planificado para ser finalizados no podrán ser terminados a tiempo se haga lo que se

haga, aunque se añadan más desarrolladores y se incrementen los recursos. La solución

que plantea XP es realizar un nuevo "Release plan" para concretar los nuevos tiempos

de publicación y de velocidad del proyecto. 

A la hora de codificar no seguimos la regla de XP 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. 

14

4ª Fase: Pruebas.

.......Uno de los pilares de la metodología XP es el uso de test para comprobar el

funcionamiento de los códigos que vayamos implementando. 

.......El uso de los test en XP es el siguiente: 

Se deben crear las aplicaciones que realizarán los test con un entorno de desarrollo

específico para test. 

.......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. 

.......Como se comentó anteriormente los distintos test se deben subir al repositorio de

código acompañados del código que verifican. Ningún código puede ser publicado en el

repositorio sin que haya pasado su test de funcionamiento, de esta forma, aseguramos el

uso colectivo del código (explicado en el apartado anterior).

 

.......El uso de los test es adecuado para observar la refactorización. Los test permiten

verificar que un cambio en la estructura de un código no tiene porqué cambiar su

funcionamiento. 

.......Test de aceptación. Los test mencionados anteriormente sirven para evaluar las

distintas tareas en las que ha sido dividida una historia de usuario. Para asegurar el

funcionamiento final de una determinada historia de usuario se deben crear "Test de

aceptación"; estos test son creados y usados por los clientes para comprobar que las

distintas historias de usuario cumplen su cometido. 

15

.......Al ser las distintas funcionalidades de nuestra aplicación no demasiado extensas, no

se harán test que analicen partes de las mismas, sino que las pruebas se realizarán para

las funcionalidades generales que debe cumplir el programa especificado en la

descripción de requisitos.

CICLO DE VIDA, DEFINICION Y CARACTERISTICAS PARA UN

PROYECTO XP

El ciclo de vida ideal de XP consiste de seis fases:

I. Exploración

Inicialmente en este ciclo, los clientes realizan un planteamiento a grandes rasgos

de las historias de usuario que son de interés para la primera entrega del producto. Al

mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y

prácticas que se utilizarán en el proyecto. Se prueba la tecnología y se exploran las

posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de

exploración toma de pocas semanas a pocos meses, dependiendo del tamaño y

familiaridad que tengan los programadores con la tecnología.

II. Planificación de la Entrega (Release)

En esta fase el cliente establece la prioridad de cada historia de usuario, y

correspondientemente, los programadores realizan una estimación del esfuerzo

necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera

entrega y se determina un cronograma en conjunto con el cliente. Una entrega debería

obtenerse en no más de tres meses. Esta fase dura unos pocos días. Las estimaciones de

esfuerzo asociado a la implementación de las historias la establecen los programadores

utilizando como medida el punto. Un punto, equivale a una semana ideal de

programación. Las historias generalmente valen de 1 a 3 puntos. Por otra parte, el

equipo de desarrollo mantiene un registro de la “velocidad” de desarrollo, establecida en

puntos por iteración, basándose principalmente en la suma de puntos correspondientes a

las historias de usuario que fueron terminadas en la última iteración. La planificación se

16

puede realizar basándose en el tiempo o el alcance. La velocidad del proyecto es

utilizada para establecer cuántas historias se pueden implementar antes de una fecha

determinada o cuánto tiempo tomará implementar un conjunto de historias. Al planificar

por tiempo, se multiplica el número de iteraciones por la velocidad del proyecto,

determinándose cuántos puntos se pueden completar. Al planificar según alcance del

sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la

velocidad del proyecto, obteniendo el número de iteraciones necesarias para su

implementación.

II. Iteraciones

Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan

de Entrega está compuesto por iteraciones de no más de tres semanas. En la primera

iteración se puede intentar establecer una arquitectura del sistema que pueda ser

utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen

la creación de esta arquitectura, sin embargo, esto no siempre es posible ya que es el

cliente quien decide qué historias se implementarán en cada iteración (para maximizar

el valor de negocio). Al final de la última iteración el sistema estará listo para entrar en

producción. Los elementos que deben tomarse en cuenta durante la elaboración del Plan

de la Iteración son: historias de usuario no abordadas, velocidad del proyecto, pruebas

de aceptación no superadas en la iteración anterior y tareas no terminadas en la iteración

anterior. Todo el trabajo de la iteración es expresado en tareas de programación, cada

una de ellas es asignada a un programador como responsable, pero llevadas a cabo por

parejas de programadores.

IV. 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. Al mismo

tiempo, se deben tomar decisiones sobre la inclusión de nuevas características a la

versión actual, debido a cambios durante esta fase. Es posible que se rebaje el tiempo

que toma cada iteración, de tres a una semana. Las ideas que han sido propuestas y las

sugerencias son documentadas para su posterior implementación (por ejemplo, durante

la fase de mantenimiento).

17

V. Mantenimiento

Mientras la primera versión se encuentra en producción, el proyecto XP debe

mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas

iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De esta

forma, la velocidad de desarrollo puede bajar después de la puesta del sistema en

producción. La fase de mantenimiento puede requerir nuevo personal dentro del equipo

y cambios en su estructura.

VI. Muerte del Proyecto

Esta fase se cumple cuando el cliente no tiene más opciones para ser incluidas en

el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos

como rendimiento y confiabilidad del sistema. Se crea la documentación final del

sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto también

ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no

hay presupuesto para mantenerlo.

18

CONCLUSIÓN

Extreme Programming es una metodología ligera de desarrollo de software que

se basa en la simplicidad, la comunicación y la realimentación o reutilización del código

desarrollado; desarrollada por Kent Beck.

Esta metodología trata de dar al cliente el software que él necesita y cuando lo

necesita. En donde los jefes de proyectos, clientes y programadores forman parte del

equipo y están involucrados en el desarrollo del software. XP define cuatro variables

para proyectos de software: coste, tiempo, calidad y ámbito. En las cuales sólo tres

puedan ser establecidas por las fuerzas externas (jefes de proyecto y clientes), mientras

que el valor de la cuarta variable debe ser establecido por los programadores en función

de las otras tres. El proceso de desarrollo de las pruebas de ayuda al cliente a clarificar y

concretar la funcionalidad de la historia de uso y favorece la comunicación entre el

cliente y el equipo de desarrollo.

XP se adapta a las necesidades del cliente y dónde la aplicación se va evaluando

en periodos de tiempos cortos. También una de las cualidades más destacables es su

sencillez, tanto en su aprendizaje como en su aplicación. XP está diseñada para el

desarrollo de aplicaciones que requieran un grupo de programadores pequeño, donde la

comunicación sea más factible que en grupos de desarrollo grandes. La comunicación es

un punto importante y debe realizarse entre los programadores, los jefes de proyecto y

los clientes donde el entorno físico sea un ambiente de armonía que permita una buena

comunicación y colaboración entre los miembros del equipo durante el tiempo de

desarrollo del proyecto, alguna resistencia por parte del cliente o del equipo de

desarrollo hacia las prácticas y principios puede conducir al fracaso total, ya que el

clima de trabajo, la colaboración y la relación son punto claves para llegar al éxito.

19

REFERENCIAS BIBLIOGRAFICAS

Extreme Programming (XP): un nuevo método de desarrollo de softwareCésar F. Acebal, Juan M. Cueva LovelleDepto. de Informática, Área de Lenguajes y Sistemas Informáticos,Universidad de OviedoNOVATICA, Marzo Abril 2002, pp 8-12

Ingeniería de Software orientada a objetos con UML Java e InternetAlfredo WeitzenfeldThomson editores, 2005ISBN 970-686-190-4

Programación extrema (Extreme Programming) (2008, 18 de Junio) [en línea]. Consultado el 05 de Mayo de 2012 en http://www.geronet.com.ar/?p=83

Desarrollo de software. Programación extrema (eXtreme Programming: XP) (2011, 20 de Abril) [en línea]. Consultado el 05 de Mayo de 2012 en http://jummp.wordpress.com/2011/04/20/desarrollo-de-software-programacion-extrema-extreme-programming-xp/

Extreme Programming (2009, 15 de Octubrel) [en línea]. Consultado el 05 de Mayo de 2012 en http://carlossantos.wordpress.com/category/programacion-extrema/

20