prog

Laboratorio de Sistemas de Información. Departamento de Sistemas Informáticos y Computación.
Facultad de Informática. Universidad Politécnica de Valencia.
© Letelier & Penadés
Métodologías ágiles para el desarrollo de software:
eXtreme Programming (XP)
Patricio Letelier y Mª Carmen Penadés
Universidad Politécnica de Valencia
Camino de Vera s/n, 46022 Valencia
{letelier, mpenades}@dsic.upv.es
RESUMEN
El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas
propuestas metodológicas que inciden en distintas dimensiones del proceso de
desarrollo. Por una parte tenemos aquellas propuestas más tradicionales que se centran
especialmente en el control del proceso, estableciendo rigurosamente las actividades
involucradas, los artefactos que se deben producir, y las herramientas y notaciones que
se usarán. Estas propuestas han demostrado ser efectivas y necesarias en un gran
número de proyectos, pero también han presentado problemas en otros muchos. Una
posible mejora es incluir en los procesos de desarrollo más actividades, más artefactos y
más restricciones, basándose en los puntos débiles detectados. Sin embargo, el resultado
final sería un proceso de desarrollo más complejo que puede incluso limitar la propia
habilidad del equipo para llevar a cabo el proyecto. Otra aproximación es centrarse en
otras dimensiones, como por ejemplo el factor humano o el producto software. Esta es
la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo, a la
colaboración con el cliente y al desarrollo incremental del software con iteraciones muy
cortas. Este enfoque está mostrando su efectividad en proyectos con requisitos muy
cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo pero
manteniendo una alta calidad. Las metodologías ágiles están revolucionando la manera
de producir software, y a la vez generando un amplio debate entre sus seguidores y
quienes por escepticismo o convencimiento no las ven como alternativa para las
metodologías tradicionales. En este trabajo se presenta resumidamente el contexto en el
que surgen las metodologías ágiles, sus valores, principios y comparaciones con las
metodologías tradicionales. Además se describe con mayor detalle Programación
Extrema (eXtreme Programming, XP) la metodología ágil más popular en la actualidad.
PALABRAS CLAVE
Procesos de software, Metodologías ágiles, Programación Extrema (eXtreme
Programming)
1. INTRODUCCIÓN
En las dos últimas décadas las notaciones de modelado y posteriormente las
herramientas pretendieron ser las "balas de plata" para el éxito en el desarrollo de
software, sin embargo, las expectativas no fueron satisfechas. Esto se debe en gran parte
a que otro importante elemento, la metodología de desarrollo, había sido postergado. De
nada sirven buenas notaciones y herramientas si no se proveen directivas para su

aplicación. Así, esta década ha comenzado con un creciente interés en metodologías de
desarrollo. Hasta hace poco el proceso de desarrollo llevaba asociada un marcado
énfasis en el control del proceso mediante una rigurosa definición de roles, actividades y
artefactos, incluyendo modelado y documentación detallada. Este esquema "tradicional"
para abordar el desarrollo de software ha demostrado ser efectivo y necesario en
proyectos de gran tamaño (respecto a tiempo y recursos), donde por lo general se exige
un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el
más adecuado para muchos de los proyectos actuales donde el entorno del sistema es
muy cambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo
pero manteniendo una alta calidad. Ante las dificultades para utilizar metodologías
tradicionales con estas restricciones de tiempo y flexibilidad, muchos equipos de
desarrollo se resignan a prescindir del “buen hacer” de la ingeniería del software,
asumiendo el riesgo que ello conlleva. En este escenario, las metodologías ágiles
emergen como una posible respuesta para llenar ese vacío metodológico. Por estar
especialmente orientadas para proyectos pequeños, las metodologías ágiles constituyen
una solución a medida para ese entorno, aportando una elevada simplificación que a
pesar de ello no renuncia a las prácticas esenciales para asegurar la calidad del producto.
Las metodologías ágiles son sin duda uno de los temas recientes en ingeniería de
software que están acaparando gran interés. Prueba de ello es que se están haciendo un
espacio destacado en la mayoría de conferencias y workshops celebrados en los últimos
años. Es tal su impacto que actualmente existen 4 conferencias internacionales de alto
nivel y específicas sobre el tema1
. Además ya es un área con cabida en prestigiosas
revistas internacionales. En la comunidad de la ingeniería del software, se está viviendo
con intensidad un debate abierto entre los partidarios de las metodologías tradicionales
(referidas peyorativamente como "metodologías pesadas") y aquellos que apoyan las
ideas emanadas del "Manifiesto Ágil"2
. La curiosidad que siente la mayor parte de
ingenieros de software, profesores, e incluso alumnos, sobre las metodologías ágiles
hace prever una fuerte proyección industrial. Por un lado, para muchos equipos de
desarrollo el uso de metodologías tradicionales les resulta muy lejano a su forma de
trabajo actual considerando las dificultades de su introducción e inversión asociada en
formación y herramientas. Por otro, las características de los proyectos para los cuales
las metodologías ágiles han sido especialmente pensadas se ajustan a un amplio rango
de proyectos industriales de desarrollo de software; aquellos en los cuales los equipos
de desarrollo son pequeños, con plazos reducidos, requisitos volátiles, y/o basados en
nuevas tecnologías.
El artículo está organizado como sigue. En la sección 2 se introducen las principales
características de las metodologías ágiles, recogidas en el Manifiesto y se hace una
revisión de los principales métodos ágiles. La sección 3 se centra en eXtreme
Programming (XP), presentando sus características particulares, como son las historias
de usuario y los roles, así como el proceso que se sigue y las prácticas que propone.
Finalmente aparecen las conclusiones.
1
XP Agile Universe: www.agileuniverse.com. Conference on eXtreme Programming and Agile
Processes in Software Engineering: www.xp2004.org. Agile Development Conference (EEUU):
www.agiledevelopmentconference.com. Agile Development Conference (Australia):
www.softed.com/adc2003/
2
agilemanifesto.org

