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

INDICE

DEDICATORIA
INTRODUCCIÓN
MARCO TEORICO
CAPITULO I: ¿QUÉ ES PROGRAMACION ESTREMA XP (EXTREME
PROGRAMMING)?
1. METODOLOGIA AGIL
2. DIFERENCIAS ENTRE METODLOGIAS AGILES Y NO AGILES
3. XP-EXTREME PROGRAMMIN XP
4. HISTORIA
5. OBJETIVOS DE XP
6. LA FILOSOFIA XP
7. VALORES XP
7.1. COMINICACION
7.2. SIMPLICIDAD
7.3. FEEDBACK
7.4. CORAJE
8. COSTE DEL CAMBIO
9. CICLO DE VIDA XP
 EXPLORACION
 PLANIFICACION
 ITERACIONES POR ENTREGAS
 PRODUCCION
 MANTENIMIENTO
 MUERTE
10. PRINCIPIOS DE XP
10.1 RÁPIDA RETROALIMENTACIÓ
10.2 ASUMIR LA SIMPLICIDAD
10.3 CAMBIOS INCREMENTALES
10.4 ACEPTAR EL CAMBIO
10.5 TRABAJO DE CALIDAD
10.6 OTROS PRINCIPIOS

7
7
8
9
9
10
10
11
11
11
12
12
12
14
14
14
14
14
15
15
15
15
15
15
16
16
16

CAPITULO II: FACES DE LA METODOLOGIA XP
1. PLANEACION
1.1. HISTORIAS DE USUARIO.
1.2. VELOCIDAD DEL PROYECTO.
1.3. ITERACIONES.
1.4. ENTREGAS PEQUEÑAS.
1.5. REUNIONES.
1.6. ROLES EN XP.

16
16
17
17
17
18
18
18

5
6
7

2

2.

3.

4.

1.7. TRASLADO DEL PERSONAL.
1.8. AJUSTE A XP.
DISEÑO
2.1. SIMPLICIDAD EN EL DISEÑO.
2.2. METÁFORA DEL SISTEMA.
2.3. TARJETAS CRC.
2.4. SPIKE SOLUTION.
2.5 NO SOLUCIONAR ANTES DE TIEMPO
2.6 REFACTORIZACIÓN
DESARROLLO
3.1. CLIENTE SIEMPRE PRESENTE.
3.2. CODIFICAR PRIMERO LA PRUEBA.
3.3. PROGRAMACION EN PAREJAS
3.4. INTEGRACIÓN SECUENCIAL.
3.5. INTEGRACIONES FRECUENTES.
PRUEBAS
4.1. PRUEBAS UNITARIAS
4.2. PRUEVAS DE ACEPTACIÓN
4.3. CUANDO SE ENCUENTRA UN ERROR

CAPITULO III: EJMPLO CASO PRACTICO
DESCRIPCION DEL NEGOCIO
HERRAMIENTAS EMPLEADAS
1. CODIFICACION
CLIENTE SIEMPRE PRESENTE
EL CODIGO SE ESCRIBE SIGUIENDO ESTANDARES
CODIFICAR PRIMERO LA PRUEBA
TODA LA PRODUCCIÓN DE CODIGO DEBE SER HECHA EN
PAREJAS
NO TRABAJAR HORAS EXTRAS
2. DISEÑO
SIMPLICIDAD
TARJETAS CRC
SPIKE SOLUTION (SOLUCIONE RÁPIDA)
REFACTORIZACION
3. PLANEACIÓN
HISTORIA DE USUARIO
VELOCIDAD DEL PROYECTO
DIVISION EN ITERACIONES
ENTREGAS PEQUEÑAS
PLAN DE ENTREGAS
4. PRUEBAS
PRUEBAS UNITARIAS

18
19
19
19
20
20
20
20
21
21
21
21
22
22
22
22
23
23
23
23
23
24
24
24
24
24
25
25
25
25
25
26
26
27
27
29
29
29
29
30
30

3

PRUEBAS DE ACEPTACIÓN CONCLUCIONES REFERENCIAS 30 31 32 4 .

y hacen posible que nosotros seamos mejores personas en la sociedad.Dedicamos este trabajo al esfuerzo de nuestros padres para darnos la mejor educación. INTRODUCCION 5 .

surge Xtreme Programming. Kent Beck se convirtió en el padre de la programación extrema. Su origen está ligado a los constantes inconvenientes que se presentaban en proyectos con algunas características.Las metodologías agiles tienen un origen reciente en el entorno de la ingeniería de software comparada con las mitologías pesadas. Su creador. En la década de los 90. Marco Teórico 6 . mejor conocida como XP. en los cuales la utilización de las metodologías pesadas era motivo de fracaso. una nueva metodología catalogada entre las agiles por sus aportes al manifiesto ágil.

