UNIVERSIDAD NACIONAL DE TRUJILLOFACULTAD DE INGENIERAE.A.P INGENIERIA DE SISTEMASSede Valle Jequetepeque

METODLOGIAS GILES PARA EL DESARROLLO DE SOFTWARE: PROGRAMACIN EXTREMA XP (EXTREME PROGRAMMING)

AUTORES:CEDRON FLORIAN, Alessandra MirellaCHOLAN CABANILLAS, Maguin AlfredoDAVILA VICENCIO, Mara RaysaNORIEGA CHAFLOQUE, Cesar GustavoTERAN CRUZ, Juan Gerardo

DOCENTE:Ing. Mg. JUAN PEDRO SANTOS FERNNDEZ

GUADALUPE- PERCedrn, Choln, Dvila, Noriega & TernUNIVERSIDAD NACIONAL DE TRUJILLOINGENIERIA DE SISTEMAS

2015

18

Dedicamos este trabajo al esfuerzo de nuestros padres para darnos la mejor educacin, y hacen posible que nosotros seamos mejores personas en la sociedad.

INTRODUCCION

Las metodologas agiles tienen un origen reciente en el entorno de la ingeniera de software comparada con las mitologas pesadas. Su origen est ligado a los constantes inconvenientes que se presentaban en proyectos con algunas caractersticas, en los cuales la utilizacin de las metodologas pesadas era motivo de fracaso.En la dcada de los 90, surge Xtreme Programming, mejor conocida como XP, una nueva metodologa catalogada entre las agiles por sus aportes al manifiesto gil. Su creador, Kent Beck se convirti en el padre de la programacin extrema.

CAPTULO I:MARCO TERICO

1.1. METODOLOGA GILA principios de la dcada del 90, surgi un enfoque que fue bastante revolucionario para su momento ya que iba en contra de toda creencia de que mediante procesos altamente definidos se iba a lograr obtener software en tiempo, costo y con la requerida calidad. El enfoque fue planteado por primera vez por Martin y se dio a conocer en la comunidad de Ingeniera de Software con el nombre de RAD o Rapid Application Development. RAD consista en un entorno de desarrollo altamente productivo, en el que participaban grupos pequeos de programadores utilizando herramientas que generaban cdigo en forma automtica tomando como entradas sintaxis de alto nivel. En general, se considera que este fue uno de los primeros hitos en pos de la agilidad en los procesos de desarrollo.

La historia de las Metodologas giles y su apreciacin como tales en la comunidad de la Ingeniera de Software tiene sus inicios en la creacin de una de las metodologas utilizada como arquetipo: XP - eXtreme Programming, que nace de la mente de Kent Beck, tomando ideas recopiladas junto a Ward Cunningham.

Durante 1996, Beck es llamado por Chrysler como asesor del proyecto Chrysler Comprehensive Compensation (C3) payroll system. Dada la poca calidad del sistema que se estaba desarrollando, Beck decide tirar todo el cdigo y empezar de cero utilizando las prcticas que l haba ido definiendo a lo largo del tiempo. El sistema, que administra la liquidacin de aproximadamente 10.000 empleados, y consiste de 2.000 clases y 30.000 mtodos, es puesto en operacin en Mayo de 1997 casi respetando el calendario propuesto. Como consecuencia del xito de dicho proyecto, Kent Beck dio origen a XP iniciando el movimiento de metodologas giles al que se anexaran otras metodologas surgidas mucho antes que el propio Beck fuera convocado por Chrysler.

Es as como que este tipo de metodologas fueron inicialmente llamadas metodologas livianas, sin embargo, an no contaban con una aprobacin pues se le consideraba por muchos desarrolladores como meramente intuitiva. Luego, con el pasar de los aos, en febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace formalmente el trmino gil aplicado al desarrollo de software. En esta misma reunin participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologas de software con el objetivo de esbozar los valores y principios que deberan permitir a los equipos desarrollar software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las actividades desarrolladas.

Tras esta reunin se cre The Agile Alliance, una organizacin, sin nimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo gil de software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida fue el Manifiesto gil, un documento que resume la filosofa gil.

1.2. DIFERENCIAS ENTRE METODOLOGIAS AGILES Y NO AGILES

La Tabla N 1 recoge esquemticamente las principales diferencias de las metodologas giles con respecto a las tradicionales (no giles). Estas diferencias que afectan no slo al proceso en s, sino tambin al contexto del equipo as como a su organizacin.