2. METODOLOGÍAS ÁGILES
En una reunión celebrada en febrero de 2001 en Utah-EEUU, nace el término “ágil”
aplicado al desarrollo de software. En esta reunión participan un grupo de 17 expertos
de la industria del software, incluyendo algunos de los creadores o impulsores de
metodologías de software. Su objetivo fue esbozar los valores y principios que deberían
permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios
que puedan surgir a lo largo del proyecto. Se pretendía ofrecer una alternativa a los
procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y
dirigidos por la documentación que se genera en cada una de las actividades
desarrolladas. Varias de las denominadas metodologías ágiles ya estaban siendo
utilizadas con éxito en proyectos reales, pero les faltaba una mayor difusión y
reconocimiento.
Tras esta reunión se creó The Agile Alliance3
, una organización, sin ánimo de lucro,
dedicada a promover los conceptos relacionados con el desarrollo ágil de software y
ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida es
fue el Manifiesto Ágil, un documento que resume la filosofía “ágil”.
2.1. El Manifiesto Ágil.
El Manifiesto comienza enumerando los principales valores del desarrollo ágil. Se
valora:
• Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las
herramientas. La gente es el principal factor de éxito de un proyecto software. Si se
sigue un buen proceso de desarrollo, pero el equipo falla, el éxito no está asegurado;
sin embargo, si el equipo funciona, es más fácil conseguir el objetivo final, aunque
no se tenga un proceso bien definido. No se necesitan desarrolladores brillantes,
sino desarrolladores que se adapten bien al trabajo en equipo. Así mismo, las
herramientas (compiladores, depuradores, control de versiones, etc.) son importantes
para mejorar el rendimiento del equipo, pero el disponer más recursos que los
estrictamente necesarios también puede afectar negativamente. En resumen, es más
importante construir un buen equipo que construir el entorno. Muchas veces se
comete el error de construir primero el entorno y esperar que el equipo se adapte
automáticamente. Es mejor crear el equipo y que éste configure su propio entorno de
desarrollo en base a sus necesidades.
• Desarrollar software que funciona más que conseguir una buena
documentación. Aunque se parte de la base de que el software sin documentación
es un desastre, la regla a seguir es “no producir documentos a menos que sean
necesarios de forma inmediata para tomar un decisión importante”. Estos
documentos deben ser cortos y centrarse en lo fundamental. Si una vez iniciado el
proyecto, un nuevo miembro se incorpora al equipo de desarrollo, se considera que
los dos elementos que más le van a servir para ponerse al día son: el propio código y
la interacción con el equipo.
• La colaboración con el cliente más que la negociación de un contrato. Las
características particulares del desarrollo de software hace que muchos proyectos
hayan fracasado por intentar cumplir unos plazos y unos costes preestablecidos al
inicio del mismo, según los requisitos que el cliente manifestaba en ese momento.
3
www.agilealliance.com

