TEMA:

METODOLOGÍA XP

ALUMNO: QUISPE ALDANA VÍCTOR DANIEL

DOCENTE: NOEL JUIPA CAMPO

CURSO: TALLER DE PROGRAMACION II

CICLO: VI

1

UNIVERSIDAD

FACULTAD INGENIERIA

DE SISTEMAS

2014

INDICE

DEDICATORIA

INTRODUCCION

MARCO TEORICO

CAPITULO I: QUE ES PROGRAMACION EXTREMA XP?

1. METODOLOGIA AGIL2. DIFERENCIAS ENTRE METODOLOGIAS AGILES Y NO AGILES3. XP EXTREM PROGRAMMIN4. HISTORIA5. OBJETIVOS DE XP6. LA FILOSOFIA XP7. VALORES XP

7.1 COMUNICACIÓN7.2 SIMPLICIDAD7.3 FEEDBACK7.4 CORAJE

8. COSTE DEL CAMBIO9. CICLO DE VIDA XP

EXPLORACION PLANIFICACION ITERACIONES POR ENTREGAS PRODUCCION MANTENIMIENTO MUERTE

10.PRINCIPIOS DE XP10.1 RÁPIDA RETROALIMENTACIÓN10.2 ASUMIR LA SIMPLICIDAD10.3 CAMBIOS INCREMENTALES10.4 ACEPTAR EL CAMBIO

1

10.5 TRABAJO DE CALIDAD10.6 OTROS CAMBIOS

11. CONCLUSIONES12. REFERENCIAS

1

Dedico este trabajo al esfuerzo de mis

Padres por darme la mejor educación,

Y hacen posible que sea mejor persona

En la sociedad.

1

INTRODUCCION

Las Metodologías ágiles tienen un origen reciente en el entorno de la ingeniería de software comparada con las mitologías pesadas. Su origen está ligado a los constantes inconvenientes que se presentaban en proyectos con algunas características, en los cuales la utilización de las metodologías pesadas era motivo de fracaso.

En la década de los 90, surge XtremeProgramming mejor conocida como XP, una nueva metodología catalogada entre las agiles por sus aportes el manifiesto ágil. Su creador, Kent Beck se convirtió en el padre de la programación extrema.

1

Marco Teórico

En esta parte del documento se hace una presentación teórica de XP como metodología de desarrollo y de los principios teóricos que inspiraron esta metodología

Se inicia con una descripción de general de metodologías agiles, documento que sirve como punto de partida para las metodologías que reciben el mismo nombre. Persiguiendo con una conceptualización importante sobre XP como metodología de desarrollo, la cual consta de los valores, principios y el alcance de la misma.

Finalmente se entre en detalle con cada una de las etapas de desarrollo (planeación, diseño, codificación y pruebas) describiendo cada uno de los aspectos que la componen.

CAPITULO I: QUE ES PROGRAMACION EXTREMA XP?

1. METODOLOGIA AGIL

A principio de la década de los 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 Ingeniería de Software con el nombre RAD o Rapid Application Development. RAD consistía en un entorno de desarrollo altamente productivo, en el que participaban grupos pequeños de programadores utilizando herramientas que generaban código en forma automática 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 Metodologías Ágiles y su apreciación como tales en la comunidad de la Ingeniería de Software tiene sus inicios en la creación de una de las metodologías utilizada como arquetipo: XP – ExtremeProgramming 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) payrollsystem. Dada la poca calidad del sistema que se estaba desarrollando, Beck decide tirar todo el código y empezar de cero

1

utilizando las practicas que el había ido definiendo a lo largo del tiempo. El sistema, que administra la liquidación de aproximadamente 10,000 empleados, y consiste de 2,000 clases y 30,000 métodos, es puesto en operación en Mayo de 1997 casi respetando el calendario propuesto. Como consecuencia del éxito de dicho proyecto, Kent Benck dio origen a XP iniciando el movimiento de metodologías agiles al que se anexarían otras metodologías surgidas mucho antes que el propio Beck fuera convocado por Chryster.

Es así como que este tipo de metodologías fueron inicialmente llamadas “metodologías livianas”, sin embargo, aún no contaban con una aprobación pues se le consideraba por muchos desarrolladores como meramente intuitiva. Luego, con el pasar de los años, en febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace formalmente el término “ágil” aplicado al desarrollo de software. En esta misma reunión participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software con el objetivo de esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretendía ofrecer alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos por la documentación que se genera en cada una de las actividades desarrolladas.

Tras esta reunión se creó The Agile Alliance, una organización, 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 filosofía “ágil”.

