EXTREME PROGRAMMING (XP)

NDICE

PP. INTRODUCCION DEFINICIN DE XP COMO UNA METODOLOGA GIL, HISTORIA Y PRINCIPIOS BSICOS. Marco histrico de la Programacin Extrema Principios bsicos de la Programacin Extrema ELEMENTOS FAVORABLES DE LA METODOLOGA Y SUS CARACTERSTICAS Caractersticas de XP ELEMENTOS EN EL PROCESO DE DESARROLLO DE XP FASES DE LA METODOLOGA XP 1 Fase: Planificacin del proyecto. 2 Fase: Diseo. 3 Fase: Codificacin. 4 Fase: Pruebas. CICLO DE VIDA, DEFINICION Y CARACTERISTICAS PARA UN PROYECTO XP CONCLUSIN REFERENCIAS BIBLIOGRAFICAS 16 19 20 7 8 9 10 10 12 13 15 2 3 4 1

INTRODUCCIN

Las metodologas giles de desarrollo de software han despertado inters en los ltimos aos debido a que proponen simplicidad y velocidad para crear sistemas. Los programadores se concentran solamente en aquellas funciones que se necesitan inmediatamente, entregndolas al cliente lo antes posible, obteniendo retroalimentacin constante y reaccionando rpidamente a los cambios en el negocio y la tecnologa. Se han hecho esfuerzos por analizar y clasificar stas metodologas, las cuales han aparecido en buen nmero y aparentemente no pararan de hacerlo en un futuro cercano.

Entre los ejemplos ms conocidos de estas metodologas 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 Programacin Extrema ha sido entre todas las metodologas giles nombradas anteriormente una de las ms exitosas y controversiales de los tiempos recientes. El presente trabajo presenta un resumen de las caractersticas ms destacables de esta metodologa, incluyendo las fases de su ciclo de vida, elementos que intervienen en la metodologa y dems puntos de inters que definen a esta metodologa.

DEFINICIN DE XP COMO UNA METODOLOGA GIL, HISTORIA Y PRINCIPIOS BSICOS. XP es una metodologa ligera o gil para el desarrollo de software eficiente y altamente efectivo. Existe una gran controversia en la definicin de la programacin extrema, esta viene de la mano de la palabra metodologa. Muchos consideran que no puede ser denominada metodologa porque elimina toda la parte burocrtica anteriormente asociada a las metodologas para el desarrollo de software (documentacin, diseos varios, y papeleos excesivos). Sin embargo, obviar que nos proporciona una gua o un proceso repetitivo para el desarrollo de software sera obviar lo que en s es. As pues, se puede tomar como bueno el consenso de denominarla como metodologa ligera (o gil), debido a que elimina la pesada carga del papeleo a los desarrolladores.

Bsicamente, la programacin extrema, busca dos objetivos claramente: hacer un software bien (con calidad) y de la forma ms rpida posible. De hecho estos son los objetivos fundamentales de cualquier metodologa aplicada al desarrollo de software y a cualquier otra rea en general. A pesar de esto, con las metodologas de desarrollo actuales, el 70% de los proyectos fracasan y aproximadamente, tambin, el 70% de los fallos no se deben a cuestiones tcnicas, son debidos a cambios en la gestin o problemas de comunicacin.

Luego de analizado el problema, podemos buscar y ven en la programacin extrema la solucin, o al menos un acercamiento. La programacin extrema centra su atencin en la produccin de software con una fuerte arquitectura, intentando sacar productos al mercado rpidamente, con gran calidad y motivando al equipo de trabajo para seguir mejorando esta tendencia.

Como metodologa, la programacin 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.

Marco histrico de la Programacin Extrema

Esta metodologa esta fundamentada en un paradigma de la programacin, los lenguajes orientados a objetos y en las metodologas que surgieron para ayudar en el desarrollo de proyectos que utilizan este paradigma. Las metodologas anteriores a XP, como ya hemos dicho, eran metodologas muy pesadas, debido a las necesidades de documentacin y de generacin de una serie de elementos que realmente no prestan utilidad.

La programacin extrema es una metodologa reciente (tiene alrededor de 14 aos) en el desarrollo de software. Su filosofa es satisfacer las necesidades del cliente, por eso lo integra como una parte ms del equipo de desarrollo.