Tener metodologas diferentes para aplicar de acuerdo con el proyecto que se desarrolle resulta una idea interesante. Estas metodologas pueden involucrar prcticas tanto de metodologas giles como de metodologas tradicionales. De esta manera podramos tener una metodologa para cada proyecto, la problemtica sera definir cada una de las prcticas, y en el momento preciso definir parmetros para saber cul usar.

Es importante tener en cuenta que el uso de un mtodo gil no es para todos. Sin embargo, una de las principales ventajas de los mtodos giles es su peso inicialmente ligero y por eso las personas que no estn acostumbradas a seguir procesos encuentran estas metodologas bastante agradables.

1.3. EXTREME PROGRAMMING(XP)

XP es la primera metodologa gil y la que le dio conciencia al movimiento actual de metodologas giles. De la mano de Kent Beck, XP ha conformado un extenso grupo de seguidores en todo el mundo, disparando una gran cantidad de libros a los que dio comienzo el mismo Beck en. Inclusive Addison-Wesley ha creado una serie de libros denominada The XP Series.

La imagen mental de Beck al crear XP era la de perillas en un tablero de control. Cada perilla representaba una prctica que de su experiencia saba que trabajaba bien. Entonces, Beck decidi girar todas las perillas al mximo para ver que ocurra. As fue como dio inicio a XP.

XP es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en el desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico. A continuacin presentaremos las caractersticas esenciales de XP organizadas en los tres apartados siguientes: historias de usuario, roles, proceso y prcticas.

1.4. HISTORIALa Programacin Extrema, como proceso de creacin de software diferente al convencional, nace de la mano de Kent Beck (gur de la XP y autor de los libros ms influyentes sobre el tema).

Chrysler Corporation haca tiempo que estaba desarrollando una aplicacin de nminas, pero sin demasiado xito por parte de la gente que tena en el proyecto. El verano de 1996, Beck entr en nmina en la compaa y se le pidi de hacer esta aplicacin como trabajo. Es en esta aplicacin cuando nace la Programacin Extrema como tal.

Beck reconoci que el proceso (o metodologa) de creacin de software o la carencia de este era la causa de todos los problemas y lleg a la conclusin que para proporcionar un proceso que fuera flexible era necesario realizar ciertos cambios en la estructura o manera de hacer de los programadores, los cuales se tenan que acomodar al cambio a realizar.

l tena varias ideas de metodologas para la realizacin de programas que eran cruciales para el buen desarrollo de cualquier sistema.

Las ideas primordiales de su sistema las comunic en la revista C++ Magazine en una entrevista que sta le hizo el ao 1999. En sta deca que l estaba convencido que la mejor metodologa era un proceso que enfatizase la comunicacin dentro del equipo, que la implementacin fuera sencilla, que el usuario tena que estar muy informado e implicado y que la toma de decisiones tena que ser muy rpida y efectiva.

Los autores (o mejor dicho, los propulsores como el propio Kent Beck, Ward Cunningham o Ron Jeffries entre otros) de la Programacin Extrema, fueron a la web Portland Pattern Repository y empezaron a hablar de ella y promocionarla, de lo que era y cmo realizarla. Estos propulsores de la XP hablaban de ella en cada ocasin que tenan y en cada pgina que, poco o mucho hablara de temas de programacin.Este hecho, lleg a molestar a buena parte de la comunidad que intentaba discutir sobre temas de programacin. Fue tanta esta molestia que naci el fenmeno XP Free Zone (zona libre de XP) en determinadas webs como peticin de no hablar de Programacin Extrema en ella.

La discusin sobre temas de diseo de modelos de programacin sobre los cambios recientes se hizo tema difcil porque la mayora de la actividad fue relacionada con la Programacin Extrema. Eventualmente, y debido a sto, la mayora de la gente que sola discutir sobre los temas de diseo de modelos de programacin fue apartndose de este ambiente para discutir sus ideas en otros ambientes ms "reservados". La comunidad empez a referirse a estos sitios como a Salas Wiki (Wards Wiki).

1.5. OBJETIVOS DE XP

Los objetivos de XP son muy simples: la satisfaccin del cliente. Esta metodologa trata de dar al cliente el software que l necesita y cuando lo necesita. Por tanto, debemos responder muy rpido a las necesidades del cliente, incluso cuando los cambios sean al final de ciclo de la programacin.

Potenciar al mximo el trabajo en grupo. Tanto los jefes de proyecto, los clientes y desarrolladores, son parte del equipo y estn involucrados en el desarrollo del software.EstablecerlasmejoresprcticasdeIngenieradeSoftwareenlosdesarrollodeproyectos. Mejorar la productividad de los proyectos.Garantizarla Calidad del Software desarrollando, haciendo que este supere las expectativas del cliente.Asumir que con cierta planificacin, codificacin y pruebas se puede decidir si se est siguiendo un camino correcto o equivocado, evitando retroceder cuando sea demasiado tarde.