costo y con la requerida calidad. Metodología ágil A principios de la década del ’90. Durante 1996. 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. 7 .000 clases y 30. la cual costa de los valores. Prosiguiendo con una conceptualización importante sobre XP como metodología de desarrollo. principios y el alcance de la misma. 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. y consiste de 2. es puesto en operación en Mayo de 1997 casi respetando el calendario propuesto.000 empleados. diseño. El sistema.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.000 métodos. RAD consistía en un entorno de desarrollo altamente productivo. Finalmente se entra en detalle con cada una de las etapas de desarrollo (planeación.eXtreme Programming. codificación y pruebas) describiendo cada uno de los aspectos que la componen. Beck es llamado por Chrysler como asesor del proyecto Chrysler Comprehensive Compensation (C3) payroll system. 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. documento q sirve como punto de partida para las metodologías que reciben el mismo nombre. se considera que este fue uno de los primeros hitos en pos de la agilidad en los procesos de desarrollo. En general. 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 de RAD o Rapid Application Development. CAPÍTULO I: ¿QUÉ PROGRAMMING)? ES PROGRAMACION EXTREMA XP (EXTREME 1. 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 . Como consecuencia del éxito de dicho proyecto. que nace de la mente de Kent Beck. 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. Dada la poca calidad del sistema que se estaba desarrollando. que administra la liquidación de aproximadamente 10. tomando ideas recopiladas junto a Ward Cunningham. Se inicia don una descripción de general de metodologías agiles.

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. Estas diferencias que afectan no sólo al proceso en sí. aún no contaban con una aprobación pues se le consideraba por muchos desarrolladores como meramente intuitiva. Sin embargo. la problemática sería definir cada una de las prácticas. sino también al contexto del equipo así como a su organización. nace formalmente el término “ágil” aplicado al desarrollo de software. sin ánimo de lucro. Tras esta reunión se creó The Agile Alliance. De esta manera podríamos tener una metodología para cada proyecto. Luego. Tener metodologías diferentes para aplicar de acuerdo con el proyecto que se desarrolle resulta una idea interesante. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales. 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. y en el momento preciso definir parámetros para saber cuál usar. con el pasar de los años. 2. tras una reunión celebrada en Utah-EEUU. En esta misma reunión participan un grupo de 17 expertos de la industria del software. una organización. caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas. sin embargo. 8 . en febrero de 2001. Estas metodologías pueden involucrar prácticas tanto de metodologías ágiles como de metodologías tradicionales. El punto de partida fue el Manifiesto Ágil. un documento que resume la filosofía “ágil”. dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que adopten dichos conceptos. 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”). Es importante tener en cuenta que el uso de un método ágil no es para todos.Es así como que este tipo de metodologías fueron inicialmente llamadas “metodologías livianas”.

simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. Inclusive Addison-Wesley ha creado una serie de libros denominada The XP Series. y donde existe un alto riesgo técnico.eXtreme Programming XP es la primera metodología ágil y la que le dio conciencia al movimiento actual de metodologías ágiles. roles. Cada perilla representaba una práctica que de su experiencia sabía que trabajaba bien. Historia 9 . XP. XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en el desarrollo de software. XP ha conformado un extenso grupo de seguidores en todo el mundo. promoviendo el trabajo en equipo. La imagen mental de Beck al crear XP era la de perillas en un tablero de control. A continuación presentaremos las características esenciales de XP organizadas en los tres apartados siguientes: historias de usuario. Así fue como dio inicio a XP. proceso y prácticas.3. 4. preocupándose por el aprendizaje de los desarrolladores. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo. y propiciando un buen clima de trabajo. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes. comunicación fluida entre todos los participantes. disparando una gran cantidad de libros a los que dio comienzo el mismo Beck en. Beck decidió girar todas las perillas al máximo para ver que ocurría. Entonces. De la mano de Kent Beck.

