INTRODUCCIÓN

Las metodologías de desarrollo ágil buscan elaborar software totalmente funcional

en el tiempo o plazo establecido para el desarrollo del proyecto. Utilizan un proceso
ágil, es decir que si los requerimientos del software cambian en cualquier etapa en
la que se encuentre el proyecto, el equipo debe adaptar el producto a estos cambios
ya que la agilidad como tal es la respuesta efectiva al cambio. Existen diferentes
metodologías de desarrollo ágil tales como: programación extrema XP, Scrum,
Cristal entre otras, todas con el mismo objetivo pero con diferentes formas de
trabajo.
A fin de ilustrar un proceso ágil con más detalle, se dará un panorama extenso de
la programación extrema (XP), el enfoque más utilizado del desarrollo de software
ágil. Aunque las primeras actividades con las ideas y los métodos asociados a XP
ocurrieron al final de la década de 1980, el trabajo fundamental sobre la materia
había sido escrito por Kent Beck. Una variante de XP llamada XP industrial [IXP] se
propuso en una época más reciente. IXP mejora la XP y tiene como objetivo el
proceso ágil para ser usado específicamente en organizaciones grandes.
Elegir un proceso ágil de desarrollo es uno de los mayores problemas en un
proyecto de software. Una metodología que permita lograr un código sin errores,
con alta funcionabilidad, manteniendo a cliente al tanto del proyecto y en plazos de
tiempo cómodos, siempre han sido objetivos ideales que en todo proyecto se
pretende alcanzar. La Metodología de “Programación Extrema” (XP) propone la
manera de alcanzar esos objetivos.
Esta Metodología 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. Scrum al igual que XP tiene un equipo de trabajo, la única diferencia es que
divide el equipo en scrum master (líder), DBA (administrador de la base de datos),
Programadores, diseñadores y el product owner (el cliente).
A los largos de los años la aplicación de la metodología XP ha dado los mejores
resultados, las etapas que plantea han sido llevadas al extremo, en muchos lugares
del mundo, y en diversos ámbitos de la actividad humana donde se ha necesitado
diseñar un sistema informático.
Pero 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. Lo que lleva a preguntarse, si ¿En realidad son del todo aplicables?
Por lo cual el presente proyecto investigativo, hablara acerca de las etapas que se
deberían de seguir en esta Metodología, y se analizara un ejemplo práctico, de
manera que se podrá apreciar de qué manera se podrían sortear las dificultades
que pueden surgir al momento de aplicar la Metodología de Programación Extrema.
METODOLOGÍA EXTREMA (XP)
HISTORIA
La Programación Extrema, como proceso de creación de software diferente al
convencional, nace de la mano de Kent Beck (gurú de la XP y autor de los libros
más influyentes sobre el tema).
Chrysler Corporation (un histórico grupo automovilístico de los Estados Unidos, filial
de Fiat Chrysler Automobiles) hacía tiempo que estaba desarrollando una aplicación
de nóminas, pero sin demasiado éxito por parte de la gente que tenía en el proyecto.
El verano de 1996, Beck entró en nómina en la compañía y se le pidió hacer esta
aplicación como trabajo. Es en esta aplicación cuando nace la Programación
Extrema como tal.
Beck reconoció que el proceso (o metodología) de creación de software o la
carencia de este era la causa de todos los problemas y llegó a la conclusión que
para proporcionar un proceso que fuera flexible era necesario realizar ciertos
cambios en la estructura o manera de hacer de los programadores, los cuales se
tenían que acomodar al cambio a realizar.
Él tenía varias ideas de metodologías para la realización de programas que eran
cruciales para el buen desarrollo de cualquier sistema.

Kent Beck ingeniero de software estadounidense, uno de los creadores de las metodologías de
desarrollo de software de programación extrema (eXtreme Programming o XP) y el desarrollo
guiado por pruebas (Test-Driven Development o TDD), también llamados metodología ágil. Autor
del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999).

