Este documento describe la metodología ágil XP (Extreme Programming). Explica la historia, definición y roles de XP, así como su ciclo de vida que incluye exploración, planificación, iteraciones, producción y mantenimiento. También detalla algunas de las prácticas clave de XP como el juego de planificación, entregas pequeñas, diseño simple y pruebas unitarias.

2. Por: Henrry Manuel Jiménez Calva
Jorge Luis Auquilla Villamagua
Santiago Felipe Tuqueres Quezada
Wilson Lizandro Valverde Jadan
Francisco Agreda
Facultad de la Energía, las Industrias y los Recursos Naturales No Renovables
Carrera de Ingeniería en Sistemas
Loja-Ecuador
METODOLOGIA AGIL XP

3. Agenda :
1. Historia
2. Definición
3. Equipo y Roles
4. Ciclo de Vida XP
5. Fases
6. Prácticas XP
7. Ejemplo

4. Historia :
La programación extrema o eXtreme Programming (XP) es un
enfoque de la ingeniería de software formulado por Kent Beck,
autor del primer libro sobre la materia, Extreme Programming
Explained: Embrace Change (1999). Es el más destacado de
los procesos ágiles de desarrollo de software. Al igual que
éstos, la programación extrema se diferencia de las
metodologías tradicionales principalmente en que pone más
énfasis en la adaptabilidad que en la previsibilidad.

5. Definición :
La metodología XP o Programación Extrema es una
metodología ágil y flexible utilizada para la gestión de proyectos
Extreme Programming se centra en potenciar las relaciones
interpersonales del equipo de desarrollo como clave del éxito
mediante el trabajo en equipo, el aprendizaje continuo y el buen
clima de trabajo.
Esta metodología pone el énfasis en la retroalimentación
continua entre cliente y el equipo de desarrollo y es idónea para
proyectos con requisitos imprecisos y muy cambiantes.

6. Equipo
● Se considera al equipo de proyecto como el principal
factor de éxito del proyecto
● Software funciona por encima de una buena
documentación.
● Interacción constante entre el cliente y el equipo de
desarrollo.
● Planificación flexible y abierta.
● Rápida respuesta a cambios
● Se considera al equipo de proyecto como el principal
factor de éxito del proyecto
● Software funciona por encima de una buena
documentación.
● Interacción constante entre el cliente y el equipo de
desarrollo.
● Planificación flexible y abierta.
● Rápida respuesta a cambios

7. Roles
● Cliente: responsable de definir y conducir el proyecto así como sus objetivos.
● Programadores: estiman tiempos de desarrollo de cada actividad y programan el
proyecto.
● Tester: Encargado de Pruebas.
● Tracker: Encargado de Seguimiento.
● Coach: Entrenador. Su papel es guiar y orientar al equipo.
● Consultor: Es un miembro externo del equipo con un conocimiento específico en
algún tema necesario para el proyecto. Guía al equipo para resolver un problema
específico.
● Big Boss: Gestor del proyecto, gerente del proyecto, debe tener una idea general
del proyecto y estar familiarizado con su estado.

8. Ciclo de Vida XP
EXPLORACIÓN
PLANIFICACIÓN
ITERACIONES
PRODUCCIÓN
MANTENIMIENTO
MUERTE
PROYECTO

9. Exploración
● Los clientes plantean las historias de usuario
● Se prueba la tecnología y explora la arquitectura del sistema
Planificación
● El cliente establece la prioridad de cada historia de usuario
● Se determina un cronograma en conjunto con el cliente

10. Iteraciones
● Crear la solución
● Se incluyen varias iteraciones sobre el sistema antes de ser entregado
Producción
● Entregar el producto final al cliente
● Se requiere de pruebas adicionales y revisiones de rendimiento

11. Mantenimiento
● Se debe mantener el sistema en funcionamiento al mismo tiempo que se
crean nuevas iteraciones
● Se requiere de tareas de soporte para el cliente
Muerte del proyecto
● Cuando el usuario no tiene más historias para ser incluidas en el sistema
● Se genera la documentación final

12. Fases
1. Planeación
La actividad de planeación (también llamada juego de planeación) comienza escuchando actividad para recabar
requerimientos que permite que los miembros técnicos del equipo XP entiendan el contexto del negocio para el
software y adquieran la sensibilidad de la salida y características principales y funcionalidad que se requieren.

13. ● Historias de usuario:
Las historias de usuario tienen la misma finalidad que los casos de uso pero con algunas diferencias:
● Constan de 3 ó 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.
● ambién se utilizan en la fase de pruebas, para verificar si el programa cumple con lo que especifica la historia de usuario.

14. ● Release planning:
● Significa plan de publicaciones y se lo realiza después de tener ya definidas las historias de usuario
● 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.
● 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