El verano de 1996. Objetivos de XP 10 . 5. Este hecho. 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. Eventualmente. de lo que era y cómo realizarla. 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". 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. Chrysler Corporation hacía tiempo que estaba desarrollando una aplicación de nóminas. Beck entró en nómina en la compañía y se le pidió de hacer esta aplicación como trabajo. y debido a ésto. Ward Cunningham o Ron Jeffries entre otros) de la Programación Extrema. fueron a la web Portland Pattern Repository y empezaron a hablar de ella y promocionarla. que la implementación fuera sencilla. los propulsores como el propio Kent Beck. 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. poco o mucho hablara de temas de programación. los cuales se tenían que acomodar al cambio a realizar. como proceso de creación de software diferente al convencional. Es en esta aplicación cuando nace la Programación Extrema como tal. Estos propulsores de la XP hablaban de ella en cada ocasión que tenían y en cada página que. Las ideas primordiales de su sistema las comunicó en la revista C++ Magazine en una entrevista que ésta le hizo el año 1999. llegó a molestar a buena parte de la comunidad que intentaba discutir sobre temas de programación. En ésta decía que él estaba convencido que la mejor metodología era un proceso que enfatizase la comunicación dentro del equipo.La Programación Extrema. pero sin demasiado éxito por parte de la gente que tenía en el proyecto. nace de la mano de Kent Beck (gurú de la XP y autor de los libros más influyentes sobre el tema). Los autores (o mejor dicho. Él tenía varias ideas de metodologías para la realización de programas que eran cruciales para el buen desarrollo de cualquier sistema. 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 comunidad empezó a referirse a estos sitios como a Salas Wiki (Wards Wiki).

Coraje. Esta metodología trata de dar al cliente el software que él necesita y cuando lo necesita. Tanto los jefes de proyecto. Esto es posible porque está diseñado para adaptarse en forma inmediata a los cambios. XP asume el cambio como algo natural. 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. indefectiblemente. Garantizarla Calidad del Software desarrollando.Los objetivos de XP son muy simples: la satisfacción del cliente. son parte del equipo y están involucrados en el desarrollo del software. 11 . En XP se realiza el software que el cliente solicita y necesita. XP “abraza” el cambio. Por tanto. en alguna etapa de un proyecto sucede. en cualquier etapa del ciclo de vida. incluso cuando los cambios sean al final de ciclo de la programación. evitando retroceder cuando sea demasiado tarde. y que. 6. codificación y pruebas se puede decidir si se está siguiendo un camino correcto o equivocado. 7. Simplicidad. Feedback. haciendo que este supere las expectativas del cliente. Estos valores son:     Comunicación. desarrollando software cuando los requerimientos son ambiguos o rápidamente cambiantes. Potenciar al máximo el trabajo en grupo. debemos responder muy rápido a las necesidades del cliente. en el momento que lo precisa. En pocas palabras. Asumir que con cierta planificación. los clientes y desarrolladores. Mejorar la productividad de los proyectos. A diferencia de los procesos tradicionales para desarrollar software. con bajos costos asociados. alentando a los programadores a responder a los requerimientos cambiantes que plantea el cliente en cualquier momento. La filosofía de XP XP es una metodología ágil para pequeños y medianos equipos. EstablecerlasmejoresprácticasdeIngenieríadeSoftwareenlosdesarrollodep royectos.

Con esto se pretende agregar nueva funcionalidad que cumpla con los objetivos actuales sin necesidad de preocuparse por futuros requerimientos. el uso de estándares o la estimación de las tareas. un cliente le dice al programador algo importante y este no le presta atención. programación por pares. 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. En cualquiera de los casos la comunicación es un factor importante en cualquier tipo de proyecto. Esto hace que se progrese de manera más segura y rápida en el proyecto. De esta manera se puede avanzar rápidamente y de forma efectiva. haciendo énfasis en la interacción personal. Además. La mala comunicación no surge por casualidad en un proyecto y pueden aparecer muchas circunstancias que hagan que esta falle. 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. De esta forma. realizando solo la documentación necesaria.2 Simplicidad La simplicidad es el segundo valor que se utiliza en esta metodología. Muchas de estas prácticas hacen corto circuito si no hay buena comunicación como en el caso de los testing unitarios. En otras ocasiones se hace uso del refactoring1 que permite mantener el código en funcionamiento pero mucho más simple y organizado. se planifica con el cliente y este puede estar al tanto del avance del proyecto. 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. un programador le da malas noticias al gerente y este lo castiga.1 Comunicación Uno de los valores más importantes en XP es la comunicación. 7. La comunicación con el cliente es de vital importancia en XP y es por este motivo que el cliente es integrado al equipo. a realizar algo más complicado hoy y no utilizarlo nunca. XP apuesta a realizar algo simple hoy y destinar un poco más de esfuerzo para realizar un cambio en el futuro. 12 . XP ha sido diseñada para minimizar el grado de documentación como forma de comunicación. XP propone una regla muy simple: “hacer algo que funcione de la manera más sencilla”. Otra regla muy importante es: “realizar solo lo necesario”.7. cualquier duda sobre los requerimientos puede ser evacuada inmediatamente.

