XP Informe

"Año de la Diversificación Productiva y del Fortalecimiento de la Educación"

UNIVERSIDAD NACIONAL DE TRUJILLOESCUELA ACADÉMICO PROFESIONAL DE INGENIERÍA DE SISTEMAS

TEMA:

“PROGRAMACIÓN EXTREMA”

ALUMNOS:

Alcalde Moncada Jhonatan

Campos Cabanillas Walter Wilmer

De Piérola Chávez Luis Alberto

Ulfe Isla José Alberto

CURSO:

Ingeniería de Software Aplicada a Objetos

CICLO:

VIII

Guadalupe Perú

2015

1

UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015

ContenidoCapítulo I Introducción y Reseña Histórica...................................................................................7

Introducción.................................................................................................................................8

Resumen......................................................................................................................................11

Abstract.......................................................................................................................................12

1. Reseña Histórica.................................................................................................................13

2. Conceptos Generales..........................................................................................................15

3. Definición............................................................................................................................15

4. Posturas a favor y en contra..............................................................................................16

5. Principios Básicos...............................................................................................................16

5.1. Retroalimentación a escala fina.................................................................................16

5.2. Proceso continuo en lugar de por lotes......................................................................18

5.3. Entendimiento compartido........................................................................................19

5.4. Bienestar del programador........................................................................................20

Capítulo II Fases de la metodología XP........................................................................................22

1. Proceso de desarrollo.........................................................................................................23

2. Interacción con el cliente....................................................................................................23

3. Historia de Usuario............................................................................................................23

3.1. En la primera fase......................................................................................................23

3.2. En la segunda fase......................................................................................................24

4. Planificación del proyecto..................................................................................................25

5. Diseño, desarrollo, pruebas................................................................................................26

6. Metáfora..............................................................................................................................27

7. Fases de la metodología XP................................................................................................29

7.1. Fase: Planificación del proyecto................................................................................29

7.2. Fase: Diseño................................................................................................................31

7.3. Fase: Codificación......................................................................................................32

7.4. Fase: Pruebas..............................................................................................................32

8. Valores de la metodología XP............................................................................................34

8.1. Simplicidad.................................................................................................................34

8.2. Comunicación.............................................................................................................35

METODOLOGOGÍA xp 2


8.3. Retroalimentación......................................................................................................35

8.4. Coraje o valentía.........................................................................................................36

9. Ventajas y Desventajas de la Metodología XP.................................................................36

10. Inconvenientes................................................................................................................36

11. Herramientas empleadas en XP....................................................................................37

11.1. JAVA.......................................................................................................................37

11.2. NETBeans...............................................................................................................37

11.3. JUnit........................................................................................................................37

11.4. JasperReport e IReport..........................................................................................37

11.5. PostgreSQL.............................................................................................................38

12. Tablas Comparativas de las Metodologías SCRUM y XP...........................................38

12.1. Semejanzas..............................................................................................................38

12.2. Diferencias...............................................................................................................39

13. Personas que intervienen en la Metodología XP..........................................................39

Capítulo III Conclusiones..............................................................................................................54

14. Conclusiones...................................................................................................................55

METODOLOGOGÍA xp 3


Índice de tablas

TABLA 1. PUNTOS A FAVOR Y EN CONTRA.......................................................................................16TABLA 2. PRUEBAS DE ACEPTACIÓN..................................................................................................17TABLA 3. HISTORIA DE USUARIO.........................................................................................................25TABLA 4. VENTAJAS Y DESVENTAJAS DE LA METODOLOGÍA XP.............................................36TABLA 5. COMPARACIÓN ENTRE METODOLOGÍAS.......................................................................39

METODOLOGOGÍA xp 4


Índice de figuras

FIGURA 1......................................................................................................................................................21FIGURA 2......................................................................................................................................................21FIGURA 3......................................................................................................................................................28FIGURA 4......................................................................................................................................................33FIGURA 5......................................................................................................................................................34

METODOLOGOGÍA xp 5

Capítulo IIntroducción y Reseña Histórica

6

IntroducciónEn las dos últimas décadas las notaciones de modelado y posteriormente las herramientas

pretendieron ser las "balas de plata" para el éxito en el desarrollo de software, sin embargo,

las expectativas no fueron satisfechas. Esto se debe en gran parte a que otro importante

elemento, la metodología de desarrollo, había sido postergado. De nada sirven buenas

notaciones y herramientas si no se proveen directivas para su aplicación. Así, esta década

ha comenzado con un creciente interés en metodologías de desarrollo. Hasta hace poco el

proceso de desarrollo llevaba asociada un marcado énfasis en el control del proceso

mediante una rigurosa definición de roles, actividades y artefactos, incluyendo modelado y

documentación detallada. Este esquema "tradicional" para abordar el desarrollo de software

ha demostrado ser efectivo y necesario en proyectos de gran tamaño (respecto a tiempo y

recursos), donde por lo general se exige un alto grado de ceremonia en el proceso. Sin

embargo, este enfoque no resulta ser el más adecuado para muchos de los proyectos

actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir

drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Ante las

dificultades para utilizar metodologías tradicionales con estas restricciones de tiempo y

flexibilidad, muchos equipos de desarrollo se resignan a prescindir del “buen hacer” de la

ingeniería del software, asumiendo el riesgo que ello conlleva. En este escenario, las

metodologías ágiles emergen como una posible respuesta para llenar ese vacío

metodológico. Por estar especialmente orientadas para proyectos pequeños, las

metodologías ágiles constituyen una solución a medida para ese entorno, aportando una

elevada simplificación que a pesar de ello no renuncia a las prácticas esenciales para

asegurar la calidad del producto.

Las metodologías ágiles son sin duda uno de los temas recientes en ingeniería de software

que están acaparando gran interés. Prueba de ello es que se están haciendo un espacio

destacado en la mayoría de conferencias y workshops celebrados en los últimos años. Es tal

su impacto que actualmente existen 4 conferencias internacionales de alto nivel y

específicas sobre el tema1. Además ya es un área con cabida en prestigiosas revistas

internacionales. En la comunidad de la ingeniería del software, se está viviendo con

intensidad un debate abierto entre los partidarios de las metodologías tradicionales

(referidas peyorativamente como "metodologías pesadas") y aquellos que apoyan las ideas

7


emanadas del "Manifiesto Ágil"2. La curiosidad que siente la mayor parte de ingenieros de

software, profesores, e incluso alumnos, sobre las metodologías ágiles hace prever una

fuerte proyección industrial. Por un lado, para muchos equipos de desarrollo el uso de

metodologías tradicionales les resulta muy lejano a su forma de trabajo actual considerando

las dificultades de su introducción e inversión asociada en formación y herramientas. Por

otro, las características de los proyectos para los cuales las metodologías ágiles han sido

especialmente pensadas se ajustan a un amplio rango de proyectos industriales de desarrollo

de software; aquellos en los cuales los equipos de desarrollo son pequeños, con plazos

reducidos, requisitos volátiles, y/o basados en nuevas tecnologías.

Proceso : conjunto de actividades ordenadas para lograr una serie de objetivos

Proceso Pesado :

* Fuerte dependencia de planificaciones

* Se establecen actividades

* Se establecen artefactos

* Se establecen herramientas y notaciones

* ESTAMOS MUY CONTROLADOS

Como contraposición: Metodología Ágil

Características:

- A los individuos y su interacción por encima de los procesos y las herramientas- El software que funciona por encima de la documentación exhaustiva- La colaboración con el cliente por encima la negociación contractual- La respuesta al cambio por encima seguimiento de un plan

Resumen * Estamos menos controlado

* Preparados para el cambio* Cliente forma parte del equipo* Pocos artefactos

METODOLOGOGÍA xp 8


* Más importante software funcionando que documentación