15. ● Iteraciones
iteración los clientes deben seleccionar las historias de usuario definidas en el "Release planning" que serán implementadas.
se seleccionan las historias de usuario que no pasaron el test de aceptación que se realizó al terminar la iteración anterior
tareas de entre 1 y 3 días de duración que se asignan a los programadores.
● Velocidad del proyecto
representa la rapidez con la que se desarrolla el proyecto
contar el número de historias de usuario que se pueden implementar en una iteración

16. ● Velocidad del proyecto
representa la rapidez con la que se desarrolla el proyecto
contar el número de historias de usuario que se pueden implementar en una iteración
● Programación en pareja
incrementa la productividad y la calidad del software desarrollado.

17. 2. Diseño
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 impleméntable que a la larga costará menos tiempo y
esfuerzo desarrollar.
....... Glosarios de términos: Usar glosarios de términos y un 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.
....... 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.
. Funcionalidad 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.
....... 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.
.......Tarjetas C.R.C. El uso de las tarjetas C.R.C (Class, Responsabilities and Collaboration) permiten al programador centrarse y
apreciar el desarrollo orientado a objetos olvidándose de los malos hábitos de la programación procedural clásica.
......

18. 3. Codificación
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.
.......Crear test que prueben el funcionamiento de los distintos códigos implementados nos ayudará a desarrollar dicho código.

19. 4. Pruebas
❖ .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

20. Prácticas XP

21. Prácticas XP
El juego de la planificación
❏ Existen dos tipos de jugadores: Cliente y Programador.
❏ El cliente establece la prioridad de cada historia de usuario
❏ Los programadores estiman el esfuerzo asociado a cada historia de usuario.
❏ Se ordenan las historias de usuario según prioridad y esfuerzo.
❏ Se realiza durante la planificación de la entrega, en la planificación de cada iteración y
cuando sea necesario reconducir el proyecto.

22. Prácticas XP
Entregas pequeñas
❏ La idea es producir rápidamente versiones del sistema que sean operativas.
❏ No cuentan con toda la funcionalidad pretendida para el sistema, pero sí que constituyan
un resultado de valor para el negocio.
❏ Una entrega no debería tardar más de 3 meses.
Metáfora
❏ El sistema es definido mediante una metáfora o un conjunto de metáforas compartidas
por el cliente y el equipo de desarrollo.
❏ Una metáfora es una historia compartida que describe cómo debería funcionar el
sistema.
❏ Martin Fowler explica que la práctica de la metáfora consiste en formar un conjunto de
nombres que actúen como vocabulario para hablar sobre el dominio del problema.
❏ Este conjunto de nombres ayuda a la nomenclatura de clases y métodos del sistema

23. Prácticas XP
Diseño simple
❏ Se debe diseñar la solución más simple que pueda funcionar y ser implementada en un momento
determinado del proyecto.
❏ La complejidad innecesaria y el código extra debe ser removido inmediatamente.
❏ Kent Beck dice que en cualquier momento el diseño adecuado para el software es aquel que
supera con éxito todas las pruebas (no tiene lógica duplicada, refleja claramente la intención de
implementación de los programadores y tiene el menor número posible de clases y métodos).
Pruebas
❏ La producción de código está dirigida por las pruebas unitarias.
❏ Las pruebas unitarias son establecidas antes de escribir el código y son ejecutadas
constantemente ante cada modificación del sistema.
❏ Los clientes escriben las pruebas funcionales para cada historia de usuario que deba validarse.
❏ La automatización para apoyar esta actividad es crucial.

24. Prácticas XP
❏ Refactorización (Refactoring)
❏ La refactorización es una actividad constante de reestructuración del código (remover
duplicación de código, mejorar su legibilidad, simplificarlo y hacerlo más flexible)
❏ En el transcurso del tiempo este diseño evoluciona conforme cambia la funcionalidad
del sistema.
❏ Para mantener un diseño apropiado, es necesario realizar actividades de cuidado
continuo durante el ciclo de vida del proyecto.
.

25. Prácticas XP
Programación en parejas
Toda la producción de código debe realizarse con trabajo en parejas de programadores.
Según Cockburn y Williams, las principales ventajas:
❏ Muchos errores son detectados conforme son introducidos en el código (inspecciones de
código continuas),
❏ Los diseños son mejores y el tamaño del código menor (continúa discusión de ideas de los
programadores).
❏ Se posibilita la transferencia de conocimientos de programación entre los miembros del
equipo.
En los estudios realizados por Cockburn y Williams este lapso de tiempo varía de 3 a 4 meses.

26. Prácticas XP
Propiedad colectiva del código
❏ Cualquier programador puede cambiar cualquier parte del código en cualquier momento.
❏ Esta práctica motiva a todos a contribuir con nuevas ideas en todos los segmentos del
sistema.
Integración continua
❏ Cada pieza de código es integrada en el sistema una vez que esté lista.
❏ Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo código sea
incorporado definitivamente.
❏ La integración continua a menudo reduce la fragmentación de los esfuerzos de los
desarrolladores.
❏ Martin Fowler afirma que el desarrollo de un proceso disciplinado y automatizado es
esencial para un proyecto controlado