7. Si no hay coraje en un proyecto no se puede clasificar como extremo y es necesario que los otros tres valores estén presentes. el cliente está al tanto del avance del proyecto. el cual se convierte en el objetivo de XP. el sistema es puesto en producción en menor tiempo. 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.7. 8. El otro tipo de feedback que se realiza es a través de pequeñas entregas del sistema. El feedback trabaja a diferentes escalas de tiempo. Uno es el feedback que se realiza minuto a minuto. Como se ve en la siguiente figura la comunicación. 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. Esto hace. por tanto se pretende conseguir esto: 13 . diseñar e implementar solo lo necesario para el presente. Además.4 Coraje Obviamente cada uno de los valores antes mencionados tiene una gran interacción entre ellos. la simplicidad y el feedback forman el coraje. pedir ayuda o reducir el alcance de una entrega si el tiempo no alcanza. 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 coraje también es poder realizar cambios cuando algo no funciona del todo bien. 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.3 Feedback Brindar un feedback correcto y preciso hace que se pueda mantener una buena comunicación y conocer el estado actual del proyecto. 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 cómo lo haces. con lo cual los programadores saben si realizaron un buen trabajo y si sus decisiones fueron acertadas. a que por ejemplo. 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”. De esta manera.

no existe una forma mágica desde luego hay varias medidas que nos ayudan a conseguirla. para hacer sólo lo imprescindible en un momento dado. podemos idear una aproximación para desarrollar software en la que se tomen decisiones rápidamente. He oído a muchos programadores (entre los que me incluyo) decir: “Hasta que no he terminado el programa no lo he entendido ahora lo haría con esta jerarquía y que esta clase herede de esta otra”. dejemos pues abierta la puesta a esta posibilidad.Si decidimos aceptar el cambio debemos de desarrollar para basarnos en dicha curva. Diseñar lo más sencillo que sea posible. 14 . 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 quería tocar. 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. 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. pero ¿cómo se consigue dicha curva?. 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 del software. cada mensaje a un objeto es una oportunidad de cambio sin necesidad de cambiar el código existente.

 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. Iterations to Release. Durante esta fase suele suceder que las iteraciones se aceleren de tres a una semana. El cliente decide que stories van a ser implementadas para cada iteración. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas. La duración del calendario para la entrega del primer release no suele superar los dos meses. Esto se logra seleccionando las stories que hagan referencia a la construcción de la estructura de todo el sistema. Los programadores estiman cuanto esfuerzo requiere cada story y se establece el cronograma. En algunos casos se utiliza un prototipo para testear la nueva tecnología y explorar algunos aspectos de la arquitectura a ser implementada. realizados por el cliente. Producción.  Exploración En esta fase los clientes realizan las story cards que desean que estén para la primera entrega. En la primera iteración se crea un sistema que abarca los aspectos más importantes de la arquitectura global. al final de cada iteración. en la fase de mantenimiento. La duración de esta fase puede extenderse desde unas pocas semanas a varios meses dependiendo de la adaptación del equipo de desarrollo.9. Duración de la fase de planificación en sí no toma más de dos días. Planificación. Mantenimiento y Muerte. Ciclo de Vida de XP El ciclo de vida de XP consiste básicamente de seis fases: Exploración.  Producción La fase de producción requiere realizar muchos más chequeos y testing antes que el sistema sea entregado al cliente. por ejemplo. 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.  Iteraciones por entregas Esta fase incluye varias iteraciones del sistema antes de la entrega del primer release. Además. Las ideas pospuestas y las sugerencias son documentadas para luego ser implementadas más adelante. En esta fase aparecen nuevos cambios y se tiene que decidir si serán incorporados o no en dicha entrega. Al final de la última iteración el sistema está listo para ser puesto en producción. la tecnología y las prácticas a ser utilizadas durante el proyecto. se realizan los test funcionales. Cada story describe una de las funcionalidades que el programa tendrá. 15 .