1.6. CARACTERSTICAS Metodologa basada en prueba y error para obtener un software que funcione realmente.

Fundamentada en Principios.

Expresada en forma de 12 Prcticas (conjunto completo, complementndose unas a otras).Las cuales son conocidas pero su novedades juntarlas.

Est orientada hacia quien produce y usa el software (el cliente participa muy activamente)

Reduce el coste del cambio en todas las etapas del ciclo de vida del sistema.

Combinalasquehandemostradoserlasmejoresprcticasparadesarrollarsoftware, y las lleva al extremo.

Cliente bien definido.

Los requisitos pueden cambiar.

1.7. LA FILOSOFA DE XP

XP es una metodologa gil para pequeos y medianos equipos, desarrollando software cuando los requerimientos son ambiguos o rpidamente cambiantes.

A diferencia de los procesos tradicionales para desarrollar software, XP asume el cambio como algo natural, y que, indefectiblemente, en alguna etapa de un proyecto sucede. En XP se realiza el software que el cliente solicita y necesita, en el momento que lo precisa, alentando a los programadores a responder a los requerimientos cambiantes que plantea el cliente en cualquier momento. Esto es posible porque est diseado para adaptarse en forma inmediata a los cambios, con bajos costos asociados, en cualquier etapa del ciclo de vida. En pocas palabras, XP abraza el cambio.

1.8. VALORES EN XPPara poder implementar las prcticas que presenta XP hay que conocer cules son los valores principales que hacen a esta mitologa. Estos valores son:

Comunicacin. Simplicidad. Feedback. Coraje.

1 2 3 4 5 6 7 1.8.1. Comunicacin

Uno de los valores ms importantes en XP es la comunicacin. La mala comunicacin no surge por casualidad en un proyecto y pueden aparecer muchas circunstancias que hagan que esta falle; un programador le da malas noticias al gerente y este lo castiga, un cliente le dice al programador algo importante y este no le presta atencin.

En cualquiera de los casos la comunicacin es un factor importante en cualquier tipo de proyecto. En XP se trata de mantener una buena comunicacin mediante un conjunto de prcticas que no se pueden realizar sin tener una buena comunicacin en el equipo. Muchas de estas prcticas hacen corto circuito si no hay buena comunicacin como en el caso de los testing unitarios, programacin por pares, el uso de estndares o la estimacin de las tareas. Trabajar en espacios abiertos hace que la comunicacin mejore al contrario de otras metodologas en las cuales los programadores trabajan en espacios reducidos.

La comunicacin con el cliente es de vital importancia en XP y es por este motivo que el cliente es integrado al equipo. De esta forma, cualquier duda sobre los requerimientos puede ser evacuada inmediatamente. Adems, se planifica con el cliente y este puede estar al tanto del avance del proyecto.

XP ha sido diseada para minimizar el grado de documentacin como forma de comunicacin, haciendo nfasis en la interaccin personal. De esta manera se puede avanzar rpidamente y de forma efectiva, realizando solo la documentacin necesaria.

1.8.2. Simplicidad

La simplicidad es el segundo valor que se utiliza en esta metodologa. XP apuesta a realizar algo simple hoy y destinar un poco ms de esfuerzo para realizar un cambio en el futuro, a realizar algo ms complicado hoy y no utilizarlo nunca.

XP propone una regla muy simple: hacer algo que funcione de la manera ms sencilla. En el caso de tener que aadir nueva funcionalidad al sistema se deben examinar todas las posibles alternativas y seleccionar la ms sencilla. En otras ocasiones se hace uso del refactoring1 que permite mantener el cdigo en funcionamiento pero mucho ms simple y organizado.

Otra regla muy importante es: realizar solo lo necesario. Con esto se pretende agregar nueva funcionalidad que cumpla con los objetivos actuales sin necesidad de preocuparse por futuros requerimientos. Esto hace que se progrese de manera ms segura y rpida en el proyecto.

1.8.3. Feedback

Brindar un feedback correcto y preciso hace que se pueda mantener una buena comunicacin y conocer el estado actual del proyecto.

El feedback trabaja a diferentes escalas de tiempo. Uno es el feedback que se realiza minuto a minuto. Cuando un cliente escribe sus stories1 los programadores realizan la estimacin de cada una de ellas y el cliente puede obtener inmediatamente el feedback sobre la calidad de dichas stories.

