Programación Extrema (xp)

Sin categoría


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.Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

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.


Kent Beck, Creador de la Metodología XP

Objetivos

El objetivo principal de la XP es la satisfacción del cliente. Se le trata de dar al cliente lo que quiere y cuando quiere. Por tanto, se debe responder rápidamente a las necesidades del cliente, aunque realice cambios en fases avanzadas del proyecto. Como metodología Ágil que es, se pueden producir modificaciones de los requisitos del proyecto a lo largo de su desarrollo, sin que esto produzca un buen dolor de cabeza.

Otro de los objetivos es el trabajo en grupo. Tanto los jefes del proyecto, clientes y desarrolladores forman parte del equipo y deben estar involucrados en el desarrollo.

Ciclo de vida xp

El ciclo de vida de un proyecto XP incluye, al igual que las otras metodologías,
entender lo que el cliente necesita, estimar el esfuerzo, crear la solución y entregar
el producto final al cliente.

Sin embargo, XP propone un ciclo de vida dinámico, donde se admite expresamente que, en muchos casos, los clientes no son capaces de especificar sus requerimientos al comienzo de un proyecto. Por esto, se trata de realizar ciclos de desarrollo cortos (llamados iteraciones), con entregables funcionales al finalizar cada ciclo.

En cada iteración se realiza un ciclo completo de análisis, diseño, desarrollo y pruebas, pero utilizando un conjunto de reglas y prácticas que caracterizan a XP (y que serán detalladas más adelante). Típicamente un proyecto con XP lleva 10 a 15 ciclos o iteraciones.


Pasos en xp

Los Pasos fundamentales inmersos en las fases del método son:

  • Desarrollo iterativo e incremental: Pequeñas mejoras, unas tras otras
  • Pruebas unitarias continuas: Son frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación.
  • Programación en parejas: Se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe-es más importante que la posible pérdida de productividad inmediata.
  • Frecuente integración del equipo de programación con el cliente o usuario: Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
  • Corrección de todos los errores antes de añadir nueva funcionalidad: Hacer entregas frecuentes.
  • Refactorización del código: Es decir, reescribir ciertas partes del código para aumentar su legibilidad y Mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
  • Propiedad del código compartido: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
  • Simplicidad del código:es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

Fases en xp

Fase I -Planificación del proyecto

Historias de usuario: El primer paso de cualquier proyecto que siga la metodología XP es definir las historias de usuario con el cliente. Las historias de usuario tienen la misma finalidad que los casos de uso pero con algunas diferencias: Constan de 3 ó 4 líneas escritas por el cliente en un lenguaje 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énse utilizan en la fase de pruebas, para verificar si el programa cumple con lo queespecifica 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 que hacer dicha historia. El tiempo de desarrollo ideal para una historia de usuario es entre 1 y 3 semanas.

Release Planning: Después de tener ya definidas las historias de usuario es necesario crear un plan de publicaciones, en inglés «Release plan», donde se indiquenlas historias de usuario que se crearán para cada versión del programa y las fechas en las que se publicarán estas versiones. Un «Release plan» 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. Después de un «Release plan» tienen que estar claros estos cuatro factores: los objetivos que se deben cumplir (que son principalmente las historias que se deben desarrollar en cada versión), el tiempo que tardarán en desarrollarse y publicarse las versiones del programa, el número de personas que trabajarán en el desarrollo y cómo se evaluará la calidad del trabajo realizado. (*Release plan: Planificación de publicaciones).

Iteraciones: 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. También se seleccionan 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 asignarán a los programadores.

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; de esta forma, se sabrá 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 ó 4 iteraciones y si se aprecia que no es adecuada hay que negociar con el cliente un nuevo «Release Plan».

Programación en Parejas: 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 está implementando, el otro analiza si ese método o función es adecuado y está bien diseñado.De esta forma se consigue un código y diseño con gran calidad.

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 tiene que tener voz y voto.

Fase II -Diseño

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ácilmenteentendible e impleméntable que a la larga costará menos tiempo y esfuerzo desarrollar.

Glosarios 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 facilitará sus posteriores ampliaciones y la reutilización del código.

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

Funcionabilidad extra: 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: 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. Es muy común rehusar códigos ya creados que contienen funcionalidades que no serán usadas y diseños obsoletos.

Fase III -Codificación


Como ya se dijo en la introducción, el cliente es una parte más del equipo de desarrollo; su presencia es indispensable en las distintas fases de XP. A la hora de codificar una historia de usuario su presencia es aún más necesaria. No olvidemos que los clientes son los que crean las historias de usuario y negocian los tiempos en los que serán implementadas. Antes del desarrollo de cada historia de usuario el cliente debe especificar detalladamente lo que ésta hará y también tendrá que estar presente cuando se realicen los test que verifiquen que la historia implementada cumple la funcionalidad especificada. La codificación debe hacerse ateniendo a estándares de codificación ya creados. Programar bajo estándares mantiene el código consistente y facilita su comprensión y escalabilidad.

Fase 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á.
  • Como se comentó anteriormente los distintos test se deben subir al repositorio de código acompañados del código que verifican.
  • Test de aceptación. Los test mencionados anteriormente sirven para evaluar las distintas tareas en las que ha sido dividida una historia de usuario.
  • 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 requisitos