Esta fase aparece también.  Mantenimiento En esta fase por lo general se necesita un esfuerzo extra de los programadores para satisfacer los requerimientos del cliente.2 Asumir la Simplicidad Este es uno de los principios más difíciles de llevar a la práctica. cuando el sistema no da los resultados deseados o se vuelve demasiado caro para seguir siendo desarrollado. Sin embargo. 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. 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. el proyecto debe mantener el sistema en producción corriendo mientas se trabaja en las nuevas iteraciones. 10. A raíz de esto se requiere incorporar nuevos integrantes al equipo y cambiar la estructura del equipo. 10. 10. feedback y coraje – nos brindan un estándar para obtener buenos resultados.Luego que el primer release es creado. Principios de XP Los cuatro valores mencionados anteriormente – comunicación. simplicidad.3 Cambios Incrementales 16 . Tener una rápida retroalimentación nos permite interpretarla.  Muerte Esta última fase se acerca una vez que el cliente no tiene ninguna story a ser implementada. Casi siempre se planifica para el futuro y se diseña para poder rehusar.1 Rápida Retroalimentación En la práctica el tiempo transcurrido entre una acción y su feedback es crítico. Para ello se necesita destilar estos valores en principios que puedan ser utilizados. 10. los valores son muy vagos a la hora de ayudarnos a decidir que prácticas utilizar. aprender de ella y poner en práctica lo asimilado lo antes posible. Por este motivo la velocidad de desarrollo suele disminuir una vez que el sistema es puesto en producción.

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.Realizar grandes cambios en una sola oportunidad no es una buena solución. 10. La mejor estrategia es aquella que preserva la mayor cantidad de opciones mientras resuelve los problemas más precisos. Si cada integrante realiza su trabajo de la mejor manera posible se puede asegurar la calidad del producto. 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. 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 XP el cambio es asimilado como algo habitual e inevitable. 17 .5 Trabajo de Calidad Uno de los objetivos más importantes en XP es realizar un producto de buena calidad. En este punto se comienza a interactuar con el cliente y el resto del grupo de desarrollo para descubrir los requerimientos del sistema. PLANEACIÓN La planeación es la etapa inicial de todo proyecto en XP. 10.           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.

de allí se obtiene el concepto de metodología iterativa. sin profundizar en detalles. Ajuste A XP. los proyectos constan de más de tres etapas. no del desarrollador. Roles En XP.En este apartado se tendrán en cuenta ocho elementos. Velocidad Del Proyecto. Cabe recordar que la velocidad del proyecto ayuda a determinar la cantidad de historias que se pueden implementar en las siguientes iteraciones. 1. Al final de la iteración se obtiene como resultado la 18 . Las historias de usuario también son utilizadas para estimar el tiempo que el equipo de desarrollo tomará para realizar las entregas. Iteraciones Por lo general. Son pequeños textos en los que el cliente describe una actividad que realizará el sistema.1. los cuales son los siguientes:         Historias De Usuario. 1. Entregas Pequeñas. Reuniones.3. Iteraciones. Esta medida se calcula totalizando el número de historias de usuario realizadas en una iteración. de forma que sea clara y sencilla. Historias de usuario Las historias de usuario son utilizadas como herramienta para dar a conocer los requerimientos del sistema al equipo de desarrollo. la redacción de los mismos se realiza bajo la terminología del cliente. Para la iteración siguiente se podrá (teóricamente) implementar el mismo número de historias de usuario que en la iteración anterior.2. Traslado Del Personal. aunque no de manera exacta. las cuales toman el nombre de iteraciones. Para cada iteración se define un módulo o conjunto de historias que se van a implementar. En una entrega se puede desarrollar una o varias historias de usuario. 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. esto depende del tiempo que demore la implementación de cada una de las mismas. 1.

Los programadores son quienes construyen el sistema y realizan las pruebas correspondientes a cada módulo o unidad de código.entrega del módulo correspondiente. además de decidir el orden en que se entregarán cada segmento del proyecto. es por ello que XP requiere de una revisión continua del plan de trabajo. al final de la cual habrá una entrega de los avances del producto. junto al cliente.5. 1. 1. Las tareas que no se realicen en una iteración son tomadas en cuenta para la próxima iteración. A pesar de ser una metodología que evita la documentación exagerada. los cuales deberán ser completamente funcionales. colabora en la realización de las pruebas de aceptación y es quien muestra los resultados de las mismas.  El usuario o cliente determina qué se va a construir en el sistema. es muy estricta en la organización del trabajo. si se deben realizar o si deben ser removidas de la planeación del sistema. Reuniones El planeamiento es esencial para cualquier tipo de metodología. Estas entregas deben caracterizarse por ser frecuentes.  El rastreador (tracker) tiene como tarea observar la realización del sistema. donde se define.  En el grupo de los programadores se encuentran además los diseñadores y los analistas.  El tester o quien realiza las pruebas. 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. Varias veces por semana cuestiona a los integrantes del equipo para anotar sus logros y avances. el cual debe haber superado las pruebas de aceptación que establece el cliente para la verificar el cumplimiento de los requisitos. Entregas pequeñas La duración de una iteración varía entre una y tres semanas.7. 1.4. Traslado del personal 19 . 1.6.

