eXtreme Programming1

Parte del Trabajo de Grado Adecuacin de la metodologa de desarrollo Extreme

Programming a proyectos llevados a cabo en la materia Laboratorio III de la
Facultad de Ingeniera de la Universidad Austral de Lucila Ana Cuccaro Goggi

ndice General
Motivacin del trabajo de grado........................................................................................3
ntroduccin a las metodologas giles..............................................................................6
Historia de las metodologas giles..............................................................................6
Manifiesto gil..............................................................................................................7
Los 12 principios giles.................................................................................................8
Distintas Metodologas giles.....................................................................................10
Introduccin a eXtreme Programming............................................................................14
Su creador: Kent Beck.............................................................................................14
Descripcin de la Metodologa: XP detallado.............................................................15
Actividades de Xp.......................................................................................................16
Escuchar..................................................................................................................16
Disear.....................................................................................................................16
Codificar..................................................................................................................16
Hacer pruebas..........................................................................................................17
Proceso XP..................................................................................................................17
Prcticas XP................................................................................................................18
El juego de la planificacin.....................................................................................18
Entregas pequeas...................................................................................................18
Metfora..................................................................................................................19
Diseo simple..........................................................................................................19
Pruebas....................................................................................................................19
Refactorizacin (Refactoring).................................................................................19
Programacin en parejas.........................................................................................20
Propiedad colectiva del cdigo................................................................................20
Integracin continua................................................................................................20
40 horas por semana................................................................................................21
Cliente on-site..........................................................................................................21
Estndares de programacin....................................................................................21
Artefactos XP..............................................................................................................23
Las Historias de Usuario.........................................................................................23
Task Cards...............................................................................................................23
CRC Card................................................................................................................24
Roles XP......................................................................................................................24
Programador............................................................................................................24
Cliente.....................................................................................................................25
Encargado de pruebas (Tester)................................................................................25
Encargado de seguimiento (Tracker).......................................................................25
Entrenador (Coach).................................................................................................25
Consultor.................................................................................................................26
Gestor (Big boss).................................................................................................26
Casos de estudio en los que se utilizo Extreme Programming................................26
Bibliografa......................................................................................................................31
Glosario...........................................................................................................................33

Motivacin del trabajo de grado

La creacin de software o desarrollo de sistemas es una tarea altamente
compleja. Debido a esta complejidad con el transcurso del tiempo se han desarrollado
numerosas metodologas de desarrollo que afectan las distintas dimensiones del proceso
de desarrollo.
Por una parte podemos encontrar aquellas metodologas ms tradicionales que
hacen hincapi principalmente en el control del proceso, estableciendo cuidadosamente
las actividades involucradas, los distintos artefactos que se deben producir y las
herramientas que han de ser utilizadas para producir dichos artefactos. Estas propuestas
metodolgicas han demostrado ser altamente efectivas en numerosos proyectos e
inclusive, en ocasiones, necesarias; pero por desgracia tambin han presentado varios
problemas en muchos otros proyectos. Ante dichos problemas se han propuesto
diferentes alternativas para combatir estos inconvenientes.
Una de ellas fue la introduccin de nuevas actividades en los procesos de
desarrollo. Otra alternativa fue la introduccin de ms artefactos y restricciones
teniendo en cuenta los puntos dbiles en cada proyecto. Pero el resultado de llevar a
cabo estas acciones fue la obtencin de un proceso de desarrollo ms engorroso y
complejo que incluso, en algunos casos, poda llegar a limitar la habilidad del equipo a
la hora de trabajar en el desarrollo del proyecto.
Otra posible solucin planteada posteriormente fue centrarse en otros aspectos
del desarrollo como por ejemplo el factor humano o equipo involucrado en el proceso
de desarrollo as como en el software a desarrollar.
A partir de esta solucin que hoy en da es considerada como una filosofa,
nacen las metodologas giles. Esta filosofa brinda mayor valor a los individuos
involucrados, as como a la colaboracin con el cliente y al desarrollo incremental del
software basado en iteraciones que constan de un corto plazo.
En la actualidad este enfoque esta mostrando una alta efectividad en proyectos
con requerimientos muy cambiantes y en aquellos casos en lo que se exige reducir
notablemente los tiempos de desarrollo pero sin descuidar la alta calidad del producto.
Apoyadas en esta filosofa nacen las metodologas giles, las cuales estn
revolucionando la forma de producir software y a la vez generando un amplio debate
entre sus seguidores, gente innovadora en el rea de desarrollo y aquellos que por
convencionalismo o escepticismo no las ven como una alternativa viable para el
desarrollo de aplicaciones.
En este marco centraremos nuestro estudio para analizar la ms importante y
utilizada en el mercado laboral de estas metodologas giles de las software factories,
Extreme Programming.
En el presente trabajo se estudiar en que consiste esta metodologa analizando
sus valores, estructura, artefactos y conceptos; y se realizara un estudio detallado de
como adaptar dicha metodologa a la materia Laboratorio III de la Facultad de
Ingeniera de la Universidad Austral.
Junto con lo anteriormente mencionado, este trabajo tiene como objetivos
introducir a los alumnos en una metodologa utilizada en la actualidad y servir de gua
de consulta a los mismos a la hora de trabajar con dicha metodologa.
El trabajo comienza con la presentacin de los lineamientos necesarios para
trabajar con XP y RUP; contina con la comparacin entre dichas metodologas y la
adecuacin de la metodologa XP a la cursada de la materia Laboratorio III y concluye
con una reflexin sobre el estudio realizado.
3

Historia de los procesos de desarrollo

El modelo ms antiguo de desarrollo era el de codificar y probar. Este modelo
fue utilizado en los inicios del desarrollo de software. Dicho modelo fue el que
predomin en la dcada de los aos 60.
ste estaba basado en requerimientos ambiguos y sin especificaciones puntuales.
Constaba en implementar el cdigo y, a continuacin, pensar sobre los requerimientos,
el diseo y el mantenimiento.
Para sistemas pequeos este modelo result ser til, pero cuando los sistemas se
presentaban con una mayor complejidad resultaba muy peligroso, ya que no
proporcionaba medios de evaluacin de la calidad o de identificacin de riesgos.
Su principal falla se presentaba si se estaba a punto de terminar de codificar y se
descubra que el diseo era incorrecto ya que en dichas condiciones, no haba otra
solucin ms que desechar el trabajo realizado y comenzar de nuevo. Esto resultaba
muy elevado en costos de los recursos y tiempos de desarrollo.
Posteriormente, en la dcada del 70, propuesto por Winston Royce 2, surgi el
denominado modelo en cascada. Dicho modelo sirvi como base para la formulacin
del anlisis estructurado, el cual fue uno de los precursores en el camino hacia la
aplicacin de prcticas estandarizadas dentro de la ingeniera de software.
El modelo en cascada, buscaba ordenar el proceso de desarrollo de una forma
fcil de implementar. Este modelo tuvo una gran aceptacin. La principal ventaja que
brindaba con respecto al anterior, el modelo de implementacin y prueba, era que ya se
contaba con cierta disciplina en el desarrollo de sistemas; se introducen la planeacin y
administracin, y se deben controlar dichas actividades; es decir, deba existir alguien
que vigile que el grupo de desarrollo realmente cumpla con lo que se haba planeado.
Este modelo se basaba en el desarrollo de etapas (anlisis, diseo, codificacin,
pruebas y mantenimiento) las cuales cuentan con una entrada y una salida predefinida.
El proceso de desarrollo toma la forma de una cascada ya que se requiere la finalizacin
de la etapa anterior para comenzar con la siguiente.
La principal desventaja del modelo en cascada era que no es flexible con
respecto a los cambios. Esto exiga que se tengan que especificar completamente todos
los requerimientos al comienzo del proyecto lo que puede durar meses o incluso aos
antes de tener el software funcionando. Una vez que se iniciaba el desarrollo no se
permita cambio alguno a los requerimientos, por lo que el usuario no poda ver la
aplicacin hasta que ya estuviese totalmente construida. Se corra asimismo con el
riesgo de no cubrir sus necesidades.
Conforme se fueron descubriendo las deficiencias del modelo en cascada,
fueron surgiendo diversos procesos denominados iterativos que fueron mejorando
muchas de las fallas del modelo en cascada. Como especializacin de este modelo
surgen los procesos iterativos como el modelo en espiral, el modelo iterativo e
incremental, el modelo basado en prototipo, el modelo MBASE (Model-Based
Architecture and Software Engineering 3) y finalmente el de mayor renombre de ellos el
Rational Unified process(RUP).4

http://en.wikipedia.org/wiki/Winston_W._Royce
http://en.wikipedia.org/wiki/MBASE
4
http://www.qualitrain.com.mx/index.php/Procesos-de-software/Evolucion-de-losprocesos-de-desarrollo-Primera-parrte/Page-3.html
3

Estos modelos hicieron un gran aporte en la historia del desarrollo al basar el

