Roque Mamani Alfonso

Vidal
Huallpa Yupanqui Erick
Sandro
 Metodología XP
XP es una metodología ágil para el desarrollo de software y consiste
básicamente en ajustarse estrictamente a una serie de reglas que se centran en
las necesidades del cliente para lograr un producto de buena calidad en poco
tiempo, centrada en potenciar las relaciones interpersonales como clave para el
éxito del desarrollo de software.
La filosofía de XP es satisfacer al completo las necesidades del cliente. Y
además los desarrolladores están en constante aprendizaje ya que se realizan
proyectos muy cambiantes y de alto riesgo técnico

XP está diseñada para el desarrollo de aplicaciones que requieran un grupo de

programadores pequeño, dónde la comunicación sea más factible que en grupos de
desarrollo grandes. La comunicación es un punto importante y debe realizarse entre los
programadores, los jefes de proyecto y los clientes
Comunicación Respeto

Valores de XP

Simplicidad Valentía

Retroalimentación
 Programador

Clientes

Encargado de pruebas

Role Encargado de seguimiento

s
Entrenador

Consultor

Gestor
 Modelo XP
La metodología XP define cuatro variables
para cualquier proyecto de software: costo,
tiempo, calidad y alcance
Además, se especifica que, de estas cuatro variables, sólo tres de
ellas podrán ser fijadas arbitrariamente por actores externos al
grupo de desarrolladores (clientes y jefes de proyecto). El valor de
la variable restante podrá ser establecido por el equipo de
desarrollo, en función de los valores de las otras tres. Este
mecanismo indica que, por ejemplo, si el cliente establece el
alcance y la calidad, y el jefe de proyecto el precio, el grupo de
desarrollo tendrá libertad para determinar el tiempo que durará el
proyecto
con entregables funcionales al finalizar cada ciclo. En Típicamente un proyecto con XP lleva 10 a 15
cada iteración se realiza un ciclo completo de análisis, ciclos o iteraciones.
diseño, desarrollo y pruebas, pero utilizando un
conjunto de reglas y prácticas que caracterizan a XP.
 Esquema XP

Historias del usuario Diseño de tarjetas

Valores CRC
Criterios de pruebas de
Planificación Diseño
adaptación Planificación Diseño
Plan de iteración
Soluciones
Pruebas unitarias en punto
Integración prototipo
continua
Lanzamiento Pruebas Codificación
Lanzamiento Pruebas Codificación

Incremento del software Pruebas de Programación por

Velocidad calculada del iteración pareja
proyecto
 PROCESO XP
¿CUÁNDO TIENE ÉXITO UN PROCESO PX?

• El cliente define el valor de negocio a implementar.

• El programador estima el esfuerzo necesario para su implementación.
• El cliente selecciona qué construir, de acuerdo con sus prioridades y
las restricciones de tiempo
• El programador construye ese valor de negocio.
FASES DE CICLO DE VIDA DE
UN PROYECTO XP
Exploración

Planificación de la Entrega (Release)

Iteraciones

Producción

Mantenimiento

Muerte del Proyecto.

EXPLORACIÓN

• 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 se familiariza con las herramientas
tecnológicas y práctica que se utilizarán en el proyecto.
• Una ves probado la tecnología se explotan posibilidades de la
arquitectura del sistema construyendo un prototipo; puede durar
pocas semanas a pocos meses
PLANIFICACIÓN DE LA ENTREGA
(RELEASE)

• En esta fase el cliente establece prioridad por cada historia de usuario, y

los programadores calculan el esfuerzo necesario para cada uno de ellos.
• Tomar acuerdos sobre la primera entrega.
• Una entrega debe durar no mas de 3 meses.
• Las estimaciones de esfuerzo de los programadores miden por puntos: una
historia equivale de 1 a 3 puntos.
• Por otra parte el equipo de desarrollo mantiene un “RESGISTRO DE
VELOCIDAD DE DESARROLLO” establecida en puntos por iteración
basándose en la cantidad de historia.
ITERACIONES

• En esta fase incluye varias iteraciones sobre el sistema antes de ser

entregado.
• El plan está entrega por iteraciones de no más de 3 semanas.
1° ITERACIÓN: Se intenta establecer una
arquitectura que pueda ser utilizada durante el
resto del proyecto.

• historias de usuario no abordadas

• Velocidad del proyecto
• Pruebas de aceptación no superadas en la iteración anterior.
• Tareas no terminadas en la iteración anterior.
PRODUCCIÓN

• Requiere de pruebas y revisiones de rendimiento antes de que sea

trasladador al entorno del cliente.
• Durante esa fase habrá cambios y se tiene que tomar decisiones sobre
la inclusión de nuevas características a la versión actual.
• Es posible que se reduzca el tiempo de iteración a de 3 a 1 semana.
• Las ideas que han sido propuestas y las sugerencias son documentadas
para su posterior implementación.
Mantenimiento

