Metodologias agiles Programacion Xtrema

METODOLOGIAS
AGILES
METODOLOGIA XP
CARLOS CORTES
VANESSA MOLINA
LISETH PATERNINA
OSCAR VARGAS

¿METODOLOGIAS AGILES?
Surge ante la necesidad
de ofrecer una
alternativa a la
metodologías
tradicionales,
caracterizados por ser
rígidos y dirigidos por
la documentación que se
genera en cada una de
las actividades
desarrolladas.

PRINCIPIOS DE LOS METODOS
AGILES

DIFERENCIAS ENTRE
METODOLOGIAS AGILES Y NO AGILES

¿Qué es
Programación Extrema
o XP(EXTREME PROGRAMMING)?

¿Programación Extrema o XP?
 La Programación Extrema es una
metodología ligera de desarrollo de
software que se basa en la
simplicidad, la comunicación y la
realimentación o reutilización del
código desarrollado.

 Centrada en potenciar las
relaciones interpersonales como
clave para el éxito en el desarrollo
de software.

 Su objetivo es aumentar la
productividad al desarrollar
software.

ORIGEN DE LA METODOLOGIA
XP
 Nace de la mano de Kent Beck en
el verano de 1996, cuando
trabajaba para Chrysler
Corporation.

 El tenía varias ideas de
metodologías para la realización
de programas que eran cruciales
para el buen desarrollo de
cualquier sistema.

 Las ideas primordiales de su
sistema las comunicó en la revista
C++ Magazine en una entrevista
que ésta le hizo el año 1999.

OBJETIVOS DE XP

 La satisfacción del cliente.

 Potenciar el trabajo en grupo.

 Minimizar el riesgo actuando sobre
las variables del proyecto:
- Coste
- Tiempo
- Calidad
- Alcance

VALORES QUE INSPIRAN XP

 Comunicación

 Sencillez

 Retroalimentación

 Valentía

INTRODUCCION A LA
METODOLOGIA XP

EL COSTE DEL CAMBIO

Evolución de los largos ciclos de desarrollo en cascada (a) a ciclos iterativos más
cortos (b) y a la mezcla que hace XP
.

Prácticas de Codificación

• Simplicidad de código y de diseño para producir software
fácil de modificar.
• Reingeniería continua para lograr que el código tenga un
diseño óptimo.
• Desarrollar estándares de codificación, para comunicar ideas
con claridad a través del código.
• Desarrollar un vocabulario común, para comunicar las ideas
sobre el código con claridad.

Prácticas de Desarrollo

• Adoptar un método de desarrollo basado en las pruebas
para asegurar que el código se comporta según lo esperado.
• Programación por parejas, para incrementar el
conocimiento, la experiencia y las ideas.
• Asumir la propiedad colectiva del código, para que todo el
equipo sea responsable de él.
• Integración continua, para reducir el impacto de la
incorporación de nuevas funcionalidades.

Prácticas de Negocios

• Integración de un representante del cliente en el equipo,
para encauzar las cuestiones de negocio del sistema de
forma directa, sin retrasos o pérdidas por intermediación.
• Adoptar el juego de la planificación para centrar en la
agenda el trabajo más importante.
• Entregas regulares y frecuentes para satisfacer la inversión
del cliente.
• Ritmo de trabajo sostenible, para terminar la jornada
cansado pero no agotado.

1RA FASE:
PLANIFICACIÓN DEL
PROYECTO

Fases de la Metodología XP (planificación)
A) HISTORIAS DEL USUARIO

• Las historias de usuario tienen el mismo propósito que los casos de uso.

• Las escriben los propios clientes, tal y como en ellos las necesidades del
sistema.

• Las historias de usuario son similares al empleo de escenarios, con la
excepción de que no se limitan a la descripción de la interfaz de usuario.
También conducirán el proceso de creación de los test de
aceptación(empleados para verificar que las historias de usuario han sido
implementadas correctamente).

• Existen diferencias entre estas y la tradicional especificación de requisitos.
La principal diferencia es el nivel de detalle. Las historias de usuario
solamente proporcionaran los detalles sobre la estimación del riesgo y
cuánto tiempo conllevará la implementación de dicha historia de usuario.

A) HISTORIAS DEL USUARIO

B) RELEASE PLANNING

es una planificación donde los desarrolladores y clientes establecen los tiempos de
implementación ideales de las historias de usuario, la prioridad con la que serán
implementadas y las historias que serán implementadas en cada versión del
programa.

C) PLAN DE ITERACION

Así puede verse un plan de iteración: Iteración y planes de iteración_

Fases de la Metodología XP
(planificación)

