3/10/2015

CyTA

::Imprimir

Fuente: a

<Cerrar

Artculo

Mtodologasgilesparaeldesarrollodesoftware:eXtreme
Programming(XP)
PatricioLetelier
Ph.D.
DepartamentodeSistemasInformticosyComputacin(DSIC)
UniversidadPolitcnicadeValencia(UPV)
letelier@dsic.upv.es
MCarmenPenads
Ph.D.
DepartamentodeSistemasInformticosyComputacin(DSIC)
UniversidadPolitcnicadeValencia(UPV)
mpenades@dsic.upv.es

Resumen
El desarrollo de software no es una tarea fcil. Prueba de ello es que existen numerosas
propuestas metodolgicas que inciden en distintas dimensiones del proceso de desarrollo.
Porunapartetenemosaquellaspropuestasmstradicionalesquesecentranespecialmente
en el control del proceso, estableciendo rigurosamente las actividades involucradas, los
artefactos que se deben producir, y las herramientas y notaciones que se usarn. Estas
propuestas han demostrado ser efectivas y necesarias en un gran nmero de proyectos,
perotambinhanpresentadoproblemasenotrosmuchos.Unaposiblemejoraesincluiren
losprocesosdedesarrollomsactividades,msartefactosymsrestricciones,basndose
en los puntos dbiles detectados. Sin embargo, el resultado final sera un proceso de
desarrollomscomplejoquepuedeinclusolimitarlapropiahabilidaddelequipoparallevar
a cabo el proyecto. Otra aproximacin es centrarse en otras dimensiones, como por
ejemplo el factor humano o el producto software. Esta es la filosofa de las metodologas
giles, las cuales dan mayor valor al individuo, a la colaboracin con el cliente y al
desarrollo incremental del software con iteraciones muy cortas. Este enfoque est
mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige
reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las
metodologas giles estn revolucionando la manera de producir software, y a la vez
generando un amplio debate entre sus seguidores y quienes por escepticismo o
convencimiento no las ven como alternativa para las metodologas tradicionales. En este
trabajose presenta resumidamente el contexto en el que surgen las metodologas giles,
sus valores, principios y comparaciones con las metodologas tradicionales. Adems se
describe con mayor detalle Programacin Extrema (eXtreme Programming, XP) la
metodologagilmspopularenlaactualidad.
PalabrasClave: Procesosdesoftware,Metodologasgiles,ProgramacinExtrema(eXtreme
Programming)

Agilemethodologyforthedevelopmentofthesoftware:eXtreme
Programming(XP)

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

1/15

3/10/2015

CyTA

The development of software is not an easy task. The proof for that is the fact that there
are many methodological proposals that affect different dimensions of the development
process.Ononehand,wecanfindmore traditional proposals, which are specially centred
in the control of the process by rigorously setting the involved activities, the devices that
areduetoproduce,andthetoolsandannotationsthatwillbeused.Theseproposalshave
demonstrated to be effective and necessary in a great number of projects, but also they
have presented problems in others. A possible improvement for that is to include more
activities, devices and restrictions in the development processes, which is based on the
weak points that were detected. Nevertheless, the final result would be a morecomplex
process of development which can even limit the own ability of the equipment to develop
the project. Another approach is focusing in other dimensions, for example the human
factororthesoftwareproduct.Thisisthephilosophyoftheagilemethodologies,whichgive
greater value to the individual, to the collaboration with the client and the incremental
development of software with very short iterations. This approach is presenting its
effectiveness in projects with changing requirements and when it is demanded to reduce
drastically the times of development but maintaining a high quality. The agile
methodologiesarerevolutionizingthewaytoproducesoftwareand,atthesametime,they
are generating an considerable debate between their followers and the ones that, by
scepticismorconviction,donotseethemasanalternativefortraditionalmethodologies.In
thisworkitisbrieflypresentedthecontextinwhichtheagilemethodologiesemerge,their
values, principles and comparisons with traditional methodologies. In addition, it is
described in detail the most popular agile methodology at the present time: eXtreme
Programming.

Keywords:

SoftwareprocessagilemethodseXtremeProgramming

1.Introduccin
Enlasdosltimasdcadaslasnotacionesdemodeladoyposteriormentelasherramientas
pretendieron ser las "balas de plata" para el xito en el desarrollo de software, sin
embargo, las expectativas no fueron satisfechas. Esto se debe en gran parte a que otro
importanteelemento,lametodologadedesarrollo,habasidopostergado.Denadasirven
buenasnotacionesyherramientassinoseproveendirectivasparasuaplicacin.As,esta
dcada ha comenzado con un creciente inters en metodologas de desarrollo. Hasta hace
pocoelprocesodedesarrollollevabaasociadaunmarcadonfasisenelcontroldelproceso
medianteunarigurosadefinicinderoles,actividadesyartefactos,incluyendomodeladoy
documentacindetallada.Esteesquema"tradicional"paraabordareldesarrollodesoftware
hademostradoserefectivoynecesarioenproyectosdegrantamao(respectoatiempoy
recursos), donde por lo general se exige un alto grado de ceremonia en el proceso. Sin
embargo, este enfoque no resulta ser el ms 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 una alta calidad. Ante las
dificultades para utilizar metodologas tradicionales con estas restricciones de tiempo y
flexibilidad, muchos equipos de desarrollo se resignan a prescindir del buen hacer de la
ingeniera del software, asumiendo el riesgo que ello conlleva. En este escenario, las
metodologas giles emergen como una posible respuesta para llenar ese vaco
metodolgico. Por estar especialmente orientadas para proyectos pequeos, las
metodologas giles constituyen una solucin a medida para ese entorno, aportando una
elevada simplificacin que a pesar de ello no renuncia a las prcticas esenciales para
asegurarlacalidaddelproducto.
Lasmetodologasgilessonsindudaunodelostemasrecienteseningenieradesoftware
que estn acaparando gran inters. Prueba de ello es que se estn haciendo un espacio
destacado en la mayora de conferencias y workshops celebrados en los ltimos aos. Es
tal su impacto que actualmente existen 4 conferencias internacionales de alto nivel y
especficas sobre el tema1. Adems ya es un rea con cabida en prestigiosas revistas
internacionales. En la comunidad de la ingeniera del software, se est viviendo con
intensidad un debate abierto entre los partidarios de las metodologas tradicionales
http://www.cyta.com.ar/ta0502/v5n2a1.htm