Por ello, se propone que exista una interacción constante entre el cliente y el equipo
de desarrollo. Esta colaboración entre ambos será la que marque la marcha del
proyecto y asegure su éxito.
• Responder a los cambios más que seguir estrictamente un plan. La habilidad de
responder a los cambios que puedan surgir a los largo del proyecto (cambios en los
requisitos, en la tecnología, en el equipo, etc.) determina también el éxito o fracaso
del mismo. Por lo tanto, la planificación no debe ser estricta puesto que hay muchas
variables en juego, debe ser flexible para poder adaptarse a los cambios que puedan
surgir. Una buena estrategia es hacer planificaciones detalladas para unas pocas
semanas y planificaciones mucho más abiertas para unos pocos meses.
Los valores anteriores inspiran los doce principios del manifiesto. Estos principios son
las características que diferencian un proceso ágil de uno tradicional. Los dos primeros
son generales y resumen gran parte del espíritu ágil. Son:
I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de
software que le aporte un valor. Un proceso es ágil si a las pocas semanas de
empezar ya entrega software que funcione aunque sea rudimentario. El cliente
decide si pone en marcha dicho software con la funcionalidad que ahora le
proporciona o simplemente lo revisa e informa de posibles cambios a realizar.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente
tenga una ventaja competitiva. Este principio es una actitud que deben adoptar los
miembros del equipo de desarrollo. Los cambios en los requisitos deben verse
como algo positivo. Les va a permitir aprender más, a la vez que logran una
mayor satisfacción del cliente. Este principio implica además que la estructura del
software debe ser flexible para poder incorporar los cambios sin demasiado coste
añadido. El paradigma orientado a objetos puede ayudar a conseguir esta
flexibilidad.
Luego existen una serie de principios que tienen que ver directamente con el proceso de
desarrollo de software a seguir.
III. Entregar frecuentemente software que funcione desde un par de semanas a un par
de meses, con el menor intervalo de tiempo posible entre entregas. Las entregas al
cliente se insiste en que sean software, no planificaciones, ni documentación de
análisis o de diseño.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del
proyecto. El proceso de desarrollo necesita ser guiado por el cliente, por lo que la
interacción con el equipo es muy frecuente.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el
apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. La
gente es el principal factor de éxito, todo los demás (proceso, entorno, gestión,
etc.) queda en segundo plano. Si cualquiera de ellos tiene un efecto negativo sobre
los individuos debe ser cambiado.
VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar
información dentro de un equipo de desarrollo. Los miembros de equipo deben
hablar entre ellos, éste es el principal modo de comunicación. Se pueden crear
documentos pero no todo estará en ellos, no es lo que el equipo espera.

VII. El software que funciona es la medida principal de progreso. El estado de un
proyecto no viene dado por la documentación generada o la fase en la que se
encuentre, sino por el código generado y en funcionamiento. Por ejemplo, un
proyecto se encuentra al 50% si el 50% de los requisitos ya están en
funcionamiento.
VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,
desarrolladores y usuarios deberían ser capaces de mantener una paz constante.
No se trata de desarrollar lo más rápido posible, sino de mantener el ritmo de
desarrollo durante toda la duración del proyecto, asegurando en todo momento
que la calidad de lo producido es máxima.
Finalmente los últimos principios están más directamente relacionados con el equipo de
desarrollo, en cuanto metas a seguir y organización del mismo.
IX. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
Producir código claro y robusto es la clave para avanzar más rápidamente en el
proyecto.
X. La simplicidad es esencial. Tomar los caminos más simples que sean consistentes
con los objetivos perseguidos. Si el código producido es simple y de alta calidad
será más sencillo adaptarlo a los cambios que puedan surgir.
XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados
por sí mismos. Todo el equipo es informado de las responsabilidades y éstas
recaen sobre todos sus miembros. Es el propio equipo el que decide la mejor
forma de organizarse, de acuerdo a los objetivos que se persigan.
XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más
efectivo, y según esto ajusta su comportamiento. Puesto que el entorno está
cambiando continuamente, el equipo también debe ajustarse al nuevo escenario de
forma continua. Puede cambiar su organización, sus reglas, sus convenciones, sus
relaciones, etc., para seguir siendo ágil.
Los firmantes de los valores y principios de este Manifiesto son: Kent Beck, Mike
Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler,
James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick,
Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas.
2.2. Revisión de metodologías

