UNIVERSIDAD NACIONAL DE TRUJILLO SEDE VALLE

JEQUETEPEQUE

FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS

ESCUELA PROFESIONAL DE INFORMATICA

METODLOGIAS ÁGILES PARA EL DESARROLLO DE SOFTWARE:

PROGRAMACIÓN EXTREMA XP (EXTREME PROGRAMMING)

GÁLVEZ ALCALDE, NILS

GONZALES HORNA, CHRISTIAN

TIRADO TORRES, JORDY

2

INDICE

DEDICATORIA 5

INTRODUCCIÓN 6

MARCO TEORICO 7

CAPITULO I: ¿QUÉ ES PROGRAMACION ESTREMA XP (EXTREME PROGRAMMING)? 7

1. METODOLOGIA AGIL 7

2. DIFERENCIAS ENTRE METODLOGIAS AGILES Y NO AGILES 8

3. XP-EXTREME PROGRAMMIN XP 9

4. HISTORIA 9

5. OBJETIVOS DE XP 10

6. LA FILOSOFIA XP 10

7. VALORES XP 11

7.1. COMINICACION 11

7.2. SIMPLICIDAD 11

7.3. FEEDBACK 12

7.4. CORAJE 12

8. COSTE DEL CAMBIO 12

9. CICLO DE VIDA XP 14

EXPLORACION 14

PLANIFICACION 14

ITERACIONES POR ENTREGAS 14

PRODUCCION 14

MANTENIMIENTO 15

MUERTE 15

10. PRINCIPIOS DE XP 15

10.1 RÁPIDA RETROALIMENTACIÓ 15

10.2 ASUMIR LA SIMPLICIDAD 15

10.3 CAMBIOS INCREMENTALES 15

10.4 ACEPTAR EL CAMBIO 16

10.5 TRABAJO DE CALIDAD 16

10.6 OTROS PRINCIPIOS 16

CAPITULO II: FACES DE LA METODOLOGIA XP 16

1. PLANEACION 16

1.1. HISTORIAS DE USUARIO. 17

1.2. VELOCIDAD DEL PROYECTO. 17

1.3. ITERACIONES. 17

1.4. ENTREGAS PEQUEÑAS. 18

3

1.5. REUNIONES. 18

1.6. ROLES EN XP. 18

1.7. TRASLADO DEL PERSONAL. 18

1.8. AJUSTE A XP. 19

2. DISEÑO 19

2.1. SIMPLICIDAD EN EL DISEÑO. 19

2.2. METÁFORA DEL SISTEMA. 20

2.3. TARJETAS CRC. 20

2.4. SPIKE SOLUTION. 20

2.5 NO SOLUCIONAR ANTES DE TIEMPO 20

2.6 REFACTORIZACIÓN 21

3. DESARROLLO 21

3.1. CLIENTE SIEMPRE PRESENTE. 21

3.2. CODIFICAR PRIMERO LA PRUEBA. 21

3.3. PROGRAMACION EN PAREJAS 22

3.4. INTEGRACIÓN SECUENCIAL. 22

3.5. INTEGRACIONES FRECUENTES. 22

4. PRUEBAS 22

4.1. PRUEBAS UNITARIAS 23

4.2. PRUEVAS DE ACEPTACIÓN 23

4.3. CUANDO SE ENCUENTRA UN ERROR 23

CAPITULO III: EJMPLO CASO PRACTICO 23

DESCRIPCION DEL NEGOCIO 23

HERRAMIENTAS EMPLEADAS 24

1. CODIFICACION 24

CLIENTE SIEMPRE PRESENTE 24

EL CODIGO SE ESCRIBE SIGUIENDO ESTANDARES 24

CODIFICAR PRIMERO LA PRUEBA 24

TODA LA PRODUCCIÓN DE CODIGO DEBE SER HECHA EN PAREJAS 25

NO TRABAJAR HORAS EXTRAS 25

2. DISEÑO 25

SIMPLICIDAD 25

TARJETAS CRC 25

SPIKE SOLUTION (SOLUCIONE RÁPIDA) 26

REFACTORIZACION 26

3. PLANEACIÓN 27

HISTORIA DE USUARIO 27

VELOCIDAD DEL PROYECTO 29

DIVISION EN ITERACIONES 29

ENTREGAS PEQUEÑAS 29

4

PLAN DE ENTREGAS 29

4. PRUEBAS 30