Los autores (o mejor dicho, los propulsores como el propio Kent Beck, Ward
Cunningham o Ron Jeffries entre otros) de la Programación Extrema, fueron a la
web Portland Pattern Repository y empezaron a hablar de ella y promocionarla, de
lo que era y cómo realizarla. Estos propulsores de la XP hablaban de ella en cada
ocasión que tenían y en cada página que, poco o mucho hablara de temas de
programación.
Este hecho, llegó a molestar a buena parte de la comunidad que intentaba discutir
sobre temas de programación. Fue tanta esta molestia que nació el fenómeno XP
Free Zone (zona libre de XP) en determinadas webs como petición de no hablar de
Programación Extrema en ella.
La discusión sobre temas de diseño de modelos de programación sobre los cambios
recientes se hizo tema difícil porque la mayoría de la actividad fue relacionada con
la Programación Extrema. Eventualmente, y debido a esto, la mayoría de la gente
que solía discutir sobre los temas de diseño de modelos de programación fue
apartándose de este ambiente para discutir sus ideas en otros ambientes más
"reservados". La comunidad empezó a referirse a estos sitios como a Salas Wiki
(Wards Wiki).
DEFINICIÓN
La metodología XP o Programación
Extrema (Extreme Programming) es
una metodología ágil para el desarrollo
de software y consiste básicamente en
ajustarse estrictamente a una serie de
reglas que se centran en las
necesidades del cliente para lograr un
producto de buena calidad en poco tiempo, centrada en potenciar las relaciones
interpersonales como clave para el éxito del desarrollo de software.
La filosofía de XP es satisfacer al completo las necesidades del cliente, por eso lo
integra como una parte más del equipo de desarrollo. Promueve el trabajo en
equipo, preocupándose en todo momento del aprendizaje de los desarrolladores y
estableciendo un buen clima de trabajo.
Este tipo de programación es la adecuada para los proyectos con requisitos
imprecisos, muy cambiantes y donde existe un alto riesgo técnico.
XP está diseñada para el desarrollo de aplicaciones que requieran un grupo de
programadores pequeño, dónde la comunicación sea más factible que en grupos de
desarrollo grandes. La comunicación es un punto importante y debe realizarse entre
los programadores, los jefes de proyecto y los clientes.
Es habitual relacionarla con scrum, y la combinación de ambas asegura un mayor
control sobre el proyecto, y una implementación más efectiva y eficiente.
A continuación se muestra un gráfico estadístico sobre el uso de las metodologías
agiles, en la cual destaca la programación XP:
 Figura 1: Datos Estadísticos

OBJETIVOS DE LA PROGRAMACIÓN EXTREMA (XP)

La satisfacción del cliente.
Potenciar el trabajo en grupo.
Minimizar el riesgo actuando sobre las variables del proyecto: costo, tiempo,
calidad, alcance.

CARACTERÍSTICAS

Software que funciona por encima de una buena documentación.

Planificación flexible y abierta.
Rápida respuesta a cambios; ya que los requisitos pueden cambiar.
Metodología basada en prueba y error para obtener un software que
funcione realmente.
Fundamentada en Valores y Prácticas.
Grupo pequeño y muy integrado (2-12 personas).
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.
 Figura 2: Características de la metodología XP

VALORES XP

Kent Beck define un conjunto de cinco valores que establecen el fundamento para
todo trabajo realizado como parte de XP: comunicación, simplicidad,
retroalimentación, valentía y respeto. Cada uno de estos valores se usa como un
motor para actividades, acciones y tareas específicas de XP. A fin de lograr la
comunicación eficaz entre los ingenieros de software y otros participantes (por
ejemplo, para establecer las características y funciones requeridas para el
software), XP pone el énfasis en la colaboración estrecha pero informal (verbal)
entre los clientes y los desarrolladores, en el establecimiento de metáforas para
comunicar conceptos importantes, en la retroalimentación continua y en evitar la
documentación voluminosa como medio de comunicación.

Comunicación: Prevalece en todas las prácticas de Extreme Programming.

Comunicación cara a cara es la mejor forma de comunicación, entre los
desarrolladores y el cliente. Método muy ágil. Gracias a esto el equipo esta pude
realizar cambios que al cliente no le gustaron.
Simplicidad: La simplicidad ayuda a que los desarrolladores de software
encuentren soluciones más simples a problemas, según el cliente lo estipula. Los
desarrolladores también crean características en el diseño que pudieran ayudar a
resolver problemas en un futuro.

Retroalimentación: La retroalimentación continua del cliente permite a los

desarrolladores llevar y dirigir el proyecto en una dirección correcta hacia donde el
cliente quiera.

Valentía: Requiere que los desarrolladores vayan a la par con el cambio, porque
sabemos que este cambio es inevitable, pero el estar preparado con una
metodología ayuda a ese cambio. Programa para hoy y no para mañana.

Respeto: El equipo debe trabajar como uno, sin hacer decisiones repentinas.
Extreme Programming promueve el trabajo del equipo. Cada integrante del proyecto
(cliente, desarrolladores, etc.) forman parte integral del equipo encargado de
desarrollar software de calidad. El equipo debe trabajar como uno, sin hacer
decisiones repentinas.