Roles

Cliente

El cliente es el responsable de conducir el proyecto. Define el proyecto y sus objetivos. Cuanto más preciso es su trabajo y cuanto mayor sea su involucración, mayores serán las oportunidades de éxito.

Programador

Una vez que se han comprendido las historias de usuario, el XP adjudica a los programadores la responsabilidad de tomar decisiones técnicas. Los desarrolladores estiman el tiempo que les va a tomar cada historia.

Encargado de Pruebas (Tester).

El encargado de pruebas ayuda al cliente a definir y escribir las pruebas de aceptación de las historias de usuario. Este rol en un equipo XP también es responsable realizar test periódicamente y informar de los resultados al equipo. A medida que el volumen de pruebas aumenta, el encargado de pruebas necesitará una herramienta para crear y mantener la batería de pruebas, ejecutarlas y obtener los resultados más rápidamente.

Encargado de Seguimiento (Tracker)

Hace el seguimiento de acuerdo a la planificación. La métrica más importante para XP es la velocidad del equipo, que se define como el tiempo ideal estimado para las tareas frente al tiempo real dedicado. Esta métrica ayuda a determinar si el proyecto está dentro del tiempo de la iteración.

Entrenador (Coach)

No es un rol cubierto en todos los equipos de XP. Su papel es guiar y orientar al equipo,especialmente cuando un equipo comienza a trabajar siguiendo la metodología XP. Esto se debe a que no es fácil aplicar XP de forma consistente. Aunque son prácticas de sentido común, se necesita un tiempo para interiorizarlas. También hay situaciones especiales en las que se requiere la sabiduría de un especialista en XP para aplicar sus normas frente a un obstáculo en el proyecto.

Gestor (Big Boss)

Es el gerente del proyecto, debe tener una idea general del proyecto y estar familiarizado con su estado. El cliente puede asumir este papel.

Ventajas y Desventajas en XP

Ventajas:

  • Se consiguen productos usables con mayor rapidez.
  • El proceso de integración es continuo, por lo que el esfuerzo final para la integración es nulo. Se consigue integrar todo el trabajo con mucha mayor facilidad.
  • Se atienden las necesidades del usuario con mayor exactitud. Esto se consigue gracias a las continuas versiones que se ofrecen al usuario.
  • Se consiguen productos más fiables y robustos contra los fallos gracias al diseño de los 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 errores.
  • Gracias a la filosofía del “pair programming” (programación en parejas), se consigue 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.
  • 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 trabajar 40 horas a la semana), y por otro la comunicación entre los miembros del equipo que consigue una mayor integración entre ellos

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.

Herramientas

ExtremePlanner

Es una solución de gestión de proyectos ágiles basada en navegador que está diseñada específicamente para admitir métodos ágiles, como Scrum y Programacion extrema. Se puede usar en linea y tiene versión de prueba.http://www.extremeplanner.com/

Project Planning and Tracking System

PPTS es un entorno basado en la web que apoya equipos que han elegido desarrollar software de acuerdo con la metodologia Scrum y / o Extreme Programming. http://ses-ppts.sourceforge.net/

Targetprocess

Targetprocess es un software de gestión de proyectos visuales , gratuita, que le permite gestionar visualmente el trabajo complejo y centrarse en las cosas que importan. Brinda la visibilidad y la transparencia que necesita en toda su organización. Desde Kanban y Scrum hasta casi cualquier proceso operativo. https://www.targetprocess.com/

Ejemplos de empresas que utilizan Progracion Extrema (Xtreme Programming)

  • Microsoft ha adoptado prácticas de desarrollo ágil desde los tiempos del lanzamiento del SQL Server 2005, según uno de sus Vicepresidentes, la adopción de ágil no fue una imposición (desde los altos niveles), sino que se realizó por la vía de incentivar y alentar. Se comenzó con prácticas de Scrum y de Extreme Programming (XP).
  • IBM ha adoptado prácticas de Gerencia de Proyectos que vienen de Scrum, tales como las reuniones Stand Ups, el Product Backlog, la planificación en iteraciones (llamadas Sprints). También han adoptado prácticas que vienen de la Programación Extrema (XP), tales como la integración continua, las pruebas continuas o Test Driven Development (TDD), entre otras.

Link Fuente: http://www.pmoinformatica.com/2013/04/desarrollo-agil-en-grandes-empresas_16.html

Conclusión

Actualmente existen muchas propuestas de metodología para desarrollar
software, sin embargo el uso exclusivo de alguna metodología dependerá, del que
sea de preferencia para el desarrollador de acuerdo al tipo de sistema que este
desarrollara.

Dentro del marco de metodologías agiles que existen, encontramos a la muy
reconocida y usada Metodología XP (Programación Extrema), propuesta por Kent
Beck en 1999. Esta metodología constituye un modelo de trabajo compartido,
además existe la conexión entre cliente y desarrollador, lo que permitirá la
construcción del sistema de acuerdo a los requerimientos establecidos por el
cliente en un principio.


Referencias


Deja un comentario