Estadísticas : método que más popularidad ha alcanzado de las metodologías ágilesSe basa en la suposición de que es posible desarrollar software de gran calidad a pesar, o incluso como consecuencia del cambio continuo Asume que con un poco de planificación, un poco de codificación y unas pocas pruebas se puede decidir si se está siguiendo un camino acertado o equivocado, evitando así tener que echar marcha atrás demasiado tarde.

Valores que inspiran XP

- Simplicidad: La simplicidad consiste en desarrollar sólo el sistema que realmente se necesita. Implica resolver en cada momento sólo las necesidades actuales. Los costos y la complejidad de predecir el futuro son muy elevados, y la mejor forma de acertar es esperar al futuro. Con este principio de simplicidad, junto con la comunicación y el feedback resulta más fácil conocer las necesidades reales

- Feedback: Una metodología basada en el desarrollo incremental iterativo de pequeñas partes, con entregas y pruebas frecuentes y continuas, proporciona un flujo de retro-información valioso para detectar los problemas o desviaciones. De esta forma fallos se localizan muy pronto. La planificación no puede evitar algunos errores, que sólo se evidencian al

desarrollar el sistema. La retro-información es la herramienta que permite reajustar la agenda y los

planes.

- Coraje: Implica saber tomar decisiones difíciles. Reparar un error cuando se detecta Mejorar el código siempre que tras el feedback y las sucesivas iteraciones se

manifieste susceptible de mejora Tratar rápidamente con el cliente los desajustes de agendas para decidir qué partes y

cuándo se van a entregar

- Comunicación: XP pone en comunicación directa y continua a clientes y desarrolladores. El cliente se integra en el equipo para establecer prioridades y resolver dudas. De esta forma ve el avance día a día, y es posible ajustar la agenda y las funcionalidades de forma consecuente

-

METODOLOGOGÍA xp 9


Resumen

El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas

propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo.

Por una parte tenemos aquellas propuestas más tradicionales que se centran especialmente

en el control del proceso, estableciendo rigurosamente las actividades involucradas, los

artefactos que se deben producir, y las herramientas y notaciones que se usarán. Estas

propuestas han demostrado ser efectivas y necesarias en un gran número de proyectos, pero

también han presentado problemas en otros muchos. Una posible mejora es incluir en los

procesos de desarrollo más actividades, más artefactos y más restricciones, basándose en

los puntos débiles detectados. Sin embargo, el resultado final sería un proceso de desarrollo

más complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el

proyecto. Otra aproximación es centrarse en otras dimensiones, como por ejemplo el factor

humano o el producto software. Esta es la filosofía de las metodologías ágiles, las cuales

dan mayor valor al individuo, a la colaboración con el cliente y al desarrollo incremental

del software con iteraciones muy cortas. Este enfoque está mostrando su efectividad en

proyectos con requisitos muy cambiantes y cuando se exige reducir drásticamente los

tiempos de desarrollo pero manteniendo una alta calidad. Las metodologías ágiles están

revolucionando la manera de producir software, y a la vez generando un amplio debate

entre sus seguidores y quienes por escepticismo o convencimiento no las ven como

alternativa para las metodologías tradicionales. En este trabajo se presenta resumidamente

el contexto en el que surgen las metodologías ágiles, sus valores, principios y

comparaciones con las metodologías tradicionales. Además se describe con mayor detalle

Programación Extrema (eXtreme Programming, XP) la metodología ágil más popular en la

actualidad.

Palabras Clave: Procesos de software, Metodologías ágiles, Programación Extrema

(eXtreme Programming)

METODOLOGOGÍA xp 10


Abstract

The development of software is not an easy task. The proof for that is the fact that there are

many methodological proposals that affect different dimensions of the development

process. On one hand, we can find more traditional proposals, which are specially centred

in the control of the process by rigorously setting the involved activities, the devices that

are due to produce, and the tools and annotations that will be used. These proposals have

demonstrated to be effective and necessary in a great number of projects, but also they have

presented problems in others. A possible improvement for that is to include more activities,

devices and restrictions in the development processes, which is based on the weak points

that were detected. Nevertheless, the final result would be a more-complex process of

development which can even limit the own ability of the equipment to develop the project.

Another approach is focusing in other dimensions, for example the human factor or the

software product. This is the philosophy of the agile methodologies, which give greater

value to the individual, to the collaboration with the client and the incremental development

of software with very short iterations. This approach is presenting its effectiveness in

projects with changing requirements and when it is demanded to reduce drastically the

times of development but maintaining a high quality. The agile methodologies are

revolutionizing the way to produce software and, at the same time, they are generating an

considerable debate between their followers and the ones that, by scepticism or conviction,

do not see them as an alternative for traditional methodologies. In this work it is briefly

presented the context in which the agile methodologies emerge, their values, principles and

comparisons with traditional methodologies. In addition, it is described in detail the most

popular agile methodology at the present time: eXtreme Programming.

Key-words: Software process; agile methods; eXtreme Programming



1. Reseña Histórica

La programación extrema, como proceso de creación de software diferente al

convencional, nace de la mano de Kent Beck (gurú de la XP y autor de los libros más

influyentes sobre el tema).

Chrysler Corporation hacía tiempo que estaba desarrollando una aplicación de nóminas,

pero sin demasiado éxito por parte de la gente que tenía en el proyecto. El verano de

1996, Beck entró en nómina en la compañía y se le pidió de hacer esta aplicación como

trabajo. Es en esta aplicación cuando nace la Programación Extrema como tal.

Beck reconoció que el proceso (o metodología) de creación de software o la carencia de

este era la causa de todos los problemas y llegó a la conclusión que para proporcionar

un proceso que fuera flexible era necesario realizar ciertos cambios en la estructura o

manera de hacer de los programadores, los cuales se tenían que acomodar al cambio a

realizar.

Él estaba convencido que la mejor metodología era un proceso que enfatizase la

comunicación dentro del equipo, que la implementación fuera sencilla, que el usuario

tenía que estar muy informado 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 Pattern Repository y empezaron a hablar de ella y promocionarla, de lo que era

y cómo realizarla. Estos propulsores de la XP hablaban de ella en cada ocasión que

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

Beck invitó a Ron Jeffries al proyecto para ayudar a desarrollar y perfeccionar estos

métodos. Jeffries partir de entonces actuó como un entrenador para inculcar las

prácticas, hábitos en el equipo C3.

La información sobre los principios y prácticas detrás de XP se difundió al resto del

mundo a través de discusiones en el wiki original, WikiWikiWeb de Cunningham.

Varios colaboradores discuten y se expandieron en las ideas, y algunas metodologías



spin-off resultado. Además, se han explicado los conceptos XP, desde hace varios años,

con un mapa del sistema de hipertexto en el sitio web en XP

"http://www.extremeprogramming.org" alrededor de 1999.

Beck editó una serie de libros sobre XP, empezando por su propia Programación

Extrema Explicada, difundiendo sus ideas a una mucho más grande, pero muy

receptivo, audiencia. Los autores de la serie pasaron por diversos aspectos que asisten a

XP y sus prácticas.



2. Conceptos Generales

Las metodologías ágiles (como por ejemplo XP, SCRUM, DSDM, Crystal, etc.) forman

parte del movimiento de desarrollo ágil de sotfware, que se basan en la adaptabilidad de

cualquier cambio como medio para aumentar las posibilidades de éxito de un proyecto.

De forma que una metodología ágil es la que tiene como principios que:

Los individuos y sus interacciones son más importantes que los procesos y las

herramientas.

El software que funciona es más importante que la documentación exhaustiva.

La colaboración con el cliente en lugar de la negociación de contratos.

La respuesta delante del cambio en lugar de seguir un plan cerrado.

Se puede decir que, este movimiento empezó a existir a partir de febrero de 2001,

cuando se reunieron los representantes de cada una de estas metodologías y terminaron

poniendo en común sus ideas en una declaración conjunta.

3. Definición