Antes de resumir algunas metodologías ágiles, vamos a enumerar las principales
diferencias respecto de las metodologías tradicionales (“no ágiles”). La Tabla 1 recoge
esquemáticamente estas diferencias que no se refieren sólo al proceso en sí, sino
también al contexto de equipo y organización que es más favorable a cada uno de estas
filosofías de procesos de desarrollo de software.
Metodologías Ágiles Metodologías Tradicionales
Basadas en heurísticas provenientes de
prácticas de producción de código
Basadas en normas provenientes de
estándares seguidos por el entorno de
desarrollo
Especialmente preparados para cambios
durante el proyecto
Cierta resistencia a los cambios
Impuestas internamente (por el equipo
de desarrollo)
Impuestas externamente
Proceso menos controlado, con pocos
principios
Proceso mucho más controlado, con
numerosas políticas/normas
No existe contrato tradicional o al menos
es bastante flexible
Existe un contrato prefijado
El cliente es parte del equipo de
desarrollo
El cliente interactúa con el equipo de
desarrollo mediante reuniones
Grupos pequeños (<10 integrantes) y
trabajando en el mismo sitio
Grupos grandes y posiblemente
distribuidos
Pocos artefactos Más artefactos
Pocos roles Más roles
Menos énfasis en la arquitectura del
software
La arquitectura del software es esencial
y se expresa mediante modelos
Tabla 1. Diferencias entre metodologías ágiles y no ágiles
Aunque los creadores e impulsores de las metodologías ágiles más populares han
suscrito el manifiesto ágil y coinciden con los principios enunciados anteriormente,
cada metodología tiene características propias y hace hincapié en algunos aspectos más
específicos. A continuación se resumen dichas metodologías ágiles, dejando el análisis
más detallado de XP para la siguiente sección.
• SCRUM4
[16]. Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle.
Define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los
últimos 10 años. Está especialmente indicada para proyectos con un rápido cambio de
requisitos. Sus principales características se pueden resumir en dos. El desarrollo de
software se realiza mediante iteraciones, denominadas sprints, con una duración de 30
días. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente.
La segunda característica importante son las reuniones a lo largo proyecto. Éstas son
las verdaderas protagonistas, especialmente la reunión diaria de 15 minutos del equipo
de desarrollo para coordinación e integración.
4
www.controlchaos.com

• Crystal Methodologies5
[5]. Se trata de un conjunto de metodologías para el
desarrollo de software caracterizadas por estar centradas en las personas que
componen el equipo (de ellas depende el éxito del proyecto) y la reducción al máximo
del número de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El
desarrollo de software se considera un juego cooperativo de invención y
comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor
clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así
como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del
tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo Crystal
Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).
• Dynamic Systems Development Method6
(DSDM) [17]. Define el marco para
desarrollar un proceso de producción de software. Nace en 1994 con el objetivo el
objetivo de crear una metodología RAD unificada. Sus principales características son:
es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan
juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado
funcional, diseño y construcción, y finalmente implementación. Las tres últimas son
iterativas, además de existir realimentación a todas las fases.
• Adaptive Software Development7
(ASD) [9]. Su impulsor es Jim Highsmith. Sus
principales características son: iterativo, orientado a los componentes software más
que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases
esenciales: especulación, colaboración y aprendizaje. En la primera de ellas se inicia el
proyecto y se planifican las características del software; en la segunda desarrollan las
características y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La
revisión de los componentes sirve para aprender de los errores y volver a iniciar el
ciclo de desarrollo.
• Feature-Driven Development8
(FDD) [3]. Define un proceso iterativo que consta de
5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseño
e implementación del sistema partiendo de una lista de características que debe reunir
el software. Sus impulsores son Jeff De Luca y Peter Coad.
• Lean Development9
(LD) [15]. Definida por Bob Charette’s a partir de su experiencia
en proyectos con la industria japonesa del automóvil en los años 80 y utilizada en
numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se
consideran riesgos, pero si se manejan adecuadamente se pueden convertir en
oportunidades que mejoren la productividad del cliente. Su principal característica es
introducir un mecanismo para implementar dichos cambios.
La Tabla 2 (obtenida de [10]), compara las distintas aproximaciones ágiles en base a
tres parámetros: vista del sistema como algo cambiante, tener en cuenta la colaboración
entre los miembros del equipo y características más específicas de la propia
metodología como son simplicidad, excelencia técnica, resultados, adaptabilidad, etc.
También incorpora como referencia no ágil el Capability Madurity Model10
(CMM).
5
www.crystalmethodologies.org
6
www.dsdm.org
7
www.adaptivesd.com
8
www.featuredrivendevelopment.com
9
www.poppendieck.com
10
www.sei.cmu.edu/cmm/cmm.html