La programacin extrema surgi gracias a Kent Beck. Kent, haba trabajado, sobre todo, con Smalltalk, el primer lenguaje orientado a objetos que realmente se hizo popular.

Siendo un amante de la orientacin a objetos, Kent trabaj junto con Ward Cunnigham intentando encontrar un acercamiento al desarrollo de software que permitiese hacer las cosas ms simples y de forma ms eficiente.

Debido a sus investigaciones, Kent entr a formar parte en un proyecto de DaimlerChrysler, que se denomin C3 (Chrysler Comprehensive Compensation), dnde, debido a las necesidades del propio proyecto, se vio obligado a aplicar sus investigaciones y a ponerlas en prctica, surgiendo lo que actualmente se conoce como Extreme Programming. El denominar a esta metodologa Extreme Programming surge por el nfasis de sta en tener unas buenas prcticas y seguirlas constantemente, pero seguirlas de una forma extrema, es decir, los principios de XP deben ser seguidos sin alejarse de ellos en ningn momento, y cualquier otra prctica ser ignorada.

Fue inicialmente creada para el desarrollo de aplicaciones dnde el cliente no sabe muy bien lo que quiere, lo que provoca un cambio constante en los requisitos que
3

debe cumplir la aplicacin. Por este motivo es necesaria una metodologa gil como XP que se adapta a las necesidades del cliente y dnde la aplicacin se va revaluando en periodos cortos de tiempo.

XP est diseada para el desarrollo de aplicaciones que requieran un grupo de programadores pequeo, dnde la comunicacin sea ms factible que en grupos de desarrollo grandes. La comunicacin es un punto importante y debe realizarse entre los programadores, los jefes de proyecto y los clientes.

Principios bsicos de la Programacin Extrema

XP propone una serie de principios que dirigen la metodologa y los cuales se describen brevemente a continuacin:

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.

Economa: Al producir software, tambin se debe producir valor para el negocio. Dos aspectos de la economa son la clave para XP: valor actual y el valor de las opciones. La primera dice que una moneda hoy, vale ms que una moneda maana, por lo que el desarrollo de software ms temprano, hace ganar dinero y hacerlo ms tarde hace gastar dinero, cuanto ms pronto sea, mayor ser la ganancia que dar.

Beneficio mutuo: cada actividad debe beneficiar a todas las personas y organizaciones interesadas. Este es, quizs, el principio ms importante de XP, y el ms difcil de cumplir. Siempre hay soluciones fciles para cualquier problema, donde algunos ganan y otros pierden. A menudo, estas soluciones son atajos tentadores. Sin embargo, son siempre una prdida 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

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

Mejora: la mejora continua es la clave para XP. La perfeccin no existe, pero debe esforzarse continuamente por la perfeccin. En la prctica, en cada iteracin del sistema se mejora en calidad y funcionalidades, utilizando la informacin (feedback) del cliente, a partir de pruebas automatizadas y del propio equipo.

Diversidad: Es muy cmodo 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.

Reflexin: un equipo eficaz no se limita a hacer su trabajo. Se preguntan cmo estn trabajando, y por qu estn trabajando de esa manera. Tienen que analizar las razones del xito o el fracaso sin ocultar los errores, hacerlas explcitas y tratando de aprender de ellas. Durante iteraciones trimestral y semanales, se debe tomar tiempo para reflexionar acerca de cmo se est ejecutando el proyecto, y cules 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 prcticas de XP suponen un flujo continuo de actividades, no una secuencia de fases diferentes, con el lanzamiento del software slo despus de la ltima. Slo el flujo continuo permite la retroalimentacin (feedback) para asegurar que el sistema est evolucionando hacia la direccin 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 solucin sera el uso de ciclos de planificacin 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 solucin posible es programar de a pares.

