CI-4713 Ingeniera de Software II Trimestre Abril/Julio 2009

DESARROLLO GIL DE SOFTWARE CASO PROGRAMACIN EXTREMA - XP

I. INTRODUCCIN
Se entiende como Desarrollo gil de software a un paradigma de Desarrollo de Software
basado en procesos giles. Los procesos giles de desarrollo de software, conocidos
anteriormente como metodologas livianas, intentan evitar los tortuosos y burocrticos caminos
de las metodologas tradicionales enfocndose en la gente y los resultados.
Es un marco de trabajo conceptual de la ingeniera de software que promueve iteraciones en el
desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos mtodos de desarrollo
gil; la mayora minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software
desarrollado en una unidad de tiempo es llamado una iteracin, la cual debe durar de una a
cuatro semanas. Cada iteracin del ciclo de vida incluye: planificacin, anlisis de
requerimientos, diseo, codificacin, revisin y documentacin. Una iteracin no debe agregar
demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es
tener un demo (sin errores) al final de cada iteracin. Al final de cada iteracin el equipo vuelve
a evaluar las prioridades del proyecto.
Los mtodos giles enfatizan las comunicaciones cara a cara en vez de de la documentacin.
La mayora de los equipos giles estn localizados en una simple oficina abierta, a veces
llamadas "plataformas de lanzamiento" (bullpen en ingls). La oficina debe incluir revisores,
diseadores de iteracin, escritores de documentacin y ayuda y directores de proyecto. Los
mtodos giles tambin enfatizan que el software funcional es la primera medida del progreso.
Combinado con la preferencia por las comunicaciones cara a cara, generalmente los mtodos
giles son criticados y tratados como "indisciplinados" por la falta de documentacin tcnica.
Las metodologas giles, como es el caso de XP, forman parte del movimiento de desarrollo gil
de software, que se basan en la adaptabilidad de cualquier cambio como medio para aumentar
las posibilidades de xito de un proyecto.
De forma que una metodologa gil es la que tiene como principios que:

Los individuos y sus interacciones son ms importantes que los procesos y las
herramientas.

El software que funciona es ms importante que la documentacin exhaustiva.

La colaboracin con el cliente en lugar de la negociacin de contratos.

La respuesta delante del cambio en lugar de seguir un plan cerrado.

Se puede decir que, este movimiento empez a existir a partir de febrero de 2001, cuando se
reunieron los representantes de cada una de estas metodologas y terminaron poniendo en
comn sus ideas en una declaracin conjunta.
Aunque no es posible extendernos aqu sobre este aspecto, creemos importante al menos
resear una de las asunciones ms importantes e innovadoras que hace XP frente a la mayora
de los mtodos conocidos, y es la referida al coste del cambio. En efecto, siempre ha sido una
verdad universal el hecho de que el coste del cambio en el desarrollo de un proyecto se
incrementaba exponencialmente en el tiempo, como indica la figura 1:

1 de 9

CI-4713 Ingeniera de Software II Trimestre Abril/Julio 2009

Fig. 1. Costo del cambio durante el ciclo de vida

II. EXTREME PROGRAMMING XP

La programacin extrema o eXtreme Programming (XP) es un enfoque de la ingeniera de
software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme
Programming Explained: Embrace Change (1999). Es el ms destacado de los procesos giles
de desarrollo de software. Al igual que stos, la programacin extrema se diferencia de las
metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en
la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la
marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen
que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del
proyecto es una aproximacin mejor y ms realista que intentar definir todos los requisitos al
comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos.
Se puede considerar la programacin extrema como la adopcin de las mejores metodologas
de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de
manera dinmica durante el ciclo de vida del software.
II.1 POSTURAS A FAVOR Y EN CONTRA
La mejor manera de reflejar las diferentes posturas sobre las preferencias de la Programacin
Extrema es hacer referencia a una encuesta realizada por IBM el octubre del ao 2000, donde
se formulaba precisamente la opinin de profesionales sobre el mtodo de programacin que
nos ocupa (Fig. 2).
A. Lo he probado y no me gusta nada
B. Es una mala idea, no puede funcionar nunca
C. Es una buena idea, pero no funcionar.
D. Lo he probado y me gusta mucho

2 de 9

CI-4713 Ingeniera de Software II Trimestre Abril/Julio 2009

Fig. 2. Opiniones sobre XP

Con el poco tiempo que hace que existe esta metodologa, ya se ha generado un gran alboroto
en la comunidad de ingeniera del software. Hay opiniones de todos los gustos de quienes lo
prueban.
Las opiniones negativas mayoritarias alegan lo siguiente:

Los programadores tienen un acusado sentimiento de posesin del cdigo y esta postura
no encaja con la filosofa de XP.

Tambin se ve un fuerte sentimiento para respectar las 40 horas semanales, y X.P. no lo

garantiza.

Los jefes de proyecto tambin expresan su recelo con este mtodo tan poco tradicional.

En cambio una visin ms optimista dice que:

XP. slo funcionar con gente buena, es decir, profesionales que son capaces de hacer
un buen diseo, sencillo y a la vez fcilmente ampliable.

Por otro lado se ha de recalcar que XP no ha inventado ningn mtodo nuevo,

sencillamente ha recogido mtodos ya existentes y los ha agrupado, y ha comprobado
que funcionen. Y para terminar, mencionar que el creador de XP asegura que se
garantiza un rato si ms no divertido.

II.2 PRINCIPIOS.
La Programacin Extrema se basa en 12 principios bsicos agrupados en cuatro categoras:
Retroalimentacin a escala fina.

El principio de pruebas: se tiene que establecer un perodo de pruebas de aceptacin del

programa (llamado tambin perodo de caja negra) donde se definirn las entradas al
sistema y los resultados esperados de estas entradas. Es muy recomendable automatizar
estas pruebas para poder hacer varias simulaciones del sistema en funcionamiento. Para
hacer estas simulaciones automatizadas, se pueden utilizar Ambientes de Prueba (Unit

3 de 9

CI-4713 Ingeniera de Software II Trimestre Abril/Julio 2009

testing frameworks). Un buen ejemplo de un ambiente de prueba es el JUnit para Java

(www.junit.org/index.htm). Otros ambientes de pruebas para otros lenguajes como C, C++,
JavaScript,
XML
y
servicios
Web,
pueden
encontrarse
en
www.xprogramming.com/software.htm.

Proceso de planificacin: en esta fase, el usuario tendr que escribir sus necesidades,
definiendo las actividades que realizar el sistema. Se crear un documento llamado
Historias del usuario (User Stories). Entre 20 y 80 historias (todo dependiendo de la
complejidad del problema) se consideran suficientes para formar el llamado Plan de
Liberacin, el cual define de forma especfica los tiempos de entrega de la aplicacin para
recibir retroalimentacin por parte del usuario. Por regla general, cada una de les Historias
del usuario suelen necesitar de una a tres semanas de desarrollo.
Son muy importantes y tienen que ser una constante las reuniones peridicas durante esta
fase de planificacin. Estas pueden ser a diario, con todo el equipo de desarrollo para
identificar problemas, proponer soluciones y sealar aquellos puntos a los que se les ha de
dar ms importancia por su dificultad o por su punto crtico.

El cliente en el sitio: se le dar poder para determinar los requerimientos, definir la

funcionalidad, sealar las prioridades y responder las preguntas de los programadores. Esta
fuerte interaccin cara a cara con el programador disminuye el tiempo de comunicacin y la
cantidad de documentacin, junto con los altos costes de su creacin y mantenimiento. Este
representante del cliente estar con el equipo de trabajo durante toda la realizacin del
proyecto.

Programacin en parejas: uno de los principios ms radicales y en el que la mayora de

gerentes de desarrollo pone sus dudas. Requiere que todos los programadores XP escriban
su cdigo en parejas, compartiendo una sola mquina. De acuerdo con los experimentos,
este principio puede producir aplicaciones ms buenas, de manera consistente, a iguales o
menores costes.

Proceso continuo en lugar de por lotes.

Integracin continua: permite al equipo hacer un rpido progreso implementando las

nuevas caractersticas del software. En lugar de crear builds (o versiones) estables de
acuerdo a un cronograma establecido, los equipos de programadores XP pueden reunir su
cdigo y reconstruir el sistema varias veces al da. Esto reduce los problemas de integracin
comunes en proyectos largos y estilo cascada.

Refactoring: permite a los equipos de programadores XP mejorar el diseo del sistema a

travs de todo el proceso de desarrollo. Los programadores evalan continuamente el
diseo y recodifican lo necesario. La finalidad es mantener un sistema enfocado a proveer el
valor de negocio mediante la minimizacin del cdigo duplicado y/o ineficiente.

Entregas pequeas: colocan un sistema sencillo en produccin rpidamente que se

actualiza de forma rpida y constante permitiendo que el verdadero valor de negocio del
producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las 2 o 3
semanas como mximo.

Entendimiento compartido.

Diseo simple: se basa en la filosofa de que el mayor valor de negocio es entregado por el
programa ms sencillo que cumpla los requerimientos. Simple Design se enfoca en
proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni ms ni menos.
Este proceso permite eliminar redundancias y rejuvenecer los diseos obsoletos de forma
sencilla.