PRUEBAS UNITARIAS 30

PRUEBAS DE ACEPTACIÓN 30

CONCLUCIONES 31

REFERENCIAS 32

5

Dedicamos este trabajo al esfuerzo de nuestros

padres para darnos la mejor educación, y hacen

posible que nosotros seamos mejores personas en

la sociedad.

6

INTRODUCCION

Las metodologías agiles 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 al manifiesto ágil. Su creador, Kent Beck se

convirtió en el padre de la programación extrema.

7

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 don una descripción de general de metodologías agiles, documento q sirve como punto

de partida para las metodologías que reciben el mismo nombre. Prosiguiendo con una

conceptualización importante sobre XP como metodología de desarrollo, la cual costa de los

valores, principios y el alcance de la misma.

Finalmente se entra 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.

CAPÍTULO I: ¿QUÉ ES PROGRAMACION EXTREMA XP (EXTREME PROGRAMMING)?

1. Metodología ágil

A principios de la década del ’90, surgió un enfoque que fue bastanterevolucionario para su momento ya que iba en contra de toda creencia de quemediante 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 nombrede RAD o Rapid ApplicationDevelopment. RAD consistía en un entorno dedesarrollo altamente productivo, en el que participaban grupos pequeños deprogramadores utilizando herramientas que generaban código en formaautomá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 ComprehensiveCompensation (C3) payrollsystem. Dada la poca calidad del sistema que se estaba desarrollando, Beck decide tirar todo el código y empezar de cero utilizando las prácticas que él 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 Beck dio origen a XP iniciando el movimiento de metodologías ágiles al que se anexarían otras metodologías surgidas mucho antes que el propio Beck fuera convocado por Chrysler. 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

8

“á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 una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos 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 prácticas 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 sería definir cada una de las prácticas, y en el momento preciso definir parámetros para saber cuál usar. 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 ágiles es su peso inicialmente ligero y por eso las personas que no estén acostumbradas a seguir procesos encuentran estas metodologías bastante agradables.

9

3. XP- eXtremeProgramming

XP es la primera metodología ágil y la que le 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 a 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 equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un 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 Corporationhací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 a 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 ésta 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

10