Redundancia: problemas crticos y difciles deben resolverse de varias maneras diferentes. As, si una solucin falla, las otras van a prevenir un desastre. En estos casos, el costo de la redundancia es fcilmente pagado. Los defectos de software deben ser buscados, encontrados y corregidos de muchas maneras, (programacin en parejas, las pruebas (testeos) automatizadas, sentarse juntos, la participacin 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 cmo poner en prctica 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 ensea algo. Por lo tanto, no se debe temer al fracaso. Es mejor probar algo y fallar, en lugar de demorar demasiado tiempo para una accin, tratando de hacer lo correcto desde el principio.

Calidad: la calidad debe ser siempre la mxima posible. Aceptar una menor calidad no produce un ahorro, ni un desarrollo ms rpido. Por el contrario, la mejora de la calidad produce necesariamente una mejora de otras caractersticas del sistema, como la productividad y la eficiencia. Por otra parte, la calidad no es slo un factor econmico. Los miembros del equipo deben estar orgullosos de su trabajo porque mejora la autoestima del equipo y la eficacia. No se debe confundir la calidad con el perfeccionismo, sin embargo. Si se demora la accin en bsqueda de la mxima calidad, eso no es promover realmente la calidad. Es mucho mejor intentar y fallar, y luego perfeccionar aquellas soluciones imperfectas encontradas.

Pasos de Beb: grandes cambios, preparados en un largo perodo 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 direccin correcta. Por otra parte, pasos de beb no significa avanzar lentamente. Un equipo capaz de avanzar con pasos de beb puede dar un montn de ellos en poco tiempo, volvindose rpido y con alta capacidad de respuesta. Una de las razones detrs de los pasos del beb es que un pequeo paso en la direccin equivocada ocasiona pequeos daos, mientras que un gran paso puede daar severamente el proyecto.

Aceptacin de la responsabilidad: la responsabilidad slo puede ser aceptada. Es fcil ordenar a los desarrolladores "Haz esto", o "Haz aquello", pero no funciona. Inevitablemente, se le pedir menos de lo que podra lograrse o, probablemente, ms 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 METODOLOGA Y SUS CARACTERSTICAS

A continuacin se nombraran algunos de los elementos favorables de la metodologa XP: Primeramente, las pruebas unitarias en el cdigo es una prctica 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 codificacin, quizs en el peor de los casos pudiera parecer un exceso. De manera semejante, la integracin continua es aceptada y recomendada para evitar catstrofes ocasionadas por defectos no detectados a tiempo.

Se hace nfasis en la simplicidad y la refabricacin, es encontrado como un factor saludable en la prctica de programacin, ya que normalmente se asocia el exceso de cdigo con una lgica deficiente, un diseo innecesariamente complejo, problemas para el mantenimiento del sistema y un problema para encontrar defectos que demeritan la calidad del producto.

Tambin se puede ver como positivo el hecho de que, filosficamente, XP tiene un enfoque extremadamente humano, siendo este un aspecto que el resto del campo del software debera 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 comunicacin y el rol protagnico que toma el programador en la etapa de planeacin.

Por el lado del cliente tambin 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 programacin, la declaracin de que escuchar al cliente es una de las cuatro actividades esenciales de la programacin y el hecho de que se le otorga el mayor peso en la planeacin.

Caractersticas de XP Esta metodologa 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, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. Se realiza creando grupos pequeos y medianos de construccin de software en donde los requisitos an son muy ambiguos, cambian rpidamente o son de alto riesgo. Busca la satisfaccin 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 comunicacin y el proporcionar una agenda dinmica en el entorno de cada proyecto.

 Es un proceso muy orientado a la implementacin, en el que se genera poca documentacin y en que la funcionalidad exacta del sistema final no se define nunca formal y contractualmente. Es por eso que este mtodo es ms aplicable para desarrollos internos.

ELEMENTOS EN EL PROCESO DE DESARROLLO DE XP Historias de usuario: Se tratara de tarjetas donde el cliente especifica requisitos funcionales o no. Dichos requisitos debern ser entendibles e implementables en unas pocas semanas. Cada tarea, terminar siendo una tarea de programacin asignada a un desarrollador durante una iteracin. Roles XP: Los roles habituales que componen un equipo XP seran: Programador: Escribe cdigo 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 algn tema concreto al que acudir en caso de problemas. Gestor: Unin entre el cliente y el equipo de desarrollo. Sus labores son de coordinacin principalmente.

FASES DE LA METODOLOGA XP

HISTORIAS DE USUARIOS RELEASE PLANNING ITERACIONES PLANIFICACION VELOCIDAD DEL PROYECTO PROGRAMACION EN PAREJA

Xtreme Programming

REUNIONES DIARIAS DISEOS SIMPLES GLOSARIO DE TERMINOS DISEO CODIFICACION RIESGOS FUNCIONALIDAD EXTRA TARJETAS C.R.C. PRUEBAS TEST DE ACEPTACION

1 Fase: Planificacin del proyecto.

Historias de usuario: El primer paso de cualquier proyecto que siga la metodologa 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 lneas escritas por el cliente en un lenguaje no tcnico sin hacer mucho hincapi en los detalles; no se debe hablar ni de posibles algoritmos para su implementacin ni de diseos de base de datos adecuados, etc. Son usadas para estimar tiempos de desarrollo de la parte de la aplicacin que describen. Tambin 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

desarrolladores se renen 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: .Despus de tener ya definidas las historias de usuario es necesario crear un plan de publicaciones, en ingls "Release plan", donde se indiquen las historias de usuario que se crearn para cada versin del programa y las fechas en las que se publicarn estas versiones. Un "Release plan" es una planificacin donde los desarrolladores y clientes establecen los tiempos de implementacin ideales de las historias de usuario, la prioridad con la que sern implementadas y las historias que sern implementadas en cada versin del programa. Despus 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 versin), el tiempo que tardarn en desarrollarse y publicarse las versiones del programa, el nmero de personas que trabajarn en el desarrollo y cmo se evaluar la calidad del trabajo realizado.