4 de 9

CI-4713 Ingeniera de Software II Trimestre Abril/Julio 2009

Metfora: desarrollada por los programadores al inicio del proyecto, define una historia de
como funciona el sistema completo. XP estimula historias, que son breves descripciones de
un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified
Modeling Language). La metfora expresa la visin evolutiva del proyecto que define el
alcance y propsito del sistema.
Las tarjetas CRC (Clase, Responsabilidad y Colaboracin) tambin ayudarn al equipo a
definir actividades durante el diseo del sistema. Cada tarjeta representa una clase en la
programacin orientada a objetos y define sus responsabilidades (lo que ha de hacer) y las
colaboraciones con las otras clases (cmo se comunica con ellas).

Propiedad colectiva del cdigo: un cdigo con propiedad compartida. Nadie es el

propietario de nada, todos son el propietario de todo. Este mtodo difiere en mucho a los
mtodos tradicionales en los que un simple programador posee un conjunto de cdigo. Los
defensores de XP argumentan que mientras haya ms gente trabajando en una pieza,
menos errores aparecern.

Estndar de codificacin: define la propiedad del cdigo compartido as como las reglas
para escribir y documentar el cdigo y la comunicacin entre diferentes piezas de cdigo
desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera
que el cdigo en el sistema se vea como si hubiera estado escrito por una sola persona.

Bienestar del programador.

La semana de 40 horas: la programacin extrema sostiene que los programadores
cansados escriben cdigo de menor cualidad. Minimizar las horas extras y mantener los
programadores frescos, generar cdigo de mayor calidad. Como dice Beck, est bien
trabajar tiempos extra cuando es necesario, pero no se ha de hacer durante dos semanas
seguidas.

II.3 CARACTERSTICAS FUNDAMENTALES.

Las caractersticas fundamentales del mtodo son:
Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo

pruebas de regresin. Se aconseja escribir el cdigo de la prueba antes de la codificacin.

Vase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a
Delphi y NUnit para la plataforma.NET. Estas dos ltimas inspiradas en JUnit.
Programacin en parejas: se recomienda que las tareas de desarrollo se lleven a cabo

por dos personas en una misma posicin. Se supone que la mayor calidad del cdigo
escrito de esta manera -el cdigo es revisado y discutido mientras se escribe- es ms
importante que la posible prdida de productividad inmediata.
Frecuente integracin del equipo de programacin con el cliente o usuario. Se

recomienda que un representante del cliente trabaje junto al equipo de desarrollo.

Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas

frecuentes.
Refactoring del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su

legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de

garantizar que en el refactoring no se ha introducido ningn fallo.
Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de

cada mdulo en grupos de trabajo distintos, este mtodo promueve el que todo el personal

5 de 9

CI-4713 Ingeniera de Software II Trimestre Abril/Julio 2009

pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de
regresin garantizan que los posibles errores sern detectados.
Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo

funcione se podr aadir funcionalidad si es necesario. La programacin extrema apuesta

que es ms sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se
requiere, que realizar algo complicado y quizs nunca utilizarlo.

Fig. 3 Caractersticas de la metodologa

La simplicidad y la comunicacin son extraordinariamente complementarias. Con ms

comunicacin resulta ms fcil identificar qu se debe y qu no se debe hacer. Mientras ms
simple es el sistema, menos tendr que comunicar sobre este, lo que lleva a una comunicacin
ms completa, especialmente si se puede reducir el equipo de programadores.
En la figura 3 se evidencian estas caractersticas.
II. 4 FASES DE LA PROGRAMACIN EXTREMA (XP).
1 Fase: Planificacin del Proyecto.
Historias de usuario.
Release planning.
Iteraciones.
Velocidad del proyecto.
Programacin en pareja.
Reuniones diarias.
2 Fase: Diseo.
Diseos simples.
Glosarios de trminos.
Riesgos.
Funcionalidad extra.

6 de 9

CI-4713 Ingeniera de Software II Trimestre Abril/Julio 2009

Tarjetas CRC.
3 Fase: Codificacin.
4 Fase: Pruebas.

III. CICLO DE VIDA DE UN PROYECTO XP

El ciclo de vida de un proyecto XP consiste de seis fases (Fig. 4):

Fig. 4 Ciclo de vida en XP

Exploracin

En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de inters
para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con
las herramientas, tecnologas y prcticas que se utilizarn en el proyecto. Se prueba la
tecnologa y se exploran las posibilidades de la arquitectura del sistema construyendo un
prototipo. La fase de exploracin toma de pocas semanas a pocos meses, dependiendo del
tamao y familiaridad que tengan los programadores con la tecnologa.

