METODOLOGIAS XP

1. “Año de la Diversificación Productiva y del
Fortalecimiento de la Educación”
INSTITUTO SUPERIOR TECNOLÓGICO PRIVADO
“JUAN MEJÍA BACA”
CURSO: INGENERIA DE SOFTWARE I
TEMA: METODOLOGIAS XP
CICLO: V TURNO: NOCHE CODIGO: 1615NA
GRUPO: BIINGE’SOFT
ALUMNOS: ARCE SANDOVAL JOSE
INGA MILIAN ROSMRY
DOCENTE:MARCO AURELIO PORRO CHULLI

2. DEFINICION
La programación extrema, o Extreme Programming (XP), es una metodología de desarrollo
ágil, una de las más exitosas en tiempo reciente. Su autor principal es Kent Beck, quien eligió
algunas características de otras metodologías y las relacionó de forma que cada una
complementara a la otra.
Esta metodología tiene como base la simplicidad y como objetivo principal la satisfacción del
cliente; para lograrlo se deben tomar en cuenta cuatro valores fundamentales:
 Comunicación
Es muy importante que haya una comunicación constante con el cliente y dentro de todo
el equipo de trabajo.
 Simplicidad
En la XP se refiere que ante todo y sin importar qué funcionalidad requiera el usuario en
su sistema, éste debe ser fácil.
 Retroalimentación
Es la comunicación constante entre el desarrollador y el usuario.
 Coraje
Se refiere a la valentía que se debe tener al modificar o eliminar el código que se realizó
con tanto esfuerzo; el desarrollador debe saber cuándo el código que desarrolló no es útil
en el sistema y, por lo mismo, debe ser eliminado.

3. CARACTERISTICAS
 Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
 Pruebas unitarias continuas: frecuentemente repetidas y automatizadas, incluyendo pruebas de
regresión.
 Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas
en un mismo puesto.
 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.
 Corrección de todos los errores: antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
 Refactorización del código: es decir, rescribir ciertas partes del código para aumentar su legibilidad y
mantenibilidad pero sin modificar su comportamiento.
 Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo
en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender
cualquier parte del proyecto.
 Simplicidad en el código: es la mejor manera de que las cosas funcionen.
La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta
más fácil identificar qué se debe y qué no se debe hacer.

5. CICLO DE DESARROLLO
Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar basado en la
habilidad del equipo para medir la funcionalidad que puede entregar a través del tiempo. El ciclo de
desarrollo consiste (a grandes rasgos) en los siguientes pasos. El cliente define el valor de negocio a
implementar.
1. El programador estima el esfuerzo necesario para su implementación.
2. El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo.
3. El programador construye ese valor de negocio.
4. Vuelve al paso 1.
El ciclo de vida ideal de XP consiste de seis fases [2]: Exploración, Planificación de la Entrega (Release),
Iteraciones, Producción, Mantenimiento y Muerte del Proyecto.
Fase I: 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.
Fase II: Planificación de la Entrega
En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los
programadores realizan una estimación del esfuerzo necesario de cada una de ellas. Se toman acuerdos
sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente.
La planificación se puede realizar basándose en el tiempo o el alcance. La velocidad del proyecto es
utilizada para establecer cuántas historias se pueden implementar antes de una fecha determinada o cuánto
tiempo tomará implementar un conjunto de historias.

6. Fase III: Iteraciones
Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega está
compuesto por iteraciones de no más de tres semanas. En la primera iteración se puede intentar establecer
una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto.
Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la Iteración son: historias de
usuario no abordadas, velocidad del proyecto, pruebas de aceptación no superadas en la iteración anterior y
tareas no terminadas en la iteración anterior.
Fase IV: Producción
La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema
sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusión de
nuevas características a la versión actual, debido a cambios durante esta fase.
Fase V: Mantenimiento
Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener el sistema en
funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas
de soporte para el cliente.
Fase VI: Muerte del Proyecto
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.

7. EJEMPLO
Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca. El sistema debe
admitir el alta y la baja de socios y de libros. Los socios pueden pedir libros en préstamo, pero no se
pueden tener más de tres libros en préstamo en un momento determinado. Los libros se han de
devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después
de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede
tener simultáneamente. Cuando llega a cero el socio se da de baja automáticamente. Ahora
supongamos que este problema nos lo ha planteado nuestro cliente, que quiere que le construyamos
exactamente el sistema descrito en el enunciado ¿Cómo llegamos desde el mismo, a la lista de
tareas del backlog?
Por el momento vamos a obviar aquellas tareas que a simple vista no aportan valor al cliente pero
que son del todo necesarias para el proyecto (definir e implementar la arquitectura del sistema por
ejemplo) y vamos a centrarnos únicamente en los objetivos funcionales.
Lo que vamos a hacer va a ser un “clásico” análisis de requerimientos, intentando extraer del texto (lo
que nos dice el cliente) las diferentes funcionalidades que debe tener el sistema. Para ello analizamos
los párrafos del texto. A simple vista podemos extraer las siguientes funcionalidades: De la siguiente
frase: El sistema debe admitir el alta y la baja de socios y de libros extraemos las siguientes posibles
historias de usuario:
*Alta Libro
*Baja Libro
*Alta Socio
*Baja Socio
Los socios pueden pedir libros en préstamo, pero no se pueden tener mas de tres libros en préstamo
en un momento determinado obtenemos una única funcionalidad o historia Préstamo libro
Los libros se han de devolver antes de un mes de la fecha del préstamo: Cada vez que un socio
devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el
número de libros que puede tener simultáneamente creo que podrían identificarse dos historias (es mi
opinión, quizás otra gente opine que sólo hay una posible historia)