2. DIFERENCIAS ENTRE METODOLOGIAS AGILES Y NO AGILES

La tabla N°1 recoge esquemáticamente las principales diferencias de las metodologías ágiles con respecto a las tradicionales (“no ágiles”). Estas diferencias que afectan no sólo al proceso en sí, sino también al contexto del equipo así como a su organización.

Tener metodologías diferentes para aplicar de acuerdo con el proyecto que se desarrolle resulta una idea interesante. Estas metodologías pueden involucrar practicar tanto de metodologías ágiles como de metodologías tradicionales. De esta manera podríamos tener una metodología para cada proyecto, la problemática seria definir cada una de las prácticas, y en el momento preciso definir parámetros para saber cuál usar.

1

Es importante tener en cuenta que el uso de un método ágil no es para todos. Sin embargo, una de las principales ventajas de los métodos agiles es su peso inicialmente ligero y por eso las personas que no estén acostumbradas a seguir procesos encuentran estas metodologías bastante agradables.

Metodologías Ágiles Metodologías TradicionalesBasadas en heurísticas provenientes de prácticas de producción de código

Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo

Especialmente preparados para cambios durante el proyecto

Cierta resistencia a los cambios

Impuestas internamente (por el equipo)

Impuestas externamente

Proceso menos controlado, con pocos principios

Proceso mucho más controlado, con numerosas políticas / normas.

No existe contrato tradicional o al menos es bastante flexible

Existe un contrato prefijado

El cliente es parte del equipo de desarrollo

El cliente interactúa con el equipo de desarrollo mediante reuniones

Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio

Grupos grandes y posiblemente distribuidos

Pocos artefactos Más artefactosPocos roles Más rolesMenos énfasis en la arquitectura del software

La arquitectura del software es esencial y expresa mediante modelos

3. XP EXTREM PROGRAMMIN

XP es la primera metodología ágil y la que dio conciencia al movimiento actual de metodologías á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 práctica que de su experiencia sabía que trabajaba bien. Entonces, Beck decidió girar todas las perillas al máximo para ver que ocurría. Así fue como dio inicio XP.

XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en el desarrollo de software, promoviendo el trabajo en

1

equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando de buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación 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 técnico. A continuación presentaremos las características esenciales de XP organizadas en los tres apartados siguientes: historias de usuario, roles, proceso y prácticas.

4. HISTORIA

La Programación Extrema, como proceso de creación de software diferente al convencional, nace de la mano de Kent Beck (gurú de la XP y autor de los libros más influyentes sobre el tema).

Chrysler Corporation hacía tiempo que estaba desarrollando una aplicación de nóminas, pero sin demasiado éxito por parte de la gente que tenía en el proyecto. El verano de 1996, Beck entró en nómina en la compañía y se le pidió de hacer esta aplicación como trabajo. Es en esta aplicación cuando nace la Programación Extrema como tal.

Beck reconoció que el proceso (o metodología) de creación de software o la carencia de este era la causa de todos los problemas y llegó a la conclusión que para proporcionar un proceso que fuera flexible era necesario realizar ciertos cambios en la estructura o manera de hacer de los programadores, los cuales se tenían que acomodar al cambio de realizar.

Él tenía varias ideas de metodologías para la realización de programas que eran cruciales para el buen desarrollo de cualquier sistema.

Las ideas primordiales de su sistema las comunicó en la revista C++ Magazine en una entrevista que esta le hizo el año 1999. En ésta decía que él estaba convencido que la mejor metodología era un proceso que enfatizase la comunicación dentro del equipo, que la implementación fuera sencilla, que el usuario tenía que estar muy informado o implicado y que la toma de decisiones tenía que ser muy rápida y efectiva.

Los autores (o mejor dicho, los propulsores como el propio Kent Beck, Ward Cunningham o Ron Jeffries entre otros) de la Programación Extrema, fueron a la web Portland PatternRepository y empezaron a hablar de ella y promocionarla, de lo que era y cómo realizarla. Estos propulsores de la XP hablaban de ella en cada

1

ocasión que tenían y en cada página que, poco o mucho hablara de ella de temas de programación.

Este hecho, llego a molestar a buena parte de la comunidad que intentaba discutir sobre temas de programación. Fue tanta esa molestia que nació el fenómeno XP Free Zone (Zona Libre de XP) en determinadas webs como petición de no hablar de Programación Extrema en ella.

