Nombres: Mario Tapia, Diego Morales, Nicolas Muñoz

Profesora: Ana Lemus

Metodología XP

Ritmo sostenido:

La metodología XP indica que debe llevarse un ritmo sostenido de trabajo. El concepto que se
desea establecer con esta práctica es el de planificar el trabajo de manera de mantener un ritmo
constante y razonable, sin sobrecargar al equipo.

XP está concebido a largo plazo, se debe de trabajar a un ritmo que se pueda mantener
indefinidamente, sin días muertos en que no se sabe qué hacer, ni días con sobrecarga y excesos
de horas. Al tener claro semana a semana lo que debe de hacerse, el equipo se focaliza en el
objetivo cercano de terminar una historia de usuario o reléase.

Características del ritmo sostenido:

-Se necesita tener un software completo, probado e integrado.

-En caso de no tener la capacidad necesaria para poder obtener todo, es necesario hacer una
reunión de planificación para maximizar la velocidad del proyecto.

-NO Horas extra de trabajo: Pueden cansar al equipo y ralentizar aún más el trabajo.

-NO Gente nueva: En cuanto tomo esta decisión es porque me doy cuenta de que mi equipo de
trabajo ya va lento, es por ello que ya es demasiado tarde

-SÍ Utilizar reunión de planificación de liberación para redefinir alcance o en mejor forma el
calendario.

Codificación:
Estas indicaciones hacen referencia al enfoque y el formato. Es importante que los desarrolladores
puedan trabajar en los códigos de sus compañeros y que sepan qué cambios ha realizado cada
uno.
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

• Codificar primero la prueba

Ventajas

Desarrollo ágil

Código unificado y entendible

Diferentes visiones acerca de la creación de código.

Soluciones con diferentes enfoques.

Pruebas:

Uno de los pilares de la eXtreme Programming (XP a partir de ahora) es el proceso de pruebas.XP
anima a probar constantemente tanto como sea posible. Esto permite aumentar la calidad de los
sistemas reduciendo el número de errores no detectados y disminuyendo el tiempo transcurrido
entre la aparición de un error y su detección. También permite aumentar la seguridad de evitar
efectos colaterales no deseados a la hora de realizar modificaciones y refactorizaciones.

Entre algunas de estas pruebas están PRUEBAS UNITARIAS y las PRUEBAS DE ACEPTACION.

Pruebas unitarias

Las pruebas unitarias son una de las piedras angulares de XP. Todos los módulos deben de pasar
las pruebas unitarias antes de ser liberados o publicados. Por otra parte, como se mencionó
anteriormente, las pruebas deben ser definidas antes de realizar el código (“Test-driven
programming”). Que todo código liberado pase correctamente las pruebas unitarias es lo que
habilita que funcione la propiedad colectiva del código. En este sentido, el sistema y el conjunto de
pruebas debe ser guardado junto con el código, para que pueda ser utilizado por otros
desarrolladores, en caso de tener que corregir, cambiar o recodificar parte de este.

Pruebas de aceptación

Las pruebas de aceptación son creadas en base a las historias de usuarios, en cada ciclo de la
iteración del desarrollo. El cliente debe especificar uno o diversos escenarios para comprobar que
una historia de usuario ha sido correctamente implementada. Las pruebas de aceptación son
consideradas como “pruebas de caja negra” (“Black box system tests”). Los clientes son
responsables de verificar que los resultados de estas pruebas sean correctos. Asimismo, en caso
de que fallen varias pruebas, deben indicar el orden de prioridad de resolución. Una historia de
usuario no se puede considerar terminada hasta tanto pase correctamente todas las pruebas de
aceptación. Dado que la responsabilidad es grupal, es recomendable publicar los resultados de las
pruebas de aceptación, de manera que todo el equipo esté al tanto de esta información.

Ventajas y desventajas de la metodología XP

Ventajas

Programación organizada.

Menor taza de errores.

Satisfacción del programador.

Solución de errores de programas

Versiones nuevas

Implementa una forma de trabajo donde se adapte fácilmente a las circunstancias

Desventajas

Es recomendable emplearlo solo en proyectos a corto plazo

Altas comisiones en caso de fallar

Imposible prever todo antes de programar

Demasiado costoso e innecesario