Iteraciones Todo proyecto que siga la metodologa XP se ha de dividir en iteraciones de aproximadamente 3 semanas de duracin. Al comienzo de cada iteracin los clientes deben seleccionar las historias de usuario definidas en el "Release planning" que sern implementadas. Tambin se seleccionan las historias de usuario que no pasaron el test de aceptacin que se realiz al terminar la iteracin anterior. Estas historias de usuario son divididas en tareas de entre 1 y 3 das de duracin que se asignarn 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 nmero de historias de usuario que se pueden implementar en una iteracin; 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 iteracin. 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".

Programacin en pareja: La metodologa XP aconseja la programacin 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 funcin o mtodo que est implementando, el otro analiza si ese mtodo o funcin es adecuado y est bien diseado. De esta forma se consigue un cdigo y diseo con gran calidad.

....... Reuniones diarias. Es necesario que los desarrolladores se renan 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: Diseo.

....... Diseos simples: La metodologa XP sugiere que hay que conseguir diseos simples y sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir un diseo fcilmente entendible e implemntable que a la larga costar menos tiempo y esfuerzo desarrollar.

....... Glosarios de trminos: Usar glosarios de trminos y un correcta especificacin de los nombres de mtodos y clases ayudar a comprender el diseo y facilitar sus posteriores ampliaciones y la reutilizacin del cdigo.

....... Riesgos: Si surgen problemas potenciales durante el diseo, X.P sugiere utilizar una pareja de desarrolladores para que investiguen y reduzcan al mximo el riesgo que supone ese problema.

....... Funcionalidad extra: Nunca se debe aadir funcionalidad extra al programa aunque se piense que en un futuro ser utilizada. Slo 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 codificacin de cdigos ya creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo estos cdigos para procurar optimizar su funcionamiento. Es muy comn rehusar cdigos ya creados que contienen funcionalidades que no sern usadas y diseos obsoletos. Esto es un error

12

porque puede generar cdigo completamente inestable y muy mal diseado; por este motivo, es necesario refactorizar cuando se va a utilizar cdigo 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 olvidndose de los malos hbitos de la programacin procedural clsica. ...... .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: Codificacin.

.......Como ya se dijo en la introduccin, el cliente es una parte ms 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 an ms necesaria. No olvidemos que los clientes son los que crean las historias de usuario y negocian los tiempos en los que sern implementadas. Antes del desarrollo de cada historia de usuario el cliente debe especificar detalladamente lo que sta har y tambin tendr que estar presente cuando se realicen los test que verifiquen que la historia implementada cumple la funcionalidad especificada.

