METODOLOGÍAS XP

Definición:

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.

CARACTERÍSTICAS1. Desarrollo interactivo e incremental:

Pequeñas mejoras, unas tras otras.2. Pruebas Unitarias Continuas:

frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit, la cual, a su vez, se insipiró en SUnit, el primer framework orientado a realizar tests, realizado para el lenguaje de programación Smalltalk.

3. Programación en Pareja:se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. 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.4. 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.5. Corrección de todos los errores:Antes de añadir nueva funcionalidad. Hacer entregas frecuentes.

6. 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.7. Propiedad del código compartida: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.8. Simplicidad en el 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.

CICLO DE DESARROLLO1. Exploración:En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos meses, dependiendo del tamaño y familiaridad que tengan los programadores con la tecnología.

2. Planeacion de entrega (RELEASE):

En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimación del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. Una entrega debería obtenerse en no más de tres meses. Esta fase dura unos pocos días. Las estimaciones de esfuerzo asociado a la implementación de las historias la establecen los programadores utilizando como medida el punto. Un punto, equivale a una semana ideal de programación. Las historias generalmente valen de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la “velocidad” de desarrollo, establecida en puntos por iteración, basándose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la última iteración.

3. Iteraciones:Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega está compuesto por iteraciones de no más de tres semanas. En la primera iteración se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la creación de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qué historias se implementarán en cada iteración (para maximizar el valor de negocio). Al final de la última iteración el sistema estará listo para entrar en producción. Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la Iteración son: historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptación no superadas en la iteración anterior y tareas no terminadas en la iteración anterior.

4. Producción:

La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusión de nuevas características a la versión actual, debido a cambios durante esta fase. Es posible que se rebaje el tiempo que toma cada iteración, de tres a una semana. Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementación (por ejemplo, durante la fase de mantenimiento).

5. Mantenimiento:

Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puede bajar después de la puesta del sistema en producción. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura.

6. Muerte de Proyecto:

Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentación final del sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.

EJEMPLOS

RESUMENEs 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 la 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. Es una herramienta que facilita el proceso de conceptualización y análisis de causalidades, así como el diseño, ejecución, monitoreo y evaluación de programas y proyectos desde una perspectiva de orientación por objetivos.

SUMMARYIt is a development methodology of software engineering made by Kent Beck, author of the first book on the subject, Extreme Programming Explained: Embrace Change (1999). It is the highlight of agile software development processes. Like them, extreme programming differs from traditional methodologies mainly in putting more emphasis on adaptability in predictability. Proponents of XP consider changing requirements on the fly is a natural, inevitable and even desirable aspect of project development. They believe that being able to adapt to changing requirements at any point in the project life is better and more realistic than trying to define all requirements early in the project and invest in control efforts after changes in approach one requisitos.Es tool that facilitates the process of conceptualization and causality analysis and design, implementation, monitoring and evaluation of programs and projects from the perspective of goal orientation.

RECOMENDACIONES

No aplicar la metodología si existe la posibilidad de no cumplir con los plazos establecidos en la etapa de planeación, ya que además se incrementaría de gran manera los costos del proyecto.Es recomendable que se consulten diversas fuentes bibliográficas para lograr un mayor entendimiento del tema.Se recomienda que antes de elegir una metodología se analicen sus ventajas y desventajas a fin de que sea la mas adecuada para el proyecto a realizar.

CONCLUSIONES• En la practica es un poco complicado aplicar “al pie de la letra” los

postulados de la Metodología XP si los involucrados no cuentan con total disponibilidad de tiempo.

• La metodología XP es de uso común desde hace varios años de manera que adquirir información acerca de ella resulto sencillo, ya que la mayoría de textos técnicos y de proyectos realizados por otras personas hablan de esta metodología.

GLOSARIO DE TÉRMINOS• REFACTORIZACION: Se usa a menudo para describir la modificación del código fuente sin cambiar su comportamiento, lo que se conoce informalmente por limpiar el código.

LINKOGRAFIAS• https://sites.google.com/site/xpmetodologia/• http://es.slideshare.net/EvelingGiselleCruzVs/metodologia-monografia.• http

://desarrollo-de-software-j.blogspot.pe/2012/03/metodologia-xpprogramacion-extrema.html.

GRACIAS