UNIVERSIDAD NACIONAL EXPERIMENTAL

DE LOS LLANOS OCCIDENTALES

“EZEQUIEL ZAMORA”
BARINAS EDO. BARINAS

MODULO III
CASO DE ESTUDIO: PROGRAMACION EXTREMA (XP)

Docente: Estudiante:
Ailicec Bolivar Mayerling Valecillo
Ingeniería en Informática C.I: 28.460.714

Barinas, Mayo del 2021

 INDICE

INTRODUCCIÓN.....................................................................................................................3

1. Definición de XP como una metodología ágil, historia y principios básicos........................4

Historia...................................................................................................................................4

Principios básicos...................................................................................................................5

2. Elementos favorables de la metodología y sus características, Elementos en el proceso de

desarrollo de XP, fases: cliente e interacción con los mismos, definición y planificación del

proyecto, diseño y desarrollo de pruebas...............................................................................7

Elementos favorables de la metodología y sus características...............................................7

Elementos en el proceso de desarrollo de XP........................................................................9

Fases.....................................................................................................................................10

Ciclo de vida para un proyecto XP..........................................................................................12

Definición y características de los elementos del ciclo de vida...............................................15

CONCLUSION........................................................................................................................17

RESUMEN...............................................................................................................................18

REFERENCIAS BIBLIOGRAFICAS.....................................................................................19
 INTRODUCCIÓN

Cuando se requiere que un software sea desarrollado de manera ágil las metodologías

enfocadas a este tema son la solución para que los desarrolladores se adapten a los cambios a

los que puede estar sujeto un proyecto de software, y así asegurar un sistema que tenga éxito.

La metodología de “Programación Extrema” (XP) consiste en un conjunto de prácticas,

fundamentadas en valores que deben de mantener los participantes de proyecto que, a manera

de trabajo en grupo, pretende lograr como producto final un software con un muy alto grado

de calidad. Las etapas que recomienda seguir esta metodología se plantean de manera sencilla

pero a la vez son estrictas, y se inspiran en la total participación de los involucrados.

Los métodos ágiles surgen como una inflexión en un momento o contexto definido, en

donde se hace necesario una renovación metodológica que busca satisfacer la necesidad de

realizar los proyectos de una forma más rápida sin disminuir la calidad del mismo.

Indistintamente en el año 2001 firman para Xp en el manifiesto ágil Kent Beck, Ward

Cinningham, Martin Fowler, James Grenning, Ron Jeffries, Brian Marick, y Robert C. Matin,

poco después y hasta hoy surge un gran número de libros y escritos que describen los pasos

para aplicar esta metodología.

Por lo tanto en este trabajo se presenta un ámbito general de lo que sería la metodología de

la Programación Extrema (XP).

1. Definición de XP como una metodología ágil, historia y principios básicos

La metodología XP o Programación Extrema es una metodología ágil y flexible utilizada

para la gestión de proyectos.

Extreme Programming se centra en potenciar las relaciones interpersonales del equipo de

desarrollo como clave del éxito mediante el trabajo en equipo, el aprendizaje continuo y el

buen clima de trabajo.

Esta metodología pone el énfasis en la retroalimentación continua entre cliente y el equipo

de desarrollo y es idónea para proyectos con requisitos imprecisos y muy cambiantes.

Historia

Los fundamentos de XP vienen de las prácticas tomadas a cabo por Kent Beck en un

proyecto para el pago de nóminas en Chrysler. El trabajo de Kent en este proyecto se hizo

popular por haber tenido éxito en tan sólo un año y dos meses cuando un equipo de 30

personas había fracasado durante años.

Esta aplicación de nóminas, llamada C3, pretendía sustituir una aplicación anterior hecha

con una tecnología antigua. En el momento de la incorporación de Kent al proyecto, tres años

después de su inicio, C3 no había podido pagar una sola nómina en Chrysler.

Implementando principios de las industrias de fabricación, como Lean Manufacturing, el

equipo de Kent consiguió aumentar enormemente la eficiencia del sistema. Al principio se

calculaba que ejecutar el proceso de pago de nóminas llevaría unas 1000 horas. Diversas

actividades de mejora redujeron este tiempo a alrededor de 40 horas, luego a 12 y por último

quedó en tan sólo 9 horas.

 A pesar del gran avance que supusieron estas técnicas, el proyecto C3 fue cancelado solo

unos años después, en el 2000, tras la compra de Chrysler por Daimler-Benz. Con esto puede

verse que, usar XP, no es una garantía de éxito.

Principios básicos

Tenemos 12 principios básicos que se agrupan en 4 categorías distintas:

- Retroalimentación.

- Proceso continuo en lugar de por bloques.

- Propiedad intelectual compartida.

- Entendimiento compartido.

RETROALIMENTACIÓN:

Principio de pruebas: lo primero que se debe hacer es establecer un período de pruebas de

aceptación del programa, en el cual se definirán las entradas y salidas del sistema.

Básicamente se define lo que debe hacer el software desarrollado. Como si fuese una caja

negra.

Planificación: el cliente (o su representante) escribirá sus necesidades para definir

concretamente las actividades que el sistema debe realizar. En esta fase se creará un

documento que contendrá historias de usuario que forman el plan de liberación, el cual define

los tiempos de entrega de la aplicación para poder recibir feedback por parte del cliente.

Cliente in-situ: el cliente (o su representante) deberá formar parte del equipo de desarrollo.

Se le dará poder para determinar los requisitos de la aplicación, definir la funcionalidad y dar

prioridad a determinadas cosas. Gracias a esto, habrá una fuerte interacción con los

programadores, disminuyendo así el tiempo de comunicación y la cantidad de documentación

a redactar. El cliente estará con el equipo durante todo el proceso de desarrollo del proyecto.
 Pair-programming: este punto junto con el anterior son los más radicales de esta

metodología. Consiste en escribir código en parejas compartiendo una sola máquina. Según

los experimentos ya realizados sobre este método, se producen mejores y más consistentes

aplicaciones a igual o menor coste.

PROCESO CONTINUO EN LUGAR DE POR BLOQUES

Integración continua: consiste en implementar progresivamente las nuevas características

del software. En lugar de crear versiones estables en función de una planificación

previamente realizada, los programadores reunen su código y reconstruyen el proyecto varias

veces al día si hace falta.

Refactorización: mediante la constante eliminación de código duplicado y/o ineficiente los

equipos de programación mejoran el diseño del sistema. El código se evalúa continuamente

para ofrecer la mayor calidad posible.

Entregas pequeñas: el producto es evaluado en un ambiente real mediante la colocación de

un sistema sencillo en producción el cual se actualizará rápidamente, es decir, cada 2 semanas

(3 como máximo) el software será puesto en producción.

ENTENDIMIENTO COMPARTIDO

Diseño simple: el mejor programa será aquel que cumpla con los requisitos y sea más

simple. Es importante proporcionar un software que cubra las necesidades de un cliente. Ni

más ni menos.

Metáfora: expresa la visión evolutiva del proyecto y define los objetivos del sistema

mediante una historia.

Propiedad colectiva del código: el código tiene propiedad compartida. Nadie es

propietario de nada, ni siquiera de lo que ha desarrollado. Todos los programadores son

"dueños" de todo el código. Según esta metodología, cuantos más programadores haya

trabajado en una parte de código, menos errores tendrá.

Estándar de programación: define las reglas para escribir y documentar código, además de

cómo se comunican las diferentes piezas de código desarrolladas por diferentes equipos. El

objetivo de esto es que parezca que el código ha sido escrito por una única persona.

BIENESTAR DEL PROGRAMADOR

Semana de 40 horas: los programadores cansados escriben peor código. Es importante

minimizar las horas extras y mantener a los programadores frescos y descansados. De esta

manera, se generará mejor código. Si es necesario hacer horas extras, quiere decir que el

proyecto está mal planificado.

2. Elementos favorables de la metodología y sus características, Elementos en el

proceso de desarrollo de XP, fases: cliente e interacción con los mismos,

definición y planificación del proyecto, diseño y desarrollo de pruebas.

Elementos favorables de la metodología y sus características

Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.

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.

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, rescribir 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 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.

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.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más

comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más

simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una

comunicación más completa, especialmente si se puede reducir el equipo de programadores.

Elementos en el proceso de desarrollo de XP

- Historias de usuario: Se trataría de “tarjetas” donde el cliente especifica requisitos

funcionales o no. Dichos requisitos deberán ser entendibles e implementables en unas pocas

semanas. Cada tarea, terminará siendo una tarea de programación asignada a un desarrollador

durante una iteración.

- Roles XP: Los roles habituales que componen un equipo XP serían:

- Programador: Escribe código y realiza pruebas unitarias.

- Cliente: Obvio, encarga el trabajo, escribe las historias de usuario y prioriza tareas.

- Tester: Escribe pruebas funcionales junto al cliente y, ejecuta y difunde los resultado de las

pruebas regularmente.

- Tracker: Realiza el seguimiento de las distintas iteraciones, estimaciones frente a tiempo

real, para poder afinar las estimaciones.

- Coach: Es el responsable del equipo XP, se encarga de que este siga el proceso

correctamente.

- Consultor: Miembro externo experto en algún tema concreto al que acudir en caso de

problemas.

- Gestor: Unión entre el cliente y el equipo de desarrollo. Sus labores son de coordinación

principalmente.

Fases

1ª Fase: Planificación del proyecto.

Historias de usuario: El primer paso de cualquier proyecto que siga la metodología X.P 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é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 que