• La rotaciones evitarán que las personas se conviertan en si mismas en un cuello de
botella. Las rotaciones permitirán que todo el mundo conozca cómo funciona el
sistema.

• Reuniones de seguimiento diarias

• Deberemos corregir el proceso cuando éste falle.
• Todo el mundo debe estar al corriente de los cambios.
• Para que esto funcione correctamente hay que crear unidades de prueba de cada
módulo que se desarrolle.

Fases de la Metodología XP (Diseño)

X.P sugiere que hay que conseguir diseños simples y sencillos

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.

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. SPIKE(programa simple que explora una posible solución a un
problema)
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 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.

• representan objetos; la clase a la que pertenece el objeto se puede escribir en la
parte de arriba de la tarjeta, en una columna a la izquierda se pueden escribir las
responsabilidades u objetivos que debe cumplir el objeto y a la derecha, las clases
que colaboran con cada responsabilidad.

TARJETAS CRC

(DESARROLLO)

• Disponibilidad del CLIENTE
• Unidades de prueba o test
• Programación pareja
• Integración del código
• Frecuencia en la integración del código
• El código es propiedad de todos:
• Dejar la optimizaciones para el final
• No a las horas extras: 40 horas semanales

(PRUEBAS)

Unidades de test o pruebas: Pilar básico
Implantación: El código será implantado cuando supere sus correspondientes
unidades de test.

Protección contra fallos: Solución, un test

Pruebas de aceptación: Evaluación del cliente

1. PROGRAMADOR
 Pieza básica en desarrollos XP

 Más responsabilidad que en otros modos de desarrollo

 Responsable sobre el código

 Responsable sobre el diseño (refactorización, simplicidad)

 Responsable sobre la integridad del sistema (pruebas)

 Capacidad de comunicación

 Acepta críticas (código colectivo)

2. CLIENTE

 Pieza básica en desarrollos XP

 Define especificaciones

 Influye sin controlar

 Confía en el grupo de desarrollo

 Define pruebas funcionales

3. Encargado de pruebas (Tester)

 Apoya al cliente en la preparación/realización de las pruebas
funcionales

 Ejecuta las pruebas funcionales y publica los resultados

4. Encargado de seguimiento
(Tracker)

 Recoge, analiza y publica información sobre la marcha del proyecto sin
afectar demasiado el proceso

 Supervisa el cumplimiento de la estimaciones en cada iteración

 Informa sobre la marcha de la iteración en curso

 Controla la marcha de las pruebas funcionales, de los errores reportados,
de las responsabilidades aceptadas y de las prueba añadidas por los
errores encontrados

5. Entrenador (Coach)

 Experto en XP
 Responsable del proceso en su conjunto
 Identifica las desviaciones y reclama atención sobre las
mismas
 Guía al grupo de forma indirecta (sin dañar su seguridad ni
confianza)
 Interviene directamente si es necesario
 Atajar rápidamente el problema

6. Gestor (Big boss)

 Favorece la relación entre usuarios y desarrolladores

 Confía en el equipo XP

 Cubre las necesidades del equipo XP

 Asegura que alcanza sus objetivos

VENTAJAS Y DESVENTAJAS DE XP

Programación organizada.
Menor taza de errores.
Satisfacción del programador.

Es recomendable emplearlo solo en proyectos a
corto plazo.
Altas comisiones en caso de fallar.

REFERENCIAS BIBLIOGRAFICAS

Archivo .pdf de la Universidad Politécnica de Valencia con una amplia explicación sobre
metodologías ágiles y la programación extrema (XP). Recuperado el 20 de Febrero de 2013.
http://www.willydev.net/descargas/prev/TodoAgil.pdf

CALERO SOLÍS, Manuel. Una explicación de la programación extrema (XP). V Encuentro usuarios
xBase 2003 MADRID. Recuperado el 20 de Febrero de 2013.
http://www.willydev.net/descargas/prev/ExplicaXP.pdf

ACOSTA QUIROZ, César Augusto. Recuperado el 20 de Febrero de 2013.
http://www.slideshare.net/cesar_acosta/programacin-extrema-extream-programming-xp

Isaías Carrillo Pérez, Rodrigo Pérez González, Aureliano David Rodríguez Martín. Recuperado el 20
de Febrero de 2013.
http://es.scribd.com/doc/54060274/Metodologias-de-desarrollo

Metodologias agiles Programacion Xtrema

Más contenido relacionado

La actualidad más candente (20)

Destacado (8)

Similar a Metodologias agiles Programacion Xtrema (20)

Metodologias agiles Programacion Xtrema