Los aspectos que se tratarán a continuación son:     Simplicidad En El Diseño. Eso no quiere decir que los desarrolladores pueden hacer lo que se les antoje. 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. este debe ser discutido y aprobado por el grupo. 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. 2. sin embargo no se debe dudar en modificar aquellos aspectos en que no funcione. se considera un desperdicio de tiempo. 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.Al mover el personal se evitan problemas relacionados con la pérdida de conocimiento y cuellos de botella. Antes de implementarse un cambio. Al iniciar el proyecto se debe aplicar XP tal como es. Figura 2: rotación de parejas.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. Metáfora Del Sistema. el hacer un diseño muy extenso en las fases iniciales el proyecto para luego modificarlo. Spike Solution. 20 . 1. El segundo motivo es que dada la naturaleza cambiante del proyecto. Tarjetas Crc.

 No Solucionar Antes De Tiempo. y que estos correspondan a un sistema de nombres consistente. 2. Se considera que un diseño sencillo se logra más rápido y se implementa en menos tiempo.  Refactoring. 2. Tarjetas de clase. prestando atención a los mensajes que éstas se transmiten mientras los demás miembros del grupo que permanecen sentados.5. esta es una práctica ineficiente. 2. Según mediciones. Puede ser burda y simple. concluyendo que tan solo el 10% de las soluciones para el 21 . Soluciones puntuales (Spike Solution) 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. Simplicidad En El Diseño Una de las partes más importantes de la filosofía XP es la simplicidad en todos los aspectos. siempre que brinde la información suficiente para enfrentar el problema encontrado. No Solucionar Antes De Tiempo Los desarrolladores tienden a predecir las necesidades futuras e implementarlas antes.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. 2.4. es ayudar a dejar el pensamiento procedimental para incorporarse al enfoque orientado a objetos. La idea es que se haga el diseño más sencillo que cumpla con los requerimientos de las historias de usuario. por lo cual esto es lo que se busca. participan en la discusión obteniendo así lo que puede considerarse un diagrama de clases preliminar. Esto será de mucha utilidad en fases posteriores del desarrollo para identificar aspectos importantes del sistema. 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.1.3. responsabilidad. colaboración (CRC cards) La principal funcionalidad que tienen estas.

A continuación una descripción de los siguientes temas:      3.6. Codificar Primero La Prueba. debería ser parte de éste. Cliente Siempre Presente. para garantizar que lo implementado cubre con las necesidades planteadas en las historias de usuario. 3.2. 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. 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. funcionalidad no necesaria o aspecto en general por corregir. En este sentido se convierte en gran ayuda al solucionar todas las dudas que puedan surgir. Integraciones Frecuentes. En cada inspección que se encuentre alguna redundancia. desperdiciando complicando el diseño innecesariamente. Codificar Primero La Prueba 22 . 2. Secuencial. olvidando por completo cualquier necesidad que se pueda presentar en el futuro. No solamente para solucionar las dudas del grupo de desarrollo. Cliente Siempre Presente Uno de los requerimientos de XP es que el cliente esté siempre disponible.futuro son utilizadas.1. tiempo de desarrollo y En XP sólo se analiza lo que se desarrollará en la iteración actual. lo que supone uno de los preceptos más radicales de la programación extrema. especialmente cara a cara. Integración. Refactorización (Refactoring) La refactorización en el código pretende conservarlo tan sencillo y fácil de mantener como sea posible. 3.

además de la ventaja que representa contar con un compañero que ayude a solucionar inconvenientes en tiempo de codificación. como darle propiedad de determinadas clases a algunos desarrolladores. los cuales son los responsables de mantenerlas actualizadas y consistentes. 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. ya que habrán pasado todas las pruebas. 3. 3. Sin embargo. 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.3. 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.Una de las ventajas de crear una prueba antes que el código es que permite identificar los requerimientos de dicho código.4. Para saldar este problema han surgido muchos mecanismos.5. En otras palabras. sean evitados por completo. los cuales se presentan con mucha frecuencia. 23 . Integración Secuencial Uno de los mayores inconvenientes presentados en proyectos de software tiene que ver con la integración. 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. 3. 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 el desarrollador sabrá con completa certeza en qué momento ha terminado. De esta forma se garantiza surjan problemas como que un programador trabaje sobre versiones obsoletas de alguna clase. sobre todo si todos los programadores son dueños de todo el código. 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.