hacer dicha historia. El tiempo de desarrollo ideal para una historia de usuario es entre 1 y 3

semanas.

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 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 pareja: La metodología X.P. 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.

2ª Fase: Diseño.
Diseños simples: La metodología X.P 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 implementables que a la larga costará menos tiempo y

esfuerzo desarrollar.

Glosarios de términos: Usar glosarios de términos y un 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, X.P sugiere utilizar una pareja de

desarrolladores para que investiguen y reduzcan al máximo el riesgo que supone ese

problema.

Funcionalidad 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.

3ª Fase: Codificación.

El cliente es una parte más del equipo de desarrollo; su presencia es indispensable en las

distintas fases de X.P. 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.
4ª Fase: Pruebas.

Uno de los pilares de la metodología X.P es el uso de test para comprobar el

funcionamiento de los códigos que vayamos implementando.

El uso de los test en X.P 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.

Ciclo de vida para un proyecto XP

El ciclo de vida ideal de XP consiste de seis fases:

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.

Planificación de la 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. La planificación se puede realizar basándose en el tiempo o el alcance. La

velocidad del proyecto es utilizada para establecer cuántas historias se pueden implementar

antes de una fecha determinada o cuánto tiempo tomará implementar un conjunto de

historias. Al planificar por tiempo, se multiplica el número de iteraciones por la velocidad del

proyecto, determinándose cuántos puntos se pueden completar. Al planificar según alcance

del sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la

velocidad del proyecto, obteniendo el número de iteraciones necesarias para su

implementación.

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. Todo el trabajo de la iteración es

expresado en tareas de programación, cada una de ellas es asignada a un programador como

responsable, pero llevadas a cabo por parejas de programadores.

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).

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.

Muerte del 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.
Definición y características de los elementos del ciclo de vida

Al igual que otras metodologías de gestión de proyectos, tanto Ágiles como tradicionales,

el ciclo XP incluye:

Entender lo que el cliente necesita > Fase de Exploración

Estimar el esfuerzo > Fase de Planificación

Crear la solución > Fase de Iteraciones

Entregar el producto final al cliente > Fase de puesta en producción

Lo que caracteriza a XP, al igual que al resto de métodos Agiles es un ciclo de vida

dinámico. ¿Cómo lo logra XP? metodología XP Ciclo XP mediante ciclos de desarrollo

cortos (llamados iteraciones), al fin de los cuales se generan unos entregables funcionales.

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 específicas de XP. Un proyecto con XP,

implica de entre a 10 a 15 iteraciones habitualmente.

 CONCLUSION

En conclusión, la Programación Extrema, se ha mostrado como una alternativa para cierto

tipo de proyectos, sobre todo en aquellos donde el cambio en la tecnología ó en los

requerimientos es la constante principal durante todas las etapas de desarrollo. Es

precisamente en estas condiciones que otras metodologías que requieren gran inversión de
tiempo en las etapas iniciales de análisis de requerimientos y diseño, muestran una

inflexibilidad importante a adaptarse a cambios continuos.

Es importante mencionar qué en la metodología de desarrollo de software, es de suma

importancia la comunicación, el trabajo en equipo y el orden que se tiene en los procesos del

mismo, ya que dicha metodología trabaja de manera iterativa y cada incremento de software

debe irse mejorando y afinando.

RESUMEN
 XP forma parte del conjunto de métodos ágiles que centran sus prioridades en las

personas, no en los procesos, en la actualidad XP se proyecta a ser un modelo de desarrollo

común, sencillo y adaptable a las características cambiantes y exigentes de empresas y

clientes, es por ello que en este documento se presentan en forma resumida las características

principales, las actividades, las prácticas, el ciclo de vida, los artefactos y las críticas a esta

metodología recopiladas en el transcurso de la investigación.

La Programación Extrema es un paradigma de desarrollo de software que queda

encuadrado en el grupo de metodologías ágiles. A seis años de su concepción se ha mostrado

como una alternativa efectiva si se utiliza en un contexto adecuado.

REFERENCIAS BIBLIOGRAFICAS
https://www.diegocalvo.es/metodologia-xp-programacion-extrema-metodologia-agil/

https://www.antoniomartel.com/2018/12/un-poco-de-historia-sobre-extreme-

programming.html

https://geekytheory.com/programacion-extrema-que-es-y-principios-basicos

https://sites.google.com/site/xpmetodologia/marco-teorico/caracteristicas

https://infow.wordpress.com/2011/10/22/desarrollo-agil-iv-extreme-programming-xp/

https://programacionextrema.tripod.com/fases.htm

http://oness.sourceforge.net/proyecto/html/ch05s02.html

https://proagilist.es/blog/agilidad-y-gestion-agil/agile-scrum/la-metodologia-xp/

#La_Metodologia_Xp_El_Ciclo_de_vida