La programación extrema es una metodología de desarrollo ligera (o ágil) basada en

una serie de valores y de prácticas de buenas maneras que persigue el objetivo de

aumentar la productividad a la hora de desarrollar programas.

Este modelo de programación se basa en una serie de metodologías de desarrollo de

software en la que se da prioridad a los trabajos que dan un resultado directo y que

reducen la burocracia que hay alrededor de la programación.

Una de las características principales de este método de programación, es que sus

ingredientes son conocidos desde el principio de la informática. Los autores de XP han

seleccionado aquellos que han considerado mejores y han profundizado en sus

relaciones y en cómo se refuerzan los unos con los otros. El resultado de esta selección

ha sido esta metodología única y compacta. Por esto, aunque no está basada en

principios nuevos, sí que el resultado es una nueva manera de ver el desarrollo de

software.



El objetivo que se perseguía en el momento de crear esta metodología era la búsqueda

de un método que hiciera que los desarrollos fueran más sencillos. Aplicando el sentido

común.

4. Posturas a favor y en contra

Tabla 1. Puntos a favor y en contra

A favor En contra

X.P. sólo funcionará con gente buena, es

decir, profesionales que son capaces de

hacer un buen diseño, sencillo y a la vez

fácilmente ampliable.

Por otro lado se ha de recalcar que XP no

ha inventado ningún método nuevo,

sencillamente ha recogido métodos ya

existentes y los ha agrupado, y ha

comprobado que funcionen.

Los programadores tienen un acusado

sentimiento de posesión del código y esta

postura no encaja con la filosofía de X.P.

También se ve un fuerte sentimiento para

respectar las 40 horas semanales, y X.P. no

lo garantiza.

Los jefes de proyecto también expresan su

recelo con este método tan poco

tradicional.

Fuente: (Elaboración propia, 2014)

5. Principios Básicos

La programación extrema se basa en 12 principios básicos agrupados en cuatro

categorías:

5.1. Retroalimentación a escala fina

5.1.1. El principio de pruebas

Se tiene que establecer un periodo de pruebas de aceptación del programación

(llamada también periodo de caja negra) donde se definirán las entradas al

sistema y los resultados esperados de estas entradas. Es muy recomendable

automatizar estas pruebas para poder hacer varias simulaciones del sistema del



sistema en funcionamiento. Para hacer estas simulaciones automatizadas, se

puede utilizar Ambientes de Prueba (Unit testing frameworks).

Tabla 2. Pruebas de Aceptación

Caso de Prueba

Número Caso de Prueba: Número Historia de Usuario:

Descripción:

Condiciones de ejecución:

Entradas:

Resultado esperado:

Evaluación:


5.1.2. Proceso de planificación

En esta fase, el usuario tendrá que escribir sus necesidades, definiendo las

actividades que realizará el sistema. Se creará un documento llamado Historias

del usuario (User Stories). Entre 20 y 80 historias (todo dependiendo de la

complejidad del problema) se consideran suficientes para formar el llamado

Plan de Liberación, el cual define de forma específica los tiempos de entrega

de la aplicación para recibir retroalimentación por parte del usuario.

Son muy importantes y tienen que ser una constante las reuniones periódicas

durante esta fase de planificación. Estas pueden ser a diario, con todo el equipo

de desarrollo para identificar problemas, proponer soluciones y señalar

aquellos puntos a los que se les ha de dar más importancia por su dificultad o

por su punto crítico.

5.1.3. El cliente en el sitio

Se le dará poder para determinar los requerimientos, definir la funcionalidad,

señalar las prioridades y responder las preguntas de los programadores. Esta



fuerte interacción cara a cara con el programador disminuye el tiempo de

comunicación y la cantidad de documentación, junto con los altos costes de su

creación y mantenimiento.

5.1.4. Programación en parejas

Uno de los principios más radicales y en el que la mayoría de gerentes de

desarrollo pone sus dudas. Requiere que todos los programadores XP escriban

su código en parejas, compartiendo una sola máquina. De acuerdo con los

experimentos, este principio puede producir aplicaciones más buenas, de

manera consistente, a iguales o menores costes.

5.2. Proceso continuo en lugar de por lotes

5.2.1. Integración continua

Permite al equipo hacer un rápido progreso implementando las nuevas

características del software. En lugar de crear builds (o versiones) estables de

acuerdo a un cronograma establecido, los equipos de programadores XP

pueden reunir su código y reconstruir el sistema varias veces al día. Esto

reduce los problemas de integración comunes en proyectos largos y estilo

cascada.

5.2.2. Refactorización

Permite a los equipos de programadores XP mejorar el diseño del sistema a

través de todo el proceso de desarrollo. Los programadores evalúan

continuamente el diseño y recodifican lo necesario. La finalidad es mantener

un sistema enfocado a proveer el valor de negocio mediante la minimización

del código duplicado y/o ineficiente.

5.2.3. Entregas pequeñas

Colocan un sistema sencillo en producción rápidamente que se actualiza de

forma rápida y constante permitiendo que el verdadero valor de negocio del

producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las

2 o 3 semanas como máximo.



5.3. Entendimiento compartido

5.3.1. Diseño simple

Se basa en la filosofía de que el mayor valor de negocio es entregado por el

programa más sencillo que cumpla los requerimientos. Simple Design se

enfoca en proporcionar un sistema que cubra las necesidades inmediatas del

cliente, ni más ni menos. Este proceso permite eliminar redundancias y

rejuvenecer los diseños obsoletos de forma sencilla.

5.3.2. Metáfora

Desarrollada por los programadores al inicio del proyecto, define una historia

de cómo funciona el sistema completo. XP estimula historias, que son breves

descripciones de un trabajo de un sistema en lugar de los tradicionales

diagramas y modelos UML (Unified Modeling Language). La metáfora

expresa la visión evolutiva del proyecto que define el alcance y propósito del

sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboración) también

ayudarán al equipo a definir actividades durante el diseño del sistema. Cada

tarjeta representa una clase en la programación orientada a objetos y define sus

responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases

(cómo se comunica con ellas).

5.3.3. Propiedad colectiva del código

Un código con propiedad compartida. Nadie es el propietario de nada, todos

son el propietario de todo. Este método difiere en mucho a los métodos

tradicionales en los que un simple programador posee un conjunto de código.

Los defensores de XP argumentan que mientras haya más gente trabajando en

una pieza, menos errores aparecerán.

5.3.4. Estándar de codificación

Define la propiedad del código compartido así como las reglas para escribir y

documentar el código y la comunicación entre diferentes piezas de código

desarrolladas por diferentes equipos. Los programadores las han de seguir de



tal manera que el código en el sistema se vea como si hubiera estado escrito

por una sola persona.

5.4. Bienestar del programador

5.4.1. La semana de 40 horas

La programación extrema sostiene que los programadores cansados escriben

código de menor cualidad. Minimizar las horas extras y mantener los

programadores frescos, generará código de mayor calidad.





Figura 1

Figura 2

Capítulo IIFases de la metodología XP

22

1. Proceso de desarrollo

La programación extrema parte del caso habitual de una compañía que desarrolla

software, normalmente a medida, en la que hay diferentes roles: un equipo de gestión (o

diseño), uno de desarrollo y los clientes finales. La relación entre el equipo de diseño,

los que desarrollan el software y clientes es totalmente diferente al que se ha producido

en las metodologías tradicionales, que se basaba en una fase de captura de los requisitos

previa al desarrollo, y de una fase de validación posterior al mismo.

2. Interacción con el cliente

En este tipo de programación el cliente pasa a ser parte implicada en el equipo de

desarrollo. Su importancia es máxima en el momento de tratar con los usuarios y en

efectuar las reuniones de planificación. Tiene un papel importante de interacción con el

equipo de programadores, sobre todo después de cada cambio, y de cada posible

problema localizado, mostrando las prioridades. En este tipo de programación existirán