mismo en iteraciones y la construccin de la aplicacin en forma progresiva, agregando
funcionalidad paulatinamente.
Las iteraciones eran tomadas de esta forma como un mini - proyecto, el cual est
compuesto por todas las fases del desarrollo (requerimientos, anlisis, diseo,
implementacin y pruebas). Los incrementos en la aplicacin estn dados por la
funcionalidad que se va agregando al software en cada una de sus iteraciones.
Los modelos iterativos fomentan el cambio en forma temprana y proponen un
control de cambio disciplinado que permite al usuario ajustar sobre el desarrollo sus
requerimientos.
A mediados de los aos 90 como parte de una reaccin contra los modelos muy
estructurados y estrictos, extrados del modelo de desarrollo en cascada nacen las
metodologas giles.
El proceso originado del uso del modelo en cascada era visto como burocrtico,
lento, degradante e inconsistente con las formas de desarrollo de software que realmente
realizaban un trabajo eficiente. Inicialmente, los mtodos giles fueron llamados
mtodos de "peso liviano". En el ao 2001, miembros prominentes de la comunidad se
reunieron en Sonwbird, Utah, y adoptaron el nombre de "Metodologas giles". Poco
despus, algunas de estas personas formaron la "alianza gil", una organizacin sin fines
de lucro que promueve el desarrollo gil de aplicaciones.5
Muchos mtodos creados similares al gil fueron introducidos posteriormente a
la familia Agile propiamente dicha y aceptada como tal en el ao 2001. Entre los ms
notables se encuentran: Scrum(1986), Crystal Clear (cristal transparente),
programacin extrema o XP (1996), desarrollo de software adaptativo, feature driven
development, Mtodo de desarrollo de sistemas dinmicos(1995)6.
A continuacin se presenta un grfico que resume e ilustra la evolucin completa
de los desarrollos de software a lo largo del tiempo.

Figura 1 - Evolucin histrica de las metodologas de desarrollo

5
6

http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software
http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software
5

Introduccin a las metodologas giles

Frente a los numerosos problemas que se presentaban en el desarrollo de software
en las ltimas dos dcadas, expertos enunciaron numerosas notaciones de modelado y
herramientas de soporte con la intencin de que stas actuasen como "balas de plata"
para conseguir el xito en el desarrollo del software. No obstante, las expectativas no
fueron alcanzadas. Esto se debi en gran parte a que otro importante elemento a analizar
y mejorar, la metodologa de desarrollo, haba sido dejado a un lado. De nada sirvieron
las buenas notaciones y herramientas si no venan de la mano con buenas directivas para
ser aplicadas.
As, en la dcada de los aos 90 se comenz a tomar un notable inters en las
metodologas de desarrollo. Hasta no hace mucho tiempo el proceso de desarrollo
llevaba asociado consigo un marcado nfasis en el control del proceso mediante una
rigurosa definicin de actividades, roles y artefactos, incluyendo todo lo comprendido
en el modelado y una detallada documentacin del proyecto. Este enfoque tradicional
para tratar el tema del desarrollo de software result ser efectivo y necesario en
proyectos de gran escala o tamao en cuanto a tiempo y recursos, donde por lo general,
se exiga un alto grado de anlisis en el proceso.
Sin embargo este enfoque no result ser el mas adecuado para muchos de los
proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige
reducir drsticamente los tiempos de desarrollo pero manteniendo un elevado nivel de
calidad. Ante las adversidades que se presentan para utilizar metodologas tradicionales,
con tantas restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se
resignan a prescindir del buen actuar de la ingeniera del software y robusta
documentacin, asumiendo el riesgo que esto conlleva consigo.
En dicho marco, las metodologas giles nacen como una respuesta posible para
resolver este problema y llenar as ese vaco metodolgico presente. Estas metodologas
especialmente orientadas para proyectos pequeos, constituyen una solucin a medida
para entornos con dichas condiciones (proyectos pequeos), aportando una elevada
simplificacin que sin embargo, no renuncia a las buenas prcticas esenciales que
aseguran la buena calidad del producto.
Las metodologas Agile constituyen, sin duda alguna, uno de los principales
temas mas novedosos en la industria del software, que da a da van acaparando gran
inters en el mercado. Esto se ve reflejado en que estn ganando mucho espacio en la
mayora de los workshops y conferencias de los ltimos aos.
Tambin cabe destacar que las metodologas giles fueron especialmente
pensadas para proyectos con distintas caractersticas que se ajustan a un amplio rango
de proyectos de distintas industrias de desarrollo de software.

Historia de las metodologas giles

En el mes de febrero del ao 2001, 17 expertos reconocidos de la industria del
software, incluyendo algunos de los creadores o impulsores de metodologas de
software, se reunieron en Utah-EEUU para discutir varias cuestiones relacionados con
el desarrollo de aplicaciones informticas. En dicha reunin nace el trmino gil que
abarcaba una serie de principios y valores que sern explicados con mayor detalle a
continuacin.

El objetivo de dicha reunin fue esbozar los valores y principios que deberan
permitir a los equipos involucrados en un proyecto desarrollar sus tareas de forma
rpida y respondiendo a los cambios que puedan surgir a lo largo de todo el ciclo de
vida del proyecto.
Pretendan brindar una alternativa a los procesos de desarrollo de software
tradicionales, que se caracterizaban por ser rgidos y dirigidos por la documentacin que
se genera en cada una de las actividades desarrolladas.
Tras esta reunin se cre The Agile Alliance, una organizacin, sin fines de
lucro que se dedica a promover los conceptos relacionados con el desarrollo gil de
software y ayuda a las organizaciones para que adopten dichos conceptos en sus
procesos. El punto de partida de dichos valores y principios fue el Manifiesto gil. Este
documento resume la filosofa gil7.

Manifiesto gil
Los creadores del manifiesto gil 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
Dave Thomas

El manifiesto gil establece que se valora:

- Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las
herramientas.
- Desarrollar software que funciona ms que conseguir una buena documentacin.
- La colaboracin con el cliente ms que la negociacin de un contrato.
- Responder a los cambios ms que seguir estrictamente un plan.

Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las

herramientas.

Este principio es probablemente el ms importante de todos los principios del

manifiesto. Sabemos que los procesos constituyen una gran ayuda al trabajo de
desarrollo junto con las herramientas a la hora de mejorar la eficiencia. Sin embargo,
son las personas con una correcta actitud y conocimiento tcnicos quienes hacen posible
junto con dichos procesos y herramientas, alcanzar los resultados esperados. La gente
constituye el factor clave de xito en un proyecto de desarrollo de software. Es ms
importante construir un buen equipo que construir el entorno adecuado. Lo ideal es que
7

www.willydev.net/descargas/prev/TodoAgil.pdf
7

una vez que se cuente con el quipo adecuado de desarrollo, ste sea quien establezca el
entorno necesario para desarrollarse cmodamente.
Desarrollar software
documentacin.

que

funciona

ms

que

conseguir

una

buena

Si es posible, se aconseja desarrollar un prototipo o mdulos del sistema final

desarrollados para poder ver sobre ellos como han de comportarse las funcionalidades
esperadas. Esto brinda una retroalimentacin muy rica que estimula la generacin de
ideas que no habran sido posibles de concebir en una primera instancia. Difcilmente se
podr conseguir un documento que contenga requisitos detallados antes de comenzar el
proyecto. Los documentos deben ser un soporte que permita la transferencia del
conocimiento, registre informacin histrica, y que cubra las cuestiones legales o
normativas en aquellos casos que esto sea necesario; pero son menos importantes que
los productos finales en buen funcionamiento. Los documentos no pueden sustituir, ni
pueden ofrecer la riqueza y generacin de valor que se logra con la comunicacin
directa entre las personas y a travs de la interaccin con los prototipos. Por eso,
siempre que sea posible debe preferirse, y reducir al mnimo indispensable el uso de
documentacin que genera trabajo que no aporta un valor directo al producto final. Los
documentos deben ser de poco tamao y no ir ms all de lo fundamental. Deben ser
claros y concisos.
La colaboracin con el cliente ms que la negociacin de un contrato.

Como hemos dicho anteriormente, las metodologas giles estn principalmente

enfocadas en proyectos en los que los requerimientos del producto son muy difciles de
definir con detalle en los inicios del proyecto o se cree que los mismos irn cambiando
por la velocidad del entorno de desarrollo y del mismo negocio sobre el cual estn
pensados. Los contratos con el cliente no son mas que una formalidad que establece
lineamientos sobre como deben comportarse las distintas partes que lo integran. El
desarrollo gil ve al cliente como un miembro ms del equipo, que se integra y colabora
en el grupo de trabajo. Se propone que exista una interaccin constante entre el cliente y
el equipo de desarrollo ya que es precisamente esta colaboracin la que asegure el xito
del proyecto y determine la velocidad con el cual el mismo ser desarrollado.
Responder a los cambios ms que seguir estrictamente un plan.

Aqu se nos est diciendo que debemos valorar ms la capacidad de respuesta

