Metodologia XP

Metodologia XP

Es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el mas destacado de los procesos agiles de desarrollo de software. Al igual que estos, la programacion extrema se diferencia de las metodologías tradicionales principalmente en que pone mas énfasis en la adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos.

La metodología XP se encuentra dividida en cuatro fases que son:

1. Planeación del proyecto.

1.1. Historias de usuario: el primer paso de cualquier proyecto que siga la metodología XP es definir las historias de usuario, tienen la misma finalidad que los casos de uso pero con algunas diferencias: constan de tres o cuatro líneas escritas por el cliente en un leguaje 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. También se utilizan en la fase de pruebas, para verificar si el programa cumple con lo que especifica la historia de usuario. Cuando llega la hora de implementar una historia de usuario, el cliente y los desarrolladores se reúnen para concretar y detallar lo que tiene hacer dicha historia. El tiempo de desarrollo ideal para una de usuario es entre 1 y 3 semanas.

1.2. Release planning: después de tener ya definidas las historias de usuario es necesario crear un plan de publicaciones, donde se indiquen las historias de usuario que se crearan para cada versión del programa y las fechas en las que se publicaran estas versiones. Un reléase plan es una planificación donde los desarrolladores 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. Después de un reléase plan tienen que estar claros estos cuatro factores:

1.2.1. Los objetivos que se deben cumplir (que son principalmente las historias que se deben desarrollar en cada versión).

1.2.2. El tiempo que tardaran en desarrollarse y publicarse las versiones del programa, el numero de personas que trabajaran en el desarrollo y como se evaluara la calidad del trabajo realizado.

1.3. Iteraciones: Todo proyecto que siga la metodología XP, se ha de dividir en 3 iteraciones de aproximadamente 3 semanas de duración. Al comienzo de cada iteración los clientes deben seleccionar las historias de usuario definidas en el reléase planning que serán implementadas. También se seleccionaran las historias de usuario que no pasaron el test de aceptación que se realizó al terminar la iteración anterior. Estas historias de usuario son divididas en tareas de entre 1 y 3 días de duración que se asignaran a los programadores.

1.4. Velocidad del proyecto: la velocidad del proyecto es una medida que representa la rapidez con la que se desarrolla el proyecto; estimarla es muy sencillo, basta con contar el numero de historias de usuario que se pueden implementar en una iteración; de esta forma, se sabra el cupo de historias que se pueden desarrollar en las distintas iteraciones. Usando la velocidad del proyecto controlaremos que todas las tareas se puedan desarrollar en el tiempo del que dispone la iteración. Es conveniente reevaluar esta medida cada 3 o 4 iteraciones y si se aprecia que no es adecuada hay que negociar con el cliente un nuevo Release Plan.

1.5. Programación en pareja: la metodología XP aconseja la programación en parejas pues incrementa la productividad y la calidad del software desarrollado. El trabajo en pareja involucra a dos programadores trabajando en el mismo equipo; mientras uno codifica haciendo hincapié en la calidad de la función o método que esta implementando, el otro analiza si ese método o función es adecuado y esta bien diseñado de esta forma se consigue un código y diseño con gran calidad.

1.6. Reuniones diarias: Es necesario que los desarrolladores se reúnan diariamente y expongan sus problemas. Soluciones e ideas de forma conjunta. Las reuniones tienen que ser fluidas y todo el mundo que que tener voz y voto.

2. Diseño

2.1. Diseños simples: La metodología XP 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 implementable que a la larga costara menos tiempo y esfuerzo desarrollar.

2.2. Glosario de términos: usar glosarios de términos y una correcta especificación de los nombres de métodos y clases ayudar a comprender el diseño y facilitara sus posteriores ampliaciones y la reutilización del código.

2.3. Riesgos: si surgen problemas potenciales durante el diseño XP sugiere utilizar una pareja de desarrolladores para que investiguen y reduzcan al máximo el riesgo que supone ese problema.

2.4. Funcionalidad extra: nunca se debe añadir funcionalidad extra al programa aunque se piense que en un futuro será utilizada. Solo el 10% de la misma es utilizada, lo que implica que el desarrollo de funcionalidad extra es un desperdicio de tiempo y recursos.

2.5. Refactorizar: refactorizar

...