pruebas de aceptación de la programación que ayudarán a que su labor sea lo más

provechosa posible.

Al fin y al cabo, el cliente se encuentra mucho más cerca del proceso de desarrollo. Se

elimina la fase inicial de recopilación de requerimientos, y se permite que éstos se

vayan cogiendo a lo largo del proyecto, de una manera ordenada. De esta forma se

posibilita que el cliente pueda ir cambiando de opinión sobre la marcha, pero a cambio

han de estar siempre disponibles para solucionar las dudas del equipo de desarrollo.

3. Historia de Usuario

En XP aparece un nuevo concepto llamado “Historia de usuario”. Se trata de una lista

de características que el cliente necesita que existan en el producto final. Estas constan

de dos fases.

3.1. En la primera fase

El cliente describe con sus propias palabras las características y, es el responsable

del equipo, el encargado de informarlo de las dificultades técnicas de cada una de

ellas y de su coste. A consecuencia de este diálogo, el cliente deja por escrito un

23


conjunto de historias y las ordena en función de la prioridad que tienen para él. De

esta manera ya es posible definir unas fechas aproximadas para ellos.

3.2. En la segunda fase

El cliente cogerá las primeras historias a implementar y las dividirá en trabajos a

realizar. El cliente también participa, pero hay más peso por parte del equipo de

desarrolladores, esto dará como resultado una planificación más exacta. Este

método se repetirá para cada historia.

A diferencia de otras técnicas, como puede ser UML, en el caso de XP, se exige que

sea el cliente el encargado de escribir los documentos con las especificaciones de lo

que realmente quiere, como un documento de requisitos de usuario.

En esta fase, el equipo técnico será el encargado de catalogar las historias del cliente

y asignarles una duración. La norma es que cada historia de usuario tiene que poder

ser realizable en un espacio entre una y tres semanas de programación. Las que

requieran menos tiempo serán agrupadas, y las que necesiten más serán modificadas

o divididas.

Finalmente decir que las historias de los usuarios serán escritas en tarjetas, lo que

facilitará que el cliente pueda especificar la importancia relativa entre las diferentes

historias de usuario, así como el trabajo de los programadores que podrán

catalogarlas correctamente. Este formato también es muy útil en el momento de las

pruebas de aceptación.



Tabla 3. Historia de Usuario

Historia de Usuario

Número: 1 Nombre: Enviar artículo

Usuario: Autor

Modificación de Historia Número: Iteración Asignada: 2

Prioridad en Negocio: Alta

(Alta/Media/Baja)

Puntos Estimados:

Riesgos en Desarrollo: Puntos Reales:

Descripción

Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de los

autores (nombre, e-mail, afiliación). Uno de los autores debe indicarse como autor de

contacto. El sistema confirma la correcta recepción del artículo enviando un e-mail al

autor de contacto con un userid y password para que el autor pueda posteriormente

acceder al artículo.

Observaciones:


4. Planificación del proyecto

En este punto se tendrá que elaborar la planificación por etapas, donde se aplicarán

diferentes iteraciones. Para hacerlo será necesaria la existencia de reglas que se han de

seguir por las partes implicadas en el proyecto para que todas las partes tengan voz y se

sientan realmente partícipes de la decisión tomada.

Las entregas se tienen que hacer cuanto antes mejor, y con cada iteración, el cliente ha

de recibir una nueva versión. Cuanto más tiempo se tarde en introducir una parte

esencial, menos tiempo se tendrá para trabajar con ella después. Se aconseja muchas

entregas y muy frecuentes. De esta manera un error en la parte inicial del sistema tiene

más posibilidades de detectarse rápidamente.



Una de las máximas a aplicar es, los cambios, no han de suponer más horas de

programación para el programador, ya que el que no se termina en un día, se deja para

el día siguiente.

Se ha de tener asumido que en el proceso de planificación habrán errores, es más, serán

comunes, y por esto esta metodología ya los tiene previstos, por lo tanto se establecerán

mecanismos de revisión. Cada tres o cinco iteraciones es normal revisar las historias de

los usuarios, y renegociar la planificación.

Cada iteración necesita también ser planificada, es lo que se llama planificación

iterativa, en la que se anotarán las historias de usuarios que se consideren esenciales y

las que no han pasado las pruebas de aceptación. Estas planificaciones también se harán

en tarjetas, en las que se escribirán los trabajos que durarán entre uno y tres días.

Es por esto que el diseño se puede clasificar como continuo. Añade agilidad al proceso

de desarrollo y evita que se mire demasiado hacia delante, desarrollando trabajos que

aún no han estado programados.

Este tipo de planificación en iteraciones y el diseño iterativo, hace que aparezca una

práctica que no existía en la programación tradicional. Se trata de las discusiones diarias

informales, para fomentar la comunicación, y para hacer que los desarrolladores tengan

tiempo de hablar de los problemas a los que se enfrentan y de ver cómo van con sus

trabajos.

5. Diseño, desarrollo, pruebas

El desarrollo es la parte más importante en el proceso de la programación extrema.

Todos los trabajos tienen como objetivo que se programen lo más rápidamente posible,

sin interrupciones y en dirección correcta.

También es muy importante el diseño, y se establecen los mecanismos, para que éste

sea revisado y mejorado de manera continuada a lo largo del proyecto, según se van

añadiendo funcionalidades al mismo.



La clave del proceso de desarrollar XP es la comunicación. La mayoría de los

problemas en los proyectos son por falta de comunicación en el equipo.

6. Metáfora

En XP, aparece un nuevo concepto llamado Metáfora. Su principal objetivo es mejorar

la comunicación entre todos los integrantes del equipo, al crear una visión global y

común de lo que se quiere desarrollar. La metáfora tiene que ser expresada en términos

conocidos por los integrantes del equipo, por ejemplo comparando el sistema que se

desarrollará con alguna cosa de la vida real.

Antes de empezar a codificar se tienen que hacer pruebas unitarias, es decir:

Cada vez que se quiere implementar una parte de código, en XP, se tiene que escribir

una prueba sencilla, y después escribir el código para que la pase. Una vez pasada se

amplía y se continúa. En XP hay una máxima que dice "Todo el código que puede fallar

tiene que tener una prueba".

Con estas normas se obtiene un código simple y funcional de manera bastante rápida.

Por esto es importante pasar las pruebas al 100%

Respecto a la integración del software, en XP se ha de hacer una integración continua,

es decir, cada vez se tienen que ir integrando pequeños fragmentos de código, para

evitar que al finalizar el proyecto se tenga que invertir grandes esfuerzos en la

integración final. En todo buen proyecto de XP, tendría que existir una versión al día

integrada, de manera que los cambios siempre se realicen en esta última versión.

Otra peculiaridad de XP es que cada programador puede trabajar en cualquier parte del

programa.

De esta manera se evita que haya partes "propietarias de cada programador". Por esto es

tan importante la integración diaria.

Para terminar, otra peculiaridad que tiene la XP. La de fomentar la programación en

parejas, es decir, hacer que los programadores no trabajen en solitario, sino que siempre

estarán con otra persona. Una pareja de programadores ha de compartir el teclado, el



monitor y el ratón. El principio fundamental de este hecho es realizar de manera

continua y sin parar el desarrollo de código. Las parejas tienen que ir cambiando de

manera periódica, para hacer que el conocimiento se difunda en el grupo. Está

demostrado que de esta manera el trabajo es más eficaz y también se consigue más y

mejor código.

Figura 3




7. Fases de la metodología XP

7.1. Fase: Planificación del proyecto

7.1.1. Historias de usuario

El primer paso de cualquier proyecto que siga la metodología X.P es definir las

historias de usuario con el cliente. Las historias de usuario tienen la misma

finalidad que los casos de uso pero con algunas diferencias:

Constan de 3 o 4 líneas escritas por el cliente en un lenguaje no técnico sin

hacer mucho hincapié en los detalles.