frente a los cambios que puedan surgir por encima de la capacidad de seguimiento y
aseguramiento de planes establecidos con anterioridad. En la actualidad es muy comn
encontrarse con entornos inestables, que tienen como factor inherente al cambio y la
evolucin rpida y continua. Es importante analizar como el quipo responde en dicho
entorno y la preparacin con la que cuenta para responder a los cambios que se
presenten. La planificacin en un proyecto no debe ser estricta sino flexible y abierta ya
que la habilidad de responder a estos cambios, ya sean cambios de requerimientos, de
tecnologa, o en el equipo a cargo del proyecto, son los que determinarn tambin el
xito o fracaso del proyecto.

Los 12 principios giles

Basados en los valores anteriores enunciados se han formulado los doce principios
que componen el manifiesto gil. Estos son caractersticas comunes que deben tener
todos los procesos giles y que los diferencian de los procesos tradicionales.

1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas

de software que le aporte un valor.

Este principio establece que se deben realizar pequeas entregas al cliente para
que ste vaya viendo el estado del proyecto y pueda comunicar su satisfaccin o
descontento frente a las expectativas sobre el sistema. Las entregas realizadas a las
pocas semanas de empezado el proyecto, facilitan la comprensin de los requerimientos
del cliente. El cliente luego decide si pone en marcha dicho software con la
funcionalidad que ahora ste le proporciona o simplemente lo revisa e informa los
posibles cambios que desea que se realicen.
2. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente
tenga una ventaja competitiva.

Los cambios de requerimientos son algo inevitable en todo proyecto de desarrollo.

Dichos cambios deben ser vistos como algo positivo por parte del equipo. Esta actitud
lleva al equipo a adquirir nuevos conocimientos, y a la vez, a lograr una mayor
satisfaccin por parte del cliente. Este principio implica adems que la estructura del
software debe ser flexible para poder incorporar los cambios sin demasiado costo
aadido y sin que estos cambios corrompan el software o partes del mismo ya
producidas. Hace que las componentes de software se vuelvan reutilizables y mas
independientes entre s.
3. Entregar frecuentemente software que funcione desde un par de semanas a
un par de meses, con el menor intervalo de tiempo posible entre entregas.

Este principio nos dice que debemos tratar de hacer entregas pequeas en cortos
plazos y no dejar pasar grandes intervalos de tiempo entre una entrega y la siguiente.
Este principio hace nfasis en la entrega de componentes de software en lugar de
componentes de planificacin o documentacin, ya sea de anlisis o de diseo.
4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del
proyecto.

La interaccin con el cliente constituye una pieza clave del desarrollo del
proyecto. Este principio nos dice que tanto cliente como equipo deben trabajar
conjuntamente para facilitar la comunicacin y asegurar as el xito del proyecto.
5. 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.

Las mitologas giles establecen que las personas asignadas al proyecto

constituyen el principal factor de xito. Todo los dems (proceso, entorno, gestin, etc.)
pasan a estar en segundo plano. Si cualquiera de ellos tiene un efecto negativo sobre los
individuos debe ser cambiado. Es muy importante que las personas se encuentren en un
ambiente cmodo ya que esto contribuir a que desarrollen sus tareas correctamente
obteniendo un mayor rendimiento.

6. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar

informacin dentro de un equipo de desarrollo.

Los miembros del equipo deben hablar entre ellos y con el cliente constantemente.
Si bien pueden existir otras formas de comunicacin como los documentos, no toda la
informacin necesaria estar comprendida en ellos. Es por esto que la comunicacin
oral debe ser la principal forma de comunicacin.
7. El software que funciona es la medida principal de progreso.

El estado de un proyecto no se puede medir por la documentacin generada o la

fase en la que el mismo se encuentre. Slo el cdigo generado y en funcionamiento
sern los que dirn efectivamente en que estado se encuentra el proyecto.
8. Los procesos giles promueven un desarrollo sostenible. Los promotores,
desarrolladores y usuarios deberan ser capaces de mantener una paz
constante.

Este principio nos dice que debe mantenerse un ritmo constante de desarrollo
durante todo el proyecto en lugar de tratar de desarrollar lo ms rpido posible. Esto
asegurar una mayor calidad en el producto final.
9. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad.

Un buen diseo nos llevar a la produccin de un cdigo ms claro y robusto, lo

cual constituye la clave para avanzar ms rpidamente en el proyecto.
10. La simplicidad es esencial.

Un cdigo simple y de alta calidad siempre es ms sencillo de leer y adaptar a los

cambios que puedan surgir. Siempre debe intentarse tomar el camino ms simples que
consistente con los objetivos perseguidos.
11. Las mejores arquitecturas, requisitos y diseos surgen de los equipos
organizados por s mismos.

Los requerimientos son entregados al equipo quedando todos sus miembros al

tanto de los mismos. El equipo es quien decide la mejor forma de organizarse, de
acuerdo a los objetivos que se persigan asignando a cada miembro la tarea que mejor se
adapte a su perfil.
12. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser
ms efectivo, y segn esto ajusta su comportamiento.

Debido a los constantes cambios del entorno, el equipo tambin debe adaptarse al
nuevo escenario de forma continua para poder realizar las modificaciones necesarias
para poder trabajar correctamente y conseguir buenos resultados. Puede realizar
cambios en su organizacin, sus reglas, sus convenciones, sus relaciones, etc., y de sta
forma seguir siendo gil.

Distintas Metodologas giles

Aunque los creadores e impulsores de las metodologas giles ms populares han
suscrito el manifiesto gil y coinciden con los principios enunciados anteriormente, cada
10

metodologa tiene caractersticas propias y hace hincapi en algunos aspectos ms

especficos. A continuacin se resumen dichas metodologas giles, dejando el anlisis
ms detallado de XP para la siguiente seccin.

Extreme Programming: XP
Es el proceso gil ms popular y utilizado de todas las metodologas giles. Esta
metodologa pone mayor nfasis en la colaboracin, en la rpida y temprana entrega de
componentes de software y en prcticas de desarrollo simples. Sus prcticas
establecidas core son: un equipo trabajando en un mismo ambiente, pair programming
(programacin de a pares), uso constante de y la promocin del desarrollo orientado al
testing (realizar pruebas antes de programar). Hablaremos de xp con mayor detalle a lo
largo del trabajo.
Scrum
Metodologa desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. La
misma establece un marco para el management o gestin de proyectos, que ha sido
empleado con xito durante los ltimos 10 aos. Se encuentra principalmente dirigida
para proyectos que cuentan con un rpido cambio de requerimientos o requerimientos
inestables que presentan difcultades a la hora de ser definidos. Sus principales
caractersticas son el desarrollo de software iterativo y las reuniones diarias. El
desarrollo iterativo establece que el desarrollo de software se debe realizar mediante
iteraciones, denominadas sprints, que son de corta duracin, aproximadamente de unos
30 das. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente
junto con el resto de los stakeholders. Las reuniones diarias se realizan a lo largo de
todo el proyecto se realizan reuniones diarias que poseen una duracin de
aproximadamente 15 minutos. En ellas participa todo el equipo de desarrollo junto con
el cliente o un representante del mismo quienes conjuntamente coordinan e integran el
proyecto.

Crystal Methodologies
Las metodologas Crystal para el desarrollo de software se caracterizan por
estar focalizadas en las personas que componen el equipo de desarrollo, de quienes
depende el verdadero xito del proyecto; as como en la reduccin al mximo del
nmero de artefactos producidos en un tiempo determinado. Las mismas fueron
desarrolladas por Alistair Cockburn. Esta metodologa ve al desarrollo de software
como un juego cooperativo de invencin y comunicacin, limitado por los recursos a
utilizar8. El equipo de desarrollo constituye una pieza clave en el proceso, por lo que
8

http://www.willydev.net/descargas/prev/TodoAgil.pdf
11

han de ser invertidos grandes esfuerzos en mejorar sus habilidades y destrezas (tanto
conocimientos tcnicos como aptitudes personales); as como tener polticas bien
definidas de trabajo grupal. Estas polticas dependern del tamao del equipo,
establecindose una clasificacin por colores, por ejemplo Crystal Clear en el caso que
el equipo cuente con un nmero de entre 3 y 8 miembros; y Crystal Orange en el caso
que este compuesto por un nmero de entre 25 y 50 miembros.

Dynamic Systems Development Method: DSDM