.......La codificacin debe hacerse ateniendo a estndares de codificacin ya creados. Programar bajo estndares mantiene el cdigo consistente y facilita su comprensin y escalabilidad.

.......Crear test que prueben el funcionamiento de los distintos cdigos implementados nos ayudar a desarrollar dicho cdigo. Crear estos test antes nos ayuda a saber qu es exactamente lo que tiene que hacer el cdigo a implementar y sabremos que una vez implementado pasar dichos test sin problemas ya que dicho cdigo ha sido diseado para ese fin. Se puede dividir la funcionalidad que debe cumplir una tarea a programar en pequeas unidades, de esta forma se crearn primero los test para cada unidad y a

13

continuacin 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 programacin en pareja ya que permite un cdigo ms eficiente y con una gran calidad.

.......XP sugiere un modelo de trabajo usando repositorios de cdigo dnde las parejas de programadores publican cada pocas horas sus cdigos implementados y corregidos junto a los test que deben pasar. De esta forma el resto de programadores que necesiten cdigos ajenos trabajarn siempre con las ltimas versiones. Para mantener un cdigo consistente, publicar un cdigo en un repositorio es una accin exclusiva para cada pareja de programadores.

.......XP tambin propone un modelo de desarrollo colectivo en el que todos los programadores estn implicados en todas las tareas; cualquiera puede modificar o ampliar una clase o mtodo de otro programador si es necesario y subirla al repositorio de cdigo. El permitir al resto de los programadores modificar cdigos que no son suyos no supone ningn riesgo ya que para que un cdigo pueda ser publicado en el repositorio tiene que pasar los test de funcionamiento definidos para el mismo.

.......La optimizacin del cdigo siempre se debe dejar para el final. Hay que hacer que funcione y que sea correcto, ms tarde se puede optimizar.

.......XP afirma que la mayora de los proyectos que necesiten ms tiempo extra que el planificado para ser finalizados no podrn ser terminados a tiempo se haga lo que se haga, aunque se aadan ms desarrolladores y se incrementen los recursos. La solucin que plantea XP es realizar un nuevo "Release plan" para concretar los nuevos tiempos de publicacin 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 especificacin 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 metodologa XP es el uso de test para comprobar el funcionamiento de los cdigos que vayamos implementando.

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

Se deben crear las aplicaciones que realizarn los test con un entorno de desarrollo especfico para test.

.......Hay que someter a tests las distintas clases del sistema omitiendo los mtodos ms triviales.

.......Se deben crear los test que pasarn los cdigos antes de implementarlos; en el apartado anterior se explic la importancia de crear antes los test que el cdigo.

.......Un punto importante es crear test que no tengan ninguna dependencia del cdigo que en un futuro evaluar. Hay que crear los test abstrayndose del futuro cdigo, de esta forma aseguraremos la independencia del test respecto al cdigo que evala.

.......Como se coment anteriormente los distintos test se deben subir al repositorio de cdigo acompaados del cdigo que verifican. Ningn cdigo puede ser publicado en el repositorio sin que haya pasado su test de funcionamiento, de esta forma, aseguramos el uso colectivo del cdigo (explicado en el apartado anterior).

.......El uso de los test es adecuado para observar la refactorizacin. Los test permiten verificar que un cambio en la estructura de un cdigo no tiene porqu cambiar su funcionamiento.

.......Test de aceptacin. 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 aceptacin"; 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 aplicacin no demasiado extensas, no se harn test que analicen partes de las mismas, sino que las pruebas se realizarn para las funcionalidades generales que debe cumplir el programa especificado en la descripcin de requisitos.

CICLO DE VIDA, DEFINICION Y CARACTERISTICAS PARA UN PROYECTO XP

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

I. Exploracin

Inicialmente en este ciclo, los clientes realizan un planteamiento a grandes rasgos de las historias de usuario que son de inters para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologas y prcticas que se utilizarn en el proyecto. Se prueba la tecnologa y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploracin toma de pocas semanas a pocos meses, dependiendo del tamao y familiaridad que tengan los programadores con la tecnologa.

II. Planificacin de la Entrega (Release)

