Metodología XP
La programación extrema o eXtreme Programming (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 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. Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.
Características
-
Se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad.
-
Se aplica de manera dinámica durante el ciclo de vida del software.
-
Es capaz de adaptarse a los cambios de requisitos.
-
Los individuos e interacciones son más importantes que los procesos y herramientas.
-
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.
-
Software que funcione es más importante que documentación exhaustiva.
-
Desarrollar software que funciona más que conseguir una buena documentación.
-
La colaboración con el cliente más que la negociación de un contrato. (Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo)
-
La respuesta ante el cambio es más importante que el seguimiento de un plan.
Valores que se toman en cuenta en la metodología XP
COMUNICACIÓN: La comunicación se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto más simple sea.La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo.
SIMPLICIDAD: La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento.
RETROALIMENTACIÓN: Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programador esa centrarse en lo que es más importante.
CORAJE O VALENTÍA: Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para hoy y no para mañana. La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario.
​
Fases de la metodología XP
El primer paso de cualquier proyecto que siga la metodología XP es definir las historias de usuario con el cliente. Son usadas para estimar tiempos de desarrollo de la parte de la aplicación que describen.
Después de tener ya definidas las historias de usuario es necesario crear un plan de publicaciones, en inglés "Release plan", donde se indiquen las historias de usuario que se crearán para cada versión del programa y las fechas en las que se publicarán estas versiones.
Todo proyecto que siga la metodología X.P. se ha de dividir en 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 "Release planning" que serán implementadas
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 número de historias de usuario que se pueden implementar en una iteración.
La metodología X.P. aconseja la programación en parejas pues incrementa la productividad y la calidad del software desarrollado.
Por último, Es necesario que los desarrolladores se reúnan diariamente y expongan sus problemas, soluciones e ideas de forma conjunta
​
I. Planificación
II. Diseño
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 impleméntable que a la larga costará menos tiempo y esfuerzo desarrollar. 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.
Nunca se debe añadir funcionalidad extra al programa aunque se piense que en un futuro será utilizada. Refactorizar es mejorar y modificar la estructura y codificación de códigos ya creados sin alterar su funcionalidad.
​
III. Codificación
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 impleméntable que a la larga costará menos tiempo y esfuerzo desarrollar. 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.
Nunca se debe añadir funcionalidad extra al programa aunque se piense que en un futuro será utilizada. Refactorizar es mejorar y modificar la estructura y codificación de códigos ya creados sin alterar su funcionalidad.
​
IV. Pruebas
Uno de los pilares de la metodología XP es el uso de test para comprobar el funcionamiento de los códigos que vayamos implementando. El uso de los test en XP es el siguiente:
-
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; en el apartado anterior se explicó la importancia de crear antes los test que el código.
Un punto importante es crear test que no tengan ninguna dependencia del código que en un futuro evaluará. Al ser las distintas funcionalidades de nuestra aplicación no demasiado extensas, no se harán test que analicen partes de las mismas, sino que las pruebas se realizarán para las funcionalidades generales que debe cumplir el programa especificado en la descripción de requisito.
Ventajas
Desventajas
â–ºProgramación organizada
â–ºMenor tasa de errores
â–ºSatisfacción del programador
â–ºFácil de adaptarse
â–ºOptimiza el tiempo en desarrollo
â–ºPermite realizar el desarrollo en parejas para complementar el conocimiento
â–ºEs recomendable emplearlo solo en proyectos a corto plazo.
â–ºHay altas comisiones en caso de fallar.
â–ºNo se tiene un costo o tiempo definido.
â–ºEl sistema va creciendo con cada entrega que se le realiza al cliente.
â–ºSe necesitaría de la presencia constante del cliente lo cual resulta difícil de lograr.