Define el marco para desarrollar un proceso de produccin de software. Nace en
1994 con el objetivo de crear una metodologa RAD unificada. Sus principales
caractersticas son: es un proceso iterativo e incremental y el equipo de desarrollo y el
usuario trabajan juntos. Propone cinco fases: estudio de viabilidad, estudio del negocio,
modelado funcional, diseo y construccin, y finalmente implementacin. Las tres
ltimas son iterativas, adems de existir realimentacin a todas las fases.
Adaptive Software Development: ASD
Esta metodologa fue impulsada por Jim Highsmith. Se encuentra inspirada en
sistemas de alta complejidad que cuenta con una fuerte adaptabilidad y mtodos de
desarrollo con rpida aplicacin. Sus principales caractersticas son que es iterativo,
orientado a las componentes de software ms que a las tareas y tolerante a los cambios.
El ciclo de vida que propone esta formado por tres fases principales: especulacin,
colaboracin y aprendizaje. En la primera de ellas el proyecto es iniciado y se planifican
las funcionalidades o caractersticas que tendr el software; en la segunda se desarrollan
dichas funcionalidades y finalmente en la tercera se revisa la calidad de lo
implementado, y se lo entrega al cliente. La revisin de las componentes sirve para
aprender de los errores y volver a iniciar el ciclo de desarrollo contando con un mayor
conocimiento por parte de todos los integrantes del equipo.
Feature-Driven Development: FDD
Esta metodologa creada por Jeff De Luca y Peter Coad establece que el desarrollo
debe originarse a partir del domino o modelo de negocio. Define un proceso iterativo
que consta de 5 pasos: desarrollar un modelo general, crear la lista de caractersticas o
funcionalidades que debe tener el sistema, realizar un plan de desarrollo acorde a la lista
de funcionalidades, realizar el diseo para dichas funcionalidades, y finalmente,
implementar dichas funcionalidades.
Las iteraciones son cortas, de una plazo de hasta 2 semanas. Se concentra en las fases de
diseo e implementacin del sistema, partiendo de una lista de requerimientos
principales que debe reunir el software.

12

Lean Development : LD
Lean Development es un metodologa pensada por Bob Charettes a partir de
su trabajo realizado en proyectos relacionados con la industria automotriz japonesa en la
dcada de los 80. Fue utilizada en numerosos proyectos del rea de telecomunicaciones
en toda Europa. En ella, los cambios se consideran riesgos, pero si se manejan
adecuadamente se pueden convertir en oportunidades que mejoren la productividad del
equipo as como la calidad del producto. Su principal caracterstica es introducir un
mecanismo para implementar dichos cambios sin que impacte de forma negativa en las
componentes previamente desarrolladas del sistema.
A continuacin se presenta una tabla en la que se compara las distintas
aproximaciones giles en base a tres parmetros: vista del sistema como algo cambiante,
tener en cuenta la colaboracin entre los miembros del equipo y caractersticas ms
especficas de la propia metodologa (CM) como son los resultados, la simplicidad, la
excelencia tcnica, adaptabilidad, etc.
Tambin incorpora como referencia no gil el Capability Madurity Model
(CMM).
Los valores ms altos representan una mayor agilidad.

Figura 3 Tabla de Ranking de agilidad

Como se puede observar en la Figura 3, todas las metodologas giles tienen una
significativa diferencia del ndice de agilidad respecto a CMM y entre ellas destacan
ASD, Scrum y XP como las ms giles a nivel general. Asimismo se puede observar que
XP, ASD y Scrum presentan los mayores valores con respecto a la adaptacin de los
cambios dentro del sistema. Lo mismo ocurre con la colaboracin y los resultados
obtenidos en donde se les suma a la lista Crystal.
Ahora bien, si observamos la grilla verticalmente, podremos notar que XP y ASD
son las metodologas con mayor nivel de agilidad de todas ya que poseen cinco de los
9

http://www.cyta.com.ar/ta0502/v5n2a1.htm
13

sietes aspectos analizados con el mayor valor posible de agilidad. Luego con un nivel
inferior pero an as elevado de agilidad les siguen Cristal y Scrum.
Como podemos ver XP presenta notables ventajas con respecto a las otras
metodologas de desarrollo y son estas ventajas las que precisamente lo posesionan
fuertemente dentro de la familia Agile as como en el actual mercado de la informtica.

14

Introduccin a eXtreme Programming

A continuacin realizaremos un detallado estudio de la metodologa Extreme
Programming. La misma constituye el ms destacado de los procesos giles de
desarrollo de software, es la metodologa ms utilizada en el mercado laboral y cuenta
con una notable adaptacin y flexibilidad frente a los distintos tipos de proyecto.

Su creador: Kent Beck

10

Figura 4 - Kent Beck, Autor de XP

Aunque la creacin de la metodologa XP es atribuida tanto a Kent Beck como a

Ron Jeffries y Ward Cinningham, se hable de Beck como el padre y mayor
influenciador de la misma. Kent Beck tambin cre, junto con Erich Gamma el
framework de pruebas unitarias para Java conocido como JUnit. Es el fundador y
director de Three Rivers Institute (TRI). Su carrera combina la prctica de desarrollo
de software con reflexin, innovacin y comunicacin.
Es el author/co-author de numerosos libros como: Implementation Patterns11,
Extreme Programming Explained: Embrace Change 2nd Edition 12, Contributing to
Eclipse13, Test-Driven Development: By Example 14, Planning Extreme

10

http://images.google.com.ar
2008. Implementation Patterns. Addison-Wesley.
12
1999. Extreme Programming Explained: Embrace Change. Addison-Wesley.
13
2003. Contributing to Eclipse: Principles, Patterns, and Plugins. With Erich Gamma.
Addison-Wesley.
14
2002. Test-Driven Development: By Example. Addison-Wesley. Winner of the Jolt
Productivity Award.
11

15

Programming15, Smalltalk Best Practice Patterns16, and the JUnit Pocket Guide17.
Obtuvo sus ttulos en Computer Science (Ciencias de la computacin) en la
Universidad de Oregon. Sus actividades de negocio incluyen: contract programming
utilizando Java/Eclipse, writing, consulting y presentacin de workshops con su
compaera Cynthia Andres.
En la actualidad Beck divide su tiempo entre la escritura, la programacin y el
entrenamiento.
Su contribucin al desarrollo de software incluye patrones, el redescubrimiento
de:

Test-first programming
Es una metodologa basada en las pruebas unitarias como parte vital y buena
prctica del desarrollo de software. La misma establece que previamente a realizar la
implementacin del sistema deben realizarse dichas pruebas y slo teniendo la totalidad
de ellas aprobadas podr comenzarse entonces a desarrollar el cdigo fuente.
Esta metodologa cuenta con la particularidad de ser a su vez parte de otras
metodologas (XP y TDD Test driven Development).

xUnit
Es un framework de pruebas conducido por cdigo que ha llegado a conocerse
colectivamente y tomado gran importancia en los ltimos tiempos. Dicho framework
esta basado en un diseo de Kent Beck, implementado originalmente para Smalltalk.
Actualmente, se encuentra disponible para muchos lenguajes de programacin y
plataformas de desarrollo.
Finalmente, su mayor aporte al mundo de la informtica: Extreme
Programming, metodologa de la cual hablaremos con mayor detalle posteriormente.

Descripcin de la Metodologa: XP detallado

Extreme Programming es una metodologa gil basada en cuatro principios:
simplicidad, comunicacin, retroalimentacin y valor.
Al hablar de simplicidad, nos referimos a la simplicidad aplicada a todos los
aspectos del proyecto, desde la forma de trabajar en s, plasmada en los procesos y las
prcticas aplicadas al implementar las soluciones, as como a la simplicidad del cdigo
que facilita su lectura, correccin y extensin entre los distintos programadores.
En cuanto a la comunicacin, XP plantea que debe existir una comunicacin
fluida entre todos los participantes del proyecto lo cual mejorar tantos los tiempos del
proyecto as como la calidad del producto.
Con respecto a la retroalimentacin, XP nos dice que debe existir una
retroalimentacin continua entre el cliente y el equipo de desarrollo, lo cual facilitar en
15

2000. Planning Extreme Programming. With Martin Fowler. Addison-Wesley.

1996. Smalltalk Best Practice Patterns. Prentice Hall.
17
2004. JUnit Pocket Guide. O'Reilly.
16

16

forma notable el trabajo y desarrollo del proyecto.

Extreme Programming es una metodologa centrada en potenciar las relaciones
interpersonales como clave para el xito en desarrollo de software, promoviendo el
trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y
propiciando un buen clima de trabajo.
XP se define como una metodologa especialmente adecuada para proyectos en
donde los requisitos an son muy ambiguos o imprecisos, cambian rpidamente, o
donde existe un alto riesgo tcnico.
Los principios y prcticas son principios y prcticas de sentido comn, usualmente
aplicados en numerosas metodologas, pero aqu se diferencian en que son llevados al
extremo, de ah proviene su nombre Extreme Programming.
A continuacin presentaremos las caractersticas esenciales de XP.

Actividades de Xp
La metodologa cuenta con cuatro actividades bsicas y esenciales: escuchar,
disear, codificar y hacer pruebas. A continuacin se describen las mismas.

Escuchar
Beck menciona en una frase que los programadores no lo conocen todo, y sobre
todo desconocen muchas cosas que las personas de negocios piensan que son
interesantes.
Al realizar las pruebas sobre el sistema es necesario preguntar si los resultados
obtenidos son los deseados, es decir, se debe preguntar al cliente si era precisamente lo
obtenido lo que l estaba buscando por parte del software. Es necesario escuchar por
parte de los clientes cules son los problemas que presenta su negocio. Se debe tener
una escucha activa, explicando lo que es fcil y lo que es difcil de obtener a la hora de
desarrollar el sistema. La retroalimentacin entre ambas partes (cliente y equipo de
desarrollo) ser la que brindar la mayor ayuda a todos a la hora de entender los
problemas existentes a resolver. Es por ello que el equipo del proyecto debe estar
continuamente atento a lo que el cliente esta diciendo y debe hacerse escuchar por parte
del mismo a la hora de proponer nuevas soluciones.