CMM ASD Crystal DSDM FDD LD Scrum XP
Sistema como algo
cambiante
1 5 4 3 3 4 5 5
Colaboración 2 5 5 4 4 4 5 5
Características
Metodología (CM)
- Resultados 2 5 5 4 4 4 5 5
- Simplicidad 1 4 4 3 5 3 5 5
- Adaptabilidad 2 5 5 3 3 4 4 3
- Excelencia técnica 4 3 3 4 4 4 3 4
- Prácticas de
colaboración
2 5 5 4 3 3 4 5
Media CM 2.2 4.4 4.4 3.6 3.8 3.6 4.2 4.4
Media Total 1.7 4.8 4.5 3.6 3.6 3.9 4.7 4.8
Tabla 2. Ranking de “agilidad” (Los valores más altos representan una mayor agilidad)
Como se observa en la Tabla 2, todas las metodologías ágiles tienen una significativa
diferencia del índice de agilidad respecto a CMM y entre ellas destacan ASD, Scrum y
XP como las más ágiles.
3. PROGRAMACIÓN EXTREMA (EXTREME PROGRAMMING, XP)
XP11
[2] es una metodología ágil centrada en potenciar las relaciones interpersonales
como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo,
preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima
de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de
desarrollo, comunicación fluida entre todos los participantes, simplicidad en las
soluciones implementadas y coraje para enfrentar los cambios. XP se define como
especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y
donde existe un alto riesgo técnico.
Los principios y prácticas son de sentido común pero llevadas al extremo, de ahí
proviene su nombre. Kent Beck, el padre de XP, describe la filosofía de XP en [2] sin
cubrir los detalles técnicos y de implantación de las prácticas. Posteriormente, otras
publicaciones de experiencias se han encargado de dicha tarea. A continuación
presentaremos las características esenciales de XP organizadas en los tres apartados
siguientes: historias de usuario, roles, proceso y prácticas.
3.1. Las Historias de Usuario
Las historias de usuario son la técnica utilizada en XP para especificar los requisitos del
software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las
11
www.extremeprogramming.org, www.xprogramming.com,
c2.com/cgi/wiki?ExtremeProgramming

características que el sistema debe poseer, sean requisitos funcionales o no funcionales.
El tratamiento de las historias de usuario es muy dinámico y flexible, en cualquier
momento historias de usuario pueden romperse, reemplazarse por otras más específicas
o generales, añadirse nuevas o ser modificadas. Cada historia de usuario es lo
suficientemente comprensible y delimitada para que los programadores puedan
implementarla en unas semanas [12].
Respecto de la información contenida en la historia de usuario, existen varias plantillas
sugeridas pero no existe un consenso al respecto. En muchos casos sólo se propone
utilizar un nombre y una descripción [18] o sólo una descripción [12], más quizás una
estimación de esfuerzo en días [14]. Beck en su libro [2] presenta un ejemplo de ficha
(customer story and task card) en la cual pueden reconocerse los siguientes contenidos:
fecha, tipo de actividad (nueva, corrección, mejora), prueba funcional, número de
historia, prioridad técnica y del cliente, referencia a otra historia previa, riesgo,
estimación técnica, descripción, notas y una lista de seguimiento con la fecha, estado
cosas por terminar y comentarios.
Una de las interrogantes (que también se presenta cuando se utilizan casos de uso) es
¿cuál es el nivel de granularidad adecuado para una historia de usuario? La respuesta no
es tajante. Jeffries en [12] dice que depende de la complejidad del sistema, debe haber al
menos una historia por cada característica importante, y propone realizar una o dos
historias por programador por mes. Si se tienen menos, probablemente sea conveniente
dividir las historias, si se tienen más lo mejor es disminuir el detalle y agruparlas. Para
efectos de planificación, las historias pueden ser de una a tres semanas de tiempo de
programación (para no superar el tamaño de una iteración).
No hay que preocuparse si en un principio no se identifican todas las historias de
usuario. Al comienzo de cada iteración estarán registrados los cambios en las historias
de usuario y según eso se planificará la siguiente iteración.
Las historias de usuario son descompuestas en tareas de programación y asignadas a los
programadores para ser implementadas durante una iteración.
3.2. Roles XP
Aunque en otras fuentes de información aparecen algunas variaciones y extensiones de
roles XP, en este apartado describiremos los roles de acuerdo con la propuesta original
de Beck.
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.
3.3. Proceso XP
Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a
implementar basado en la habilidad del equipo para medir la funcionalidad que puede
entregar a través del tiempo. El ciclo de desarrollo consiste (a grandes rasgos) en los
siguientes pasos [12]:
1. El cliente define el valor de negocio a implementar.
2. El programador estima el esfuerzo necesario para su implementación.
3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las
restricciones de tiempo.
4. El programador construye ese valor de negocio.
5. Vuelve al paso 1.
En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No
se debe presionar al programador a realizar más trabajo que el estimado, ya que se
perderá calidad en el software o no se cumplirán los plazos. De la misma forma el
cliente tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse
que el sistema tenga el mayor valor de negocio posible con cada iteración.
El ciclo de vida ideal de XP consiste de seis fases [2]: 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.
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 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. Wake en [18] proporciona algunas guías útiles para realizar
la planificación de la entrega y de cada iteración.
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).
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.
3.4. Prácticas XP
La principal suposición que se realiza en XP es la posibilidad de disminuir la mítica
curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el
diseño evolutivo funcione. XP apuesta por un crecimiento lento del costo del cambio y
con un comportamiento asintótico. Esto se consigue gracias a las tecnologías
disponibles para ayudar en el desarrollo de software y a la aplicación disciplinada de las
prácticas que describiremos a continuación.
El juego de la planificación
Es un espacio frecuente de comunicación entre el cliente y los programadores. El equipo
técnico realiza una estimación del esfuerzo requerido para la implementación de las
historias de usuario y los clientes deciden sobre el ámbito y tiempo de las entregas y de
cada iteración. Esta práctica se puede ilustrar como un juego, donde existen dos tipos de
jugadores: Cliente y Programador. El cliente establece la prioridad de cada historia de
usuario, de acuerdo con el valor que aporta para el negocio. Los programadores estiman
el esfuerzo asociado a cada historia de usuario. Se ordenan las historias de usuario
según prioridad y esfuerzo, y se define el contenido de la entrega y/o iteración,
apostando por enfrentar lo de más valor y riesgo cuanto antes. Este juego se realiza
durante la planificación de la entrega, en la planificación de cada iteración y cuando sea
necesario reconducir el proyecto.
Entregas pequeñas
La idea es producir rápidamente versiones del sistema que sean operativas, aunque
obviamente no cuenten con toda la funcionalidad pretendida para el sistema pero si que