que representan un resultado esperado de determinada transacción con el sistema. este temor se mitiga en gran medida. En todas las iteraciones. de las cuales deberán determinar los casos de prueba e identificar los errores que serán corregidos. permitiéndole al programador tener máxima claridad sobre lo que va a programar antes de hacerlo. lo que optimizará su trabajo y su código será de mejor calidad. PRUEBAS Del buen uso de las pruebas depende el éxito de otras prácticas. cada una de las historias de usuario seleccionadas por el cliente deberá tener una o más pruebas de aceptación.1.2.3. 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. tales como la propiedad colectiva del código y la refactorización. Cuando se Encuentra un Error 24 . 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. 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. también llamadas pruebas funcionales son supervisadas por el cliente basándose en los requerimientos tomados de las historias de usuario. 4. las pruebas mostrarán el error y permitirán encontrarlo. así como conocer cada uno de los casos de prueba que deberá pasar. Sólo se deberá liberar una nueva versión si esta ha pasado con el cien por ciento de la totalidad de las pruebas. 4. 4. Según XP se debe ser muy estricto con las pruebas. Uno de los elementos más importantes en estas es que idealmente deben ser construidas antes que los métodos mismos. Si se tiene un grupo de pruebas que garantice su buen funcionamiento. Las pruebas de aceptación son pruebas de caja negra.4. Pruebas de Aceptación Las pruebas de aceptación. En caso contrario se empleará el resultado de estas para identificar el error y solucionarlo con mecanismos ya definidos.

el negocio contaba con una caja registradora convencional la cual no ofrecía las funcionalidades que requería el cliente. Al momento de iniciar el proyecto. 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.Al momento de encontrar un error debe escribirse una prueba antes de intentar corregirlo. CODIFICACIÓN Entre los elementos más importantes que menciona XP referentes a la codificación están: • Cliente siempre presente 25 . Por otro lado se logrará evitar volver a cometerlo. 1. Por un lado se empleó JAVA como herramienta de desarrollo mientras que como motor de base de datos se decidió por PostgreSQL. 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. Herramientas Empleadas Se optó por seleccionar herramientas libres para el desarrollo de la aplicación. por lo cual se acordó desarrollar un 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.

que los mismos venían siendo empleados desde antes por el equipo de desarrollo. 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. 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. 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. la herramienta empleada para desarrollar facilitaba el aplicar dichos estándares y en segundo.  La estandarización del código fue asumida desde el mismo momento en que se inició la codificación. El código se escribe siguiendo estándares.  Por tal motivo se debió implementar una estrategia de comunicación distinta. tenían conocimientos elevados sobre todas las herramientas que se emplearon. Codificar primero la prueba ¿Se trata de codificar SIEMPRE una prueba antes que el código. fue suficiente para lograr una buena comunicación con el cliente. que en definitiva son las más importantes y de las cuales se debe tener garantía de estar muy bien construidas. en la cual los programadores podían llamar vía telefónica al cliente en el momento que requirieran solucionar cualquier duda. En el caso de ambos desarrolladores. En primer lugar. por lo cual el nivel de autonomía fue superior.  Si bien esta estrategia no fue igual de efectiva que haber tenido al usuario acompañando el desarrollo.  En el caso de este proyecto se aplicaron todos los estándares con gran éxito debido a dos motivos.• • • • 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. 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 lógica del negocio. 26 .

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. Cada Tarjeta CRC se convirtió en un objeto. 27 . 2. elaborado para modelar la base de datos. se acogió la recomendación de XP. 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. sus responsabilidades en métodos públicos y sus colaboradores en llamados a otras clases. sólo invirtiendo el tiempo exclusivamente necesario en elaboración de diagramas y diseño de interfaz gráfica. sino que también fueron la base del modelo Entidad Relación. DISEÑO Entre los elementos más importantes que menciona XP referentes al diseño están: •Simplicidad •Las tarjetas CRC •El Refactoring •Spike Solution SIMPLICIDAD En lo que respecta a la sencillez del diseño.

El estudio de esta fue encargado a uno de los desarrolladores. La mejor solución encontrada fue JasperReport. sin que retrasara sus demás responsabilidades con el proyecto. la cual fue estudiada en el transcurso de la primera iteración por un desarrollador.En el proceso de elaboración de las tarjetas CRC los dos miembros del equipo estuvieron presentes manipulándolas. Por otro lado. el cual destinó aproximadamente ocho horas a su estudio. de modo tal que tanto el diseño fue producto de la participación de los dos desarrolladores. 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. 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. al término del cual se compartió la información al otro desarrollador tal como en el caso anterior. se requirió de una herramienta que permitiera crear reportes impresos de calidad de una forma sencilla. 28 .

los cuales son los siguientes. en ningún momento se convirtieron en cuellos de botella. 3. Como salida a estos problemas se optó por la refactorización de las partes afectadas. 29 . 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. conservando la simplicidad del código. fue él quien diseñó su contenido y dirigió la redacción de las mismas.REFACTORIZACIÓN Al transcurrir el desarrollo de la aplicación. buscando las soluciones más convenientes y sencillas. Aunque estos cambios fueron extensos. PLANEACIÓN En la planeación se tendrán en cuenta varios elementos. • 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.