2/15

3/10/2015

CyTA

(referidaspeyorativamentecomo"metodologaspesadas")yaquellosqueapoyanlasideas
emanadasdel"Manifiestogil"2.La curiosidad que siente la mayor parte de ingenieros de
software, profesores, e incluso alumnos, sobre las metodologas giles hace prever una
fuerte proyeccin industrial. Por un lado, para muchos equipos de desarrollo el uso de
metodologas tradicionales les resulta muy lejano a su forma de trabajo actual
considerando las dificultades de su introduccin e inversin asociada en formacin y
herramientas. Por otro, las caractersticas de los proyectos para los cuales las
metodologas giles han sido especialmente pensadas se ajustan a un amplio rango de
proyectos industriales de desarrollo de software aquellos en los cuales los equipos de
desarrollosonpequeos,conplazosreducidos,requisitosvoltiles,y/obasadosennuevas
tecnologas.
El artculo est organizado como sigue. En la seccin 2 se introducen las principales
caractersticasdelasmetodologasgiles,recogidasenelManifiestoysehaceunarevisin
de los principales mtodos giles. La seccin 3 se centra en eXtreme Programming (XP),
presentandosuscaractersticasparticulares,comosonlashistoriasdeusuarioylosroles,
as como el proceso que se sigue y las prcticas que propone. Finalmente aparecen las
conclusiones.

2.METODOLOGASGILES
Enunareunincelebradaenfebrerode2001enUtahEEUU,naceeltrmino"gil"aplicado
al desarrollo de software. En esta reunin participan un grupo de 17 expertos de la
industria del software, incluyendo algunos de los creadores o impulsores de metodologas
desoftware. Su objetivo fue esbozar los valores y principios que deberan permitir a los
equiposdesarrollarsoftwarerpidamenteyrespondiendoaloscambiosquepuedansurgir
alolargodelproyecto.Sepretendaofrecerunaalternativaalosprocesosdedesarrollode
softwaretradicionales,caracterizadosporserrgidosydirigidosporladocumentacinque
se genera en cada una de las actividades desarrolladas. Varias de las denominadas
metodologas giles ya estaban siendo utilizadas con xito en proyectos reales, pero les
faltabaunamayordifusinyreconocimiento.
Tras esta reunin se cre The Agile Alliance3, una organizacin, sin nimo de lucro,
dedicadaapromoverlosconceptosrelacionadosconeldesarrollogildesoftwareyayudar
a las organizaciones para que adopten dichos conceptos. El punto de partida es fue el
Manifiestogil,undocumentoqueresumelafilosofa"gil".
2.1.ElManifiestogil.
ElManifiestocomienzaenumerandolosprincipalesvaloresdeldesarrollogil.Sevalora:
Al individuo y las interacciones del equipo de desarrollo sobre el
procesoylasherramientas.Lagenteeselprincipalfactordexitodeun
proyectosoftware.Sisesigueunbuenprocesodedesarrollo,peroelequipo
falla,elxitonoestaseguradosinembargo,sielequipofunciona,esms
fcilconseguirelobjetivofinal,aunquenosetengaunprocesobiendefinido.
No se necesitan desarrolladores brillantes, sino desarrolladores que se
adapten bien al trabajo en equipo. As mismo, las herramientas
(compiladores,depuradores,controldeversiones,etc.)sonimportantespara
mejorar el rendimiento del equipo, pero el disponer ms recursos que los
estrictamentenecesariostambinpuedeafectarnegativamente.Enresumen,
esmsimportanteconstruirunbuenequipoqueconstruirelentorno.Muchas
veces se comete el error de construir primero el entorno y esperar que el
equipo se adapte automticamente. Es mejor crear el equipo y que ste
configuresupropioentornodedesarrolloenbaseasusnecesidades.
Desarrollar software que funciona ms que conseguir una buena
documentacin. Aunque se parte de la base de que el software sin
documentacinesundesastre,lareglaaseguiresnoproducirdocumentosa
menos que sean necesarios de forma inmediata para tomar un decisin
importante. Estos documentos deben ser cortos y centrarse en lo
fundamental.Siunaveziniciadoelproyecto,unnuevomiembroseincorpora
http://www.cyta.com.ar/ta0502/v5n2a1.htm

3/15

3/10/2015

CyTA