constituyan un resultado de valor para el negocio. Una entrega no debería tardar más 3
meses.
Metáfora
En XP no se enfatiza la definición temprana de una arquitectura estable para el sistema.
Dicha arquitectura se asume evolutiva y los posibles inconvenientes que se generarían
por no contar con ella explícitamente en el comienzo del proyecto se solventan con la
existencia de una metáfora. El sistema es definido mediante una metáfora o un conjunto
de metáforas compartidas por el cliente y el equipo de desarrollo. Una metáfora es una
historia compartida que describe cómo debería funcionar el sistema. Martin Fowler en
[6] explica que la práctica de la metáfora consiste en formar un conjunto de nombres
que actúen como vocabulario para hablar sobre el dominio del problema. Este conjunto
de nombres ayuda a la nomenclatura de clases y métodos del sistema.
Diseño simple
Se debe diseñar la solución más simple que pueda funcionar y ser implementada en un
momento determinado del proyecto. La complejidad innecesaria y el código extra debe
ser removido inmediatamente. Kent Beck dice que en cualquier momento el diseño
adecuado para el software es aquel que: supera con éxito todas las pruebas, no tiene
lógica duplicada, refleja claramente la intención de implementación de los
programadores y tiene el menor número posible de clases y métodos.
Pruebas
La producción de código está dirigida por las pruebas unitarias. Las pruebas unitarias
son establecidas antes de escribir el código y son ejecutadas constantemente ante cada
modificación del sistema. Los clientes escriben las pruebas funcionales para cada
historia de usuario que deba validarse. En este contexto de desarrollo evolutivo y de
énfasis en pruebas constantes, la automatización para apoyar esta actividad es crucial.
Refactorización (Refactoring)
La refactorización es una actividad constante de reestructuración del código con el
objetivo de remover duplicación de código, mejorar su legibilidad, simplificarlo y
hacerlo más flexible para facilitar los posteriores cambios. La refactorización mejora la
estructura interna del código sin alterar su comportamiento externo [8]. Robert Martin
[13] señala que el diseño del sistema de software es una cosa viviente. No se puede
imponer todo en un inicio, pero en el transcurso del tiempo este diseño evoluciona
conforme cambia la funcionalidad del sistema. Para mantener un diseño apropiado, es
necesario realizar actividades de cuidado continuo durante el ciclo de vida del proyecto.
De hecho, este cuidado continuo sobre el diseño es incluso más importante que el
diseño inicial. Un concepto pobre al inicio puede ser corregido con esta actividad
continua, pero sin ella, un buen diseño inicial se degradará.