El otro tipo de feedback que se realiza es a travs de pequeas entregas del sistema. De esta manera, el cliente est al tanto del avance del proyecto. Adems, el sistema es puesto en produccin en menor tiempo, con lo cual los programadores saben si realizaron un buen trabajo y si sus decisiones fueron acertadas.

1.8.4. Coraje

Obviamente cada uno de los valores antes mencionados tiene una gran interaccin entre ellos. Como se ve en la siguiente figura la comunicacin, la simplicidad y el feedback forman el coraje, el cual se convierte en el objetivo de XP. Uno de los lemas de XP menciona: Si no trabajas al tope de tu capacidad, alguien ms lo est haciendo y si no llegas a tiempo se comer tu almuerzo.

Esto hace, a que por ejemplo, se tenga el coraje de modificar el cdigo en cualquier momento por cualquier miembro del equipo sabiendo que no se afectar el correcto funcionamiento del sistema.

El coraje tambin es poder realizar cambios cuando algo no funciona del todo bien, disear e implementar solo lo necesario para el presente, pedir ayuda o reducir el alcance de una entrega si el tiempo no alcanza.

Si no hay coraje en un proyecto no se puede clasificar como extremo y es necesario que los otros tres valores estn presentes.

1.9. COSTE DEL CAMBIO

Una de las suposiciones establecidas en la industria del software es que el coste de los cambios en un programa crece exponencialmente con el tiempo. XP propone que si el sistema que empleas hace que el coste del software aumente con el tiempo debes de actuar de forma diferente a cmo lo haces. XP propugna que esta curva ha perdido validez y con una combinacin de buenas prcticas de programacin y tecnologa es posible lograr que la curva sea la contraria, por tanto se pretende conseguir esto:Si decidimos aceptar el cambio debemos de desarrollar para basarnos en dicha curva, pero cmo se consigue dicha curva?, no existe una forma mgica desde luego hay varias medidas que nos ayudan a conseguirla.

Disear lo ms sencillo que sea posible, para hacer slo lo imprescindible en un momento dado, la simplicidad del cdigo y los test continuos hace que los cambios sean posibles tan a menudo como sea necesario.

La programacin orientada a objetos es una tecnologa clave para el mantenimiento del software, cada mensaje a un objeto es una oportunidad de cambio sin necesidad de cambiar el cdigo existente, esto no quiere decir que no puedas tener flexibilidad sin programar orientado al objeto y el caso contrario que haya programas orientados a objetos que nadie quera tocar, slo se dice que el programar orientado a objetos reduce el costo del cambio.

En vez de tomar grandes decisiones al principio y pocas posteriormente, podemos idear una aproximacin para desarrollar software en la que se tomen decisiones rpidamente, pero estas decisiones apoyadas por pruebas y que te preparan para mejorar el diseo del software cuando aprendas una mejor manera de disearlo.

He odo a muchos programadores (entre los que me incluyo) decir: Hasta que no he terminado el programa no lo he entendido ahora lo hara con esta jerarqua y que esta clase herede de esta otra, dejemos pues abierta la puesta a esta posibilidad.

1.10. CICLO DE VIDA DE XP

El ciclo de vida de XP consiste bsicamente de seis fases: Exploracin, Planificacin, Iterations to Release, Produccin, Mantenimiento y Muerte.

Exploracin

En esta fase los clientes realizan las story cards que desean que estn para la primera entrega. Cada story describe una de las funcionalidades que el programa tendr. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, la tecnologa y las prcticas a ser utilizadas durante el proyecto. En algunos casos se utiliza un prototipo para testear la nueva tecnologa y explorar algunos aspectos de la arquitectura a ser implementada. La duracin de esta fase puede extenderse desde unas pocas semanas a varios meses dependiendo de la adaptacin del equipo de desarrollo.

Planificacin

El objetivo de esta fase es fijar la prioridad de cada una de las stories y se establece cual va a ser el contenido de la primera entrega. Los programadores estiman cuanto esfuerzo requiere cada story y se establece el cronograma. La duracin del calendario para la entrega del primer release no suele superar los dos meses. Duracin de la fase de planificacin en s no toma ms de dos das.

Iteraciones por entregas

Esta fase incluye varias iteraciones del sistema antes de la entrega del primer relase. El calendario es dividido en un nmero iteraciones de tal manera de que cada iteracin tome de una a cuatro semanas de implementacin. En la primera iteracin se crea un sistema que abarca los aspectos ms importantes de la arquitectura global. Esto se logra seleccionando las stories que hagan referencia a la construccin de la estructura de todo el sistema.

El cliente decide que stories van a ser implementadas para cada iteracin. Adems, se realizan los test funcionales, realizados por el cliente, al final de cada iteracin. Al final de la ltima iteracin el sistema est listo para ser puesto en produccin.