30 . Considerando por un lado la recomendación de que no sean menos de 20 ni más de 80. se hizo una reunión del equipo de trabajo donde se plantearon los tiempos necesarios para su implementación. Finalmente desde el punto de vista del número de historias de usuario. se obtuvo un total de veintiuno. 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. los cuales resultaron en estimaciones inusualmente aproximadas de los tiempos de desarrollo en comparación con los realmente requeridos.Desde el punto de vista del nivel de detalle.

31 .

32 .FIGURA 3: Historia de Usuario 1 FIGURA 3: Historia de Usuario 2 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. excepto en la última. Esto representó un éxito en el desarrollo del 33 . ya que se redujo la carga de obligaciones externas al proyecto. las cuales siempre fueron funcionales. por consiguiente se obtuvo un total de cuatro entregas para las cuales se desarrollaron partes de la aplicación completamente funcionales. fue al término de este plazo que se realizaron entregas. ENTREGAS PEQUEÑAS Debido a que las iteraciones tenían una duración de 15 días. En la planeación de iteraciones se tomaron dos semanas como período. la cual sólo se fijó para una semana. lo que quiere decir que al momento de la entrega estaban en condiciones de ser puestas en funcionamiento en las instalaciones del cliente. La primera iteración se refirió al módulo de POST mientras las demás iteraciones se relacionaron con la manipulación de inventarios.

4. 3. por tratarse de la actividad más importante en el negocio. se tomó como medida dos semanas.proyecto ya que mantenía el interés del cliente en continuarlo debido a que estaba viendo resultados en el corto plazo. 4. martes. Para aproximar el tiempo que demoraría cada iteración. éste resultaba de manera casi inmediata. lo cual no generó problemas en las entregas de los módulos funcionales. La clasificación de las historias no fue realizada estrictamente por su grado de importancia en el proyecto. Se realizaron tres reuniones iníciales. Sólo se optó por desarrollar el módulo de servicio al cliente en la primera iteración. pero al realizar la codificación del método. Cada semana constaba de cuatro días (lunes. PLAN DE ENTREGAS 1. 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. 2. Esto se considera una ventaja ya que se destina tiempo en la construcción de la prueba. incluyendo al cliente. La tarea de escoger las historias fue realizada por el grupo en conjunto. jueves y viernes) en los que se trabajaban cuatro horas sin distracciones. También se destaca la autonomía que deben 34 .

Pruebas de aceptación Tres elementos permitieron al grupo de desarrollo diseñar las pruebas de aceptación. el trabajo en equipo y disciplina. sino que promueve habilidades sociales como la comunicación.tener dichas pruebas a la hora de su ejecución. 35 . Requieren las otras prácticas para equilibrarse. CONCLUCIONES Ninguna práctica funciona bien por si sola (con la excepción de las pruebas). 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. se lo impidió. como ya es mencionada en otros apartados del documento. lo que implicaba la manipulación de la base de datos y la recuperación de su estado inicial al finalizar la prueba. En primer lugar el tipo de sistema implementado era suficientemente sencillo y conocido por todos los miembros del equipo de desarrollo. La XP brinda no solo ventajas en cuanto a rapidez.

Jorge Carlos. ver y hacer las cosas. Metodologías Ágiles: 2007 36 . el cual debe formar parte del equipo para mantener una comunicación fluida y poder de esta forma. como de los desarrolladores y también del cliente. aunque requiere de una nueva menara de pensar. al cliente y a la idiosincrasia de la empresa desarrolladora.En XP la comunicación es vital tanto entre el grupo de desarrollo como con el cliente. así como sus ventajas y desventajas. teniendo en cuenta el tamaño y tipo de proyecto. y esto aplica también a XP. XP propone una metodología ágil y concreta. Sarah Damaris y VALVERDE REBAZA. Es claro que no existe una metodología única para garantizar el éxito de cualquier proyecto de desarrollo de software. Luis Miguel y DELGADO CARMONA. REFERENCIAS ECHEVERRY TOBÓN. Caso Práctico de la Mitología Ágil XP al Desarrollo de Software: 2007 AMARO CALDERON. Toda metodología requiere de cierta adaptación al proyecto. evacuar cualquier tipo de duda que surja con los requerimientos. La aplicabilidad de ésta metodología a cada proyecto debería ser analizada en cada caso. tanto por parte de los gerentes (responsables de la rentabilidad general del proyecto). Luz Elena.

Programación Extrema CALERO SOLIS. Una Explicación de la Programación Extrema (XP): 2003 CALABRIA. Luis y PIRIZ. Manuel. Metodología XP: 2003 37 . Pablo.