Disear
El diseo moldea la estructura que ordenar la lgica de la aplicacin. Un correcto
diseo brinda la posibilidad de que el sistema crezca con cambios en un solo lugar, lo
hace extensible y reutilizable. Los diseos deben de ser sencillos, si alguna parte del
sistema es de desarrollo complejo, lo apropiado es dividirla en varias partes. Si hay
fallas en el diseo o malos diseos, estas deben ser corregidas cuanto antes porque de lo
contrario se vern plasmadas en el producto disminuyendo su calidad o en ocasiones, no
cumpliendo los requerimientos para los cuales ha sido creado el producto.

17

Codificar
El proceso de codificacin se basa en plasmar las ideas y funcionalidades del
sistema a travs del cdigo. En programacin, el cdigo expresa la interpretacin del
problema en trmino de los programadores. De esta forma podemos utilizar el cdigo
para comunicar, para hacer comunes las ideas y tambin para aprender y mejorar el
nivel de los mismos recursos involucrados en el desarrollo del proyecto. El cdigo es el
idioma de comunicacin de los programadores. Es por ellos que se recomienda que el
mismo sea sencillo y legible para todos los integrantes del equipo.

Hacer pruebas
Todas las caractersticas del software que muestran su correcto funcionamiento
deben ser demostradas mediante pruebas. Las pruebas brindan la oportunidad de saber
si lo implementado es lo que en verdad se tena en mente por parte del cliente. Las
pruebas son las que nos indican que el trabajo, es decir el propio sistema se encuentra
funcionando en perfectas condiciones. Cuando no es posible pensar en ninguna prueba
que pueda originar una falla en el sistema, entonces se da por finalizado el proceso de
testing o prueba del sistema. Es importante destacar que a la hora de realizar las pruebas
es importante la objetividad de dichas pruebas y que las mismas sean realizadas desde el
punto de vista del usuario. Es por ello que es recomendable que no sean realizadas por
los mismos programadores. Recordemos que al hablar de pruebas en este apartado
hacemos referencia a pruebas de testeo posterior al desarrollo del cdigo y no a las
pruebas unitarias realizadas previamente al desarrollo.
Resumiendo las actividades de Xp: Debe codificarse porque sin cdigo no hay
programas, se deben hacer pruebas de testeo porque sin pruebas no es posible
determinar si se ha acabado de codificar, se debe escuchar, porque si no hay escucha no
existe forma de saber que codificar ni probar, y finalmente se tiene que disear para
poder codificar, probar y prestar una mejor atencin para poder focalizar la escucha en
los puntos crticos o poco definidos del proyecto.

Proceso XP
Un proyecto XP tiene xito cuando el equipo de desarrollo cumple con todos las
expectativas del cliente, es decir el producto final realiza todo aquello para lo que fue
pensado. Para poder llevar a cabo esto, el cliente debe seleccionar el valor de negocio a
implementar (funcionalidad) basndose en la habilidad del equipo para medir la
funcionalidad que puede entregar dentro de un determinado perodo de tiempo. Es decir,
el cliente prioriza las funcionalidades y las agrupa acorde a la capacidad del equipo y la
importancia que stas poseen para l.
El ciclo de desarrollo de una iteracin consiste (a grandes rasgos) en los siguientes
pasos:

18

1. El cliente define el valor de negocio a implementar.

2. El programador estima el esfuerzo necesario para su implementacin.
3. El cliente selecciona qu construir, de acuerdo con sus prioridades y las
restricciones de tiempo que presenta el equipo junto con el entorno de desarrollo.
4. El programador construye ese valor de negocio.
5. Se vuelve al paso 1.
En todos los release o iteraciones tanto el programador como el cliente aprenden
de sus errores. El desarrollador no debe ser presionado para hacer una mayor cantidad
de trabajo que la estimada previamente, ya que no slo se perder calidad en el software
o no se cumplirn los plazos; sino que tambin podra haber una desmotivacin en el
mismo y su rendimiento en las prximas iteraciones podra llegar a disminuir. De la
misma forma el cliente tiene la obligacin de manejar el mbito de entrega del producto,
para asegurarse que el sistema tenga el mayor valor de negocio posible con cada
iteracin.

Prcticas XP
Uno de los principales anlisis que se realiza en XP es el estudio de la reduccin
de los costos que acarrean los cambios a lo largo de todo el proyecto. Se trata de
llevarlos a valores de forma tal que el diseo evolutivo funcione ptimamente. XP
apuesta por un crecimiento lento del costo del cambio con un comportamiento
asinttico; es decir, trata de reducir los costos de la mayor forma posible hasta llevarlos
a su valor mnimo y que estos permanezcan constantes en dicho valor. Esto es posible
de conseguir gracias a las tecnologas disponibles para ayudar en el desarrollo de
software y a la aplicacin disciplinada de las prcticas que describiremos a
continuacin.

El juego de la planificacin
Es un espacio frecuente de comunicacin entre el cliente y los programadores. El
equipo tcnico realiza una estimacin del esfuerzo requerido para la implementacin de
las historias de usuario y los clientes deciden sobre el mbito y tiempo de las entregas y
de cada iteracin. Esta prctica 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 segn prioridad y esfuerzo, y se define el contenido de la entrega y/o iteracin,
apostando por enfrentar lo de ms valor y riesgo cuanto antes. Este juego se realiza
durante la planificacin de la entrega, en la planificacin de cada iteracin y cuando sea
necesario reconducir el proyecto.

Entregas pequeas
La idea es producir rpidamente versiones del sistema que sean operativas, aunque
obviamente no cuenten con toda la funcionalidad pretendida para el sistema pero si que

19

constituyan un resultado de valor para el negocio. Una entrega no debera tardar ms 3

meses.

Metfora
En XP no se enfatiza la definicin temprana de una arquitectura estable para el
sistema. Dicha arquitectura se asume en forma evolutiva. Los posibles inconvenientes
que se generarn por no contar con ella explcitamente en el comienzo del proyecto se
solventan con la existencia de una metfora. El sistema es definido mediante una
metfora o un conjunto de metforas compartidas por el cliente y el equipo de
desarrollo. Una metfora es una historia compartida que describe cmo debera
funcionar el sistema. Martn Fowler18 explica que la prctica de la metfora consiste en
formar un conjunto de nombres que acten como vocabulario para hablar sobre el
dominio del problema. Este conjunto de nombres ayuda a la nomenclatura de clases y
mtodos del sistema. Esta prctica simplemente nos dice que a la hora de abordar un
problema complejo, debemos atacar al mismo estableciendo una analoga entre dicha
problemtica y una historia o situacin que nos permita visualizarla y resolverla con una
mayor facilidad.

Diseo simple
Se debe disear la solucin ms simple que pueda funcionar y ser implementada
en un momento determinado del proyecto. La complejidad innecesaria y el cdigo extra
debe ser removido inmediatamente. Kent Beck dice que en cualquier momento el diseo
adecuado para el software es aquel que: supera con xito todas las pruebas, no tiene
lgica duplicada, refleja claramente la intencin de implementacin de los
programadores y tiene el menor nmero posible de clases y mtodos. 19

Pruebas
La produccin de cdigo est dirigida por las pruebas unitarias. Las pruebas
unitarias son establecidas antes de escribir el cdigo y son ejecutadas constantemente
ante cada modificacin 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 automatizacin para apoyar esta actividad es
crucial.

Refactorizacin (Refactoring)
La refactorizacin es una actividad constante de reestructuracin del cdigo con el
objetivo de remover duplicacin de cdigo, mejorar su legibilidad, simplificarlo y
hacerlo ms flexible para facilitar los posteriores cambios. La refactorizacin mejora la
18
19

http://martinfowler.com/
http://www.cyta.com.ar/ta0502/v5n2a1.htm
20

estructura interna del cdigo sin alterar su comportamiento externo. Robert Martn 20
seala que el diseo del sistema de software es una cosa viviente. No se puede imponer
todo en un inicio, pero en el transcurso del tiempo este diseo evoluciona conforme
cambia la funcionalidad del sistema. Para mantener un diseo apropiado, es necesario
realizar actividades de cuidado continuo durante el ciclo de vida del proyecto.
De hecho, este cuidado continuo sobre el diseo es incluso ms importante que el
diseo inicial. Un concepto pobre al inicio puede ser corregido con esta actividad
continua, pero sin ella, un buen diseo inicial se degradar.

Programacin en parejas
Toda la produccin de cdigo debe realizarse con trabajo en parejas de
programadores.
Las principales ventajas de introducir este estilo de programacin son:
- Una gran cantidad de errores son detectados conforme son introducidos los
distintos mdulos desarrollados. Se realizan inspecciones de cdigo continuas,
por consiguiente la tasa de errores del producto final es ms baja.
- Los diseos son mejores y el tamao del cdigo es menor (continua discusin de
ideas de los programadores).
- Los problemas de programacin se resuelven ms rpidamente.
- Se posibilita la transferencia de conocimientos de programacin entre los
miembros del equipo.
- Varias personas entienden las diferentes partes sistema
- Los programadores conversan mejorando as el flujo de la informacin y la
dinmica del equipo.
- Los programadores disfrutan ms su trabajo.
Dichos beneficios se consiguen despus de varios meses de practicar la
programacin en parejas. Se estima que este lapso de tiempo vara de 3 a 4 meses.