No se debe hablar ni de posibles algoritmos para su implementación ni de

diseños de base de datos adecuados, etc.

Son usadas para estimar tiempos de desarrollo de la parte de la aplicación

que describen.

También se utilizan en la fase de pruebas, para verificar si el programa

cumple con lo que especifica la historia de usuario.

Cuando llega la hora de implementar una historia de usuario, el cliente y

los desarrolladores se reúnen para concretar y detallar lo que tiene que

hacer dicha historia. El tiempo de desarrollo ideal para una historia de

usuario es entre 1 y 3 semanas.

Similar a los Casos de Uso

Usadas para estimaciones de tiempo en la planificación de las liberaciones

Usados en lugar del Documento de Requerimientos

Escritas por el Cliente en términos del Cliente

Guían la creación de Pruebas de Aceptación

7.1.2. Release Planning

Después de tener ya definidas las historias de usuario es necesario crear un

plan de publicaciones, en inglés "Release plan", donde se indiquen las historias

de usuario que se crearán para cada versión del programa y las fechas en las

que se publicarán estas versiones. Un "Release plan" es una planificación



donde los desarrolladores y clientes establecen los tiempos de implementación

ideales de las historias de usuario, la prioridad con la que serán implementadas

y las historias que serán implementadas en cada versión del programa.

Después de un "Release plan" tienen que estar claros estos cuatro factores:

Los objetivos que se deben cumplir (que son principalmente las historias

que se deben desarrollar en cada versión).

El tiempo que tardarán en desarrollarse y publicarse las versiones del

programa.

El número de personas que trabajarán en el desarrollo.

Y Cómo se evaluará la calidad del trabajo realizado. (*Release plan:

Planificación de publicaciones).

7.1.3. Iteraciones

Todo proyecto que siga la metodología X.P. se ha de dividir en iteraciones de

aproximadamente 3 semanas de duración. Al comienzo de cada iteración los

clientes deben seleccionar las historias de usuario definidas en el "Release

planning" que serán implementadas. También se seleccionan las historias de

usuario que no pasaron el test de aceptación que se realizó al terminar la

iteración anterior. Estas historias de usuario son divididas en tareas de entre 1

y 3 días de duración que se asignarán a los programadores.

7.1.4. La velocidad del proyecto

Es una medida que representa la rapidez con la que se desarrolla el proyecto;

estimarla es muy sencillo, basta con contar el número de historias de usuario

que se pueden implementar en una iteración; de esta forma, se sabrá el cupo de

historias que se pueden desarrollar en las distintas iteraciones. Usando la

velocidad del proyecto controlaremos que todas las tareas se puedan

desarrollar en el tiempo del que dispone la iteración. Es conveniente reevaluar

esta medida cada 3 o 4 iteraciones y si se aprecia que no es adecuada hay que

negociar con el cliente un nuevo "Release Plan".



7.1.5. Programación en Parejas

La metodología X.P. aconseja la programación en parejas pues incrementa la

productividad y la calidad del software desarrollado.

El trabajo en pareja involucra a dos programadores trabajando en el mismo

equipo; mientras uno codifica haciendo hincapié en la calidad de la función o

método que está implementando, el otro analiza si ese método o función es

adecuado y está bien diseñado. De esta forma se consigue un código y diseño

con gran calidad.

7.1.6. Reuniones Diarias

Es necesario que los desarrolladores se reúnan diariamente y expongan sus

problemas, soluciones e ideas de forma conjunta. Las reuniones tienen que ser

fluidas y todo el mundo tiene que tener voz y voto.

7.2. Fase: Diseño

7.2.1. Diseños Simples

La metodología X.P sugiere que hay que conseguir diseños simples y

sencillos. Hay que procurar hacerlo todo lo menos complicado posible para

conseguir un diseño fácilmente entendible e que se pueda implementar que a la

larga costará menos tiempo y esfuerzo desarrollar.

7.2.2. Glosarios de Términos

Usar glosarios de términos y una correcta especificación de los nombres de

métodos y clases ayudará a comprender el diseño y facilitará sus posteriores

ampliaciones y la reutilización del código.

7.2.3. Riesgos

Si surgen problemas potenciales durante el diseño, X.P sugiere utilizar una

pareja de desarrolladores para que investiguen y reduzcan al máximo el riesgo

que supone ese problema.



7.2.4. Funcionabilidad extra

Nunca se debe añadir funcionalidad extra al programa aunque se piense que en

un futuro será utilizada. Sólo el 10% de la misma es utilizada, lo que implica

que el desarrollo de funcionalidad extra es un desperdicio de tiempo y

recursos.

7.2.5. Refactorizar

Refactorizar es mejorar y modificar la estructura y codificación de códigos ya

creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo

estos códigos para procurar optimizar su funcionamiento. Es muy común

rehusar códigos ya creados que contienen funcionalidades que no serán usadas

y diseños obsoletos.

7.3. Fase: Codificación

El cliente es una parte más importante del equipo de desarrollo; su presencia es

indispensable en las distintas fases de X.P. A la hora de codificar una historia de

usuario su presencia es aún más necesaria. No olvidemos que los clientes son los

que crean las historias de usuario y negocian los tiempos en los que serán

implementadas. Antes del desarrollo de cada historia de usuario el cliente debe

especificar detalladamente lo que ésta hará y también tendrá que estar presente

cuando se realicen los test que verifiquen que la historia implementada cumple la

funcionalidad especificada. La codificación debe hacerse ateniendo a estándares de

codificación ya creados. Programar bajo estándares mantiene el código consistente

y facilita su comprensión y escalabilidad.

7.4. Fase: Pruebas

Uno de los pilares de la metodología X.P es el uso de test para comprobar el

funcionamiento de los códigos que vayamos implementando. El uso de los test en

X.P es el siguiente:

Se deben crear las aplicaciones que realizarán los test con un entorno de desarrollo

específico para test.



Hay que someter a tests las distintas clases del sistema omitiendo los métodos más

triviales.

Se deben crear los test que pasarán los códigos antes de implementarlos; en el

apartado anterior se explicó la importancia de crear antes los test que el código.

Un punto importante es crear test que no tengan ninguna dependencia del código

que en un futuro evaluará.

Como se comentó anteriormente los distintos test se deben subir al repositorio de

código acompañados del código que verifican.

Test de aceptación. Los test mencionados anteriormente sirven para evaluar las

distintas tareas en las que ha sido dividida una historia de usuario.

Al ser las distintas funcionalidades de nuestra aplicación no demasiado extensas, no

se harán test que analicen partes de las mismas, sino que las pruebas se realizarán

para las funcionalidades generales que debe cumplir el programa especificado en la

descripción de requisitos.



Figura 4 Fases de la Metodología XPFigura 4



8. Valores de la metodología XP

Los valores originales de la programación extrema son: simplicidad, comunicación,

retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la

segunda edición de Extreme Programming Explained. Los cinco valores se detallan a

continuación:

8.1. Simplicidad

La simplicidad es la base de la programación extrema. Se simplifica el diseño

para agilizar el desarrollo y facilitar el mantenimiento.

Un diseño complejo del código junto a sucesivas modificaciones por parte de

diferentes desarrolladores hace que la complejidad aumente exponencialmente.

Para mantener la simplicidad es necesaria la refactorización del código, ésta es

la manera de mantener el código simple a medida que crece.

También se aplica la simplicidad en la documentación, de esta manera el código

debe comentarse en su justa medida, intentando eso sí que el código esté auto-

documentado. Para ello se deben elegir adecuadamente los nombres de las

variables, métodos y clases. Los nombres largos no decrementan la eficiencia

del código ni el tiempo de desarrollo gracias a las herramientas de

autocompletado y refactorización que existen actualmente.


Figura 5 Fases de la Metodología XP según Ian SommervilleFigura 5


Aplicando la simplicidad junto con la autoría colectiva del código y la

