xp informe
Post on 11-Jul-2016
216 Views
Preview:
DESCRIPTION
TRANSCRIPT
"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
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
Í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
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
Í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
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
* 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
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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
METODOLOGOGÍA xp 11
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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
METODOLOGOGÍA xp 12
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
METODOLOGOGÍA xp 13
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
METODOLOGOGÍA xp 14
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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
METODOLOGOGÍA xp 15
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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:
Fuente: (Elaboración propia, 2014)
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
METODOLOGOGÍA xp 16
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
METODOLOGOGÍA xp 17
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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
METODOLOGOGÍA xp 18
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
METODOLOGOGÍA xp 19
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
Fuente: (Elaboración propia, 2014)
METODOLOGOGÍA xp 20
Figura 1
Figura 2
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
Fuente: (Elaboración propia, 2015)
METODOLOGOGÍA xp 21
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
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
METODOLOGOGÍA xp 24
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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:
Fuente: (Elaboración propia, 2015)
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.
METODOLOGOGÍA xp 25
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
METODOLOGOGÍA xp 26
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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
METODOLOGOGÍA xp 27
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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
Fuente: (Elaboración propia, 2015)
METODOLOGOGÍA xp 28
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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
METODOLOGOGÍA xp 29
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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".
METODOLOGOGÍA xp 30
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
METODOLOGOGÍA xp 31
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
METODOLOGOGÍA xp 32
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
Fuente: (Elaboración propia, 2015)
METODOLOGOGÍA xp 33
Figura 4 Fases de la Metodología XPFigura 4
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
Fuente: (Elaboración propia, 2015)
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.
METODOLOGOGÍA xp 34
Figura 5 Fases de la Metodología XP según Ian SommervilleFigura 5
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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
METODOLOGOGÍA xp 35
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
Fuente: (Elaboración propia, 2015)
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.
METODOLOGOGÍA xp 36
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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
METODOLOGOGÍA xp 37
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
METODOLOGOGÍA xp 38
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
Fuente: (Elaboración propia, 2015)
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.
METODOLOGOGÍA xp 39
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
METODOLOGOGÍA xp 40
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
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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)
METODOLOGOGÍA xp 42
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
METODOLOGOGÍA xp 43
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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:
METODOLOGOGÍA xp 44
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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é
METODOLOGOGÍA xp 45
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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
METODOLOGOGÍA xp 46
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
METODOLOGOGÍA xp 47
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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:
METODOLOGOGÍA xp 48
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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:
METODOLOGOGÍA xp 49
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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
METODOLOGOGÍA xp 50
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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
METODOLOGOGÍA xp 51
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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:
METODOLOGOGÍA xp 52
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
METODOLOGOGÍA xp 53
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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
METODOLOGOGÍA xp 54
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
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
METODOLOGOGÍA xp 56
UNIVERSIDAD NACIONAL DE TRUJILLO 25-3-2015
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.
METODOLOGOGÍA xp 57
top related