Propiedad colectiva del cdigo

Esta prctica establece que cualquier programador puede tener acceso y cambiar
cualquier parte del cdigo en cualquier momento que as lo desee. Esta prctica motiva
a todos a contribuir con nuevas ideas en todos los segmentos del sistema, evitando a la
vez que algn programador sea imprescindible para realizar cambios en alguna porcin
de cdigo.

Integracin continua
Cada pieza de cdigo 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 da. Todas
las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo cdigo sea
20

http://www.objectmentor.com/omTeam/martin_r.html
21

incorporado definitivamente. La integracin continua a menudo reduce la fragmentacin

de los esfuerzos de los desarrolladores por falta de comunicacin sobre lo que puede ser
reutilizado o compartido. Varios expertos de la informtica afirman que el desarrollo de
un proceso disciplinado y automatizado es esencial para un proyecto controlado. De esta
forma, el equipo de desarrollo est ms preparado para modificar el cdigo cuando sea
necesario debido a la confianza en la identificacin y correccin de los errores de
integracin.

40 horas por semana

Esta prctica establece que se debe trabajar un mximo de 40 horas por semana.
No se deben asimismo trabajar 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 planificacin para cambiar el mbito del proyecto o la fecha de
entrega.

Cliente on-site
En esta prctica se establece que el cliente debe estar presente y disponible en
todo momento para el equipo de desarrollo. 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 de esta forma, los programadores pueden resolver de manera
inmediata cualquier duda asociada. La comunicacin oral es ms efectiva que la escrita,
ya que esta ltima toma mucho tiempo en generarse y puede tener ms riesgo de ser mal
interpretada. En caso de que el cliente no cuente con dicha disponibilidad necesaria, se
recomienda lo siguiente: intentar conseguir un representante que pueda estar siempre
disponible y que acte como interlocutor del cliente, contar con el cliente al menos en
las reuniones de planificacin, establecer visitas frecuentes de los programadores al
cliente para validar el sistema, anticiparse a los problemas asociados estableciendo
llamadas telefnicas frecuentes y conferencias reforzando el compromiso de trabajo en
equipo.

Estndares de programacin
XP enfatiza la comunicacin de los programadores a travs del cdigo, con lo cual
es indispensable que se sigan ciertos estndares de programacin (del equipo, de la
organizacin u otros estndares reconocidos para los lenguajes de programacin
utilizados). Los estndares de programacin mantienen el cdigo legible para los
miembros del equipo, facilitando los cambios.

Comentarios respecto de las prcticas

El mayor beneficio de las prcticas se consigue con su aplicacin conjunta y
22

equilibrada puesto que se apoyan unas en otras.

La mayora de las prcticas propuestas por XP no son novedosas sino que en
alguna forma ya haban sido propuestas en ingeniera del software e incluso demostrado
su valor en la prctica. El mrito 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.
A continuacin se presenta un grfico que muestra como funciona el circuito de
una iteracin as como el refuerzo que ejercen las prcticas entre s.

21

Figura 5 - Interaccin entre las prcticas de XP

Inicialmente se realiza un Release Plan el cual esta determinado por la

cantidad de User stories que integrarn la iteracin. ste junto con las fallas
encontradas y el proyecto de velocidad de la prxima iteracin se integran para
confeccionar el Plan de Iteracin. Recordemos que en el caso de la primera iteracin las
fallas encontradas y el plan de la prxima iteracin sern vacos. Una vez finalizado el
plan de iteracin se procede a desarrollar las funcionalidades o user stories
establecidas para dicha iteracin. As se obtiene la primera versin de la aplicacin.
Luego se testea el trabajo realizado y se documentan las fallas encontradas y se reinicia
21

http://www.extremeprogramming.org/
23

el proceso entero con los problemas a resolver (Bugs), nuevas funcionalidades y se

guardan las tareas no completadas para la instancia de la planificacin de Plan.

Artefactos XP
Las Historias de Usuario
Las historias de usuario son la tcnica utilizada en XP para especificar los
requisitos del software. Estas constituyen el artefacto ms importante de XP. Se trata de
tarjetas de papel en las cuales el cliente describe brevemente las caractersticas que el
sistema debe poseer, sean requisitos funcionales o no funcionales.
El tratamiento de las historias de usuario es muy dinmico y flexible, en cualquier
momento del proyecto las historias de usuario pueden romperse en varias historias de
usuario, reemplazarse por otras ms especficas o generales, aadirse nuevas o ser
modificadas. Cada historia de usuario es lo suficientemente comprensible y delimitada
para que los programadores puedan implementarla en solo unas semanas.
Respecto de la informacin contenida en la historia de usuario, existen varias
plantillas sugeridas pero no existe un consenso al respecto. En muchos casos slo se
propone utilizar un nombre y una descripcin o slo una descripcin, ms quizs una
estimacin de esfuerzo en das. Beck en su libro presenta un ejemplo de ficha (customer
story and task card) en la cual pueden reconocerse los siguientes contenidos: fecha, tipo
de actividad (nueva, correccin, mejora), prueba funcional, nmero de historia,
prioridad tcnica y del cliente, referencia a otra historia previa, riesgo, estimacin
tcnica, descripcin, notas y una lista de seguimiento con la fecha, estado de cosas por
terminar y comentarios.
Una de los interrogantes (que tambin se presenta cuando se utilizan casos de uso)
es: Cul es el nivel de granularidad adecuado para una historia de usuario?
Desafortunadamente no existe una respuesta tajante a este interrogante. Jeffries dice que
depende de la complejidad del sistema aunque establece que debe haber al menos una
historia por cada caracterstica importante del mismo, y propone realizar una o dos
historias por programador en un perodo de un mes. Si se tienen menos, probablemente
sea conveniente dividir las historias en varias; si se tienen ms, por el contrario, lo
mejor es disminuir el detalle y agruparlas. Para efectos de planificacin, las historias
pueden ser de una a tres semanas en tiempo de programacin (para no superar el
tamao de una iteracin, recordemos que en XP las iteraciones son de corta duracin).
No hay que preocuparse si en un principio no se identifican todas las historias de
usuario. Al comienzo de cada iteracin estarn registrados los cambios en las historias
de usuario y segn eso se planificar la siguiente iteracin.
Las historias de usuario son descompuestas en tareas de programacin y asignadas
a los programadores para ser implementadas durante una iteracin.

Task Cards
Como hemos mencionado anteriormente las historias de usuario se encuentran
compuestas por distintas tareas. Para brindar informacin acerca de las mismas, se
24

utilizan las denominadas Task Cards.Si bien tampoco existe una plantilla o template
especfico para las mismas se recomiendan que contengan la siguiente informacin: el
numero de tarea, la historia de usuario a la que hacen referencia, el nombre de la tarea,
el tipo de tarea (si es de desarrollo, de correccin, de mejora, o algn otro tipo de tarea
especfico), los puntos estimados, una fecha de inicio, una fecha de finalizacin, el
programador responsable de ella, y una breve descripcin de la tarea (en que consiste la
misma).

CRC Card
Estas tarjetas pueden ser tambin denominadas: tarjetas de clase-responsabilidadcolaboracin. Estas tarjetas se dividen en tres secciones que contienen la informacin
del nombre de la clase, sus responsabilidades y sus colaboradores.
Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte. Las
responsabilidades de una clase son las cosas que conoce y las que realiza, sus atributos y
mtodos. Los colaboradores de una clase son las dems clases con las que trabaja en
conjunto para llevar a cabo sus responsabilidades.
En la prctica conviene tener pequeas tarjetas de cartn, que se llenarn y que
son mostradas al cliente, de manera que se pueda llegar a un acuerdo sobre la validez de
las abstracciones propuestas.
Los pasos a seguir para llenar las tarjetas son los siguientes:
- Encontrar clases
- Encontrar responsabilidades
- Definir colaboradores
- Disponer las tarjetas
Para encontrar las clases debemos pensar qu cosas interactan con el sistema (en
nuestro caso el usuario), y qu cosas son parte del sistema, as como las pantallas tiles
a la aplicacin (un despliegue de datos, una entrada de parmetros y una pantalla
general, entre otros). Una vez que las clases principales han sido encontradas se procede
a buscar los atributos y las responsabilidades. Para esto se puede formular la siguiente
pregunta: Qu sabe la clase? y Qu hace o como queremos que se comporte la clase?
Finalmente se buscan los colaboradores dentro de la lista de clases que se tenga es decir
quienes queremos que interacten con cada clase.

Roles XP
Segn Kent Beck existen los siguientes distintos roles involucrados en un
desarrollo basado en la metodologa extreme programming:

25