Produccin

La fase de produccin requiere realizar muchos ms chequeos y testing antes que el sistema sea entregado al cliente. En esta fase aparecen nuevos cambios y se tiene que decidir si sern incorporados o no en dicha entrega. Durante esta fase suele suceder que las iteraciones se aceleren de tres a una semana. Las ideas pospuestas y las sugerencias son documentadas para luego ser implementadas ms adelante, por ejemplo, en la fase de mantenimiento.

Luego que el primer release es creado, el proyecto debe mantener el sistema en produccin corriendo mientas se trabaja en las nuevas iteraciones.

Mantenimiento

En esta fase por lo general se necesita un esfuerzo extra de los programadores para satisfacer los requerimientos del cliente. Por este motivo la velocidad de desarrollo suele disminuir una vez que el sistema es puesto en produccin. A raz de esto se requiere incorporar nuevos integrantes al equipo y cambiar la estructura del equipo.

Muerte

Esta ltima fase se acerca una vez que el cliente no tiene ninguna story a ser implementada. Los requerimientos del sistema deben ser satisfechos en otros aspectos como ser la performance o la confiabilidad del mismo. Esta es la etapa en la cual no hay ms cambios en la arquitectura, el diseo o el cdigo y aqu es cuando se realiza la documentacin correspondiente. Esta fase aparece tambin, cuando el sistema no da los resultados deseados o se vuelve demasiado caro para seguir siendo desarrollado.

1.11. Principios de XP

Los cuatro valores mencionados anteriormente comunicacin, simplicidad, feedback y coraje nos brindan un estndar para obtener buenos resultados. Sin embargo, los valores son muy vagos a la hora de ayudarnos a decidir que prcticas utilizar. Para ello se necesita destilar estos valores en principios que puedan ser utilizados.

2. 3. 4. 1.11.1. Rpida Retroalimentacin

En la prctica el tiempo transcurrido entre una accin y su feedback es crtico. Tener una rpida retroalimentacin nos permite interpretarla, aprender de ella y poner en prctica lo asimilado lo antes posible.

1.11.2. Asumir la Simplicidad

Este es uno de los principios ms difciles de llevar a la prctica. Casi siempre se planifica para el futuro y se disea para poder rehusar. En lugar de esto XP dice que hay que hacer un buen trabajo para las necesidades actuales y confiar en nuestra habilidad para solucionar problemas futuros.

1.11.3. Cambios Incrementales

Realizar grandes cambios en una sola oportunidad no es una buena solucin. Cada problema debe ser resuelto con una serie de cambios pequeos para poder atacar dicho problema mucho ms en profundidad.

1.11.4. Aceptar el Cambio

En XP el cambio es asimilado como algo habitual e inevitable. La mejor estrategia es aquella que preserva la mayor cantidad de opciones mientras resuelve los problemas ms precisos.

1.11.5. Trabajo de Calidad

Uno de los objetivos ms importantes en XP es realizar un producto de buena calidad. Si cada integrante realiza su trabajo de la mejor manera posible se puede asegurar la calidad del producto.

1.11.6. Otros Principios

Adems de los principios antes mencionados surgen algunos otros de menor trascendencia que pueden ayudar a tomar buenas decisiones en situaciones especficas.

Aceptar la responsabilidad Adaptacin local Comunicacin abierta y honesta Ensear conocimientos Experimentos concretos Jugar para ganar Mediciones honestas Pequea inversin inicial Trabajar con los instintos de las personas Viajar liviano

CAPITULO II: FACES DE LA METODOLOGIA XP

2.1. FASE PLANEACINLa planeacin es la etapa inicial de todo proyecto en XP. En este punto se comienza interactuar con el cliente y el resto del grupo de desarrollo para descubrir los requerimientos del sistema. En este punto se identifican el nmero y tamao de las iteraciones al igual que se plantean ajustes necesarios a la metodologa segn las caractersticas del proyecto.En este apartado se tendrn en cuenta ocho elementos, los cuales son los siguientes: Historias De Usuario. Velocidad Del Proyecto. Iteraciones. Entregas Pequeas. Reuniones. Roles En XP. Traslado Del Personal. Ajuste A XP.

Figura 3. El juego de Planificacin Fuente: (info-ab.uclm.es, 2002)

2.1.1. Historias de usuario

Las historias de usuario son utilizadas como herramienta para dar a conocer los requerimientos del sistema al equipo de desarrollo. Son pequeos textos en los que el cliente describe una actividad que realizar el sistema; la redaccin de los mismos se realiza bajo la terminologa del cliente, no del desarrollador, de forma que sea clara y sencilla, sin profundizar en detalles.