alequipodedesarrollo,seconsideraquelosdoselementosquemslevana
servirparaponersealdason:elpropiocdigoylainteraccinconelequipo.
Lacolaboracinconelclientemsquelanegociacindeuncontrato.
Las caractersticas particulares del desarrollo de software hace que muchos
proyectos hayan fracasado por intentar cumplir unos plazos y unos costes
preestablecidos al inicio del mismo, segn los requisitos que el cliente
manifestabaenesemomento.Porello,seproponequeexistaunainteraccin
constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre
ambosserlaquemarquelamarchadelproyectoyaseguresuxito.
Responder a los cambios ms que seguir estrictamente un plan. La
habilidad de responder a los cambios que puedan surgir a los largo del
proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.)
determinatambinelxitoofracasodelmismo.Porlotanto,laplanificacin
no debe ser estricta puesto que hay muchas variables en juego, debe ser
flexible para poder adaptarse a los cambios que puedan surgir. Una buena
estrategia es hacer planificaciones detalladas para unas pocas semanas y
planificacionesmuchomsabiertasparaunospocosmeses.
Los valores anteriores inspiran los doce principios del manifiesto. Estos principios son las
caractersticas que diferencian un proceso gil de uno tradicional. Los dos primeros son
generalesyresumengranpartedelespritugil.Son:
I.Laprioridadessatisfaceralclientemediantetempranasycontinuasentregas
desoftwarequeleaporteunvalor.Unprocesoesgilsialaspocassemanasde
empezar ya entrega software que funcione aunque sea rudimentario. El cliente
decide si pone en marcha dicho software con la funcionalidad que ahora le
proporcionaosimplementelorevisaeinformadeposiblescambiosarealizar.
II.Darlabienvenidaaloscambios.Secapturanloscambiosparaqueelcliente
tenga una ventaja competitiva. Este principio es una actitud que deben adoptar
los miembros del equipo de desarrollo. Los cambios en los requisitos deben
verse como algo positivo. Les va a permitir aprender ms, a la vez que logran
una mayor satisfaccin del cliente. Este principio implica adems que la
estructura del software debe ser flexible para poder incorporar los cambios sin
demasiado coste aadido. El paradigma orientado a objetos puede ayudar a
conseguirestaflexibilidad.
Luego existen una serie de principios que tienen que ver directamente con el proceso de
desarrollodesoftwareaseguir.
III.Entregarfrecuentementesoftwarequefuncionedesdeunpardesemanasa
un par de meses, con el menor intervalo de tiempo posible entreentregas.Las
entregas al cliente se insiste en que sean software, no planificaciones, ni
documentacindeanlisisodediseo.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo
delproyecto. El proceso de desarrollo necesita ser guiado por el cliente, por lo
quelainteraccinconelequipoesmuyfrecuente.
V.Construirelproyectoentornoaindividuosmotivados.Darleselentornoyel
apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. La
genteeselprincipalfactordexito,todolosdems(proceso,entorno,gestin,
etc.) queda en segundo plano. Si cualquiera de ellos tiene un efecto negativo
sobrelosindividuosdebesercambiado.
VI.Eldilogocaraacaraeselmtodomseficienteyefectivoparacomunicar
informacin dentro de un equipo de desarrollo. Los miembros de equipo deben
hablar entre ellos, ste es el principal modo de comunicacin. Se pueden crear
documentosperonotodoestarenellos,noesloqueelequipoespera.
VII.Elsoftwarequefuncionaeslamedidaprincipaldeprogreso.Elestadodeun
proyecto no viene dado por la documentacin generada o la fase en la que se
http://www.cyta.com.ar/ta0502/v5n2a1.htm

4/15

3/10/2015

CyTA

encuentre, sino por el cdigo generado y en funcionamiento. Por ejemplo, un

proyecto se encuentra al 50% si el 50% de los requisitos ya estn en
funcionamiento.
VIII. Los procesos giles promueven un desarrollo sostenible. Los promotores,
desarrolladoresyusuariosdeberansercapacesdemantenerunapazconstante.
No se trata de desarrollar lo ms rpido posible, sino de mantener el ritmo de
desarrollo durante toda la duracin del proyecto, asegurando en todo momento
quelacalidaddeloproducidoesmxima.
Finalmente los ltimos principios estn ms directamente relacionados con el equipo de
desarrollo,encuantometasaseguiryorganizacindelmismo.
IX.Laatencincontinuaalacalidadtcnicayalbuendiseomejoralaagilidad.
Producircdigoclaroyrobustoeslaclaveparaavanzarmsrpidamenteenel
proyecto.
X. La simplicidad es esencial. Tomar los caminos ms simples que sean
consistentesconlosobjetivosperseguidos.Sielcdigoproducidoessimpleyde
altacalidadsermssencilloadaptarloaloscambiosquepuedansurgir.
XI. Las mejores arquitecturas, requisitos y diseos surgen de los equipos
organizados por s mismos. Todo el equipo es informado de las
responsabilidadesystasrecaensobretodossusmiembros.Eselpropioequipo
elquedecidelamejorformadeorganizarse,deacuerdoalosobjetivosquese
persigan.
XII. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser
ms efectivo, y segn esto ajusta su comportamiento. Puesto que el entorno
est cambiando continuamente, el equipo tambin debe ajustarse al nuevo
escenario de forma continua. Puede cambiar su organizacin, sus reglas, sus
convenciones,susrelaciones,etc.,paraseguirsiendogil.
Los firmantes de los valores y principios de este Manifiesto son: Kent Beck, Mike Beedle,
ArievanBennekum,AlistairCockburn,WardCunningham,MartinFowler,JamesGrenning,
JimHighsmith,AndrewHunt,RonJeffries,JonKern,BrianMarick,RobertC.Martin,Steve
Mellor,KenSchwaber,JeffSutherlandyDaveThomas.
2.2.Revisindemetodologas
Aunque los creadores e impulsores de las metodologas giles ms populareshansuscrito
el manifiesto gil y coinciden con los principios enunciados anteriormente, cada
metodologa tiene caractersticas propias y hace hincapi en algunos aspectos ms
especficos.Acontinuacinseresumendichasmetodologasgiles,dejandoelanlisisms
detalladodeXPparalasiguienteseccin.
SCRUM4[16].DesarrolladaporKenSchwaber,JeffSutherlandyMikeBeedle.
Define un marco para la gestin de proyectos, que se ha utilizado con xito
durante los ltimos 10 aos. Est especialmente indicada para proyectoscon
un rpido cambio de requisitos. Sus principales caractersticas se pueden
resumir en dos. El desarrollo de software se realiza mediante iteraciones,
denominadassprints,conunaduracinde30das.Elresultadodecadasprint
es un incremento ejecutable que se muestra al cliente. La segunda
caractersticaimportantesonlasreunionesalolargoproyecto.stassonlas
verdaderas protagonistas, especialmente la reunin diaria de 15 minutos del
equipodedesarrolloparacoordinacineintegracin.
Crystal Methodologies5[5]. Se trata de un conjunto de metodologas para
eldesarrollodesoftware caracterizadas por estar centradas en las personas
que componen el equipo (de ellas depende el xito del proyecto) y la
reduccin al mximo del nmero de artefactos producidos. Han sido
desarrolladasporAlistairCockburn.Eldesarrollodesoftwareseconsideraun
juego cooperativo de invencin y comunicacin, limitado por los recursos a
http://www.cyta.com.ar/ta0502/v5n2a1.htm