• Mientras la primera versión está en ejecución, el proyecto XP debe

mantener el sistema en funcionamiento al mismo tiempo que desarrolla
nuevas iteraciones.
• Dando tareas de soporte al cliente y poder haber cambios en su
estructura para bien.
MUERTE DEL PROYECTO.

• Cuando el cliente ya no tiene más historias que plasmar e el sistema;

quiere decir que el cliente está satisfecho con el rendimiento de
confiabilidad del sistema.
• Se genera una documentación al final del sistema y no se realiza más
cambios en la estructura.
“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”.
REGLAS Y PRÁCTICAS
LA METODOLOGÍA XP TIENE UN CONJUNTO DE REGLAS Y PRÁCTICAS
QUE SE AGRUPAN EN:

Reglas y prácticas para la Planificación

Reglas y prácticas para el Diseño

Reglas y prácticas para el Desarrollo

Reglas y prácticas para las Pruebas

1 REGLAS Y PRÁCTICAS PARA
LA PLANIFICACIÓN
• La metodología XP reúne para un diálogo entre cliente,
programador y gerente.
• Comienza recopilando “historias de usuarios”, ya que esto
sustituye a los casos de uso.
• Una vez obtenida las historias de usuario los
programadores evalúan rápidamente el tiempo de
desarrollo de cada historia.
1 REGLAS Y PRÁCTICAS PARA
LA PLANIFICACIÓN
• Si hay riesgos que no permiten tener un buen desarrollo;
se crea un pequeño programa de prueba(“spikes”) para
reducir los riesgos.
• Luego ya solucionado se realiza una reunión con diversos
actores para estar de acuerdo y luego proceder a las
interacciones probando e insertando las historias.
1 REGLAS Y PRÁCTICAS PARA
LA PLANIFICACIÓN
Según Martin Fowler afirmó que los planes XP se diferencia de
metodologías tradicionales en tres aspectos
• Simplicidad del plan: los planes lo realizan cualquier persona,
no requiere de un experto ya que no son predicciones sino una
mejor estimación de como saldrán las cosas.
• Los planos son útiles pero a veces son necesarios cambiar
cuando las circunstancias lo requieren.
CONCEPTOS BÁSICOS DE LA
PLANEACIÓN
1.1 HISTORIA DE USUARIO

Son términos usados em XP para detallar brevemente sobre

las características que debe poseer el sistema a crear.
Respecto de la información contenida en la historia de
usuario, existen varias plantillas sugeridas pero no existe un
consenso al respecto
Modelo de plantilla según
Beck
 Fecha
 tipo de actividad (nueva, corrección, mejora),
 prueba funcional, número de historia,
 prioridad técnica y del cliente,
 referencia a otra historia previa,
 riesgo,
 estimación técnica,
 descripción,
 notas y una lista de seguimiento con la fecha,
1.2 PLAN DE ENTREGAS

El cronograma de entregas establece qué historias de

usuario serán agrupadas para conformar una entrega, y el
orden de las mismas. Éste cronograma nace de una reunión
de miembros.
1.2 PLAN DE ENTREGAS

La metodología XP denomina a esta reunión como “JUGO DE

PLANEAMIENTO”, ó de acuerdo a como la empresa lo quiera
llamarlo.
Luego de realizar iteraciones es recomendable otra reunión
con los actores para evaluar el plan de entrega y ajustarlo
si es necesario.
1.3 PLAN DE ITERACIONES

• Las historias de usuarios seleccionados para cada

entrega son desarrolladas a aprobadas en un ciclo de
iteración.
• Cada Historia de usuario se traducen en tareas
específicas de programación.
• Para cada historia de usuario se establecen las pruebas
de aceptación.
1.3 PLAN DE ITERACIONES

• Esta prueba se realiza al final de los ciclos que se

desarrollan y también al final de cada ciclo siguiente
para verificar que nada haya afectado a los anteriores
iteraciones.
1.4 REUNIONES DIARIAS DE
SEGUIMIENTO
• El motivo de tener reuniones diarios es para mantener la
conversasión entre equipo y compartir problemas y
soluciones.
2 DISEÑO

La metodología XP se fija en diseños simples y claros.

LOS DISEÑOS MÁS IMPORTANTES SON:

2.1 SIMPLICIDAD

Un diseño simple se implementa más fácil por eso XP

propone que el diseño sea lo más sencillo y que funcione.
2.2 SOLUCIONES

Cuando una historia es complicada, se crean pequeños

programas de prueba llamado (spike), luego se desecha
después de su evaluación.
2.3 RECODIFICACION

Consiste en escribir nuevamente el código sin cambiar su

funcionalidad y que sea simple.

La metodología XP recomienda que se recodifique cada vez

que se requiera.
2.4 METÁFORA

Una metáfora es algo que todos entienden sin necesidad de