programación por parejas se asegura que cuanto más grande se haga el proyecto,

todo el equipo conocerá más y mejor el sistema completo.

8.2. Comunicación

La comunicación se realiza de diferentes formas. Para los programadores el

código comunica mejor cuanto más simple sea.

Si el código es complejo hay que esforzarse para hacerlo inteligible. El código

autodocumentado es más fiable que los comentarios ya que éstos últimos pronto

quedan desfasados con el código a medida que es modificado.

Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo de una

clase o la funcionalidad de un método. Las pruebas unitarias son otra forma de

comunicación ya que describen el diseño de las clases y los métodos al mostrar

ejemplos concretos de cómo utilizar su funcionalidad.

Los programadores se comunican constantemente gracias a la programación por

parejas. La comunicación con el cliente es fluida ya que el cliente forma parte

del equipo de desarrollo. El cliente decide qué características tienen prioridad y

siempre debe estar disponible para solucionar dudas.

8.3. Retroalimentación

Al estar el cliente integrado en el proyecto, su opinión sobre el estado del

proyecto se conoce en tiempo real.

Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se

minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda

a los programador esa centrarse en lo que es más importante. Considérense los

problemas que derivan de tener ciclos muy largos.

Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios

del cliente o malentendidos por parte del equipo de desarrollo.

El código también es una fuente de retroalimentación gracias a las herramientas

de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de



salud del código. Ejecutar las pruebas unitarias frecuentemente permite

descubrir fallos debidos a cambios recientes en el código.

8.4. Coraje o valentía

Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y

programar para hoy y no para mañana. Esto es un esfuerzo para evitar

empantanarse en el diseño y requerir demasiado tiempo y trabajo para implementar

todo lo demás del proyecto. La valentía le permite a los desarrolladores que se

sientan cómodos con reconstruir su código cuando sea necesario. Esto significa

revisar el sistema existente y modificarlo si con ello los cambios futuros se

implementaran más fácilmente. Otro ejemplo de valentía es saber cuándo desechar

un código: valentía para quitar código fuente obsoleto, sin importar cuanto esfuerzo

y tiempo se invirtió en crear ese código. Además, valentía significa persistencia: un

programador puede permanecer sin avanzar en un problema complejo por un día

entero, y luego lo resolverá rápidamente al día siguiente, sólo si es persistente.

9. Ventajas y Desventajas de la Metodología XP

Tabla 4. Ventajas y Desventajas de la Metodología XP

Ventajas Desventajas

Programación organizada. Es recomendable emplearlo solo en

proyectos a corto plazo.

Menor taza de errores. Altas comisiones en caso de fallar.

Satisfacción del programador.


10. Inconvenientes

Es recomendable emplearla solo en proyectos a corto plazo.

En caso de fallar, las comisiones son muy altas.

Requiere de un rígido ajuste a los principios de XP.

Puede no siempre ser más fácil que el desarrollo tradicional.



11. Herramientas empleadas en XP

A continuación se detalla cada una de estas planteando los motivos por los cuales

fueron seleccionadas:

11.1. JAVA

Se trata de un poderos y flexible lenguaje de programación con el actual se puede

desarrollar desde aplicaciones para celulares hasta páginas web. Obviamente se

convierte en una herramienta óptima para desarrollar aplicativos de escritorio.

El primer motivo por el que se seleccionó JAVA como herramienta de desarrollo, es el

amplio conocimiento que los programadores tienen del lenguaje. En segundo lugar

existe una API de pruebas desarrolladas para trabajar con JAVA especialmente

diseñada para proyectos desarrollados con XP

11.2. NETBeans

Es un IDE de licenciado libre para desarrollar aplicaciones en JAVA.

Si bien no es el único IDE disponible para JAVA, a juicio de los programadores, es el

más adecuado, por lo cual se convirtió en la mejor elección. Por otro lado cuenta con

soporte para JUnit, herramienta seleccionada para realizar pruebas.

11.3. JUnit

Es un API para realizar pruebas que fue diseñado para ser empleado en JAVA. Un

aspecto importante es que cumple con la mayoría de las recomendaciones realizadas por

XP en lo que a pruebas se refiere, de las cuales se destaca el permitir hacer pruebas

autónomas. Por otro lado, algunos autores lo recomiendan para desarrollar aplicaciones

en JAVA empleando XP.

11.4. JasperReport e IReport

Es una combinación de librerías de JAVA y software libre que permiten el diseño e

implementación de reportes impresos. Entre las ventajas más importantes se resalta

flexibilidad y facilidad de empleo



11.5. PostgreSQL

Se caracteriza por estar entre los motores de base de datos más estables y robustos,

razones que motivaron su elección.

12. Tablas Comparativas de las Metodologías SCRUM y XP

12.1. Semejanzas

Es un Agile Manifiesto.

Existen una Interacción de Usuario a Usuario.

Realizan los Proyectos en un Corto Periodo de Tiempo.

Trabajan en Equipo.



12.2. Diferencias

Tabla 5. Comparación entre Metodologías

SCRUM XP(Programación Extrema)

Las iteraciones de entregas son de 2 a 4

semanas.

Las iteraciones de entrega son a 1 a 3

semanas.

Lo que se termina, funciona y este bien, se

aparta y ya no se toca.

Las tareas q se van entregando a los

diferentes clientes son susceptibles a las

modificaciones.

Cada miembro del Scrum Team trabaja de

forma individual.

Los miembros del programan en pareja en

un proyecto XP.

El Scrum Team trata de seguir el orden de

prioridad q marca el Product Owner en el

Sprint Backlog pueden ser modificadas.

El equipo de desarrollo sigue estrictamente

el orden de prioridad de las tareas definidas

por el cliente.

Está basada en la administración del

proyecto.

Se centra más en la propia programación o

creación del producto.


13. Personas que intervienen en la Metodología XP

Según Kent Beck

La metodología XP se encuentra en una frecuente integración del equipo de programación

con el cliente o usuario: se recomienda que un representante del cliente trabaje junto al

equipo de desarrollo. Los programadores se comunican constantemente gracias a la

programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma

parte del equipo de desarrollo; el cliente decide qué características tienen prioridad y

siempre debe estar disponible para solucionar dudas.

Según Ian Sommerville

En un proceso XP, los clientes están fuertemente implicados en la especificación y

establecimiento de prioridades de los requerimientos del sistema.



Los requerimientos no se especifican como una lista de funciones requeridas del sistema.

Más bien, los clientes del sistema son parte del equipo de desarrollo y discuten escenarios

con otros miembros del equipo. Desarrollan conjuntamente una tarjeta de historia que

recoge las necesidades del cliente. El equipo de desarrollo intentara entonces implementar

ese escenario en una entrega futura del software.

La participación del cliente se lleva a cabo a través del compromiso a tiempo completo del

cliente en el equipo de desarrollo. Los representantes de los clientes participan en el

desarrollo y son los responsables de definir las pruebas de aceptación del sistema.


Practicas Básicas del XP

De forma aislada, cualquier práctica individual de Xp tiene poco sentido, pero en conjunto,

unas compensan las carencias que las otras puedan tener.

Nos dice que para evaluar Xp hay que mirar la gran foto, es decir, todo el conjunto de

prácticas:

El juego de la Planificación - (Planning Game)

El alcance de la siguiente versión esta definido por las consideraciones de negocios

(prioridad de los módulos, fechas de entrega) y estimaciones técnicas (estimaciones de

funciones, consecuencias).

El objetivo del juego es maximizar el valor del software producido, La estrategia es poner

en producción las características más importantes lo antes posible, Las Piezas clave son las

Story Cards, Los Jugadores son los desarrolladores y el cliente y las Movidas son

Exploración, Selección y Actualización.

Versiones Pequeñas (Short Releases)

41


Un sistema simple se pone rápidamente en producción. Periódicamente, se producen