27. Prácticas XP
40 horas por semana
❏ Se debe trabajar un máximo de 40 horas por semana.
❏ El trabajo extra desmotiva al equipo.
❏ En lugar de esto se puede realizar el juego de la planificación para cambiar el ámbito del
proyecto o la fecha de entrega.
Cliente in-situ
❏ Es el cliente quien conduce constantemente el trabajo hacia lo que aportará mayor valor de
negocio.
❏ La comunicación oral es más efectiva que la escrita.
❏ Intentar conseguir un representante que actúe como interlocutor del cliente.
❏ Contar con el cliente al menos en las reuniones de planificación
❏ Establecer visitas frecuentes de los programadores al cliente para validar el sistema.
❏ Anticiparse a los problemas asociados estableciendo llamadas telefónicas frecuentes y
conferencias.

28. Prácticas XP
Estándares de programación
❏ XP enfatiza la comunicación de los
programadores a través del código
❏ Es indispensable que se sigan ciertos
estándares de programación (del equipo, de
la organización u otros estándares
reconocidos para los lenguajes de
programación utilizados).
❏ Los estándares de programación mantienen
el código legible para los miembros del
equipo, facilitando los cambios.

29. Ejemplo Práctico : Descripción del negocio
● Al momento de iniciar este proyecto el negocio contaba con una caja
registradora convencional la cual no ofrece las funcionalidades que requiere
el cliente, por lo cual se acordó desarrollar un software que desempeñará las
funcionalidades de un sistema POS con elementos de administración de
inventario que cumpliera las necesidades específicas del cliente

30. Descripción de cliente y usuario
● Para este proyecto se contó con dos usuarios de los cuales uno era el
cliente.
○ El primer usuario que además era el cliente se trataba de una persona mayor
○ El segundo usuario fue una ex empleada del cliente de edad entre veinte y veinticinco

31. Planeación
Entre los elementos a discutir para este capítulo se encuentran:
○ Historias de usuario
○ Velocidad del proyecto
○ División de Iteraciones
○ Entregas Pequeñas
○ Plan de entregas

32. Historias de usuarios

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

34. División en iteraciones
● El proyecto fue dividido en 4 iteraciones, por consiguiente, se obtuvo un total
de cuatro entregas para las cuales se desarrollaron partes de la aplicación
completamente funcionales
● La primera iteración se refirió al módulo de POST mientras las demás
iteraciones se relacionaron con la manipulación de inventarios

35. Entregas pequeñas
Debido a que las iteraciones tenían una duración de 15 días, fue al término
de este plazo que se realizaron entregas, las cuales siempre fueron
funcionales, lo que quiere decir que al momento de la entrega estaban en
condiciones de ser puestas en funcionamiento en las instalaciones del
cliente.

36. Plan de entregas

37. Diseño
A continuación se detalla la experiencia vivida con los elementos más
importantes que se menciona en XP entre ellos podemos encontrar:
● Simplificación
● Tarjetas CRC
● Refactoring

38. Simplificación

39. Tarjetas CRC
En el proceso de elaboración de las tarjetas
CRC los dos miembros del equipo estuvieron
presentes manipulandolas, de modo tal que
tanto el diseño fue producto de la participación
de los dos desarrolladores

40. Refactorización
● Al transcurrir el desarrollo de la aplicación, se revisó constantemente el
diseño de la misma surgiendo situaciones que no fueron tomadas en cuenta
al comienzo del proyecto en el diseño general
● Como salida a estos problemas se optó por la refactorización de las partes
afectadas

41. Codificación
Entre los elementos más importantes que menciona XP referentes a la
codificación están:
● Cliente siempre presente
● El código se escribe siguiendo estándares
● Toda la producción de código debe ser hecha en parejas
● No trabajar horas Extras

42. Pruebas
Pruebas de aceptación
Dos elementos permitieron al grupo
de desarrollo diseñar las pruebas de
aceptación.

43. Referencias
[1] UNIVERSIDAD TECNOLÓGICA DE PEREIRA. (2007). CASO PRÁCTICO DE LA METODOLOGÍA ÁGIL XP AL DESARROLLO DE
SOFTWARE. Recuperado de https://aalbertovargasc.files.wordpress.com/2011/07/proyecto-con-xp.pdf
[2] UNIVERSIDAD POLITÉCNICA DE VALENCIA. (2012). METODOLOGÍAS ÁGILES PARA EL DESARROLLO DE SOFTWARE: eXtreme
Programming (XP) . Recuperado de http://roa.ult.edu.cu/bitstream/123456789/477/1/masyxp.pdf