Programación en parejas
Toda la producción de código debe realizarse con trabajo en parejas de programadores.
Según Cockburn y Williams en un estudio realizado para identificar los costos y
beneficios de la programación en parejas [4], las principales ventajas de introducir este
estilo de programación son: muchos errores son detectados conforme son introducidos
en el código (inspecciones de código continuas), por consiguiente la tasa de errores del
producto final es más baja, los diseños son mejores y el tamaño del código menor
(continua discusión de ideas de los programadores), los problemas de programación se
resuelven más rápido, se posibilita la transferencia de conocimientos de programación
entre los miembros del equipo, varias personas entienden las diferentes partes sistema,
los programadores conversan mejorando así el flujo de información y la dinámica del
equipo, y finalmente, los programadores disfrutan más su trabajo. Dichos beneficios se
consiguen después de varios meses de practicar la programación en parejas. En los
estudios realizados por Cockburn y Williams este lapso de tiempo varía de 3 a 4 meses.
Propiedad colectiva del código
Cualquier programador puede cambiar cualquier parte del código en cualquier
momento. Esta práctica motiva a todos a contribuir con nuevas ideas en todos los
segmentos del sistema, evitando a la vez que algún programador sea imprescindible
para realizar cambios en alguna porción de código.
Integración continua
Cada pieza de código es integrada en el sistema una vez que esté lista. Así, el sistema
puede llegar a ser integrado y construido varias veces en un mismo día. Todas las
pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo código sea
incorporado definitivamente. La integración continua a menudo reduce la fragmentación
de los esfuerzos de los desarrolladores por falta de comunicación sobre lo que puede ser
reutilizado o compartido. Martin Fowler en [7] afirma que el desarrollo de un proceso
disciplinado y automatizado es esencial para un proyecto controlado, el equipo de
desarrollo está más preparado para modificar el código cuando sea necesario, debido a
la confianza en la identificación y corrección de los errores de integración.
40 horas por semana
Se debe trabajar un máximo de 40 horas por semana. No se trabajan horas extras en dos
semanas seguidas. Si esto ocurre, probablemente está ocurriendo un problema que debe
corregirse. El trabajo extra desmotiva al equipo. Los proyectos que requieren trabajo
extra para intentar cumplir con los plazos suelen al final ser entregados con retraso. En
lugar de esto se puede realizar el juego de la planificación para cambiar el ámbito del
proyecto o la fecha de entrega.
Cliente in-situ
El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Gran parte
del éxito del proyecto XP se debe a que es el cliente quien conduce constantemente el
trabajo hacia lo que aportará mayor valor de negocio y los programadores pueden
resolver de manera inmediata cualquier duda asociada. La comunicación oral es más
efectiva que la escrita, ya que esta última toma mucho tiempo en generarse y puede
tener más riesgo de ser mal interpretada. En [12] Jeffries indica que se debe pagar un
precio por perder la oportunidad de un cliente con alta disponibilidad. Algunas

recomendaciones propuestas para dicha situación son las siguientes: intentar conseguir
un representante que pueda estar siempre disponible y que actúe como interlocutor del
cliente, contar con el cliente al menos en las reuniones de planificación, establecer
visitas frecuentes de los programadores al cliente para validar el sistema, anticiparse a
los problemas asociados estableciendo llamadas telefónicas frecuentes y conferencias,
reforzando el compromiso de trabajo en equipo.
Estándares de programación
XP enfatiza la comunicación de los programadores a través del código, con lo cual es
indispensable que se sigan ciertos estándares de programación (del equipo, de la
organización u otros estándares reconocidos para los lenguajes de programación
utilizados). Los estándares de programación mantienen el código legible para los
miembros del equipo, facilitando los cambios.
Comentarios respecto de las prácticas
El mayor beneficio de las prácticas se consigue con su aplicación conjunta y equilibrada
puesto que se apoyan unas en otras. Esto se ilustra en la Figura 1 (obtenida de [2]),
donde una línea entre dos prácticas significa que las dos prácticas se refuerzan entre sí.
La mayoría de las prácticas propuestas por XP no son novedosas sino que en alguna
forma ya habían sido propuestas en ingeniería del software e incluso demostrado su
valor en la práctica (ver [1] para un análisis histórico de ideas y prácticas que sirven
como antecedentes a las utilizadas por las metodologías ágiles). El mérito de XP es
integrarlas de una forma efectiva y complementarlas con otras ideas desde la
perspectiva del negocio, los valores humanos y el trabajo en equipo.
Figura 1. Las prácticas se refuerzan entre sí