Programador
El programador es el encargado de escribir las pruebas unitarias y producir el
cdigo de la aplicacin. El cdigo debe ser legible por los distintos programadores del
equipo y es recomendable una buena comunicacin, coordinacin y colaboracin entre
los distintos programadores y los otros miembros del equipo.

Cliente
El cliente es el encargado de escribir las historias de usuario y las pruebas
funcionales para validar su implementacin. Adems, es quien prioriza las historias de
usuario y decide cules han de ser implementadas en cada una de las iteraciones
centrndose en el mayor valor que stas le brindan al negocio. Al hablar de cliente
hacemos referencia al cliente propiamente dicho o a su representante en aquellos casos
que el propio cliente no pueda realizar dichas tareas.

Encargado de pruebas (Tester)

Los testers son aquellos que colaboran con el cliente para escribir las pruebas
funcionales, ejecuta las pruebas regularmente, difunde los resultados obtenidos por
dichas pruebas con el equipo y en ocasiones toma las decisiones de las herramientas que
se utilizarn para realizar las pruebas de la aplicacin.

Encargado de seguimiento (Tracker)

El tracker es el encargado de verificar el cumplimiento o grado de acierto entre las
estimaciones realizadas y el tiempo real dedicado al proyecto. l es quien comunica los
resultados al resto del equipo para que luego los mismos puedan mejorar las 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 con los que se
cuenta. El es el que estar a cargo de la determinacin de si es necesario realizar algn
cambio general en el ambiente para lograr los objetivos planteados de cada iteracin por
parte el equipo.

26

Entrenador (Coach)
Es coach es el responsable del proceso global. Es quien posee mayores
conocimientos sobre el proceso de la metodologa (extreme programming) y quien
provee las guas a los miembros del equipo de forma que se apliquen correctamente
todas las prcticas XP y se siga el proceso adecuadamente.

Consultor
El 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. Los consultores son llamados en ocasiones especiales donde existe alguna
problemtica (ya sea tcnica o de lgica del negocio) que el equipo no puede resolver.

Gestor (Big boss)

El Big boss es el intermediario entre el cliente y los programadores, ayuda a que
el equipo trabaje efectivamente creando las condiciones adecuadas para esto. Su labor
esencial es de coordinacin.

Casos de estudio en los que se utilizo Extreme Programming

A continuacin se presentan algunos casos de estudio en los que se ha utilizado la
metodologa. Los mismos atacan distintas problemticas que se dan normalmente en un
proyecto de desarrollo de software. Estos artculos han sido seleccionados por la
magnitud de la problemtica que atacaban y por la importancia que aportaban para el
anlisis de la implementacin de la metodologa XP a la materia Laboratorio III de la
universidad.

The impact of Agile Methods on Software Project Management

(El impacto de los mtodos giles en la gestin de proyectos)

Tema principal: Este artculo trata sobre el estudio de los distintos factores:
personas, proyecto y proceso, para evaluar la conveniencia de la utilizacin de XP como
metodologa de desarrollo considerando el impacto que la misma metodologa podra
provocar en el management o gestin de un proyecto.
Para realizar dicho estudio se han tenido en cuenta tambin los requerimientos,
staff y factores externos (propios del negocio) para evaluar estas cuestiones.
Que nos dice: En este artculo se establece que con respecto al personal
27

involucrado en el proyecto:
Desarrolladores: Pueden no adaptarse al ambiente agile lo cual influye notablemente en
su rendimiento a la hora de desempear sus tareas. Esto se debe a que la falta
documentacin complica el trabajo.
Testers: El testing debe ser automatizado entonces requiere de una skill o habilidad
nueva por parte del tester(un conocimiento mnimo en lo que es codificacin).
Poject leaders: Los lderes del proyecto deben integrar al equipo en la toma de
decisiones.
Managers: Tener una mayor relacin con el cliente, indicar el avance del proyecto.
Customers: El cliente debe tener un mayor compromiso con el proyecto y su desarrollo.
Debe tener compromiso, conocimiento, colaborar, debe ser representativo y con poder
suficiente.
Excecutive Management: La estimacin de costos es compleja, no se puede garantizar
las fechas de entrega, y en ocasiones las funcionalidades.
Con respecto a los procesos estable:
Planning: Es muy complejo planear, suele hacerse ligeramente y en el momento Ej.:
reuniones de scrum.
Documentacin: Escasa para ahorrar esfuerzo. Informacin es comunicada
informalmente. Luego se complica tambin el mantenimiento.
Development Process: Principios giles fuerzan a cambiar varios procesos
(refactorizacin, reviews, etc.)
Con respecto al proyecto, establece que la metodologa est orientada a proyectos con
requerimientos ligeros es recomendable utilizar la metodologa.
Conclusiones: En conclusin, las metodologas giles ofrecen un razonable ajuste
para el alto nivel de cambio que posee todo proyecto, mas precisamente para la
incertidumbre que puede presentarse en el mismo. Existen algunos principios que
utilizados en las correctas circunstancias, reducen notablemente el riesgo en el proyecto
y brindan una mayor productividad y calidad al mismo tiempo. Sin embargo las
metodologas giles no son apropiadas para todo tipo de proyectos. Un lder de proyecto
debe tener en cuenta las caractersticas del mismo para asegurar que una metodologa
gil sea indicada para el mismo. Los impactos de la utilizacin de la misma en la gente,
los procesos y el proyecto deben ser considerados y analizados de antemano.
On the effectiveness of pair programming
(Sobre la efectividad de la programacin en parejas)
Tema principal: En este artculo se estudia la efectividad de la programacin de a
pares desde el punto de vista de la duracin del proyecto, el tiempo, el esfuerzo y la
calidad del producto.
Que nos dice: El estudio muestra que gracias a la programacin de a pares, en
varios casos, se alcanza a producir ms en la mitad del tiempo. Tambin muestra que los
programadores estn ms contentos, y mejora el trabajo en equipo, el conocimiento del
equipo es mayor y la transferencia de conocimientos crece notablemente.
Conclusin: Como conclusin, el caso de estudio muestra que a la hora de
28

analizar si la programacin de a pares es indicada o no, la respuesta es Depende.

Debe tenerse en cuenta la experiencia de los programadores tanto como la
complejidad del sistema y las tareas a desarrollar.

Investigating the impact of Personality Types on Comunnication and

collaboration viability in Pair Programming - an empirical study
(Investigando el impacto de los tipos de personalidad en la comunicacin y colaboracin en la
Programacin de a pares Un caso de estudio emprico)

Tema principal: El articulo trata de 2 experimentos controlados que investigan

el impacto de la personalidad y el temperamento de los desarrolladores en la
comunicacin, colaboracin, y efectividad de un par dentro de un equipo.
El estudio esta basado en experimentos que cuenta con dos pares de
programadores: uno de personalidades diferentes y otro con personalidades similares.
Lo que se evaluara es la efectividad en cuanto a performance medida con
comunicacin, velocidad, productividad y satisfaccin del cliente y la elaboracin
medida por la satisfaccin de los desarrolladores, conocimientos adquiridos y
participacin.
Se plantea la hiptesis de que la personalidad no afectar el rendimiento de las
parejas.
Que nos dice: Las estadsticas mostraron que el rendimiento no solo es afectado
por la formacin de las parejas sino que el rendimiento del equipo formado por
desarrolladores de personalidades con ms diferencias, era mayor al equipo compuesto
por programadores con personalidades similares.
La comunicacin es mayor y por ende el intercambio de informacin tambin.
Esto acarrea como consecuencia un mayor rendimiento y comprensin entre los
desarrolladores que se ve plasmado en el producto final y la calidad del mismo.
Conclusin: Basndonos en los resultados obtenidos, podemos decir que una
buena prctica para las compaas sera la de evaluar la personalidad de los
desarrolladores a la hora de formar un equipo para aumentar su productividad y de esta
forma tener un revenuew (o beneficio) mayor formando parejas con recursos de
personalidades distintas entre s.

Introducing Agile Methods: Three years of experience

(Introduciendo los mtodos giles: Tres aos de experiencia)

Tema principal: Este artculo trata de un estudio de 3 aos de experiencia

trabajando con metodologas giles en mbitos acadmicos. Su objetivo es evaluar cual
es el punto de vista de los estudiantes y como ste vara acorde al curso al que ellos
asisten. Se evalan estudiantes de distintos niveles y cursos diferentes de distintas
universidades.
Se les realiza una encuesta de 20 preguntas entre otras acerca de si se han sentido
cmodos utilizando xp como metodologa de desarrollo, si lo recomendaran a su
29

compaa en el caso de aquellos alumnos que poseen un trabajo, si consideran que la