En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimacin 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 debera obtenerse en no ms de tres meses. Esta fase dura unos pocos das. Las estimaciones de esfuerzo asociado a la implementacin de las historias la establecen los programadores utilizando como medida el punto. Un punto, equivale a una semana ideal de programacin. 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 iteracin, basndose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la ltima iteracin. La planificacin se
16

puede realizar basndose en el tiempo o el alcance. La velocidad del proyecto es utilizada para establecer cuntas historias se pueden implementar antes de una fecha determinada o cunto tiempo tomar implementar un conjunto de historias. Al planificar por tiempo, se multiplica el nmero de iteraciones por la velocidad del proyecto, determinndose cuntos puntos se pueden completar. Al planificar segn alcance del sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo el nmero de iteraciones necesarias para su implementacin.

II.

Iteraciones

Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega est compuesto por iteraciones de no ms de tres semanas. En la primera iteracin 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 creacin de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qu historias se implementarn en cada iteracin (para maximizar el valor de negocio). Al final de la ltima iteracin el sistema estar listo para entrar en produccin. Los elementos que deben tomarse en cuenta durante la elaboracin del Plan de la Iteracin son: historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptacin no superadas en la iteracin anterior y tareas no terminadas en la iteracin anterior. Todo el trabajo de la iteracin es expresado en tareas de programacin, cada una de ellas es asignada a un programador como responsable, pero llevadas a cabo por parejas de programadores.

IV. Produccin

La fase de produccin 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 inclusin de nuevas caractersticas a la versin actual, debido a cambios durante esta fase. Es posible que se rebaje el tiempo que toma cada iteracin, de tres a una semana. Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementacin (por ejemplo, durante la fase de mantenimiento).
17

V. Mantenimiento

Mientras la primera versin se encuentra en produccin, 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 despus de la puesta del sistema en produccin. 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 ms 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 documentacin final del sistema y no se realizan ms cambios en la arquitectura. La muerte del proyecto tambin ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.

18

CONCLUSIN

Extreme Programming es una metodologa ligera de desarrollo de software que se basa en la simplicidad, la comunicacin y la realimentacin o reutilizacin del cdigo desarrollado; desarrollada por Kent Beck.

Esta metodologa 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 estn involucrados en el desarrollo del software. XP define cuatro variables para proyectos de software: coste, tiempo, calidad y mbito. En las cuales slo 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 funcin 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 comunicacin entre el cliente y el equipo de desarrollo.

XP se adapta a las necesidades del cliente y dnde la aplicacin se va evaluando en periodos de tiempos cortos. Tambin una de las cualidades ms destacables es su sencillez, tanto en su aprendizaje como en su aplicacin. XP est diseada para el desarrollo de aplicaciones que requieran un grupo de programadores pequeo, donde la comunicacin sea ms factible que en grupos de desarrollo grandes. La comunicacin es un punto importante y debe realizarse entre los programadores, los jefes de proyecto y los clientes donde el entorno fsico sea un ambiente de armona que permita una buena comunicacin y colaboracin 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 prcticas y principios puede conducir al fracaso total, ya que el clima de trabajo, la colaboracin y la relacin son punto claves para llegar al xito.

19

REFERENCIAS BIBLIOGRAFICAS

Extreme Programming (XP): un nuevo mtodo de desarrollo de software Csar F. Acebal, Juan M. Cueva Lovelle Depto. de Informtica, rea de Lenguajes y Sistemas Informticos, Universidad de Oviedo NOVATICA, Marzo Abril 2002, pp 8-12

Ingeniera de Software orientada a objetos con UML Java e Internet Alfredo Weitzenfeld Thomson editores, 2005 ISBN 970-686-190-4 Programacin extrema (Extreme Programming) (2008, 18 de Junio) [en lnea]. Consultado el 05 de Mayo de 2012 en http://www.geronet.com.ar/?p=83 Desarrollo de software. Programacin extrema (eXtreme Programming: XP) (2011, 20 de Abril) [en lnea]. Consultado el 05 de Mayo de 2012 en http://jummp.wordpress.com/2011/04/20/desarrollo-de-software-programacionextrema-extreme-programming-xp/ Extreme Programming (2009, 15 de Octubrel) [en lnea]. Consultado el 05 de Mayo de 2012 en http://carlossantos.wordpress.com/category/programacion-extrema/

20