la implementación fuera sencilla, que el usuario tenía que estar muy informado e 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 PatternRepositoryy 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 ocasión que tenían y en cada página que, poco o mucho hablara de temas de programación. Este hecho, llegó a molestar a buena parte de la comunidad que intentaba discutir sobre temas de programación. Fue tanta esta 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 ésto, 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 (Wards 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 él necesita y cuando lo necesita. Por tanto, debemos responder muy rápido a las necesidades del cliente, incluso cuando 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.

EstablecerlasmejoresprácticasdeIngenieríadeSoftwareenlosdesarrollodeproyectos. 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 filosofía de XP

XP es una metodología ágil para pequeños y medianos equipos, desarrollando software cuando los requerimientos son ambiguos o rápidamente 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 ynecesita, en el momento que lo precisa,

11

alentando a los programadores a responder a los requerimientos cambiantesque plantea el cliente en cualquier momento. Esto es posible porque está diseñado para adaptarse en formainmediata a los cambios, con bajos costos asociados, en cualquier etapa del ciclo de vida. En pocas palabras, XP“abraza” el cambio.

7. Valores en 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ón

Uno 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. XP ha sido diseñada para minimizar el grado de documentación como forma de comunicación, haciendo énfasis en la interacción personal. De esta manera se puede avanzar rápidamente y de forma efectiva, realizando solo la documentación necesaria. 7.2 Simplicidad

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 manera más sencilla”. En el caso de tener que añadir nueva funcionalidad al sistema se deben examinar todas las

12

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. 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 más segura y rápida en el proyecto.

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 la 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. 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. Si no hay coraje en un proyecto no se puede clasificar como extremo y es necesario que los otros tres valores estén presentes.

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

13

sistema que empleas hace que 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 sólo lo imprescindible en un momento dado, la simplicidad del código y los test continuos hacen 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 delsoftware, cada mensaje a un objeto es una oportunidad de cambio sin necesidad de cambiar elcódigo existente, esto no quiere decir que no puedas tener flexibilidad sin programar orientadoal objeto y el caso contrario que haya programas orientados a objetos que nadie quería tocar,sólo se dice que el programar orientado a objetos reduce el costo del cambio. En vez de tomar grandes decisiones al principio y pocas posteriormente, podemosidear 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 delsoftware cuando aprendas una mejor manera de diseñarlo. He oído a muchos programadores (entre los que me incluyo) decir: “Hasta que no heterminado el programa no lo he entendido ahora lo haría con esta jerarquía y que esta claseherede de esta otra”, dejemos pues abierta la puesta a esta posibilidad.

14

9. Ciclo de Vida de XP

El ciclo de vida de 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 las 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. En algunos casos se utiliza un prototipo para testear la nueva tecnología y explorar algunos aspectos de la arquitectura a ser implementada. La duración de esta fase puede extenderse desde unas pocas semanas a varios meses dependiendo de la adaptación del equipo de desarrollo.

Planificación

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 duración del calendario para la entrega del primer release no suele superar los dos meses. Duración de la fase de planificación en sí no toma más de dos días.

Iteraciones por entregas

Esta fase incluye varias iteraciones del sistema antes de la entrega del primer release. El calendario es dividido en un número 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. El cliente decide que stories van a ser implementadas para cada iteración. Además, se realizan los test funcionales, realizados por el cliente, al final de cada iteración. Al final de la última iteración el sistema está listo para ser puesto en producción.

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 pospuestas y las sugerencias son documentadas para luego ser implementadas más adelante, por ejemplo, en la fase de mantenimiento.

15

Luego que el primer release es creado, el proyecto debe mantener el sistema en producción 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 producción. A 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 más 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 Rápida Retroalimentación

En 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 Simplicidad

Este 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 Incrementales

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

16

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

10.5 Trabajo de Calidad

Uno 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 Principios

Ademá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

CAPITULO II: FACES DE LA METODOLOGIA XP

1. PLANEACIÓN

La planeación es la etapa inicial de todo proyecto en XP. En este punto se comienza a

interactuar con el cliente y el resto del grupo de desarrollo para descubrir los

requerimientos del sistema. En este punto se identifican el número y tamaño de las

iteraciones al igual que se plantean ajustes necesarios a la metodología según las

características del proyecto.

En este apartado se tendrán en cuenta ocho elementos, los cuales son los

siguientes:

Historias De Usuario.

Velocidad Del Proyecto.

Iteraciones.

17

Entregas Pequeñas.

Reuniones.

Roles En XP.

Traslado Del Personal.

Ajuste A XP.

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 pequeños textos en los

que el cliente describe una actividad que realizará el sistema; la redacción de los mismos

se realiza bajo la terminología del cliente, no del desarrollador, de forma que sea clara y

sencilla, sin profundizar en detalles.

Las historias de usuario también 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

implementación de cada una de las mismas.

1.2. Velocidad del proyecto

Es una medida de la capacidad que tiene el equipo de desarrollo para evacuar las

historias de usuario en una determinada iteración. Esta medida se calcula totalizando el

número de historias de usuario realizadas en una iteración. Para la iteración

siguiente se podrá (teóricamente) implementar el mismo número de historias de

usuario que en la iteración anterior.

Cabe recordar que la velocidad del proyecto ayuda a determinar la cantidad de historias

que se pueden implementar en las siguientes iteraciones, aunque no de manera

exacta.

1.3. Iteraciones

Por lo general, los proyectos constan de más de tres etapas, las cuales toman el nombre

de iteraciones, de allí se obtiene el concepto de metodología iterativa.

Para cada iteración se define un módulo o conjunto de historias que se van a

implementar. Al final de la iteración se obtiene como resultado la entrega del módulo

correspondiente, el cual debe haber superado las pruebas de aceptación que establece

el cliente para la verificar el cumplimiento de los requisitos. Las tareas que no se

realicen en una iteración son tomadas en cuenta para la próxima iteración, donde se

define, junto al cliente, si se deben realizar o si deben ser removidas de la planeación del

sistema.

18

1.4. Entregas pequeñas

La duración de una iteración varía entre una y tres semanas, al final de la cual habrá una

entrega de los avances del producto, los cuales deberán ser completamente

funcionales. Estas entregas deben caracterizarse por ser frecuentes.

1.5. Reuniones

El planeamiento es esencial para cualquier tipo de metodología, es por ello que XP

requiere de una revisión continua del plan de trabajo. A pesar de ser una metodología

que evita la documentación exagerada, es muy estricta en la organización del trabajo.

1.6. Roles en XP

El jefe de proyecto tiene como responsabilidad la dirección y organización de las

reuniones que se realizan durante el proyecto.

El usuario o cliente determina qué se va a construir en el sistema, además

de decidir el orden en que se entregarán cada segmento del proyecto.

En el grupo de los programadores se encuentran además los diseñadores y los

analistas. Los programadores son quienes construyen el sistema y realizan las

pruebas correspondientes a cada módulo o unidad de código.

El tester o quien realiza las pruebas, colabora en la realización de las pruebas de

aceptación y es quien muestra los resultados de las mismas.

El rastreador (tracker) tiene como tarea observar la realización del sistema.

Varias veces por semana cuestiona a los integrantes del equipo para anotar

sus logros y avances.

1.7. Traslado del personal

Al mover el personal se evitan problemas relacionados con la pérdida 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 programación en parejas se convierte en una herramienta muy importante para lograr

el objetivo del traslado de personal sin que se pierda el rendimiento.

19

Figura 2: rotación de parejas.

1.8. Ajuste a XP

Todos los proyectos tienen características específicas por lo cual XP puede ser

modificado para ajustarse bien al proyecto en cuestión. 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. DISEÑO

En XP solo se diseñan aquellas historias de usuario que el cliente ha seleccionado para la

iteración actual por dos motivos: por un lado se considera que no es posible tener un diseño

completo del sistema y sin errores desde el principio. El segundo motivo es que

dada la naturaleza cambiante del proyecto, el hacer un diseño muy extenso en las fases

iniciales el proyecto para luego modificarlo, se considera un desperdicio de tiempo.

Los aspectos que se tratarán a continuación son:

Simplicidad En El Diseño.

Metáfora Del Sistema.

Tarjetas Crc.

SpikeSolution.

No Solucionar Antes De Tiempo.

Refactoring.

2.1. Simplicidad En El Diseño

Una de las partes más importantes de la filosofía XP es la simplicidad en todos

los aspectos. Se considera que un diseño sencillo se logra más rápido y se

implementa en menos tiempo, por lo cual esto es lo que se busca. La idea es que se

20

haga el diseño más sencillo que cumpla con los requerimientos de las historias de

usuario.

2.2. Metáfora Del Sistema

Es muy importante dentro del desarrollo de la metáfora 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.3. Tarjetas de clase, responsabilidad, colaboración (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 diseñar el sistema por medio de las tarjetas CRC como

máximo dos personas se ponen de pie adicionando o modificando las tarjetas,

prestando atención a los mensajes que éstas se transmiten mientras los demás

miembros del grupo que permanecen sentados, participan en la discusión obteniendo

así lo que puede considerarse un diagrama de clases preliminar.

2.4. Soluciones puntuales (SpikeSolution)

Se trata de una pequeña aplicación completamente desconectada del proyecto con la

cual se intenta explorar el problema y propone una solución potencial. Puede ser burda

y simple, siempre que brinde la información suficiente para enfrentar el problema

encontrado.

2.5. No Solucionar Antes De Tiempo

Los desarrolladores tienden a predecir las necesidades futuras e implementarlas

antes. Según mediciones, esta es una práctica ineficiente, concluyendo que tan solo el

10% de las soluciones para el futuro son utilizadas, desperdiciando tiempo de

desarrollo y complicando el diseño innecesariamente.

En XP sólo se analiza lo que se desarrollará en la iteración actual, olvidando por

completo cualquier necesidad que se pueda presentar en el futuro, lo que

supone uno de los preceptos más radicales de la programación extrema.

21

2.6. Refactorización (Refactoring)

La refactorización en el código pretende conservarlo tan sencillo y fácil de mantener

como sea posible. En cada inspección que se encuentre alguna redundancia,

funcionalidad no necesaria o aspecto en general por corregir, se debe rehacer esa

sección de código con el fin de lograr las metas de sencillez tanto en el código en

sí mismo como en la lectura y mantenimiento.

3. DESARROLLO

El desarrollo es un proceso que se realiza en forma paralela con el diseño y la cual está

sujeta a varias observaciones por parte de XP consideradas controversiales por

algunos expertos tales como la rotación de los programadores o la programación en parejas.

A continuación una descripción de los siguientes temas:

Cliente Siempre Presente.

Codificar Primero La Prueba.

Integración.

Secuencial.

Integraciones Frecuentes.

3.1. Cliente Siempre Presente

Uno de los requerimientos de XP es que el cliente esté siempre disponible. No

solamente para solucionar las dudas del grupo de desarrollo, debería 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.

3.2. Codificar Primero La Prueba

Una de las ventajas de crear una prueba antes que el código es que permite identificar

los requerimientos de dicho código. En otras palabras, al escribir primero las

pruebas se encuentran de una forma más sencilla y con mayor claridad todos los casos

especiales que debe considerar el código a implementar. De esta forma el

desarrollador sabrá con completa certeza en qué momento ha terminado, ya que

habrán pasado todas las pruebas.

22

3.3. Programación En Parejas

Cuando se trabaja en parejas se obtiene un diseño de mejor calidad y un código

más organizado y con menores errores que si se trabajase solo, además de la

ventaja que representa contar con un compañero que ayude a solucionar

inconvenientes en tiempo de codificación, los cuales se presentan con mucha

frecuencia.

Se recomienda que mientras un miembro de la pareja se preocupa del método que se

está escribiendo el otro se ocupe de cómo encaja éste en el resto de la clase.

3.4. Integración Secuencial

Uno de los mayores inconvenientes presentados en proyectos de software tiene que

ver con la integración, sobre todo si todos los programadores son dueños de todo el

código. 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 del código no se solucionan los

problemas presentados por la comunicación entre clases.

3.5. Integraciones Frecuentes

Se deben hacer integraciones cada pocas horas y siempre que sea posible no

debe transcurrir más un día entre una integración y otra. De esta forma se

garantiza surjan problemas como que un programador trabaje sobre versiones

obsoletas de alguna clase.

Es evidente que entre más se tarde en encontrar un problema más costoso será

resolverlo y con la integración frecuente se garantiza que dichos problemas se

encuentre más rápido o aún mejor, sean evitados por completo.

4. PRUEBAS

Del buen uso de las pruebas depende el éxito de otras prácticas, tales como la propiedad

colectiva del código y la refactorización. Cuando se tienen bien implementadas las pruebas

no habrá temor de modificar el código del otro programador en el sentido que si se daña

alguna sección, las pruebas mostrarán el error y permitirán encontrarlo. Uno de los

elementos que podría obstaculizar que un programador cambie una sección de código

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.

23

Según XP se debe ser muy estricto con las pruebas. Sólo se deberá liberar una

nueva versión 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.

4.1. Pruebas Unitarias

Estas pruebas se aplican a todos los métodos no triviales de todas las clases del

proyecto con la condición que no se liberará ninguna clase que no tenga asociada su

correspondiente paquete de pruebas. Uno de los elementos más importantes en

estas es que idealmente deben ser construidas antes que los métodos mismos,

permitiéndole al programador tener máxima 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 código será de mejor calidad.

4.2. Pruebas de Aceptación

Las pruebas de aceptación, también llamadas pruebas funcionales son supervisadas

por el cliente basándose 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 más pruebas de aceptación, de las cuales deberán

determinar los casos de prueba e identificar los errores que serán corregidos.

Las pruebas de aceptación son pruebas de caja negra, que representan un resultado

esperado de determinada transacción con el sistema.

4.3. Cuando se Encuentra un Error

Al momento de encontrar un error debe escribirse una prueba antes de intentar corregirlo. De esta forma tanto el cliente logrará tener completamente claro cuál fue y dónde 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.

CAPITULO III: EJEMPLO DE CASO PRÁCTICO Descripción del negocio: Se trata de un mini mercado en formato de autoservicio con un capital de aproximadamente quince millones de pesos el cual atiende a una población alrededor de 550 familias ubicado en la zona de Altos de Llano Grande cerca al Parque Industrial en la ciudad de Pereira. Al momento de iniciar el proyecto, el negocio contaba con una caja registradora convencional la cual no ofrecía las funcionalidades que requería el cliente, por lo cual se acordó desarrollar un

24

software que desempeñara las funcionalidades de un sistema POS (Point Of Sale) con elementos de administración de inventario que cumpliera las necesidades específicas del cliente. Herramientas Empleadas Se optó por seleccionar herramientas libres para el desarrollo de la aplicación. Por un lado se empleó JAVA como herramienta de desarrollo mientras que como motor de base de datos se decidió por PostgreSQL. 1. CODIFICACIÓN

Entre los elementos más importantes que menciona XP referentes a la codificación están:

• Cliente siempre presente • El código se escribe siguiendo estándares • Toda la producción de código debe ser hecha en parejas • No trabajar horas Extras • Codificar primero la prueba Cliente siempre presente

En el caso de este proyecto, el cliente no podía desplazarse a ninguno de los lugares

de trabajo de los desarrolladores dado que debía estar al frente de su negocio.

Por tal motivo se debió implementar una estrategia de comunicación distinta, en la cual los programadores podían llamar vía telefónica al cliente en el momento que requirieran solucionar cualquier duda.

Si bien esta estrategia no fue igual de efectiva que haber tenido al usuario

acompañando el desarrollo, fue suficiente para lograr una buena comunicación con el cliente.

El código se escribe siguiendo estándares. La estandarización del código fue asumida desde el mismo momento en que se inició

la codificación.

En el caso de este proyecto se aplicaron todos los estándares con gran éxito debido a dos motivos. En primer lugar, la herramienta empleada para desarrollar facilitaba el aplicar dichos estándares y en segundo, que los mismos venían siendo empleados desde antes por el equipo de desarrollo.

Codificar primero la prueba

¿Se trata de codificar SIEMPRE una prueba antes que el código, o solo aquellas clases encargadas de realizar la lógica del negocio? Debido que XP no tiene una respuesta clara a esta inquietud el grupo de desarrollo optó por probar solo aquellas clases que ejecutan la

25

lógica del negocio, que en definitiva son las más importantes y de las cuales se debe tener garantía de estar muy bien construidas.

Toda la producción de código debe ser hecha en parejas El no contar con una sede permanente complicó seriamente el cumplimiento del objetivo de programar en parejas. En XP se tiene como salvedad para trabajar en parejas que uno o ambos de los

programadores sean expertos en la herramienta que se está empleando. En el caso de ambos desarrolladores, tenían conocimientos elevados sobre todas las herramientas que se emplearon, por lo cual el nivel de autonomía fue superior.

No trabajar horas Extras

El plantearse trabajar horas extras después de una jornada completa de desarrollo sugiere más una pérdida de tiempo que una recuperación de los atrasos del proyecto. En el caso de este proyecto no se trabajaron horas extras debido a que se tuvo la precaución de plantear plazos amplios en las entregas con el fin de considerar cualquier posible inconveniente que surgiera en la implementación.

2. DISEÑO

Entre los elementos más importantes que menciona XP referentes al diseño están:

•Simplicidad •Las tarjetas CRC •El Refactoring •SpikeSolution

SIMPLICIDAD

En lo que respecta a la sencillez del diseño, se acogió la recomendación de XP, sólo invirtiendo el tiempo exclusivamente necesario en elaboración de diagramas y diseño de interfaz gráfica.

TARJETAS CRC

Una de las principales piezas de diseño empleada en el proyecto fueron las tarjetas CRC que no sólo sirvieron como columna vertebral de este, sino que también fueron la base del modelo Entidad Relación, elaborado para modelar la base de datos. Cada Tarjeta CRC se convirtió en un objeto, sus responsabilidades en métodos públicos y sus colaboradores en llamados a otras clases. En el proceso de elaboración de las tarjetas CRC los dos miembros del equipo estuvieron presentes manipulándolas, de modo tal que tanto el diseño fue producto de la participación de los dos desarrolladores.

26

Tabla 1: Venta

SPIKE SOLUTION (SOLUCIÓN RÁPIDA)

Para implementar las pruebas tal como XP las recomienda se debió recurrir a una librería especialmente diseñada para tal fin, JUnit. El estudio de esta fue encargado a uno de losdesarrolladores, el cual destinó aproximadamente ocho horas a su estudio, al término de las cuales en un periodo no mayor a dos horas capacitó en el empleo de la librería al otro desarrollador. Por otro lado, se requirió de una herramienta que permitiera crear reportes impresos de calidad de una forma sencilla. La mejor solución encontrada fue JasperReport, la cual fue estudiada en el transcurso de la primera iteración por un desarrollador, al término del cual se compartió la información al otro desarrollador tal como en el caso anterior, sin que retrasara sus demás responsabilidades con el proyecto.

REFACTORIZACIÓN

Al transcurrir el desarrollo de la aplicación, se revisó constantemente el diseño de la misma surgiendo situaciones que no fueron tomadas en cuenta al comienzo del proyecto en el diseño general. Como salida a estos problemas se optó por la refactorización de las partes afectadas, buscando las soluciones más convenientes y sencillas, conservando la simplicidad del código. Aunque estos cambios fueron extensos, en ningún momento se convirtieron en cuellos de botella.

27

3. PLANEACIÓN En la planeación se tendrán en cuenta varios elementos, los cuales son los siguientes.

• Historias de usuario • Velocidad del proyecto • División de Iteraciones • Entregas Pequeñas • Plan de entregas

HISTORIA DE USUARIO

Si bien el cliente no fue quien escribió personalmente las historias de usuario, fue él quien diseñó su contenido y dirigió la redacción de las mismas. Desde el punto de vista del nivel de detalle, se siguió la directiva en el sentido de no profundizar ni en descripciones ni en procesos, manteniéndolas de esta forma breve y clara. Una vez recolectadas todas las historias de usuario, se hizo una reunión del equipo de trabajo donde se plantearon los tiempos necesarios para su implementación, los cuales resultaron en estimaciones inusualmente aproximadas de los tiempos de desarrollo en comparación con los realmente requeridos. Finalmente desde el punto de vista del número de historias de usuario, se obtuvo un total de veintiuno. Considerando por un lado la recomendación de que no sean menos de 20 ni más de 80.

28

FIGURA 3: Historia de Usuario 1

FIGURA 3: Historia de Usuario 2

29

VELOCIDAD DEL PROYECTO

El número de historias de usuario realizadas por iteración no fue una buena medida de la velocidad del proyecto debido que no todas tenían el mismo nivel de dificultad y por tanto el mismo requerimiento de horas de desarrollo.

Tabla 2°: Velocidad del Proyecto

DIVISIÓN EN ITERACIONES

El proyecto fue dividido en 4 iteraciones, por consiguiente se obtuvo un total de cuatro entregas para las cuales se desarrollaron partes de la aplicación completamente funcionales.

La primera iteración se refirió al módulo de POST mientras las demás iteraciones se relacionaron con la manipulación de inventarios.

En la planeación de iteraciones se tomaron dos semanas como período, excepto en la última, la cual sólo se fijó para una semana, ya que se redujo la carga de obligaciones externas al proyecto.

ENTREGAS PEQUEÑAS

Debido a que las iteraciones tenían una duración de 15 días, fue al término de este plazo que se realizaron entregas, las cuales siempre fueron funcionales, lo que quiere decir que al momento de la entrega estaban en condiciones de ser puestas en funcionamiento en las instalaciones del cliente. Esto representó un éxito en el desarrollo del proyecto ya que mantenía el interés del cliente en continuarlo debido a que estaba viendo resultados en el corto plazo.

PLAN DE ENTREGAS

1. Se realizaron tres reuniones iníciales.

2. La tarea de escoger las historias fue realizada por el grupo en conjunto,

incluyendo al cliente, lo cual no generó problemas en las entregas de los módulos funcionales.

30

3. La clasificación de las historias no fue realizada estrictamente por su grado de importancia en el proyecto. Sólo se optó por desarrollar el módulo de servicio al cliente en la primera iteración, por tratarse de la actividad más importante en el negocio.

4. Para aproximar el tiempo que demoraría cada iteración, se tomó como

medida dos semanas. Cada semana constaba de cuatro días (lunes, martes, jueves y viernes)en los que se trabajaban cuatro horas sin distracciones.

4. PRUEBAS

Pruebas unitarias

El carácter obligatorio de la escritura de las pruebas antes del desarrollo de los métodos del sistema implica un proceso de diseño previo. Esto se considera una ventaja ya que se destina tiempo en la construcción de la prueba, pero al realizar la codificación del método, éste resultaba de manera casi inmediata. También se destaca la autonomía que deben tener dichas pruebas a la hora de su ejecución, lo que implicaba la manipulación de la base de datos y la recuperación de su estado inicial al finalizar la prueba.

Pruebas de aceptación

Tres elementos permitieron al grupo de desarrollo diseñar las pruebas de aceptación. En primer lugar el tipo de sistema implementado era suficientemente sencillo y conocido por todos los miembros del equipo de desarrollo, en segundo lugar las reuniones de las cuales se obtuvieron las historias de usuario fueron grabadas en audio y video y en tercer lugar el cliente aceptó el delegar esta función de diseño de las pruebas debido que su disponibilidad de tiempo, como ya es mencionada en otros apartados del documento, se lo impidió.

31

CONCLUCIONES

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.

32

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