Figura 3: Valores XP
VENTAJAS Y DESVENTAJAS DE LA METODOLOGÍA 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 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.
Procesos de la Metodologia XP

1ª : Planificación del proyecto.

• Historias de usuario: Es una representación de un requisito escrito en una o

dos frases utilizando el lenguaje común del usuario. Cada historia de usuario
debe ser limitada, ésta debería poderse escribir sobre una nota adhesiva
pequeña. Dentro de la metodología XP las historias de usuario deben ser
escritas por los usuarios.Las historias de usuario son una forma rápida de
administrar los requisitos de los usuarios sin tener que elaborar gran cantidad
de documentos formales y sin requerir de mucho tiempo para administrarlos.
Las historias de usuario permiten responder rápidamente a los requisitos
cambiantes.

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

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

• 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

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

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

2ª : 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 impleméntable 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. 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. Esto es un
error porque puede generar código completamente inestable y muy mal
diseñado; por este motivo, es necesario refactorizar cuando se va a utilizar
código ya creado.
Tarjetas C.R.C. El uso de las tarjetas C.R.C (Class, Responsabilities and
Collaboration) permiten al programador centrarse y apreciar el desarrollo
orientado a objetos olvidándose de los malos hábitos de la programación
procedural clásica.
Las tarjetas C.R.C representan objetos; la clase a la que pertenece el objeto se
puede escribir en la parte de arriba de la tarjeta, en una columna a la izquierda
se pueden escribir las responsabilidades u objetivos que debe cumplir el objeto
y a la derecha, las clases que colaboran con cada responsabilidad.

3ª : 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 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ª : 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.

-Un punto importante es crear test que no tengan ninguna dependencia del
código que en un futuro evaluará. Hay que crear los test abstrayéndose del
futuro código, de esta forma aseguraremos la independencia del test
respecto al código que evalúa.
-Como se comentó anteriormente los distintos test se deben subir al
repositorio de código acompañados del código que verifican. Ningún código
puede ser publicado en el repositorio sin que haya pasado su test de
funcionamiento, de esta forma, aseguramos el uso colectivo del código
(explicado en el apartado anterior).

-El uso de los test es adecuado para observar la refactorización. Los test
permiten verificar que un cambio en la estructura de un código no tiene
porqué cambiar su funcionamiento.

-Test de aceptación. Los test mencionados anteriormente sirven para evaluar

las distintas tareas en las que ha sido dividida una historia de usuario. Para
asegurar el funcionamiento final de una determinada historia de usuario se
deben crear "Test de aceptación"; estos test son creados y usados por los
clientes para comprobar que las distintas historias de usuario cumplen su
cometido.

-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

Fases de la Metodología XP
Si bien el ciclo de vida de un proyecto XP es muy dinámico, se puede separar en
las siguientes Fases:

 Exploración,

 Planificación de la Entrega (Release),

 Iteraciones,

 Producción,

 Mantenimiento y

 Muerte del Proyecto.

Fase I: 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.

Fase II: Planificación de la Entrega

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.

El resultado de esta fase es un Plan de Entregas, o “Release Plan”

Fase III: 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

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

Fase IV: 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).

En esta fase no se realizan más desarrollos funcionales, pero pueden ser

necesarias tareas de ajuste (“fine tuning”).

Fase V: 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.

Fase VI: 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.

ROLES
Aunque en otras fuentes de información aparecen algunas variaciones y
extensiones de roles XP, en este apartado describiremos los roles.

Programador. - El programador escribe las pruebas unitarias y produce el código

del sistema. Debe existir una comunicación y coordinación adecuada entre los
programadores y otros miembros del equipo.

Cliente. - El cliente escribe las historias de usuario y las pruebas funcionales para
validar su implementación. Además, asigna la prioridad a las historias de usuario y
decide cuáles se implementan en cada iteración centrándose en aportar mayor valor
al negocio. El cliente es sólo uno dentro del proyecto, pero puede corresponder a
un interlocutor que está representando a varias personas que se verán afectadas
por el sistema.

Encargado de pruebas (Tester). - El encargado de pruebas ayuda al cliente a

escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los
resultados en el equipo y es responsable de las herramientas de soporte para
pruebas.

Encargado de seguimiento (Tracker). - El encargado de seguimiento proporciona