Fase de Planeamiento o Planificacin de la Entrega (Release)

En esta fase el cliente establece la prioridad de cada historia de usuario, y

correspondientemente, los programadores realizan una estimacin 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 debera obtenerse en no ms de tres
meses. Esta fase dura unos pocos das. Las estimaciones de esfuerzo asociado a la
implementacin de las historias la establecen los programadores utilizando como medida el
punto. Un punto, equivale a una semana ideal de programacin. 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 iteracin, basndose principalmente en la
suma de puntos correspondientes a las historias de usuario que fueron terminadas en la ltima
iteracin. La planificacin se puede realizar basndose en el tiempo o el alcance. La velocidad
del proyecto es utilizada para establecer cuntas historias se pueden implementar antes de una

7 de 9

CI-4713 Ingeniera de Software II Trimestre Abril/Julio 2009

fecha determinada o cunto tiempo tomar implementar un conjunto de historias. Al planificar

por tiempo, se multiplica el nmero de iteraciones por la velocidad del proyecto, determinndose
cuntos puntos se pueden completar. Al planificar segn alcance del sistema, se divide la suma
de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo
el nmero de iteraciones necesarias para su implementacin.

Iteraciones

Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega
est compuesto por iteraciones de no ms de tres semanas. En la primera iteracin 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 creacin de esta arquitectura,
sin embargo, esto no siempre es posible ya que es el cliente quien decide qu historias se
implementarn en cada iteracin (para maximizar el valor de negocio). Al final de la ltima
iteracin el sistema estar listo para entrar en produccin. Los elementos que deben tomarse en
cuenta durante la elaboracin del Plan de la Iteracin son: historias de usuario no abordadas,
velocidad del proyecto, pruebas de aceptacin no superadas en la iteracin anterior y tareas no
terminadas en la iteracin anterior. Todo el trabajo de la iteracin es expresado en tareas de
programacin, cada una de ellas es asignada a un programador como responsable, pero
llevadas a cabo por parejas de programadores.

Produccin

La fase de produccin 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 inclusin de nuevas caractersticas a la versin actual, debido a cambios
durante esta fase. Es posible que se rebaje el tiempo que toma cada iteracin, de tres a una
semana. Las ideas que han sido propuestas y las sugerencias son documentadas para su
posterior implementacin (por ejemplo, durante la fase de mantenimiento).

Mantenimiento

Mientras la primera versin se encuentra en produccin, 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 despus de la puesta del sistema en produccin. 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 ms 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 documentacin final del sistema y no se realizan ms cambios en la
arquitectura. La muerte del proyecto tambin ocurre cuando el sistema no genera los beneficios
esperados por el cliente o cuando no hay presupuesto para mantenerlo.
IV. ROLES EN XP
Aunque en otras fuentes de informacin 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 cdigo del sistema. Debe existir una
comunicacin y coordinacin adecuada entre los programadores y otros miembros del equipo.

8 de 9

CI-4713 Ingeniera de Software II Trimestre Abril/Julio 2009

Cliente
El cliente escribe las historias de usuario y las pruebas funcionales para validar su
implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se
implementan en cada iteracin centrndose en aportar mayor valor al negocio. El cliente es slo
uno dentro del proyecto pero puede corresponder a un interlocutor que est representando a
varias personas que se vern 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 realimentacin 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.
Tambin realiza el seguimiento del progreso de cada iteracin y evala si los objetivos son
alcanzables con las restricciones de tiempo y recursos presentes. Determina cundo es
necesario realizar algn cambio para lograr los objetivos de cada iteracin.
Entrenador (Coach)
Es responsable del proceso global. Es necesario que conozca a fondo el proceso XP para
proveer guas a los miembros del equipo de forma que se apliquen las prcticas XP y se siga el
proceso correctamente.
Consultor
Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario
para el proyecto. Gua al equipo para resolver un problema especfico.
Gestor (Big boss)
Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente
creando las condiciones adecuadas. Su labor esencial es de coordinacin.
BIBLIOGRAFA Y ENLACES
Letelier, P., Penads, M.C: Mtodologas giles para el desarrollo de software: eXtreme Programming
(XP). Laboratorio de Sistemas de Informacin. Departamento de Sistemas Informticos y Computacin.
Facultad de Informtica. Universidad Politcnica de Valencia. Disponible en
http://www.willydev.net/descargas/masyxp.pdf
Programacin Extrema, disponible en http://www.programacionextrema.org/
Manifiesto gil, disponible en http://es.wikipedia.org/wiki/Manifiesto_%C3%81gil

9 de 9