4. CONCLUSIONES
No existe una metodología universal para hacer frente con éxito a cualquier proyecto de
desarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto
(recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema, etc.
Históricamente, las metodologías tradicionales han intentado abordar la mayor cantidad
de situaciones de contexto del proyecto, exigiendo un esfuerzo considerable para ser
adaptadas, sobre todo en proyectos pequeños y con requisitos muy cambiantes. Las
metodologías ágiles ofrecen una solución casi a medida para una gran cantidad de
proyectos que tienen estas características. Una de las cualidades más destacables en una
metodología ágil es su sencillez, tanto en su aprendizaje como en su aplicación,
reduciéndose así los costos de implantación en un equipo de desarrollo. Esto ha llevado
hacia un interés creciente en las metodologías ágiles. Sin embargo, hay que tener
presente una serie de inconvenientes y restricciones para su aplicación, tales como:
están dirigidas a equipos pequeños o medianos (Beck sugiere que el tamaño de los
equipos se limite de 3 a 20 como máximo, otros dicen no más de 10 participantes), el
entorno físico debe ser un ambiente que permita la comunicación y colaboración entre
todos los miembros del equipo durante todo el tiempo, cualquier resistencia del cliente o
del equipo de desarrollo hacia las prácticas y principios puede llevar al proceso al
fracaso (el clima de trabajo, la colaboración y la relación contractual son claves), el uso
de tecnologías que no tengan un ciclo rápido de realimentación o que no soporten
fácilmente el cambio, etc.
Falta aún un cuerpo de conocimiento consensuado respecto de los aspectos teóricos y
prácticos de la utilización de metodologías ágiles, así como una mayor consolidación de
los resultados de aplicación. La actividad de investigación está orientada hacia líneas
tales como: métricas y evaluación del proceso, herramientas específicas para apoyar
prácticas ágiles, aspectos humanos y de trabajo en equipo. Entre estos esfuerzos
destacan proyectos como NAME12
(Network for Agile Methodologies Experience) en el
cual hemos participado como nodo en España.
Aunque en la actualidad ya existen libros asociados a cada una de las metodologías
ágiles existentes y también abundante información en internet, es XP la metodología
que resalta por contar con la mayor cantidad de información disponible y es con
diferencia la más popular.
REFERENCIAS BIBLIOGRÁFICAS
[1] Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J. “Agile software development
methods Review and analysis”. VTT Publications. 2002.
[2] Beck, K.. “Extreme Programming Explained. Embrace Change”, Pearson
Education, 1999. Traducido al español como: “Una explicación de la programación
extrema. Aceptar el cambio”, Addison Wesley, 2000.
[3] Coad P., Lefebvre E., De Luca J. “Java Modeling In Color With UML: Enterprise
Components and Process”. Prentice Hall. 1999.
[4] Cockbun, A., Williams, L. “The Costs and Benefits of Pair Programming”. Humans
and Technology Technical Report. 2000.
12
name.case.unibz.it/

[5] Cockbun, A. “Agile Software Development”. Addison-Wesley. 2001.
[6] Fowler, M. “Is Design Dead?”. 2001.
www.martinfowler.com/articles/designDead.html
[7] Fowler, M., Foemmel M. “Continuous Integration”. 2001.
www.martinfowler.com/articles/designDead.html
[8] Fowler, M., Beck, K., Brant, J. “Refactoring: Improving the Design of Existing
Code”. Addison-Wesley. 1999
[9] Highsmith J., Orr K. “Adaptive Software Development: A Collaborative Approach
to Managing Complex Systems”. Dorset House. 2000.
[10]Highsmith, J. “Agile Software Development Ecosystems”. Addison-Wesley. 2002.
[11]Jacobson, I. “Object-Oriented Software Engineering”. Addison-Wesley. 1994.
[12]Jeffries, R., Anderson, A., Hendrickson, C. “Extreme Programming Installed”.
Addison-Wesley. 2001
[13]Martin, R. “Continuos Care vs. Initial Design”. 2002.
www.objectmentor.com/resources/articles/Continuous_Care.pdf
[14]Newkirk, J., Martin R.C. “Extreme Programming in Practice”. Addison-Wesley.
2001.
[15]Poppendieck M., Poppendieck T. “Lean Software Development: An Agile Toolkit
for Software Development Managers”. Addison Wesley. 2003.
[16]Schwaber K., Beedle M., Martin R.C. “Agile Software Development with
SCRUM”. Prentice Hall. 2001.
[17]Stapleton J. “Dsdm Dynamic Systems Development Method: The Method in
Practice”. Addison-Wesley. 1997.
[18]Wake, W.C. “Extreme Programming Explored”. Addison-Wesley. 2002.

prog

Más contenido relacionado

La actualidad más candente (16)

Destacado (20)

Similar a prog (20)

prog