realimentación al equipo en el proceso XP. Su responsabilidad es verificar el grado
de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando
los resultados para mejorar futuras estimaciones. También realiza el seguimiento
del progreso de cada iteración y evalúa si los objetivos son alcanzables con las
restricciones de tiempo y recursos presentes.

Determina cuándo es necesario realizar algún cambio para lograr los objetivos de
cada iteración.

Entrenador (Coach). - Es responsable del proceso global. Es necesario que

conozca a fondo el proceso XP para proveer guías a los miembros del equipo de
forma que se apliquen las prácticas XP y se siga el proceso correctamente.

Consultor. - Es un miembro externo del equipo con un conocimiento específico en

algún tema necesario para el proyecto. Guía al equipo para resolver un problema
específico.
Gestor (Big boss). - Es el vínculo entre clientes y programadores, ayuda a que el
equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial
es de coordinación.

NOTACIÓN

A continuación, describimos los artefactos de Xp, entre los que se encuentran:

Historias de Usuario, Tareas de Ingeniería y Tarjetas CRC.

Historias de Usuario

Representan una breve descripción del comportamiento del sistema, emplea

terminología del cliente sin lenguaje técnico, se realiza una por cada característica
principal del sistema, se emplean para hacer estimaciones de tiempo y para el plan
de lanzamientos, reemplazan un gran documento de requisitos y presiden la
creación de las pruebas de aceptación.

Historia de Usuario

Número: Nombre Historia de Usuario:

Modificación (o extensión) de Historia de Usuario (Nro.

y Nombre):

Usuario: Iteración Asignada:

Prioridad en Negocio:
Puntos Estimados:
(Alta / Media / Baja)

Riesgo en Desarrollo:
Puntos Reales:
(Alto / Medio / Bajo)

Descripción:

Observaciones:
Estas deben proporcionar sólo el detalle suficiente como para poder hacer
razonable la estimación de cuánto tiempo requiere la implementación de la historia,
difiere de los casos de uso porque son escritos por el cliente, no por los
programadores, empleando terminología del cliente. "Las historias de usuario son
más "amigables" que los casos de uso formales".

Las Historias de Usuario tienen tres aspectos:

- Tarjeta: en ella se almacena suficiente información para identificar y detallar

la historia.

- Conversación: cliente y programadores discuten la historia para ampliar los

detalles (verbalmente cuando sea posible, pero documentada cuando se
requiera confirmación)

- Pruebas de Aceptación: permite confirmar que la historia ha sido

implementada correctamente.

Caso de Prueba de Aceptación

Código: Historia de Usuario (Nro. y Nombre):

Nombre:

Descripción:

Condiciones de Ejecución:

Entrada / Pasos de ejecución:

Resultado Esperado:
 Evaluación de la Prueba:

Task Card

Tarea de Ingeniería

Número
Historia de Usuario (Nro. y Nombre):
Tarea:

Nombre Tarea:

Tipo de Tarea :

Desarrollo / Corrección / Puntos Estimados:

Mejora / Otra (especificar)

Fecha Inicio: Fecha Fin:

Programador Responsable:

Descripción:

Tarjetas CRC (Clase - Responsabilidad – Colaborador)

Estas tarjetas se dividen en tres secciones que contienen la información del nombre
de la clase, sus responsabilidades y sus colaboradores. En la siguiente figura se
muestra cómo se distribuye esta información.

Los pasos a seguir para llenar las tarjetas son los siguientes:

- Encontrar clases

- Encontrar responsabilidades

- Definir colaboradores
 - Disponer las tarjetas

BIBLIOGRAFÍA

Páginas WEB Consultadas:

 http://www.diegocalvo.es/metodologia-xp-programacion-extrema-metodologia-agil/
 http://managementplaza.es/blog/sabes-como-funciona-xp/
 https://ingsotfwarekarlacevallos.wordpress.com/2015/05/08/metodologia-de-
desarrollo-agil-xp-y-scrum/
 https://sites.google.com/site/xpmetodologia/home/introduccion
 https://ingenieriadesoftware.blogia.com/2008/090201-historia-de-la-programacion-
extrema.php
 https://iswugaps2extremeprogramming.wordpress.com/2015/09/13/sabemos-que-
todo-tiene-un-origen-conoce-como-surgio-la-maravilla-xp/

Libros Consultados:

 Metodología Ágil de Desarrollo de Software – XP - Autor: Borja López Yolanda

 Ingeniería del Software Un Enfoque Práctico – Autor: Roger S. Pressman – 6ta
Edición