8. Devolver libro Penalizar socio En el último párrafo obtenemos otra posible historia: Cuando llega a cero
el socio se de baja automáticamente. Aunque pueda parecer que es una historia repetida, yo considero
que a nivel de valor al cliente es una funcionalidad diferente. Baja automática de socio Aparte de las
historias que aparecen más o menos explícitas en el código, quizás podrían deducirse otras historias
cómo:
• Iniciar sesión en el sistema
• Cerrar sesión
• Alta usuario
• Baja usuario
La lista completa de historias que tendríamos sería la siguiente:
• Alta libro
• Baja libro
• Alta socio
• Baja socio
• Préstamo de libro
• Devolver libro
• Penalizar socio
• Baja automática de socio
• Iniciar sesión en el sistema
• Cerrar sesión
• Alta usuario
• Baja usuario
Si estuviéramos en una metodología clásica de desarrollo, en este punto deberíamos hacer los casos de
uso para los requerimientos identificados, sus diagramas de secuencia, etc.
En una metodología cómo Scrum, por definición, no es necesaria esta documentación (queda a elección
de cada uno decidir que documentación necesita su proyecto) y lo que nos quedaría por hacer es definir
e introducir las historias en el backlog. ¿Y cómo se define una funcionalidad en forma de historia de
usuario?

9. Pues la idea es expresarla desde el punto de vista del cliente, o del usuario que va a usar el sistema,
con un lenguaje que pueda ser entendido perfectamente por ellos (nada de UML, OCL o demás
lenguajes de especificación) y que no cree ambigüedades. Por ejemplo:
5 Descripción: Cómo cliente quiero que los socios puedan pedir prestado un libro, indicando su
número de socio y la referencia del libro, siempre y cuando no tengan ya tres libros en préstamo en
ese momento. Importancia: 300 Cómo probarlo:
Introducir un número de socio incorrecto y comprobar que se indica error
Introducir un socio que ya tiene 3 libros en préstamo y comprobar que se indica error
Introducir un libro del que no hay ejemplares y comprobar que se indica un error
Introducir todos los datos correctos y comprobar que el número de ejemplares disponibles del libro
disminuye y el número de préstamos del socio aumenta en uno.
Como vemos, en Scrum se detalla de manera poco explícita la funcionalidad, únicamente se explica a
nivel de cliente. La ventaja es que no se fijan los detalles de la implementación hasta el momento en
que se va a realizar (en la descomposición en tareas) con lo que se puede reaccionar más ágilmente
ante los cambios de los requisitos o de las necesidades del cliente. Haciendo lo mismo con las demás
funcionalidades, nos quedaría un product backlog similar al siguiente (se ha obviado la parte de test
de las historias): Historia Importancia Descripción Alta libros 600 Dar de alta un libro en el sistema
Baja libros 250 Dar de baja un libro del sistema Alta socio 500 Dar de alta un socio en el sistema Baja
socio 300 Dar de baja un socio del sistema Pedir libro 350 Pedir prestado un libro Devolver libro 340
Devolver un libro Penalización socio 330 Penalizar al socio por retrasarse en la devolución Baja
automática 320 Dar de baja automáticamente de socio Iniciar sesión en el sistema 550 Iniciar una
sesión de usuario en el sistema Cerrar sesión 500 Terminar sesión con el sistema Alta usuario 450
Dar de alta un nuevo usuario en el sistema Baja usuario 400 Dar de baja un usuario del sistema En
este punto tenemos identificadas todas las tareas funcionales del proyecto, y se ha descrito cada una
de ellas cómo una historia de usuario. Aunque ya tenemos completa la lista de funcionalidades, es
obvio que el

10. 4. product backlog tal y como está no es suficiente para poder avanzar en el proyecto, ya que no
aparecen todas aquellas tareas que no son funcionales (historias técnicas, requisitos no funcionales o
como se le quieran llamar) pero que son necesarias para el desarrollo del proyecto. Pero la mayoría
de estas tareas no aportan valor al cliente, entonces ¿Se deben incluir estas tareas en el backlog? ¿Y
de que manera? No vamos a discutir en este artículo el tema, ya que daría para muchos posts, pero a
modo de apunte se podría gestionar de la siguiente forma: En proyectos que se están iniciando, es
fácilmente justificable introducir tareas técnicas o no funcionales, ya que sin ellas el proyecto no
existe. Así bajo la forma de Epics (o super historias de usuario) se podrían englobar tareas tales cómo
Implementar la capa de datos, implementar la capa de comunicaciones, etc. Estas tareas se llevarían
a cabo en las primeras iteraciones, o incluso en una primera iteración mayor que las otras. En fases
más avanzadas del proyecto, es difícil justificar tareas no funcionales, cómo la refactorización de
módulos, instalación de servidores de pruebas, etc. Ya que el cliente querrá priorizar aquellas
historias que le aporten valor. En este caso lo ideal es intentar que el cliente comprenda la
importancia de las tareas a realizar, o si eso no es posible utilizar otras técnicas, cómo introducirlas
dentro de alguna de las historias de usuario, o mantener una lista separada de historias técnicas con
un porcentaje de tiempo no negociable con el dueño de producto. Cómo hemos visto el proceso de
definir historias de usuario es tan simple (o tan complicado) cómo realizar un análisis de
requerimientos, proceso para el cual no hay ningún truco infalible y dependerá en gran medida de la
experiencia y pericia del analista o analistas que se encarguen de él, y expresar las funcionalidades
resultantes del análisis en un lenguaje que pueda ser fácilmente entendido por el cliente de nuestro
proyecto.