nuevas versiones agregando en cada iteración aquellas funciones consideradas valiosas para

el cliente

Metáfora del Sistema (Metaphor)

Cada Proyecto es guiado por una historia simple de cómo funciona el sistema en general,

reemplaza a la arquitectura y debe estar en lenguaje común, entendible para todos (Cliente

y Desarrolladores), esta puede cambiar permanentemente.

Diseño Simple (Simple Designs)

El sistema se diseña con la máxima simplicidad posible (YAGNY - "No vas a necesitarlo"),

Se plasma el diseño en tarjetas CRC (Clase – Responsabilidad - Colaboración), no se

implementan características que no son necesarias, con esta técnica, las clases descubiertas

durante el análisis pueden ser filtradas para determinar qué clases son realmente necesarias

para el sistema.

Pruebas Continuas (Testing)

Los casos de prueba se escriben antes que el código. Los desarrolladores escriben pruebas

unitarias y los clientes especifican pruebas funcionales.

Refactorización (Refactoring)

Es posible reestructurar el sistema sin cambiar su comportamiento, por ejemplo eliminando

código duplicado, simplificando funciones, Mejorando el código constantemente, si el

código se esta volviendo complicado se debería modificar el diseño y volver a uno más

simple. Refactoring (Modificar la forma del código sin cambiar su funcionamiento).

Programación por parejas (Pair Programming)

El código es escrito por dos personas trabajando en el mismo computador. "Una sola

maquina con un teclado y un mouse"

Posesión Colectiva del Código (Collective Code Ownership)



Nadie es dueño de un modulo. Cualquier programador puede cambiar cualquier parte del

sistema en cualquier momento, siempre se utilizan estándares y se excluyen los

comentarios, Los test siempre deben funcionar al 100% para realizar integraciones con todo

el código permanentemente.

Integración continua (Continuous Integration)

Los cambios se integran en el código base varias veces por día. Todos lo casos de prueba se

deben pasar antes y después de la integración, se dispone de una maquina para la

integración y se realizan test funcionales en donde participa el cliente.

Semana laboral de 40 horas (40-Hour Week)

Cada Trabajador trabaja no más de 40 Horas por semana. Si fuera necesario hacer horas

extra, esto no debería hacerse dos semanas consecutivas. Sin héroes, esto hace que se

reduzca la rotación del personal y mejora la calidad del producto.

Cliente en el Sitio (On Site Customer)

El equipo de desarrollo tiene acceso todo el tiempo al cliente, el cual esta disponible para

responder preguntas, fijar prioridades, etc. Esto no siempre se consigue; Un cliente muy

Junior no sirve y un cliente muy Sénior no es disponible. "Lo ideal es un cliente Analista".

Estándares de Codificación (Coding Standard)

Todo el código debe estar escrito de acuerdo a un estándar de codificación

Ciclo de Vida

El ciclo de vida de Xp se enfatiza en el carácter interactivo e incremental del desarrollo,

Según una iteración de desarrollo es un período de tiempo en el que se realiza un conjunto

de funcionalidades determinadas que en el caso de Xp corresponden a un conjunto de

historias de usuarios.



Las iteraciones son relativamente cortas ya que se piensa que entre más rápido se le

entreguen desarrollos al cliente, más retroalimentación se va a obtener y esto va a

representar una mejor calidad del producto a largo plazo. Existe una fase de análisis inicial

orientada a programar las iteraciones de desarrollo y cada iteración incluye diseño,

codificación y pruebas, fases superpuestas de tal manera que no se separen en el tiempo.

La siguiente figura muestra las fases en las que se subdivide el ciclo de vida Xp:

Ciclo de vida de eXtreme Programming

Ahora nos describen cada una de las fases en las que se subdivide el ciclo de vida de

eXtreme Programming:



Fase de la exploración: En esta fase, los clientes plantean a grandes rasgos las historias de

usuario que son de interés para la primera entrega del producto. Al mismo tiempo el equipo

de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán

en el proyecto.

Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema

construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos meses,

dependiendo del tamaño y familiaridad que tengan los programadores con la tecnología.

Fase del planeamiento: se priorizan las historias de usuario y se acuerda el alcance del

release. Los programadores estiman cuánto esfuerzo requiere cada historia y a partir de allí

se define el cronograma. La duración del cronograma del primer release no excede

normalmente dos meses. La fase de planeamiento toma un par de días. Se deben incluir

varias iteraciones para lograr un release. El cronograma fijado en la etapa de planeamiento

se realiza a un número de iteraciones, cada una toma de una a cuatro semanas en ejecución.

La primera iteración crea un sistema con la arquitectura del sistema completo. Esto es

alcanzado seleccionando las historias que harán cumplir la construcción de la estructura

para el sistema completo. El cliente decide las historias que se seleccionarán para cada

iteración. Las pruebas funcionales creadas por el cliente se ejecutan al final de cada

iteración. Al final de la última iteración el sistema está listo para producción.

Fase de producción: requiere prueba y comprobación extra del funcionamiento del sistema

antes de que éste se pueda liberar al cliente. En esta fase, los nuevos cambios pueden

todavía ser encontrados y debe tomarse la decisión de si se incluyen o no en el release

actual. Durante esta fase, las iteraciones pueden ser aceleradas de una a tres semanas. Las

ideas y las sugerencias pospuestas se documentan para una puesta en práctica posterior por

ejemplo en la fase de mantenimiento. Después de que se realice el primer release

productivo para uso del cliente, el proyecto de Xp debe mantener el funcionamiento del

sistema mientras que realiza nuevas iteraciones.

Fase de mantenimiento: requiere de un mayor esfuerzo para satisfacer también las tareas

del cliente. Así, la velocidad del desarrollo puede desacelerar después de que el sistema esté



en la producción. La fase de mantenimiento puede requerir la incorporación de nueva gente

y cambiar la estructura del equipo.

Fase de muerte: Es cuando el cliente no tiene más historias para ser incluidas en el

sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como

rendimiento y confiabilidad del sistema. Se genera la documentación final del sistema y no

se realizan más cambios en la arquitectura. La muerte del proyecto también ocurre cuando

el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto

para mantenerlo.

Actores y Responsabilidades de XP

Existen diferentes roles (actores) y responsabilidades en Xp para diferentes tareas y

propósitos durante el proceso:

Programador (Programmer)

Responsable de decisiones técnicas

Responsable de construir el sistema

Sin distinción entre analistas, diseñadores o codificadores

En Xp, los programadores diseñan, programan y realizan las pruebas

Cliente (Customer)

Es parte del equipo

Determina qué construir y cuándo

Escribe tests funcionales para determinar cuándo está completo un determinado

aspecto

Entrenador (Coach)

El líder del equipo - toma las decisiones importantes

Principal responsable del proceso



Tiende a estar en un segundo plano a medida que el equipo madura

Rastreador (Tracker)

Metric Man

Observa sin molestar

Conserva datos históricos

Probador (Tester)

Ayuda al cliente con las pruebas funcionales

Se asegura de que los tests funcionales se ejecutan

Artefactos

A continuación describimos los artefactos de Xp, entre los que se encuentran: Historias de

Usuario, Tareas de Ingeniería y Tarjetas CRC.

Historia de usuario

Representan una breve descripción del comportamiento del sistema, emplea terminología

del cliente sin lenguaje técnico, se realiza una por cada característica principal del sistema,

se emplean para hacer estimaciones de tiempo y para el plan de lanzamientos, reemplazan

un gran documento de requisitos y presiden la creación de las pruebas de aceptación.



Historia de usuario

Numero: Nombre Historia de usuario:

Modificación de historia de Usuario (Nro. y Nombre:)

Usuario Iteración Asignada :

Prioridad en negocio

(Alta / Media / Baja)

Puntos estimados :

Riesgo en desarrollo :

(Alto / Medio / Bajo )

Puntos Reales:

Descripción:

Observaciones:



Tabla No.1. Modelo propuesto para una historia de usuario

Estas deben proporcionar sólo el detalle suficiente como para poder hacer razonable la

estimación de cuánto tiempo requiere la implementación de la historia, difiere de los casos

de uso porque son escritos por el cliente, no por los programadores, empleando

terminología del cliente. "Las historias de usuario son más "amigables" que los casos de

uso formales".

Las Historias de Usuario tienen tres aspectos:

Tarjeta: en ella se almacena suficiente información para identificar y detallar la historia.

Conversación: cliente y programadores discuten la historia para ampliar los detalles

(verbalmente cuando sea posible, pero documentada cuando se requiera confirmación)

Pruebas de Aceptación: permite confirmar que la historia ha sido implementada

correctamente.

Caso de prueba de Aceptación

Código: Historia de usuario (Nro. Y Nombre):

Nombre:

Descripción :

Condiciones de Ejecución:



Entrada / pasos de ejecución:

Resultado esperado:

Evaluación de prueba:

Tabla No.2. Modelo propuesto para una prueba de aceptación

Task Card

Tarea de Ingeniería



Número tarea Historia de usuario (Nro. Y Nombre):

Nombre Tarea:

Tipo de Tarea:

Desarrollo / Corrección / Mejora

/Otra(especificar)

Puntos Estimados:

Fecha Inicio: Fecha Fin:

Programador Responsable:

Descripción

Modelo propuesto para una tarea de ingeniería



Tarjetas CRC (Clase – Responsabilidad - Colaborador)

Estas tarjetas se dividen en tres secciones que contienen la información del nombre de la

clase, sus responsabilidades y sus colaboradores. En la siguiente figura se muestra cómo se

distribuye esta información.

Nombre de la Clase

Responsabilidades Colaboradores

Modelo de tarjeta CRC

Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte. Las

responsabilidades de una clase son las cosas que conoce y las que realiza, sus atributos y

métodos. Los colaboradores de una clase son las demás clases con las que trabaja en

conjunto para llevar a cabo sus responsabilidades.

En la práctica conviene tener pequeñas tarjetas de cartón, que se llenarán y que son

mostradas al cliente, de manera que se pueda llegar a un acuerdo sobre la validez de las

abstracciones propuestas.

Los pasos a seguir para llenar las tarjetas son los siguientes:



Encontrar clases

Encontrar responsabilidades

Definir colaboradores

Disponer las tarjetas

Para encontrar las clases debemos pensar qué cosas interactúan con el sistema (en nuestro

caso el usuario), y qué cosas son parte del sistema, así como las pantallas útiles a la

aplicación (un despliegue de datos, una entrada de parámetros y una pantalla general, entre

otros). Una vez que las clases principales han sido encontradas se procede a buscar los

atributos y las responsabilidades, para esto se puede formular la pregunta ¿Qué sabe la

clase? y ¿Qué hace la clase? Finalmente se buscan los colaboradores dentro de la lista de

clases que se tenga.

Criticas a Extreme Programing

Algunas de las críticas recopiladas de Xp son:

Xp tiene muchas críticas especialmente contra la programación por parejas por parte de

muchos programadores con gran sentimiento de posesión del código, piensan que ellos son

los mejores conocedores de las herramientas y lenguajes que utilizan y que si alguien no lo

entiende es porque no sabe lo suficiente.

También se critica el mito de las 40 horas semanales ya que es un lujo para las exigencias

del mercado.

También hay críticas hacia Xp que dicen que solo puede funcionar con programadores muy

buenos, como Kent Beck, que son capaces de hacer un buen diseño, sencillo y fácilmente

extensible.

Xp es más una filosofía de trabajo que una metodología. Por otro lado ninguna de las

practicas defendidas por Xp son invención de este método, Xp lo que hace es ponerlas

todas juntas.



Xp está diseñado para grupos de pequeños programadores, más de 10 ya sería muy

complicado, y más aún para que estén en el mismo centro de trabajo.

Capítulo IIIConclusiones y Recomendaciones


14. Conclusiones

No existe una metodología universal para hacer frente con éxito a cualquier proyecto de

desarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto

(recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema, etc. Históricamente,

las metodologías tradicionales han intentado abordar la mayor cantidad de situaciones de

contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en

proyectos pequeños y con requisitos muy cambiantes. Las metodologías ágiles ofrecen una

solución casi a medida para una gran cantidad de proyectos que tienen estas características.

Una de las cualidades más destacables en una metodología ágil es su sencillez, tanto en su

aprendizaje como en su aplicación, reduciéndose así los costos de implantación en un

equipo de desarrollo. Esto ha llevado hacia un interés creciente en las metodologías ágiles.

Sin embargo, hay que tener presente una serie de inconvenientes y restricciones para su

aplicación, tales como: están dirigidas a equipos pequeños o medianos (Beck sugiere que el

tamaño de los equipos se limite de 3 a 20 como máximo, otros dicen no más de 10

participantes), el entorno físico debe ser un ambiente que permita la comunicación y

colaboración entre todos los miembros del equipo durante todo el tiempo, cualquier

resistencia del cliente o del equipo de desarrollo hacia las prácticas y principios puede

llevar al proceso al fracaso (el clima de trabajo, la colaboración y la relación contractual

son claves), el uso de tecnologías que no tengan un ciclo rápido de realimentación o que no

soporten fácilmente el cambio, etc.

Falta aún un cuerpo de conocimiento consensuado respecto de los aspectos teóricos y

prácticos de la utilización de metodologías ágiles, así como una mayor consolidación de los

resultados de aplicación. La actividad de investigación está orientada hacia líneas tales

como: métricas y evaluación del proceso, herramientas específicas para apoyar prácticas

ágiles, aspectos humanos y de trabajo en equipo. Entre estos esfuerzos destacan proyectos

como NAME12 (Network for Agile Methodologies Experience).

Es XP la metodología que resalta por contar con la mayor cantidad de información

disponible y es con diferencia la más popular.

55


15. Recomendaciones

Debe hacerse lo posible por no realizar modificaciones a XP demasiado drásticas ya que se

corre el riesgo de alterar la esencia de la metodología.

Debe plantearse una estrategia para afrontar el diseño de datos en XP.

Se deben afijar una serie de reglas generales en la comunicación con el cliente ya que por el

grado de informalidad que la metodología presenta puede surgir diferencias que pongan en

peligro la culminación exitosa del proyecto.

Debe hacerse una capacitación al cliente sobre XP antes de iniciar el proyecto debido que

este hace parte del equipo de desarrollo.

Plantear una estrategia especial de refactoring para las bases de datos.

Tener un buen conocimiento de las herramientas para la implementación antes de iniciar

dicha etapa.

Plantear como unidad de tiempo horas en lugar de días para la asignación de tareas.

Considerar el internet y herramientas basadas en él como mecanismos de comunicación

válidos dentro de XP y discutir la necesidad de un único sitio geográfico de trabajo.

Hacer una experiencia realizando un mismo proyecto por dos grupos de desarrollo

independientes empleando una metodología pesada y XP con el fin de comparar los

resultados obtenidos.

Emplear XP en un proyecto de mayor envergadura con el fin de evaluar el desempeño de la

metodología en ese tipo de proyectos.



BibliografíaBeck, Kent. 2002. Una explicación de la Programación extrema: aceptar el cambio. s.l. :

Addison-Wesley Iberoamericana Espanya, S.A., 2002.

James Newkirk, Robert C. Martin. 2002. La Programación Extrema en la práctica. s.l. :

Addison-Wesley Iberoamericana Espanya, S.A., 2002.

Ron Jeffries, Ann Anderson, Chet Hendrickson, Ronald E. Jeffries. 2000. Extreme

Programming Installed. s.l. : Addison-Wesley Pub Co; 1 edición, 2000.


XP Informe

Documents

Transcript of XP Informe