utilizacin de xp mejora la productividad y otros aspectos del proceso de desarrollo del
proyecto.
Estas preguntas son realizadas al finalizar el curso y con ellas se sacan
posteriormente las estadsticas que permiten as alcanzar una conclusin.
Que nos dice: El estudio concluye con la observacin de que los estudiantes se
han mostrado no solo interesados en la metodologa, sino que con un alto agrado al
introducir metodologas giles a los cursos y no se observaron notables diferencias entre
lo percibido por los estudiantes de distintos niveles. Asimismo se recomienda
capacitarse y utilizar metodologas giles en los cursos para una mejor incorporacin de
los estudiantes universitarios en la industria del software.
Conclusin: Segn lo visto en este artculo podemos animarnos a decir que
sera una buena prctica la introduccin de xp en el mbito acadmico ya que los
alumnos se mostraran contentos ante dicho suceso y a la vez contaran con
conocimientos sobre una metodologa que de a poco va tomando un importante espacio
en la industria laboral en la que el da de maana formarn parte.
Extreme Programming from a CMM perspective
(Extreme programming desde una perspective CMM)

Tema principal: El articulo resume la mitologa entre XP y SW-CMM

(Software capability maturity model), muestra como XP puede ayudar a las
organizaciones a alcanzar las metas de SW-CMM y luego critica XP desde la
perspectiva CMM.
Que nos dice: El artculo comienza detallando las distintas prcticas y
conceptos de ambos metodologas: XP y CMM. Luego de un detallado anlisis concluye
con la sealizacin de que XP se centra mas en el trabajo tcnico y no tanto en el
management, diseo, arquitectura y los riesgos del sistema a nivel general como lo hace
CMM.
Conclusin: Teniendo en cuenta lo sealado por el artculo puede decirse que
extreme programming y SW-CMM se complementan ya que resumiendo, CMM le dice
a la organizacin que es lo que necesita hacer y XP le dice la forma en la que debe
llevar a cabo aquello que debe hacer, es decir el como, siempre teniendo siempre en
cuenta los entornos en los que se trabajar durante el desarrollo del proyecto.

Extreme programming in reducing the rework of requirement change

(Extreme Programming en la reduccin del retrabajo de cambio de requerimientos)

Tema principal: Este artculo trata sobre un estudio basado en el anlisis de la

reduccin del retrabajo o rework que los cambios de requerimientos acarean consigo
teniendo siempre en cuenta que estos son inevitables en todo proyecto.

30

Que nos dice: Una de las principales clusulas de xp sugiere que se trabaje con
un cliente on-site, lo cual brinda la ventaja de poder reducir el trabajo de los cambios de
requerimientos notablemente.
Este cliente on-site puede predecir a grandes rasgos cuales podran llegar a ser los
cambios de requerimientos y el trabajo que ellos traeran desde una perspectiva basada
en la lgica del negocio
Los costos de los cambios de requerimientos tienden a incrementarse a lo largo
del ciclo de vida del proyecto (de manera exponencial).
Conclusin: Teniendo en cuenta lo expuesto en el artculo podemos decir que
como el cambio de requerimientos es inevitable, es muy importante tenerlo en cuenta.
La utilizacin de XP y sus practicas reducen notablemente la cantidad de rework y es
por ello que deben ser consideradas como buenas practicas de desarrollo porque estn
enfocadas principalmente en la satisfaccin del cliente y poseen una notable flexibilidad
para los cambios que dicho cliente plantea a lo largo del proyecto.
Extreme Programming ha demostrado ser una metodologa eficiente, flexible y
desafiante no por sus prcticas, sino por la integracin que propone entre ellas. Es una
metodologa relativamente joven que va ganando mercado da a da y es por ello que
debe ser tenida en cuenta no slo en la industria laboral sino tambin en el mbito
acadmico. Como toda metodologa nueva debe ser manejada con cuidado ya que,
como es natural, siempre existirn aquellos que se resistirn al cambio y aquellos que lo
acogern con gran entusiasmo.
Sin embargo, teniendo en cuenta los artculos analizados, deben considerarse
varios factores a la hora de decidir si es correcto o no implementar xp como
metodologa de desarrollo en un proyecto. Deben analizarse los aspectos tcnicos como
la naturaleza, complejidad y extensin del proyecto as como los recursos o personas
que integrarn el equipo de desarrollo.

31

32

Bibliografa
Agile Alliance website: http://www.agilealliance.org
http://c2.com/cgi/wiki?ExtremeProgramming
http://www.extremeprogramming.org/rules/iterative.html
Kent Beck.Extreme Programming Explained. Embrace Change.pdf
Kent Beck and Martin Fowler. Planning Extreme Programming.pdf
Patricio Letelier, Departamento de Sistemas Informticos y Computacin, Universidad
Politcnica de Valencia, letelier[arroba]dsic.upv.es
Manifiesto para el Desarrollo de Software gil, http://www.agilemanifesto.org
Martn Fowler. La Nueva Metodologa: http://www.programacion.net
Alistair, Desarrollo de Software gil,
http://www.amazon.com/exec/obidos/ASIN/0201699699/programacione-20
Jacobson, Ivar; Booch, Grady; Rumbaugh, James. El Proceso Unificado de Desarrollo
de Software.
http://es.wikipedia.org/wiki/Proceso_Unificado
http://www.dybox.cl/metodologia/rup.html. (2/5/05)
Annimo. Seminario sobre RUP en un entorno empresarial de desarrollo. http://www5.ibm.com/services/learning/es/tairis.nsf/(ExtCourseNr)/RUPS1ES. (2/5/05)
Kruchten, Philippe. The Rational Unified Process: An Introduction, 3rd edition. Addison
Wesley. December 2003.
Larman, Craig. Agile and Iterative Development: A Managers guide. Addison Wesley,
2003.
http://www.cyta.com.ar/ta0502/v5n2a1.htm
http://www.slideshare.net/fmmeson/metogologias-de-desarrollo-de-softwaretradicionales-vs-agiles
http://www.qualitrain.com.mx/index.php/Procesos-de-software/Evolucion-de-losprocesos-de-desarrollo-Primera-parrte.html

33

Michael Coram and Shawn Bohner. The Impact of Agile Methods on Software Project
Management. Department of Computer Science , Virginia Polytechnical Institute and
State University ,Blacksburg, Virginia 24061.
Tore Dyba, Erik Arisholm, Dag I.K. Sjoberg, Jo E. Hannay, and Forrest Shull. On the
Effectiveness of Pair Programming.
Panagiotis Sfetsos, Ioannis Stamelos, Lefteris Angelis and Ignatios Deligiannis.
Investigating the impact of Personality Types on Comunnication and collaboration
viability in Pair Programming - an empirical study. Department of Information
Technology, Thessaloniki, Greece.
Grigori Melnik, Frank Maurer .Introducing Agile Methods: Three Years of Experience.
Department of Computer Science,University of Calgary 2500 University Dr. N.W.,
Calgary, Alberta, T2N 1N4, Canada.
Mark C. Paulk. Extreme Programming from a CMM Perspectiva. Software Engineering
Institute.
Xu Bin, Yang Xiaohu, He Zhijun. EXTREME PROGRAMMING IN REDUCING THE
REWORK OF REQUIREMENT CHANGE. College of Computer Science &
Technology, Zhejiang Univ. 310027 Hangzhou, P. R. China

34

Glosario
Proceso de desarrollo: Es el conjunto de tcnicas y procedimientos que nos permiten
conocer los elementos necesarios para definir un proyecto de software.
Release / iteracin: Es una versin del producto que cumple con determinados
requerimientos.
Software: Es el conjunto de los programas de cmputo, procedimientos, reglas,
documentacin y datos asociados que forman parte de las operaciones de un sistema de
computacin.
Seniority: Nivel de experiencia y conocimientos de un recurso en un proyecto de
desarrollo. La misma puede ser Junior, Semi Sr. o Senior.
Refactorizacin: es una tcnica de la ingeniera de software para reestructurar un cdigo
fuente, alterando su estructura interna sin cambiar su comportamiento externo.
Rework: (o retrabado) es el trabajo excedente que debe realizarse en un proceso de
desarrollo.
Artefacto: producto tangible resultante del proceso de desarrollo de software. Algunos
artefactos como los casos de uso, diagrama de clases u otros modelos UML ayudan a la
descripcin de la funcin, la arquitectura o el diseo del software.
Ad hoc: locucin latina que significa literalmente para esto. Generalmente se refiere a
una solucin elaborada especficamente para un problema o fin preciso y, por tanto, no
es generalizable ni utilizable para otros propsitos.
Metodologa RAD: (Desarrollo rpido de aplicaciones) Proceso de desarrollo de
software que permite construir sistemas utilizables en poco tiempo.
Model-Based Architecture and Software Engineering: Proceso de desarrollo ideado por
Barry Boehm y Dan Port en la dcada del 90. El mismo se enfoca principalmente en el
aseguramiento de la consistencia y el refuerzo de los modelos de producto, procesos,
propiedades y xito del proyecto.
Mtodo de desarrollo de sistemas dinmicos (DSDM): es un mtodo que provee un
framework para el desarrollo gil de software, apoyado por su continua implicacin del
usuario en un desarrollo iterativo y creciente que sea sensible a los requerimientos
cambiantes, para desarrollar un sistema que rena las necesidades de la empresa en
tiempo y presupuesto. Es uno de los tantos mtodos de desarrollo gil de software y
forma parte de la conocida alianza gil.

35