Las historias de usuario tambin son utilizadas para estimar el tiempo que el equipo de desarrollo tomar para realizar las entregas. En una entrega se puede desarrollar una o varias historias de usuario, esto depende del tiempo que demore la implementacin de cada una de las mismas.

2.1.2. Velocidad del proyectoEs una medida de la capacidad que tiene el equipo de desarrollo para evacuar las historias de usuario en una determinada iteracin. Esta medida se calcula totalizando el nmero de historias de usuario realizadas en una iteracin. Para la iteracin siguiente se podr (tericamente) implementar el mismo nmero de historias de usuario que en la iteracin anterior.

2.1.3. IteracionesPor lo general, los proyectos constan de ms de tres etapas, las cuales toman el nombre de iteraciones, de all se obtiene el concepto de metodologa iterativa. Para cada iteracin se define un mdulo o conjunto de historias que se van a implementar. Al final de la iteracin se obtiene como resultado la entrega del mdulo correspondiente, el cual debe haber superado las pruebas de aceptacin que establece el cliente para la verificar el cumplimiento de los requisitos. Las tareas que no se realicen en una iteracin son tomadas en cuenta para la prxima iteracin, donde se define, junto al cliente, si se deben realizar o si deben ser removidas de la planeacin del sistema.

2.1.4. Entregas pequeas

La duracin de una iteracin vara entre una y tres semanas, al final de la cual habr una entrega de los avances del producto, los cuales debern ser completamente funcionales. Estas entregas deben caracterizarse por ser frecuentes.

2.1.5. Reuniones

El planeamiento es esencial para cualquier tipo de metodologa, es por ello que XP requiere de una revisin continua del plan de trabajo. A pesar de ser una metodologa que evita la documentacin exagerada, es muy estricta en la organizacin del trabajo.

2.1.6. Roles en XP

ProgramadorEl programador escribe las pruebas unitarias y produce el cdigo del sistema. Debe existir una comunicacin y coordinacin adecuada entre los programadores y otros miembros del equipo.

ClienteEl cliente escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin centrndose en aportar mayor valor al negocio. El cliente es slo uno dentro del proyecto pero puede corresponder a un interlocutor que est representando a varias personas que se vern afectadas por el sistema.

Encargado de pruebas (Tester)El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.

Encargado de seguimiento (Tracker)El encargado de seguimiento proporciona realimentacin al equipo en el proceso XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones.Tambin realiza el seguimiento del progreso de cada iteracin y evala si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes. Determina cundo es necesario realizar algn cambio para lograr los objetivos de cada iteracin.

Entrenador (Coach)Es responsable del proceso global. Es necesario que conozca a fondo el proceso XP para proveer guas a los miembros del equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente.

ConsultorEs un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto. Gua al equipo para resolver un problema especfico. Gestor (Big boss)Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin.

2.1.8. Traslado del personal

Al mover el personal se evitan problemas relacionados con la prdida de conocimiento y cuellos de botella. En la medida que todos los programadores entienden todas las partes del programa se evita que unos tengan una carga de trabajo muy alta mientras que otros no tengan mucho trabajo por hacer.

La programacin en parejas se convierte en una herramienta muy importante para lograr el objetivo del traslado de personal sin que se pierda el rendimiento.

Figura 2: rotacin de parejas.

2.1.9. Ajuste a XP

Todos los proyectos tienen caractersticas especficas por lo cual XP puede ser modificado para ajustarse bien al proyecto en cuestin. Al iniciar el proyecto se debe aplicar XP tal como es, sin embargo no se debe dudar en modificar aquellos aspectos en que no funcione. Eso no quiere decir que los desarrolladores pueden hacer lo que se les antoje. Antes de implementarse un cambio, este debe ser discutido y aprobado por el grupo.

2.2. FASE DISEO

En XP solo se disean aquellas historias de usuario que el cliente ha seleccionado para la iteracin actual por dos motivos: por un lado se considera que no es posible tener un diseo completo del sistema y sin errores desde el principio. El segundo motivo es que dada la naturaleza cambiante del proyecto, el hacer un diseo muy extenso en las fases iniciales el proyecto para luego modificarlo, se considera un desperdicio de tiempo.

Los aspectos que se tratarn a continuacin son:

Simplicidad En El Diseo. Metfora Del Sistema. Tarjetas Crc. Spike Solution. No Solucionar Antes De Tiempo. Refactoring.

Figura 4. Planificacin y diseo en XP.Fuente: (info-ab.uclm.es, 2002)

3. 2.2.1. Simplicidad En El Diseo