una mayor explicación, la metodología XP sugiere lo mismo,
dar nombre o concepto de una manera sencilla de explicar.

Muy importante que el grupo comprenda la misma metáfora

para que puedan dialogar en un mismo idioma.
3 DESARROLLO

Disponibilidad de cliente: es muy importante que el

cliente disponga de tiempo completo para el proyecto y que
sea parte del grupo; el cliente es la parte fundamental para
el avance del proyecto, ya que brinda historias cortas pero
de alto nivel.
3 DESARROLLO

Uso de estándares: la M XP promueve la programación

basada en estándares de manera que sea fácil y entendible
por todo el equipo
3 DESARROLLO

Programación dirigida por las pruebas: las fases de prueba

y definición de los test, normalmente se realiza al final del
proyecto, M XP recomienda al inicio ya que condiciona o
dirige el desarrollo
4 PROGRAMACIÓN EN PARES

XP propone que se trabaje en pares, con una sola PC,

duplica tiempo asignado al proyecto, minimiza los errores y
se logra mejores diseños, etc.
Ventajas de trabajar en 2:
• Los errores se descubren en el momento de la
codificación.
• Los diseños son mejores y los códigos son cortos.
• Las personas conocen más a detalle el proyecto.
5 INTEGRACIONES PERMANENTES

Los desarrolladores necesitan trabajar en la ultima versión

y es importante que se trabaje en las versiones resientes y
no haya problemas con el sistema.
6 PROPIEDAD COLECTIVA DEL
CÓDIGO
En un equipo XP todos pueden contribuir con el objetivo de
tener un buen proyecto, ya sea cambiando los códigos,
agregando funciones, etc.
7 RITMO SOSTENIDO

La M XP se asegura que no sea necesario trabajar más horas

de lo común, sino planificar el trabajo y mantener un ritmo
estable de trabajo.
8 PRUEBAS

PRUEBAS UNITARIAS: son módulos que la M XP deben de

pasar antes de ser liberados o publicados.

las pruebas deben ser definidas antes de realizar el código

(Test-driven programming).
DETECCION Y CORRECIÓN DE ERRORES: cuando se
encuentra un error se debe de corregir inmediatamente
8 PRUEBAS

PRUEBAS DE ACEPTACIÓN: Son creados a pruebas de

historia de usuario, el cliente debe de especificar que una
historia a sido correctamente implementada.
V  Se consiguen productos usables con mayor rapidez.
 El proceso de integración es continuo, por lo que el esfuerzo final para la integración

e es nulo.
 Se consigue integrar todo el trabajo con mucha mayor facilidad.

n  Se atienden las necesidades del usuario con mayor exactitud.

 Esto se consigue gracias a las continuas versiones que se ofrecen al usuario.
t  Se consiguen productos más fiables y robustos contra los fallos gracias al diseño de los

a
test de forma previa a la codificación.
 Obtenemos código más simple y más fácil de entender, reduciendo el número de

j errores.
 Gracias a la filosofía del “pair programming” (programación en parejas), se consigue

a que los desarrolladores apliquen las buenas prácticas que se les ofrecen con la XP.
 Gracias al “refactoring” es más fácil el modificar los requerimientos del usuario.

s  Conseguimos tener un equipo de desarrollo más contento y motivado.

 Las razones son, por un lado el que la XP no permite excesos de trabajo (se debe
 Desventajas

 Resulta muy complicado planear el proyecto y establecer el costo y la duración del

mismo.

 No se puede aplicar a proyectos de gran escala, que requieran mucho personal, a

menos que se las subdivida en proyectos más pequeños.

 Es más complicado medir los avances del proyecto, pues es muy complicado el uso de
una medida estándar.

 Altas comisiones en caso de fallar.

 Conclusiones

 Es difícil estimar el costo y duración del proyecto por no existir una definición desde inicio.

 El cliente le da un valor agregado al proyecto ya que ayuda a que los requerimientos sean más
compresibles y de fácil aprobación.

 Organiza a los integrantes del equipo para trabajar a un mismo ritmo divertido y con horario
adecuado.

 Los desarrolladores deben estar involucrados en todas las funcionalidades del proyecto La
programación en parejas ayuda a reducir costo y tiempos y mejorar la calidad del proyecto.

 Los métodos en cascada o espiral son los más adecuados para proyectos. Que requieran
decenas de desarrolladores y en los que las especificaciones estén claramente determinadas
desde el comienzo.
 Recomendaciones

 Para proyectos medianos, y en los que las especificaciones no se puedan obtener hasta
luego de comenzado el proyecto, XP es la metodología recomendada.

 Usar XP en equipos pequeños de desarrollo que no superen a 20.

 Se debe involucrar al cliente en el desarrollo del proyecto desde el inicio hasta el final
ya que es indispensable que conozca y apruebe la metodología.

 Los desarrolladores deben compartan el código y ser responsables del código de todo el
proyecto.