5/15

3/10/2015

CyTA

utilizar. El equipo de desarrollo es un factor clave, por lo que se deben

invertir esfuerzos en mejorar sus habilidades y destrezas, as como tener
polticas de trabajo en equipo definidas. Estas polticas dependern del
tamaodelequipo,establecindoseunaclasificacinporcolores,porejemplo
CrystalClear(3a8miembros)yCrystalOrange(25a50miembros).
Dynamic Systems Development Method6 (DSDM) [17]. Define el marco
para desarrollar un proceso de produccin de software. Nace en 1994 con el
objetivo 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
viabilidad,estudio del negocio, modelado funcional, diseo y construccin, y
finalmenteimplementacin.Lastresltimassoniterativas,ademsdeexistir
realimentacinatodaslasfases.
Adaptive Software Development7 (ASD) [9]. Su impulsor es Jim
Highsmith. Sus principales caractersticas son: iterativo, orientado a los
componentessoftwaremsquealastareasytolerantealoscambios.Elciclo
devidaqueproponetienetresfasesesenciales:especulacin,colaboraciny
aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las
caractersticas del software en la segunda desarrollan las caractersticas y
finalmente en la tercera se revisa su calidad, y se entrega al cliente. La
revisin de los componentes sirve para aprender de los errores y volver a
iniciarelciclodedesarrollo.
FeatureDriven Development8(FDD) [3]. Define un proceso iterativo que
constade5pasos.Lasiteracionessoncortas(hasta2semanas).Secentraen
las fases de diseo e implementacin del sistema partiendo de una lista de
caractersticasquedebereunirelsoftware.SusimpulsoressonJeffDeLucay
PeterCoad.
Lean Development9 (LD) [15]. Definida por Bob Charettes a partir de su
experienciaenproyectosconlaindustriajaponesadelautomvilenlosaos
80 y utilizada en numerosos proyectos de telecomunicaciones en Europa. En
LD,loscambiosseconsideranriesgos,perosisemanejanadecuadamentese
pueden convertir en oportunidades que mejoren la productividad del cliente.
Su principal caracterstica es introducir un mecanismo para implementar
dichoscambios.
La Tabla 1 (obtenida de [10]), compara las distintas aproximaciones giles en base a tres
parmetros:vistadelsistemacomoalgocambiante,tenerencuentalacolaboracinentre
los miembros del equipo y caractersticas ms especficas de la propia metodologa como
sonsimplicidad,excelenciatcnica,resultados,adaptabilidad,etc.Tambinincorporacomo
referencianogilelCapabilityMadurityModel10(CMM).

CMM

ASD

Crystal

DSDM

FDD

LD

Scrum

XP

Sistemacomo
algocambiante

Colaboracin

Resultados

Simplicidad

Adaptabilidad

Caractersticas
Metodologa(CM)

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

6/15

3/10/2015

CyTA

Excelenciatcnica

Prcticasde
colaboracin

MediaCM

2.2

4.4

4.4

3.6

3.8

3.6

4.2

4.4

MediaTotal

1.7

4.8

4.5

3.6

3.6

3.9

4.7

4.8

Tabla1.Rankingdeagilidad(Losvaloresmsaltosrepresentanunamayoragilidad)

Como se observa en la Tabla 1, todas las metodologas giles tienen una significativa
diferencia del ndice de agilidad respecto a CMM y entre ellas destacan ASD, Scrum y XP
comolasmsgiles.
2.3.ComparacinMetodologasgilesyTradicionales
Vamos a enumerar las principales diferencias de una Metodologa gil respecto de las
MetodologasTradicionales(llamadaspeyorativamentenogilesopesadas).LaTabla2
recogeestasdiferenciasquenoserefierensloalprocesoens,sinotambinalcontexto
deequipoyorganizacinqueesmsfavorableacadaunodeestasfilosofasdeprocesos
dedesarrollodesoftware.

Metodologagil

MetodologaTradicional

PocosArtefactos.Elmodeladoes
prescindible,modelosdesechables.

MsArtefactos.Elmodeladoesesencial,
mantenimientodemodelos

PocosRoles,msgenricosyflexibles

MsRoles,msespecficos

Noexisteuncontratotradicional,debeser
bastanteflexible

Existeuncontratoprefijado

Cliente es parte del equipo de desarrollo

(ademsinsitu)

Elclienteinteractaconelequipode
desarrollomediantereuniones

Orientadaaproyectospequeos.Corta
duracin(oentregasfrecuentes),equipos
pequeos(<10integrantes)ytrabajando
enelmismositio