La discusión sobre temas de diseño de modelos de programación sobre los cambios recientes se hizo tema difícil porque la mayoría de la actividad fue relacionada con la Programación Extrema. Eventualmente, y debido a esto, la mayoría de la gente que solía discutir sobre los temas de diseño de modelos de programación fue apartándose de este ambiente para discutir sus ideas en otros ambientes más “reservados “. La comunidad empezó a referirse a estos sitios como a Salas Wiki (Ward Wiki).

5. OBJETIVOS DE XP

Los objetivos de XP son muy simples: la satisfacción del cliente. Esta metodología trata de dar al cliente el software que el necesita y cuando lo necesita. Por tanto, debemos responder muy rápido a las necesidades del cliente, incluso cando los cambios sean al final de ciclo de la programación.

Potenciar al máximo el trabajo en grupo. Tanto los jefes de proyecto, los clientes y desarrolladores, son parte del equipo y están involucrados en el desarrollo del software.

Establecer las mejores prácticas de Ingeniería de Software en los desarrollos de proyectos. Mejorar la productividad de los proyectos.

Garantizarla Calidad del Software desarrollando, haciendo que este supere las expectativas del cliente.

Asumir que con cierta planificación, codificación y pruebas se puede decidir si se está siguiendo un camino correcto o equivocado, evitando retroceder cuando sea demasiado tarde.

6. LA FILOSOFIA XP

XP es una metodología ágil para pequeños y medianos equipos, desarrollando software cuando los requerimientos son ambiguos o rápidamente cambiantes.

1

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á diseñado 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.

7. VALORES XP

Para poder implementar las prácticas que presenta XP hay que conocer cuáles son los valores principales que hacen a esta mitología. Estos valores son:

Comunicación. Simplicidad. FeedBack. Coraje.

7.1 COMUNICACIÓNUno de los valores más importantes en XP es la comunicación. La mala comunicación 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 atención.En cualquiera de los casos la comunicación es un factor importante en cualquier tipo de proyecto. En XP se trata de mantener una buena comunicación mediante un conjunto de prácticas que no se pueden realizar sin tener una buena comunicación en el equipo. Muchas de estas prácticas hacen corto circuito si no hay buena comunicación como en el caso de los testing unitarios, programación por pares, el uso de estándares o la estimación de las tareas. Trabajar en espacios abiertos hace que la comunicación mejore al contrario de otras metodologías en las cuales los programadores trabajan en espacios reducidos.La comunicación 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. Además, se planifica con el cliente y este puede estar al tanto del avance del proyecto. 7.2 SIMPLICIDAD

1

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

XP propone una regla muy simple: “hacer algo que funcione de la maner más sencilla”. En el caso de tener que añadir nueva funcionalidad al sistema se deben examinar todas las posibles alternativas y seleccionar la más sencilla. En otras ocasiones se hace uso del refactoring1 que permite mantener el código en funcionamiento pero mucho más simple y organizado.

7.3 FeedBack

Brindar un FeedBack correcto y preciso hace que se pueda mantener una buena comunicación 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 estimación 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 través de pequeñas entregas del sistema. De esta manera, el cliente está al tanto del avance del proyecto. Además, el sistema es puesto en producción en menor tiempo, con lo cual los programadores saben si realizaron un buen trabajo y si sus decisiones fueron acertadas.

7.4 Coraje

Obviamente cada uno de los valores antes mencionados tiene una gran interacción entre ellos. Como se ve en la siguiente figura la comunicación, 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 más 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 código en cualquier momento por cualquier miembro del equipo sabiendo que no se afectará el correcto funcionamiento del sistema.

1

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

8. 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 el coste del software aumente con el tiempo debes de actuar de forma diferente a cómo lo haces. XP propugna que esta curva ha perdido validez y con una combinación de buenas prácticas de programación y tecnología 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 Cómo se consigue dicha curva?, no existe una forma mágica desde luego hay varias medidas que nos ayudan a conseguirla.

Diseñar lo más sencillo que sea posible, para hacer solo lo imprescindible en un momento dado, la simplicidad del código y los test continuos hace que los cambios sean posibles tan a menudo como sea necesario.

La programación orientada a objetos es una tecnología clave para el mantenimiento del software, cada mensaje a un objeto es una oportunidad de cambio sin necesidad de cambiar el código existente, esto no quiere decir que no puedas tener flexibilidad sin programar orientado al objeto y el caso contrario que haya programas orientado a objetos que nadie quería tocar, solo 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 aproximación para desarrollar software en la que se tomen decisiones rápidamente, pero estas decisiones apoyadas por pruebas y que te preparan para mejorar el diseño del software cuando aprendas una mejor manera de diseñarlo.

1

1

9. CICLO DE VIDA XP