Una de las partes ms importantes de la filosofa XP es la simplicidad en todos los aspectos. Se considera que un diseo sencillo se logra ms rpido y se implementa en menos tiempo, por lo cual esto es lo que se busca. La idea es que se haga el diseo ms sencillo que cumpla con los requerimientos de las historias de usuario.

2.2.2. Metfora Del Sistema

Es muy importante dentro del desarrollo de la metfora darle nombres adecuados a todos los elementos del sistema constantemente, y que estos correspondan a un sistema de nombres consistente. Esto ser de mucha utilidad en fases posteriores del desarrollo para identificar aspectos importantes del sistema.

2.2.3. Tarjetas de clase, responsabilidad, colaboracin (CRC cards)La principal funcionalidad que tienen estas, es ayudar a dejar el pensamiento procedimental para incorporarse al enfoque orientado a objetos.

En el proceso de disear el sistema por medio de las tarjetas CRC como mximo dos personas se ponen de pie adicionando o modificando las tarjetas, prestando atencin a los mensajes que stas se transmiten mientras los dems miembros del grupo que permanecen sentados, participan en la discusin obteniendo as lo que puede considerarse un diagrama de clases preliminar.

2.2.4. Soluciones puntuales (Spike Solution)Se trata de una pequea aplicacin completamente desconectada del proyecto con la cual se intenta explorar el problema y propone una solucin potencial. Puede ser burda y simple, siempre que brinde la informacin suficiente para enfrentar el problema encontrado.

2.2.5. No Solucionar Antes De Tiempo

Los desarrolladores tienden a predecir las necesidades futuras e implementarlas antes. Segn mediciones, esta es una prctica ineficiente, concluyendo que tan solo el 10% de las soluciones para el futuro son utilizadas, desperdiciando tiempo de desarrollo y complicando el diseo innecesariamente.

En XP slo se analiza lo que se desarrollar en la iteracin actual, olvidando por completo cualquier necesidad que se pueda presentar en el futuro, lo que supone uno de los preceptos ms radicales de la programacin extrema.

2.2.6. Refactorizacin (Refactoring)

La refactorizacin en el cdigo pretende conservarlo tan sencillo y fcil de mantener como sea posible. En cada inspeccin que se encuentre alguna redundancia, funcionalidad no necesaria o aspecto en general por corregir, se debe rehacer esa seccin de cdigo con el fin de lograr las metas de sencillez tanto en el cdigo en s mismo como en la lectura y mantenimiento.

2.3. FASE DESARROLLOEl desarrollo es un proceso que se realiza en forma paralela con el diseo y la cual est sujeta a varias observaciones por parte de XP consideradas controversiales por algunos expertos tales como la rotacin de los programadores o la programacin en parejas.A continuacin una descripcin de los siguientes temas: Cliente Siempre Presente. Codificar Primero La Prueba. Integracin. Secuencial. Integraciones Frecuentes.

3. 2.3.1. Cliente Siempre PresenteUno de los requerimientos de XP es que el cliente est siempre disponible. No solamente para solucionar las dudas del grupo de desarrollo, debera ser parte de ste. En este sentido se convierte en gran ayuda al solucionar todas las dudas que puedan surgir, especialmente cara a cara, para garantizar que lo implementado cubre con las necesidades planteadas en las historias de usuario.

2.3.2. Codificar Primero La PruebaUna de las ventajas de crear una prueba antes que el cdigo es que permite identificar los requerimientos de dicho cdigo. En otras palabras, al escribir primero las pruebas se encuentran de una forma ms sencilla y con mayor claridad todos los casos especiales que debe considerar el cdigo a implementar. De esta forma el desarrollador sabr con completa certeza en qu momento ha terminado, ya que habrn pasado todas las pruebas.

2.3.3. Programacin En ParejasCuando se trabaja en parejas se obtiene un diseo de mejor calidad y un cdigo ms organizado y con menores errores que si se trabajase solo, adems de la ventaja que representa contar con un compaero que ayude a solucionar inconvenientes en tiempo de codificacin, los cuales se presentan con mucha frecuencia.

Se recomienda que mientras un miembro de la pareja se preocupa del mtodo que se est escribiendo el otro se ocupe de cmo encaja ste en el resto de la clase.

2.3.4. Integracin Secuencial

Uno de los mayores inconvenientes presentados en proyectos de software tiene que ver con la integracin, sobre todo si todos los programadores son dueos de todo el cdigo. Para saldar este problema han surgido muchos mecanismos, como darle propiedad de determinadas clases a algunos desarrolladores, los cuales son los responsables de mantenerlas actualizadas y consistentes. Sin embargo, sumado al hecho que esto va en contra de la propiedad colectiva el cdigo no se solucionan los problemas presentados por la comunicacin entre clases.