Aplicablesaproyectosdecualquier
tamao,perosuelenserespecialmente
efectivas/usadasenproyectosgrandesy
conequiposposiblementedispersos

Laarquitecturasevadefiniendoy
mejorandoalolargodelproyecto

Sepromuevequelaarquitecturasedefina
tempranamenteenelproyecto

nfasisenlosaspectoshumanos:el
individuoyeltrabajoenequipo

nfasisenladefinicindelproceso:roles,
actividadesyartefactos

Basadasenheursticasprovenientesde
prcticasdeproduccindecdigo

Basadasennormasprovenientesde
estndaresseguidosporelentornode
desarrollo

Seesperancambiosduranteelproyecto

Seesperaquenoocurrancambiosdegran
impactoduranteelproyecto

Tabla2.Diferenciasentremetodologasgilesynogiles
http://www.cyta.com.ar/ta0502/v5n2a1.htm

7/15

3/10/2015

CyTA

3.PROGRAMACINEXTREMA(EXTREMEPROGRAMMING,XP)
XP11[2]esunametodologagilcentradaenpotenciarlasrelacionesinterpersonalescomo
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 basa en realimentacin continua entre el cliente y el equipo de desarrollo,
comunicacin fluida entre todos los participantes, simplicidad en las soluciones
implementadas y coraje para enfrentar los cambios. XP se define como especialmente
adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un
altoriesgotcnico.
Losprincipiosyprcticassondesentidocomnperollevadasalextremo,deahproviene
su nombre. Kent Beck, el padre de XP, describe la filosofa de XP en [2] sin cubrir los
detallestcnicosydeimplantacindelasprcticas.Posteriormente,otraspublicacionesde
experiencias se han encargado de dicha tarea. A continuacin presentaremos las
caractersticas esenciales de XP organizadas en los tres apartados siguientes: historias de
usuario,roles,procesoyprcticas.
3.1.LasHistoriasdeUsuario
Las historias de usuario son la tcnica utilizada en XP para especificar los requisitos del
software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las
caractersticasqueelsistemadebeposeer,seanrequisitosfuncionalesonofuncionales.El
tratamiento de las historias de usuario es muy dinmico y flexible, en cualquiermomento
historiasdeusuariopuedenromperse,reemplazarseporotrasmsespecficasogenerales,
aadirse nuevas o ser modificadas. Cada historia de usuario es lo suficientemente
comprensible y delimitada para que los programadores puedan implementarla en unas
semanas[12].
Respecto de la informacin contenida en la historia de usuario, existen varias plantillas
sugeridasperonoexisteunconsensoalrespecto.Enmuchoscasossloseproponeutilizar
un nombre y una descripcin [18] o slo una descripcin [12], ms quizs una estimacin
deesfuerzoendas[14].Beckensulibro[2]presentaunejemplodeficha(customerstory
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 cosas por terminar y
comentarios.
Una de las interrogantes (que tambin se presenta cuando se utilizan casos de uso) es
culeselniveldegranularidadadecuadoparaunahistoriadeusuario?Larespuestanoes
tajante. Jeffries en [12] dice que depende de la complejidad del sistema, debe haber al
menos una historia por cada caracterstica importante, y propone realizar una o dos
historias por programador por mes. Si se tienen menos, probablemente sea conveniente
dividir las historias, si se tienen ms lo mejor es disminuir el detalle y agruparlas. Para
efectos de planificacin, las historias pueden ser de una a tres semanas de tiempo de
programacin(paranosuperareltamaodeunaiteracin).
No hay que preocuparse si en un principio no se identifican todas las historiasdeusuario.
Alcomienzodecadaiteracinestarnregistradosloscambiosenlashistoriasdeusuarioy
segnesoseplanificarlasiguienteiteracin.Lashistoriasdeusuariosondescompuestas
en tareas de programacin y asignadas a los programadores para ser implementadas
duranteunaiteracin.
3.2.RolesXP
Aunque en otras fuentes de informacin aparecen algunas variaciones y extensiones de
rolesXP,enesteapartadodescribiremoslosrolesdeacuerdoconlapropuestaoriginalde
Beck.
http://www.cyta.com.ar/ta0502/v5n2a1.htm

8/15

3/10/2015

CyTA

Programador
Elprogramadorescribelaspruebasunitariasyproduceelcdigodelsistema.Debeexistir
unacomunicacinycoordinacinadecuadaentre los programadores y otros miembros del
equipo.
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
implementanencadaiteracincentrndoseenaportarmayorvaloralnegocio.Elclientees
slo uno dentro del proyecto pero puede corresponder a un interlocutor que est
representandoavariaspersonasquesevernafectadasporelsistema.
Encargadodepruebas(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
herramientasdesoporteparapruebas.
Encargadodeseguimiento(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.
Tambinrealizaelseguimientodelprogresodecadaiteracinyevalasilosobjetivosson
alcanzables con las restricciones de tiempo y recursos presentes. Determina cundo es
necesariorealizaralgncambioparalograrlosobjetivosdecadaiteracin.
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
sigaelprocesocorrectamente.
Consultor
Esunmiembroexternodelequipoconunconocimientoespecficoenalgntemanecesario
paraelproyecto.Guaalequipopararesolverunproblemaespecfico.
Gestor(Bigboss)
Eselvnculoentreclientesyprogramadores,ayudaaqueelequipotrabajeefectivamente
creandolascondicionesadecuadas.Sulaboresencialesdecoordinacin.

4.PROCESOXP
UnproyectoXPtienexitocuandoelclienteseleccionaelvalordenegocioaimplementar
basadoenlahabilidaddelequipoparamedirlafuncionalidadquepuedeentregaratravs
deltiempo.Elciclodedesarrolloconsiste(agrandesrasgos)enlossiguientespasos[12]:
1. Elclientedefineelvalordenegocioaimplementar.
2. Elprogramadorestimaelesfuerzonecesarioparasuimplementacin.
3. Elclienteseleccionaquconstruir,deacuerdoconsusprioridadesylasrestricciones
detiempo.
4. Elprogramadorconstruyeesevalordenegocio.
5. Vuelvealpaso1.
Entodaslasiteracionesdeesteciclotantoelclientecomoelprogramadoraprenden.Nose
debepresionaralprogramadorarealizarmstrabajoqueelestimado,yaqueseperder
calidadenelsoftwareonosecumplirnlosplazos.Delamismaformaelclientetienela
obligacindemanejar el mbito de entrega del producto, para asegurarse que el sistema
tengaelmayorvalordenegocioposibleconcadaiteracin.
El ciclo de vida ideal de XP consiste de seis fases [2]: Exploracin, Planificacin de la
Entrega(Release),Iteraciones,Produccin,MantenimientoyMuertedelProyecto.
FaseI:Exploracin
http://www.cyta.com.ar/ta0502/v5n2a1.htm

9/15

3/10/2015

CyTA

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
construyendounprototipo.Lafasedeexploracintomadepocassemanasapocosmeses,
dependiendodeltamaoyfamiliaridadquetenganlosprogramadoresconlatecnologa.
FaseII:PlanificacindelaEntrega
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
determinauncronogramaenconjuntoconelcliente.Unaentregadeberaobtenerseenno
msdetresmeses.Estafaseduraunospocosdas.
Las estimaciones de esfuerzo asociado a la implementacin de las historias la establecen
losprogramadoresutilizandocomomedidaelpunto.Unpunto,equivaleaunasemanaideal
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
lashistoriasdeusuarioquefueronterminadasenlaltimaiteracin.
La planificacin se puede realizar basndose en el tiempo o el alcance. La velocidad del
proyectoesutilizadaparaestablecercuntashistoriassepuedenimplementarantesdeuna
fecha determinada o cunto tiempo tomar implementar un conjunto de historias. Al
planificarportiempo,semultiplicaelnmerodeiteracionesporlavelocidaddelproyecto,
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.
FaseIII:Iteraciones
Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de
Entregaestcompuestoporiteracionesdenomsdetressemanas.Enlaprimeraiteracin
se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante
elrestodelproyecto.Estoselograescogiendolashistoriasquefuercenlacreacindeesta
arquitectura,sinembargo,estonosiempreesposibleyaqueeselclientequiendecidequ
historiasseimplementarnencadaiteracin(paramaximizarelvalordenegocio).Alfinal
delaltimaiteracinelsistemaestarlistoparaentrarenproduccin.
LoselementosquedebentomarseencuentadurantelaelaboracindelPlandelaIteracin
son: historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptacin no
superadasenla iteracin anterior y tareas no terminadas en la iteracin anterior. Todoel
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.Wakeen[18]proporcionaalgunasguastilespararealizarlaplanificacin
delaentregaydecadaiteracin.
FaseIV:Produccin
Lafasedeproduccinrequieredepruebasadicionalesyrevisionesderendimientoantesde
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
cambiosduranteestafase.
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(porejemplo,durantelafasedemantenimiento).
FaseV: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
realizarestoserequieredetareasdesoporteparaelcliente.Deestaforma,lavelocidad
de desarrollo puede bajar despus de la puesta del sistema en produccin. La fase de
http://www.cyta.com.ar/ta0502/v5n2a1.htm

10/15

3/10/2015

CyTA

mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su

estructura.
FaseVI:MuertedelProyecto
Es cuando el cliente no tiene ms historias para ser incluidasenelsistema.Estorequiere
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
mscambiosenlaarquitectura.Lamuertedelproyectotambinocurrecuandoelsistema
no genera los beneficios esperados por el cliente o cuando no hay presupuesto para
mantenerlo.

5.PRCTICASXP
La principal suposicin que se realiza en XP es la posibilidad de disminuir la mtica curva
exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseo
evolutivo funcione. XP apuesta por un crecimiento lento del costo del cambio y con un
comportamiento asinttico. Esto se consigue gracias a las tecnologas disponibles para
ayudar en el desarrollo de software y a la aplicacin disciplinada de las prcticas que
describiremosacontinuacin.
Eljuegodelaplanificacin
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
cadaiteracin. 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,deacuerdoconelvalorqueaportaparaelnegocio.Losprogramadoresestimanel
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
reconducirelproyecto.
Entregaspequeas
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
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.
Dichaarquitecturaseasumeevolutivaylosposiblesinconvenientesquesegeneraranpor
no contar con ella explcitamente en el comienzo del proyecto se solventan con la
existenciadeunametfora.Elsistemaesdefinidomedianteunametforaounconjuntode
metforas compartidas por el cliente y el equipo de desarrollo. Una metfora es una
historia compartida que describe cmo debera funcionar el sistema. Martin Fowler en [6]
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
nombresayudaalanomenclaturadeclasesymtodosdelsistema.
Diseosimple
Se debe disear la solucin ms simple que pueda funcionar y ser implementada en un
momentodeterminadodelproyecto.Lacomplejidadinnecesariayelcdigoextradebeser
removidoinmediatamente. 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,reflejaclaramentelaintencindeimplementacindelosprogramadoresytiene
elmenornmeroposibledeclasesymtodos.
Pruebas
La produccin de cdigo est dirigida por las pruebas unitarias. Las pruebas unitarias son
http://www.cyta.com.ar/ta0502/v5n2a1.htm

11/15

3/10/2015

CyTA

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
pruebasconstantes,laautomatizacinparaapoyarestaactividadescrucial.
Refactorizacin(Refactoring)
Larefactorizacinesunaactividadconstantedereestructuracindelcdigoconelobjetivo
de remover duplicacin de cdigo, mejorar su legibilidad, simplificarlo y hacerlo ms
flexible para facilitar los posteriores cambios. La refactorizacin mejora la estructura
internadelcdigosinalterarsucomportamientoexterno[8].RobertMartin[13]sealaque
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
buendiseoinicialsedegradar.
Programacinenparejas
Toda la produccin de cdigo debe realizarse con trabajo en parejas de programadores.
SegnCockburnyWilliamsenunestudio realizado para identificar los costos y beneficios
de la programacin en parejas [4], las principales ventajas de introducir este estilo de
programacin son: muchos errores son detectados conforme son introducidosenelcdigo
(inspeccionesdecdigocontinuas),porconsiguientelatasadeerroresdelproductofinales
ms baja, los diseos son mejores y el tamao del cdigo menor (continua discusin de
ideasdelosprogramadores),losproblemasdeprogramacinseresuelvenmsrpido,se
posibilita la transferencia de conocimientos de programacin entre los miembros del
equipo, varias personas entienden las diferentes partes sistema, los programadores
conversanmejorandoaselflujodeinformacinyladinmicadelequipo,yfinalmente,los
programadoresdisfrutanmssutrabajo.Dichosbeneficiosseconsiguendespusdevarios
mesesdepracticarlaprogramacinenparejas.EnlosestudiosrealizadosporCockburny
Williamsestelapsodetiempovarade3a4meses.
Propiedadcolectivadelcdigo
Cualquier programador puede cambiar cualquier parte del cdigo en cualquier momento.
Esta prctica motiva a todos a contribuir con nuevas ideas en todos los segmentos del
sistema,evitandoalavezquealgnprogramadorseaimprescindiblepararealizarcambios
enalgunaporcindecdigo.
Integracincontinua
Cada pieza de cdigo es integrada en el sistema una vez que est lista. As, el sistema
puedellegaraserintegradoyconstruidovariasvecesenunmismoda.Todaslaspruebas
son ejecutadas y tienen que ser aprobadas para que el nuevo cdigo sea 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. Martin Fowler en [7] afirma que el desarrollo de un proceso
disciplinado y automatizado es esencial para un proyecto controlado, el equipo de
desarrolloestmspreparadoparamodificar el cdigo cuando sea necesario, debido a la
confianzaenlaidentificacinycorreccindeloserroresdeintegracin.
40horasporsemana
Sedebetrabajarunmximode40horasporsemana.Nosetrabajanhorasextrasendos
semanas seguidas. Si esto ocurre, probablemente est ocurriendo un problema que debe
corregirse.Eltrabajoextradesmotivaalequipo.Losproyectosquerequierentrabajoextra
paraintentarcumplirconlosplazossuelenalfinalserentregadosconretraso.Enlugarde
estosepuederealizareljuegodelaplanificacinparacambiarelmbitodelproyectoola
fechadeentrega.
Clienteinsitu
El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Gran parte
http://www.cyta.com.ar/ta0502/v5n2a1.htm

12/15

3/10/2015

CyTA

del xito del proyecto XP se debe a que es el cliente quien conduce constantemente el
trabajohacialoqueaportarmayorvalordenegocioylosprogramadorespuedenresolver
demanerainmediatacualquierdudaasociada.Lacomunicacinoralesmsefectivaquela
escrita,yaqueestaltimatomamuchotiempoengenerarseypuedetenermsriesgode
ser mal interpretada. En [12] Jeffries indica que se debe pagar un precio por perder la
oportunidaddeunclienteconaltadisponibilidad.Algunasrecomendacionespropuestaspara
dicha situacin son las siguientes: intentar conseguir un representante que pueda estar
siempredisponibleyqueactecomointerlocutordelcliente,contarconelclientealmenos
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.
Estndaresdeprogramacin
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).Losestndaresdeprogramacinmantienenelcdigolegibleparalosmiembros
delequipo,facilitandoloscambios.
Comentariosrespectodelasprcticas
El mayor beneficio de las prcticas se consigue con su aplicacin conjunta y equilibrada
puestoqueseapoyanunasenotras.EstoseilustraenlaFigura1(obtenidade[2]),donde
unalneaentredosprcticassignificaquelasdosprcticasserefuerzanentres.
LamayoradelasprcticaspropuestasporXPnosonnovedosassinoqueenalgunaforma
ya haban sido propuestas en ingeniera del software e incluso demostrado su valor en la
prctica (ver [1] para un anlisis histrico de ideas y prcticas que sirven como
antecedentesalasutilizadasporlasmetodologasgiles).ElmritodeXPesintegrarlasde
unaformaefectivaycomplementarlasconotrasideasdesdelaperspectivadelnegocio,los
valoreshumanosyeltrabajoenequipo.

Figura1.Lasprcticasserefuerzanentres

6.CONCLUSIONES
No existe una metodologa universal para hacer frente con xito a cualquier proyecto de
desarrollo de software. Toda metodologa debe ser adaptada al contexto del proyecto
(recursos tcnicos y humanos, tiempo de desarrollo, tipo de sistema, etc. Histricamente,
http://www.cyta.com.ar/ta0502/v5n2a1.htm

13/15

3/10/2015

CyTA

las metodologas tradicionales han intentado abordar la mayor cantidad de situaciones de

contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo
en proyectos pequeos y con requisitos muy cambiantes. Las metodologas giles ofrecen
una solucin casi a medida para una gran cantidad de proyectos que tienen estas
caractersticas. Una de las cualidades ms destacables en una metodologa gil es su
sencillez, tanto en su aprendizaje como en su aplicacin, reducindose as los costos de
implantacin en un equipo de desarrollo. Esto ha llevado hacia un inters creciente en las
metodologas giles. Sin embargo, hay que tener presente una serie de inconvenientes y
restricciones para su aplicacin, tales como: estn dirigidas a equipos pequeos o
medianos (Beck sugiere que el tamao de los equipos se limite de 3 a 20 como mximo,
otros dicen no ms de 10 participantes), el entorno fsico debe ser un ambiente que
permita la comunicacin y colaboracin entre todos los miembros del equipo durantetodo
eltiempo,cualquierresistenciadelclienteodelequipodedesarrollohacialasprcticasy
principios puede llevar al proceso al fracaso (el clima de trabajo, la colaboracin y la
relacin contractual son claves), el uso de tecnologas que no tengan un ciclo rpido de
realimentacinoquenosoportenfcilmenteelcambio,etc.
Falta an un cuerpo de conocimiento consensuado respecto de los aspectos tericos y
prcticosdelautilizacindemetodologasgiles,ascomounamayorconsolidacindelos
resultados de aplicacin. La actividad de investigacin est orientada hacia lneas tales
como: mtricas y evaluacin del proceso, herramientas especficas para apoyar prcticas
giles,aspectoshumanosydetrabajoenequipo.Entreestosesfuerzosdestacanproyectos
comoNAME12 (Network for Agile Methodologies Experience) en el cual hemos participado
comonodoenEspaa.
Aunqueenlaactualidadyaexistenlibrosasociadosacadaunadelasmetodologasgiles
existentesytambinabundanteinformacinenInternet,esXPlametodologaqueresalta
por contar con la mayor cantidad de informacin disponible y es con diferencia la ms
popular.

REFERENCIASBIBLIOGRFICAS

[1] Abrahamsson,P.,Salo,O.,Ronkainen,J.,Warsta,J."Agilesoftwaredevelopment
methodsReviewandanalysis".VTTPublications.2002.
[2] Beck,K.."ExtremeProgrammingExplained.EmbraceChange",PearsonEducation,
1999.Traducidoalespaolcomo:"Unaexplicacindelaprogramacinextrema.
Aceptarelcambio",AddisonWesley,2000.
[3] CoadP.,LefebvreE.,DeLucaJ."JavaModelingInColorWithUML:Enterprise
ComponentsandProcess".PrenticeHall.1999.
[4] Cockbun,A.,Williams,L."TheCostsandBenefitsofPairProgramming".Humansand
TechnologyTechnicalReport.2000.
[5] Cockbun,A."AgileSoftwareDevelopment".AddisonWesley.2001.
[6] Fowler,M."IsDesignDead?".2001.www.martinfowler.com/articles/designDead.html
[7] Fowler,M.,FoemmelM."ContinuousIntegration".2001.
www.martinfowler.com/articles/designDead.html
[8] Fowler,M.,Beck,K.,Brant,J."Refactoring:ImprovingtheDesignofExistingCode".
AddisonWesley.1999
[9] HighsmithJ.,OrrK."AdaptiveSoftwareDevelopment:ACollaborativeApproachto
ManagingComplexSystems".DorsetHouse.2000.
[10] Highsmith,J."AgileSoftwareDevelopmentEcosystems".AddisonWesley.2002.
[11] Jacobson,I."ObjectOrientedSoftwareEngineering".AddisonWesley.1994.
[12] Jeffries,R.,Anderson,A.,Hendrickson,C."ExtremeProgrammingInstalled".
AddisonWesley.2001
[13] Martin,R."ContinuosCarevs.InitialDesign".2002.
www.objectmentor.com/resources/articles/Continuous_Care.pdf
[14] Newkirk,J.,MartinR.C."ExtremeProgramminginPractice".AddisonWesley.2001.
[15] PoppendieckM.,PoppendieckT."LeanSoftwareDevelopment:AnAgileToolkitfor
SoftwareDevelopmentManagers".AddisonWesley.2003.
http://www.cyta.com.ar/ta0502/v5n2a1.htm

14/15

3/10/2015

CyTA

[16] SchwaberK.,BeedleM.,MartinR.C."AgileSoftwareDevelopmentwithSCRUM".
PrenticeHall.2001.
[17] StapletonJ."DsdmDynamicSystemsDevelopmentMethod:TheMethodinPractice".
AddisonWesley.1997.
[18] Wake,W.C."ExtremeProgrammingExplored".AddisonWesley.2002.

Notas

[volver]

[volver]

XPAgileUniverse:www.agileuniverse.com.ConferenceoneXtremeProgrammingandAgile
ProcessesinSoftwareEngineering:www.xp2004.org.AgileDevelopmentConference(EEUU):
www.agiledevelopmentconference.com.AgileDevelopmentConference(Australia):
www.softed.com/adc2003/
agilemanifesto.org

[volver]

www.agilealliance.com

[volver]

www.controlchaos.com

[volver]

www.crystalmethodologies.org

[volver]

www.dsdm.org

[volver]

www.adaptivesd.com

[volver]

www.featuredrivendevelopment.com

[volver]

www.poppendieck.com

[volver]

10 www.sei.cmu.edu/cmm/cmm.html

[volver]

11 www.extremeprogramming.org,www.xprogramming.com,c2.com/cgi/wiki?
ExtremeProgramming
12 name.case.unibz.it/

[volver]

TcnicaAdministrativa,BuenosAires
ISSN16661680
http://www.cyta.com.ar

Volumen:05
Nmero:26
abril/junio2006

Recibidoel:15/12/2005Aprobadoel:15/01/2006

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

15/15