El ciclo de vida XP consiste básicamente de seis fases: Exploración, Planificación, IterationstoRelease, Producción, Mantenimiento y Muerte.

EXPLORACIÓN

En esta fase los clientes realizan los storycards que desean que estén 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 tecnología y las prácticas a ser utilizadas durante el proyecto.

PLANIFICACIÓN

El objetivo de esta fase es fijar la prioridad de cada una de las stories y se establece cual va a ser contenido de la primera entrega. Los programadores estiman cuanto esfuerzo requiere cada story y se establece el cronograma. La duración del calendario para la entrega del primer reléase no suele superar los dos meses. Duración de la fase de planificación en si no toma más de dos días.

ITERACIONES POR ENTREGAS

Esta fase incluye varias iteraciones del sistema antes de la entrega del primer reléase. El calendario es dividido en un número de iteraciones de tal manera de que cada iteración tome de una a cuatro semanas de implementación. En la primera iteración se crea un sistema que abarca los aspectos más importantes de la arquitectura global. Esto se logra seleccionando las stories que hagan referencia a la construcción de la estructura de todo el sistema.

PRODUCCIÓN

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

MANTENIMIENTO

En esta fase 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 producción. A

1

raíz 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 cambios en la arquitectura, el diseño o el código y aquí es cuando se realiza la documentación correspondiente. Esta fase aparece también, cuando el sistema no da los resultados deseados o se vuelve demasiado caro para seguir siendo desarrollado.

10. PRINCIPIOS DE XP

Los cuatro valores mencionados anteriormente – comunicación, simplicidad, feedback y coraje – nos brindan un estándar para obtener buenos resultados. Sin embargo, los valores son muy vagos a la hora de ayudarnos a decidir que prácticas utilizar. Para ello se necesita destilar estos valores en principios que puedan ser utilizados.

10.1 RAPIDA RETROALIMENTACIONEn la práctica el tiempo transcurrido entre una acción y su feedback es crítico. Tener una rápida retroalimentación nos permite interpretarla, aprender de ella y poner en práctica lo asimilado lo antes posible.

10.2 ASUMIR LA SIMPLICIDADEste es uno de los principios más difíciles de llevar a la práctica. Casi siempre se planifica para el futuro y se diseña 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.

10.3 CAMBIOS INCREMENTALESRealizar grandes cambios en una sola oportunidad no es una buena solución. Cada problema debe ser resuelto con una serie de cambios pequeños para poder atacar dicho problema mucho más en profundidad.

10.4 ACEPTAR EL CAMBIO EN XP1

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 más precisos.

10.5 TRABAJO DE CALIDADUno de los objetivos más 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.

10.6 OTROS PRINCIPIOSAdemás de los principios antes mencionados surgen algunos otros de menor trascendencia que pueden ayudar a tomar buenas decisiones en situaciones específicas.

Aceptar la responsabilidad Adaptación local Comunicación abierta y honesta Enseñar conocimientos Experimentos concretos Jugar para ganar Mediciones honestas Pequeña inversión inicial Trabajar con los instintos de las personas Viajar liviano

1

CONCLUSIONES

Ninguna práctica funciona bien por si sola (con la excepción de las pruebas). Requieren las otras prácticas para equilibrarse. La XP brinda no solo ventajas en cuanto a rapidez, sino que promueve habilidades sociales como la comunicación, el trabajo en equipo y disciplina. En XP la comunicación es vital tanto entre el grupo de desarrollo como con el cliente, el cual debe formar parte del equipo para mantener una comunicación fluida y poder de esta forma, evacuar cualquier tipo de duda que surja con los requerimientos. Es claro que no existe una metodología única para garantizar el éxito de cualquier proyecto de desarrollo de software, y esto aplica también a XP. Toda metodología requiere de cierta adaptación al proyecto, al cliente y a la idiosincrasia de la empresa desarrolladora. XP propone una metodología á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 también del cliente. La aplicabilidad de ésta metodología a cada proyecto debería ser analizada en cada caso, teniendo en cuenta el tamaño y tipo de proyecto, así como sus ventajas y desventajas.

1

REFERENCIAS

ECHEVERRY TOBÓN, Luis Miguel y DELGADO CARMONA, Luz Elena. Caso Práctico de la Mitología Ágil XP al Desarrollo de Software: 2007

AMARO CALDERON, Sarah Damaris y VALVERDE REBAZA, Jorge Carlos. Metodologías Ágiles: 2007

Programación Extrema

CALERO SOLIS, Manuel. Una Explicación de la Programación Extrema (XP): 2003

CALABRIA, Luis y PIRIZ, Pablo. Metodología XP: 2003 32

1