2.3.5. Integraciones FrecuentesSe deben hacer integraciones cada pocas horas y siempre que sea posible no debe transcurrir ms un da entre una integracin y otra. De esta forma se garantiza surjan problemas como que un programador trabaje sobre versiones obsoletas de alguna clase.

Es evidente que entre ms se tarde en encontrar un problema ms costoso ser resolverlo y con la integracin frecuente se garantiza que dichos problemas se encuentre ms rpido o an mejor, sean evitados por completo.

2.4. FASE PRUEBASDel buen uso de las pruebas depende el xito de otras prcticas, tales como la propiedad colectiva del cdigo y la refactorizacin. Cuando se tienen bien implementadas las pruebas no habr temor de modificar el cdigo del otro programador en el sentido que si se daa alguna seccin, las pruebas mostrarn el error y permitirn encontrarlo. Uno de los elementos que podra obstaculizar que un programador cambie una seccin de cdigo funcional es precisamente hacer que esta deje de funcionar. Si se tiene un grupo de pruebas que garantice su buen funcionamiento, este temor se mitiga en gran medida.

Segn XP se debe ser muy estricto con las pruebas. Slo se deber liberar una nueva versin si esta ha pasado con el cien por ciento de la totalidad de las pruebas. En caso contrario se emplear el resultado de estas para identificar el error y solucionarlo con mecanismos ya definidos.

3. 2.4.1. Pruebas Unitarias

Estas pruebas se aplican a todos los mtodos no triviales de todas las clases del proyecto con la condicin que no se liberar ninguna clase que no tenga asociada su correspondiente paquete de pruebas. Uno de los elementos ms importantes en estas es que idealmente deben ser construidas antes que los mtodos mismos, permitindole al programador tener mxima claridad sobre lo que va a programar antes de hacerlo, as como conocer cada uno de los casos de prueba que deber pasar, lo que optimizar su trabajo y su cdigo ser de mejor calidad.

2.4.2. Pruebas de AceptacinLas pruebas de aceptacin, tambin llamadas pruebas funcionales son supervisadas por el cliente basndose en los requerimientos tomados de las historias de usuario. En todas las iteraciones, cada una de las historias de usuario seleccionadas por el cliente deber tener una o ms pruebas de aceptacin, de las cuales debern determinar los casos de prueba e identificar los errores que sern corregidos.Las pruebas de aceptacin son pruebas de caja negra, que representan un resultado esperado de determinada transaccin con el sistema.

2.4.3. Cuando se Encuentra un ErrorAl momento de encontrar un error debe escribirse una prueba antes de intentar corregirlo. De esta forma tanto el cliente lograr tener completamente claro cul fue y dnde se encontraba el mismo como el equipo de desarrollo podr enfocar mejor sus esfuerzos para solucionarlo. Por otro lado se lograr evitar volver a cometerlo.

CONCLUCIONES

Ninguna prctica funciona bien por si sola (con la excepcin de las pruebas). Requieren las otras prcticas para equilibrarse.

La XP brinda no solo ventajas en cuanto a rapidez, sino que promueve habilidades sociales como la comunicacin, el trabajo en equipo y disciplina.

En XP la comunicacin es vital tanto entre el grupo de desarrollo como con el cliente, el cual debe formar parte del equipo para mantener una comunicacin fluida y poder de esta forma, evacuar cualquier tipo de duda que surja con los requerimientos.

La programacin extrema se beneficia de la existencia de un gran nmero de herramientas de software libre que permiten aplicarla con gran productividad.

XP propone una metodologa gil y concreta, aunque requiere de una nueva menara de pensar, ver y hacer las cosas, tanto por parte de los gerentes (responsables de la rentabilidad general del proyecto), como de los desarrolladores y tambin del cliente. La aplicabilidad de sta metodologa a cada proyecto debera ser analizada en cada caso, teniendo en cuenta el tamao y tipo de proyecto, as como sus ventajas y desventajas.

REFERENCIAS

ECHEVERRY TOBN, Luis Miguel y DELGADO CARMONA, Luz Elena. Caso Prctico de la Mitologa gil XP al Desarrollo de Software: 2007

AMARO CALDERON, Sarah Damaris y VALVERDE REBAZA, Jorge Carlos. Metodologas giles: 2007

Programacin ExtremaCALERO SOLIS, Manuel. Una Explicacin de la Programacin Extrema (XP): 2003

CALABRIA, Luis y PIRIZ, Pablo. Metodologa XP: 2003