"Año de la Diversificación Productiva y del Fortalecimiento de la Educación"
UNIVERSIDAD NACIONAL DE TRUJILLO ESCUELA ACADÉMICO PROFESIONAL DE INGENIERÍA DE SISTEMAS TEMA: “PROGRAMACIÓN EXTREMA” EXTREMA”
ALUMNOS: Alcalde Moncada Jhonatan Campos Cabanillas Walter Wilmer De Piérola Chávez Luis Alberto Ulfe sla José Alberto
CURSO: Ingeniería de Software Apliada a O!"eto#
CICLO: $III
Guadalupe Perú 2!"
%
&NI$ERSI'A' NACIONA( 'E TR&)I((O
Contenido Capítulo I Introducción y Reseña Histórica ******************************************************************+ Introducción*******************************************************************************************************, Resumen**********************************************************************************************************%% Abstract***********************************************************************************************************%1.
Reseña Histórica*****************************************************************************************%.
2.
Concep ncepto toss Ge Gene nera ralles************************************************************************************%/
3.
Deinición**************************************************************************************************%/
!.
"ost "ostur uras as a a# a#or or y en en con contr traa**************************************************************************%0
$.
"rinci incipi pioos %&si &sicos cos****************************************************************************************%0 $.1. $.1.
Retr Retroa oali lime ment ntac ació ión n a esca escala la in inaa****************************************************************%0
$.2. $.2.
"roc "roces esoo con conti tinu nuoo en en lu' lu'ar ar de por por lot lotes es*******************************************************%,
$.3. .3.
(nten ntendi dim miento ento com compart partid idoo**********************************************************************%1
$.!. $.!.
%ien %ienes esta tarr del del pro' pro'ra ram mador ador**********************************************************************-2
Capítulo II )ases de la metodolo'ía *" *********************************************************************-1.
"roceso eso de de des desaarro rrollo************************************* ********************************************************* **************************************** *************************** *******-. -.
2.
Inte Intera racc cció ión n con con el clie client ntee*******************************************************************************-.
3.
Histo istori riaa de +sua +suari rioo**************************************************************************************-. 3.1.
(n la la pr primera a ase*********************************************************************************-.
3.2.
(n la la se se'unda a ase*********************************************************************************-3
!.
"lan "lani iic icac ació ión n del del pro proyect yectoo******************************************************************************-/
$.
Dis Diseño, eño, des desar arro roll llo, o, pru prueb ebas as****************************************************************************-0
-.
et&ora*************************************** ********************************************************** *************************************** ****************************************** **********************-+ -+
/.
)ase )asess de de la la met metod odol olo' o'ía ía *"****************************************************************************-1
.
/.1. /.1.
)ase )ase00 "lan "lani iic icac ació ión n del del pro proyect yectoo***************************************************************-1
/.2.
)ase0 Diseño*****************************************************************************************.%
/.3. .3.
)ase0 Co Codiicación *********************************************************************************.-
/.!.
)ase0 "ruebas***************************************************************************************.-
alore loress de de la la meto metodo dolo lo'í 'íaa *" *" *************************************************************************.3 .1.
implicidad******************************************************************************************.3
.2.
Comunicación************************************* ********************************************************* **************************************** ****************************** **********./ ./
.3. .3.
Retroalimentación *********************************************************************************./
METO'O(OGOG4A XP
-
&NI$ERSI'A' NACIONA( 'E TR&)I((O
Contenido Capítulo I Introducción y Reseña Histórica ******************************************************************+ Introducción*******************************************************************************************************, Resumen**********************************************************************************************************%% Abstract***********************************************************************************************************%1.
Reseña Histórica*****************************************************************************************%.
2.
Concep ncepto toss Ge Gene nera ralles************************************************************************************%/
3.
Deinición**************************************************************************************************%/
!.
"ost "ostur uras as a a# a#or or y en en con contr traa**************************************************************************%0
$.
"rinci incipi pioos %&si &sicos cos****************************************************************************************%0 $.1. $.1.
Retr Retroa oali lime ment ntac ació ión n a esca escala la in inaa****************************************************************%0
$.2. $.2.
"roc "roces esoo con conti tinu nuoo en en lu' lu'ar ar de por por lot lotes es*******************************************************%,
$.3. .3.
(nten ntendi dim miento ento com compart partid idoo**********************************************************************%1
$.!. $.!.
%ien %ienes esta tarr del del pro' pro'ra ram mador ador**********************************************************************-2
Capítulo II )ases de la metodolo'ía *" *********************************************************************-1.
"roceso eso de de des desaarro rrollo************************************* ********************************************************* **************************************** *************************** *******-. -.
2.
Inte Intera racc cció ión n con con el clie client ntee*******************************************************************************-.
3.
Histo istori riaa de +sua +suari rioo**************************************************************************************-. 3.1.
(n la la pr primera a ase*********************************************************************************-.
3.2.
(n la la se se'unda a ase*********************************************************************************-3
!.
"lan "lani iic icac ació ión n del del pro proyect yectoo******************************************************************************-/
$.
Dis Diseño, eño, des desar arro roll llo, o, pru prueb ebas as****************************************************************************-0
-.
et&ora*************************************** ********************************************************** *************************************** ****************************************** **********************-+ -+
/.
)ase )asess de de la la met metod odol olo' o'ía ía *"****************************************************************************-1
.
/.1. /.1.
)ase )ase00 "lan "lani iic icac ació ión n del del pro proyect yectoo***************************************************************-1
/.2.
)ase0 Diseño*****************************************************************************************.%
/.3. .3.
)ase0 Co Codiicación *********************************************************************************.-
/.!.
)ase0 "ruebas***************************************************************************************.-
alore loress de de la la meto metodo dolo lo'í 'íaa *" *" *************************************************************************.3 .1.
implicidad******************************************************************************************.3
.2.
Comunicación************************************* ********************************************************* **************************************** ****************************** **********./ ./
.3. .3.
Retroalimentación *********************************************************************************./
METO'O(OGOG4A XP
-
.!. .!.
Cora4e o #alentía***********************************************************************************.0
enta4 enta4as as y Des# Des#ent enta4a a4ass de la eto etodol dolo' o'ía ía *" *" ****************************************************.0
5. 16.
Incon#enientes*****************************************************************************************.0
11.
Herra erram mient ientaas em emplea pleada dass en en *" *"*******************************************************************.+
11.1.
7AA***********************************************************************************************.+
11.2.
8(9%eans****************************************************************************************.+
11.3.
7+nit***********************************************************************************************.+
11.!.
7asperReport e IR IReport***********************************************************************.+
11.$.
"ost're:;**************************************************************************************.,
12. 12.
9ablas blas Com Compa para rati ti#a #ass de las las et etod odol olo' o'ía íass CR+ CR+ y *" **********************************.,
12.1.
eme4an
12.2.
Dierencias****************************************************************************************.1
13. 13.
"ers "erson onas as =ue =ue int inter er#i #ien enen en en la eto etodo dolo lo'í 'íaa *" *"**********************************************.1
Capítulo III Conclusiones ***************************************************************************************/3 1!.
Conclusiones*******************************************************************************************//
>ndice de tablas 9A%;A 1. "+89? A )A?R @ (8 C?89RA **********************************************************************%0 9A%;A 2. "R+(%A D( AC("9ACI8*********************** ************************************ ************************* ****************************************** ****************************** %+ 9A%;A 3. HI9?RIA D( ++ARI?***********************************************************************************-/ 9A%;A !. (89A7A @ D((89A7A D( ;A (9?D?;?G>A *"*************************************.0 9A%;A $. C?"ARACI8 (89R( (9?D?;?G>A********************************************************.1
>ndice de i'uras )IG+RA 1*********************** *********************************** ************************ ************************* ************************* ************************ ************************ *********************************** *********************** -% )IG+RA 2*********************** *********************************** ************************ ************************* ************************* ************************ ************************ *********************************** *********************** -% )IG+RA 3*********************** *********************************** ************************ ************************* ************************* ************************ ************************ *********************************** *********************** -, )IG+RA !*********************** *********************************** ************************ ************************* ************************* ************************ ************************ *********************************** *********************** .. )IG+RA $*********************** *********************************** ************************ ************************* ************************* ************************ ************************ *********************************** *********************** .3
Capítulo I Introducción y Reseña Histórica Introducción !n las dos "ltimas décadas las notaciones de modelado # posteriormente las herramientas pretendieron ser las $balas de plata$ para el é%ito en el desarrollo de soft&are' sin embar(o' las e%pectativas no fueron satisfechas) !sto se debe en (ran parte a *ue otro importante elemento' la metodolo(+a de desarrollo' hab+a sido poster(ado) De nada sirven buenas notaciones # herramientas si no se proveen directivas para su aplicaci,n) As+' esta década ha comenzado con un creciente interés en metodolo(+as de desarrollo) -asta hace poco el proceso de desarrollo llevaba asociada un marcado énfasis en el control del proceso mediante una ri(urosa definici,n de roles' actividades # artefactos' inclu#endo modelado # documentaci,n detallada) !ste es*uema $tradicional$ para abordar el desarrollo de soft&are ha demostrado ser efectivo # necesario en pro#ectos de (ran tama.o /respecto a tiempo # recursos0' donde por lo (eneral se e%i(e un alto (rado de ceremonia en el proceso) 1in embar(o' este enfo*ue no resulta ser el más adecuado para muchos de los pro#ectos actuales donde el entorno del sistema es mu# cambiante' # en donde se e%i(e reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad) Ante las dificultades para utilizar metodolo(+as tradicionales con estas restricciones de tiempo # fle%ibilidad' muchos e*uipos de desarrollo se resi(nan a prescindir del 2buen hacer3 de la in(enier+a del soft&are' asumiendo el ries(o *ue ello conlleva) !n este escenario' las metodolo(+as á(iles emer(en como una posible respuesta para llenar ese vac+o metodol,(ico) Por estar especialmente orientadas para pro#ectos pe*ue.os' las metodolo(+as á(iles constitu#en una soluci,n a medida para ese entorno' aportando una elevada simplificaci,n *ue a pesar de ello no renuncia a las prácticas esenciales para ase(urar la calidad del producto) Las metodolo(+as á(iles son sin duda uno de los temas recientes en in(enier+a de soft&are *ue están acaparando (ran interés) Prueba de ello es *ue se están haciendo un espacio destacado en la ma#or+a de conferencias # &or4shops celebrados en los "ltimos a.os) !s tal
su impacto *ue actualmente e%isten 5 conferencias internacionales de alto nivel # espec+ficas sobre el tema6) Además #a es un área con cabida en presti(iosas revistas internacionales) !n la comunidad de la in(enier+a del soft&are' se está viviendo con intensidad un debate abierto entre los partidarios de las metodolo(+as tradicionales /referidas pe#orativamente como $metodolo(+as pesadas$0 # a*uellos *ue apo#an las ideas emanadas del $Manifiesto 7(il$8) La curiosidad *ue siente la ma#or parte de in(enieros de soft&are' profesores' e incluso alumnos' sobre las metodolo(+as á(iles hace prever una fuerte pro#ecci,n industrial) Por un lado' para muchos e*uipos de desarrollo el uso de metodolo(+as tradicionales les resulta mu# le9ano a su forma de traba9o actual considerando las dificultades de su introducci,n e inversi,n asociada en formaci,n # herramientas) Por otro' las caracter+sticas de los pro#ectos para los cuales las metodolo(+as á(iles han sido especialmente pensadas se a9ustan a un amplio ran(o de pro#ectos industriales de desarrollo de soft&are: a*uellos en los cuales los e*uipos de desarrollo son pe*ue.os' con plazos reducidos' re*uisitos volátiles' #;o basados en nuevas tecnolo(+as) •
Proceso < con9unto de actividades ordenadas para lo(rar una serie de ob9etivos
•
Proceso Pesado < = >uerte dependencia de planificaciones = 1e establecen actividades = 1e establecen artefactos = 1e establecen herramientas # notaciones = !1?AM@1 MU C@B?@LAD@1
•
Como contraposici,n< Metodolo(+a 7(il
•
Caracter+sticas<
A los individuos # su interacci,n por encima de los procesos # las herramientas !l soft&are *ue funciona por encima de la documentaci,n e%haustiva La colaboraci,n con el cliente por encima la ne(ociaci,n contractual La respuesta al cambio por encima se(uimiento de un plan
•
•
•
esumen = !stamos menos controlado = Preparados para el cambio = Cliente forma parte del e*uipo = Pocos artefactos = Más importante soft&are funcionando *ue documentaci,n !stad+sticas < método *ue más popularidad ha alcanzado de las metodolo(+as á(iles 1e basa en la suposici,n de *ue es posible desarrollar soft&are de (ran calidad a pesar' o incluso como consecuencia del cambio continuo Asume *ue con un poco de planificaci,n' un poco de codificaci,n # unas pocas pruebas se puede decidir si se está si(uiendo un camino acertado o e*uivocado' evitando as+ tener *ue echar marcha atrás demasiado tarde) Ealores *ue inspiran FP
1implicidad< La simplicidad consiste en desarrollar s,lo el sistema *ue realmente se necesita) mplica resolver en cada momento s,lo las necesidades actuales) Los costos # la comple9idad de predecir el futuro son mu# elevados' # la me9or forma de acertar es esperar al futuro) Con este principio de simplicidad' 9unto con la comunicaci,n # el feedbac4 resulta más fácil conocer las necesidades reales
>eedbac4< Una metodolo(+a basada en el desarrollo incremental iterativo de pe*ue.as partes' con entre(as # pruebas frecuentes # continuas' proporciona un flu9o de retroinformaci,n valioso para detectar los problemas o desviaciones) De esta forma fallos se localizan mu# pronto) La planificaci,n no puede evitar al(unos errores' *ue s,lo se evidencian al desarrollar el sistema) La retroinformaci,n es la herramienta *ue permite rea9ustar la a(enda # los planes)
Cora9e< mplica saber tomar decisiones dif+ciles) eparar un error cuando se detecta Me9orar el c,di(o siempre *ue tras el feedbac4 # las sucesivas iteraciones se manifieste susceptible de me9ora ?ratar rápidamente con el cliente los desa9ustes de a(endas para decidir *ué partes # cuándo se van a entre(ar Comunicaci,n< FP pone en comunicaci,n directa # continua a clientes # desarrolladores) !l cliente se inte(ra en el e*uipo para establecer prioridades # resolver dudas) De esta forma ve el avance d+a a d+a' # es posible a9ustar la a(enda # las funcionalidades de forma consecuente
Resumen !l desarrollo de soft&are no es una tarea fácil) Prueba de ello es *ue e%isten numerosas propuestas metodol,(icas *ue inciden en distintas dimensiones del proceso de desarrollo) Por una parte tenemos a*uellas propuestas más tradicionales *ue se centran especialmente en el control del proceso' estableciendo ri(urosamente las actividades involucradas' los artefactos *ue se deben producir' # las herramientas # notaciones *ue se usarán) !stas propuestas han demostrado ser efectivas # necesarias en un (ran n"mero de pro#ectos' pero también han presentado problemas en otros muchos) Una posible me9ora es incluir en los procesos de desarrollo más actividades' más artefactos # más restricciones' basándose en los puntos débiles detectados) 1in embar(o' el resultado final ser+a un proceso de desarrollo más comple9o *ue puede incluso limitar la propia habilidad del e*uipo para llevar a cabo el pro#ecto) @tra apro%imaci,n es centrarse en otras dimensiones' como por e9emplo el factor humano o el producto soft&are) !sta es la filosof+a de las metodolo(+as á(iles' las cuales dan ma#or valor al individuo' a la colaboraci,n con el cliente # al desarrollo incremental del soft&are con iteraciones mu# cortas) !ste enfo*ue está mostrando su efectividad en pro#ectos con re*uisitos mu# cambiantes # cuando se e%i(e reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad) Las metodolo(+as á(iles están revolucionando la manera de producir soft&are' # a la vez (enerando un amplio debate entre sus se(uidores # *uienes por escepticismo o convencimiento no las ven como alternativa para las metodolo(+as tradicionales) !n este traba9o se presenta resumidamente el conte%to en el *ue sur(en las metodolo(+as á(iles' sus valores' principios # comparaciones con las metodolo(+as tradicionales) Además se describe con ma#or detalle Pro(ramaci,n !%trema /eFtreme Pro(rammin(' FP0 la metodolo(+a á(il más popular en la actualidad)
"alabras Cla#e0
Procesos de soft&are' Metodolo(+as á(iles' Pro(ramaci,n !%trema
/eFtreme Pro(rammin(0
Abstract ?he development of soft&are is not an eas# tas4) ?he proof for that is the fact that there are man# methodolo(ical proposals that affect different dimensions of the development process) @n one hand' &e can find more traditional proposals' &hich are speciall# centred in the control of the process b# ri(orousl# settin( the involved activities' the devices that are due to produce' and the tools and annotations that &ill be used) ?hese proposals have demonstrated to be effective and necessar# in a (reat number of pro9ects' but also the# have presented problems in others) A possible improvement for that is to include more activities' devices and restrictions in the development processes' &hich is based on the &ea4 points that &ere detected) Bevertheless' the final result &ould be a morecomple% process of development &hich can even limit the o&n abilit# of the e*uipment to develop the pro9ect) Another approach is focusin( in other dimensions' for e%ample the human factor or the soft&are product) ?his is the philosoph# of the a(ile methodolo(ies' &hich (ive (reater value to the individual' to the collaboration &ith the client and the incremental development of soft&are &ith ver# short iterations) ?his approach is presentin( its effectiveness in pro9ects &ith chan(in( re*uirements and &hen it is demanded to reduce drasticall# the times of development but maintainin( a hi(h *ualit#) ?he a(ile methodolo(ies are revolutionizin( the &a# to produce soft&are and' at the same time' the# are (eneratin( an considerable debate bet&een their follo&ers and the ones that' b# scepticism or conviction' do not see them as an alternative for traditional methodolo(ies) n this &or4 it is briefl# presented the conte%t in &hich the a(ile methodolo(ies emer(e' their values' principles and comparisons &ith traditional methodolo(ies) n addition' it is described in detail the most popular a(ile methodolo(# at the present time< eFtreme Pro(rammin()
Beyords0 1oft&are process: a(ile methods: eFtreme Pro(rammin(
1. Reseña Histórica La pro(ramaci,n e%trema' como proceso de creaci,n de soft&are diferente al convencional' nace de la mano de Gent Hec4 /(ur" de la FP # autor de los libros más influ#entes sobre el tema0) Chr#sler Corporation hac+a tiempo *ue estaba desarrollando una aplicaci,n de n,minas' pero sin demasiado é%ito por parte de la (ente *ue ten+a en el pro#ecto) !l verano de 6II' Hec4 entr, en n,mina en la compa.+a # se le pidi, de hacer esta aplicaci,n como traba9o) !s en esta aplicaci,n cuando nace la Pro(ramaci,n !%trema como tal) Hec4 reconoci, *ue el proceso /o metodolo(+a0 de creaci,n de soft&are o la carencia de este era la causa de todos los problemas # lle(, a la conclusi,n *ue para proporcionar un proceso *ue fuera fle%ible era necesario realizar ciertos cambios en la estructura o manera de hacer de los pro(ramadores' los cuales se ten+an *ue acomodar al cambio a realizar) Kl estaba convencido *ue la me9or metodolo(+a era un proceso *ue enfatizase la comunicaci,n dentro del e*uipo' *ue la implementaci,n fuera sencilla' *ue el usuario ten+a *ue estar mu# informado e implicado # *ue la toma de decisiones ten+a *ue ser mu# rápida # efectiva) Los autores /o me9or dicho' los propulsores como el propio Gent Hec4' Ward Cunnin(ham o on Jeffries entre otros0 de la Pro(ramaci,n !%trema' fueron a la &eb Portland Pattern epositor# # empezaron a hablar de ella # promocionarla' de lo *ue era # c,mo realizarla) !stos propulsores de la FP hablaban de ella en cada ocasi,n *ue ten+an # en cada pá(ina *ue' poco o mucho hablara de temas de pro(ramaci,n) Hec4 invit, a on Jeffries al pro#ecto para a#udar a desarrollar # perfeccionar estos métodos) Jeffries partir de entonces actu, como un entrenador para inculcar las prácticas' hábitos en el e*uipo C) La informaci,n sobre los principios # prácticas detrás de FP se difundi, al resto del mundo a través de discusiones en el &i4i ori(inal' Wi4iWi4iWeb de Cunnin(ham) Earios colaboradores discuten # se e%pandieron en las ideas' # al(unas metodolo(+as spinoff resultado) Además' se han e%plicado los conceptos FP' desde hace varios a.os'
con
un
mapa
del
sistema
de
hiperte%to
en
el
sitio
&eb
en
FP
$http<;;&&&)e%tremepro(rammin()or($ alrededor de 6III) Hec4 edit, una serie de libros sobre FP' empezando por su propia Pro(ramaci,n !%trema !%plicada' difundiendo sus ideas a una mucho más (rande' pero mu# receptivo' audiencia) Los autores de la serie pasaron por diversos aspectos *ue asisten a FP # sus prácticas)
2. Conceptos Generales Las metodolo(+as á(iles /como por e9emplo FP' 1CUM' D1DM' Cr#stal' etc)0 forman parte del movimiento de desarrollo á(il de sotf&are' *ue se basan en la adaptabilidad de cual*uier cambio como medio para aumentar las posibilidades de é%ito de un pro#ecto) De forma *ue una metodolo(+a á(il es la *ue tiene como principios *ue< •
• • •
Los individuos # sus interacciones son más importantes *ue los procesos # las herramientas) !l soft&are *ue funciona es más importante *ue la documentaci,n e%haustiva) La colaboraci,n con el cliente en lu(ar de la ne(ociaci,n de contratos) La respuesta delante del cambio en lu(ar de se(uir un plan cerrado)
1e puede decir *ue' este movimiento empez, a e%istir a partir de febrero de 86' cuando se reunieron los representantes de cada una de estas metodolo(+as # terminaron poniendo en com"n sus ideas en una declaraci,n con9unta)
3. Deinición La pro(ramaci,n e%trema es una metodolo(+a de desarrollo li(era /o á(il0 basada en una serie de valores # de prácticas de buenas maneras *ue persi(ue el ob9etivo de aumentar la productividad a la hora de desarrollar pro(ramas) !ste modelo de pro(ramaci,n se basa en una serie de metodolo(+as de desarrollo de soft&are en la *ue se da prioridad a los traba9os *ue dan un resultado directo # *ue reducen la burocracia *ue ha# alrededor de la pro(ramaci,n) Una de las caracter+sticas principales de este método de pro(ramaci,n' es *ue sus in(redientes son conocidos desde el principio de la informática) Los autores de FP han seleccionado a*uellos *ue han considerado me9ores # han profundizado en sus relaciones # en c,mo se refuerzan los unos con los otros) !l resultado de esta selecci,n ha sido esta metodolo(+a "nica # compacta) Por esto' aun*ue no está basada en principios nuevos' s+ *ue el resultado es una nueva manera de ver el desarrollo de soft&are)
!l ob9etivo *ue se perse(u+a en el momento de crear esta metodolo(+a era la b"s*ueda de un método *ue hiciera *ue los desarrollos fueran más sencillos) Aplicando el sentido com"n)
!. "osturas a a#or y en contra 9abla 1. "untos a a#or y en contra A a#or
(n contra
F)P) s,lo funcionará con (ente buena' es Los pro(ramadores tienen un acusado decir' profesionales *ue son capaces de sentimiento de posesi,n del c,di(o # esta hacer un buen dise.o' sencillo # a la vez postura no enca9a con la filosof+a de F)P) fácilmente ampliable) ?ambién se ve un fuerte sentimiento para Por otro lado se ha de recalcar *ue FP no respectar las 5 horas semanales' # F)P) no ha inventado nin("n método nuevo' lo (arantiza) sencillamente ha reco(ido métodos #a e%istentes # los ha a(rupado' # ha Los 9efes de pro#ecto también e%presan su comprobado *ue funcionen)
recelo
con
este
método
tan
poco
tradicional) )uente0 E(laboración propia, 261!F
$. "rincipios %&sicos La pro(ramaci,n e%trema se basa en 68 principios básicos a(rupados en cuatro cate(or+as<
$.1. Retroalimentación a escala ina $.1.1. (l principio de pruebas 1e tiene *ue establecer un periodo de pruebas de aceptaci,n del pro(ramaci,n /llamada también periodo de ca9a ne(ra0 donde se definirán las entradas al sistema # los resultados esperados de estas entradas) !s mu# recomendable automatizar estas pruebas para poder hacer varias simulaciones del sistema del sistema en funcionamiento) Para hacer estas simulaciones automatizadas' se puede utilizar Ambientes de Prueba /Unit testin( frame&or4s0)
9abla 2. "ruebas de Aceptación Caso de Prueba B"mero Caso de Prueba< Descripci,n<
B"mero -istoria de Usuario<
Condiciones de e9ecuci,n< !ntradas< esultado esperado< !valuaci,n<
)uente0 E(laboración propia, 261!F $.1.2. "roceso de planiicación !n esta fase' el usuario tendrá *ue escribir sus necesidades' definiendo las actividades *ue realizará el sistema) 1e creará un documento llamado -istorias del usuario /User 1tories0) !ntre 8 # N historias /todo dependiendo de la comple9idad del problema0 se consideran suficientes para formar el llamado Plan de Liberaci,n' el cual define de forma espec+fica los tiempos de entre(a de la aplicaci,n para recibir retroalimentaci,n por parte del usuario) 1on mu# importantes # tienen *ue ser una constante las reuniones peri,dicas durante esta fase de planificaci,n) !stas pueden ser a diario' con todo el e*uipo de desarrollo para identificar problemas' proponer soluciones # se.alar a*uellos puntos a los *ue se les ha de dar más importancia por su dificultad o por su punto cr+tico)
$.1.3. (l cliente en el sitio 1e le dará poder para determinar los re*uerimientos' definir la funcionalidad' se.alar las prioridades # responder las pre(untas de los pro(ramadores) !sta fuerte interacci,n cara a cara con el pro(ramador disminu#e el tiempo de comunicaci,n # la cantidad de documentaci,n' 9unto con los altos costes de su creaci,n # mantenimiento)
$.1.!. "ro'ramación en pare4as Uno de los principios más radicales # en el *ue la ma#or+a de (erentes de desarrollo pone sus dudas) e*uiere *ue todos los pro(ramadores FP escriban
su c,di(o en pare9as' compartiendo una sola má*uina) De acuerdo con los e%perimentos' este principio puede producir aplicaciones más buenas' de manera consistente' a i(uales o menores costes)
$.2. "roceso continuo en lu'ar de por lotes $.2.1. Inte'ración continua Permite al e*uipo hacer un rápido pro(reso implementando las nuevas caracter+sticas del soft&are) !n lu(ar de crear builds /o versiones0 estables de acuerdo a un crono(rama establecido' los e*uipos de pro(ramadores FP pueden reunir su c,di(o # reconstruir el sistema varias veces al d+a) !sto reduce los problemas de inte(raci,n comunes en pro#ectos lar(os # estilo cascada) 5.2.2.
Reactori
Permite a los e*uipos de pro(ramadores FP me9orar el dise.o del sistema a través de todo el proceso de desarrollo) Los pro(ramadores eval"an continuamente el dise.o # recodifican lo necesario) La finalidad es mantener un sistema enfocado a proveer el valor de ne(ocio mediante la minimizaci,n del c,di(o duplicado #;o ineficiente)
$.2.3. (ntre'as pe=ueñas Colocan un sistema sencillo en producci,n rápidamente *ue se actualiza de forma rápida # constante permitiendo *ue el verdadero valor de ne(ocio del producto sea evaluado en un ambiente real) !stas entre(as no pueden pasar las 8 o semanas como má%imo)
$.3. (ntendimiento compartido $.3.1. Diseño simple 1e basa en la filosof+a de *ue el ma#or valor de ne(ocio es entre(ado por el pro(rama más sencillo *ue cumpla los re*uerimientos) 1imple Desi(n se enfoca en proporcionar un sistema *ue cubra las necesidades inmediatas del cliente' ni más ni menos) !ste proceso permite eliminar redundancias # re9uvenecer los dise.os obsoletos de forma sencilla)
$.3.2. et&ora Desarrollada por los pro(ramadores al inicio del pro#ecto' define una historia de c,mo funciona el sistema completo) FP estimula historias' *ue son breves descripciones de un traba9o de un sistema en lu(ar de los tradicionales dia(ramas # modelos UML /Unified Modelin( Lan(ua(e0) La metáfora e%presa la visi,n evolutiva del pro#ecto *ue define el alcance # prop,sito del sistema) Las tar9etas CC /Clase' esponsabilidad # Colaboraci,n0 también a#udarán al e*uipo a definir actividades durante el dise.o del sistema) Cada tar9eta representa una clase en la pro(ramaci,n orientada a ob9etos # define sus responsabilidades /lo *ue ha de hacer0 # las colaboraciones con las otras clases /c,mo se comunica con ellas0)
$.3.3. "ropiedad colecti#a del códi'o Un c,di(o con propiedad compartida) Badie es el propietario de nada' todos son el propietario de todo) !ste método difiere en mucho a los métodos tradicionales en los *ue un simple pro(ramador posee un con9unto de c,di(o) Los defensores de FP ar(umentan *ue mientras ha#a más (ente traba9ando en una pieza' menos errores aparecerán)
$.3.!. (st&ndar de codiicación Define la propiedad del c,di(o compartido as+ como las re(las para escribir # documentar el c,di(o # la comunicaci,n entre diferentes piezas de c,di(o desarrolladas por diferentes e*uipos) Los pro(ramadores las han de se(uir de tal manera *ue el c,di(o en el sistema se vea como si hubiera estado escrito por una sola persona)
$.!. %ienestar del pro'ramador $.!.1. ;a semana de !6 oras La pro(ramaci,n e%trema sostiene *ue los pro(ramadores cansados escriben c,di(o de menor cualidad) Minimizar las horas e%tras # mantener los pro(ramadores frescos' (enerará c,di(o de ma#or calidad)
)uente0 E(laboración propia, 261!F
)uente0 E(laboración propia, 261$F
Capítulo II )ases de la metodolo'ía *"
1. "roceso de desarrollo La pro(ramaci,n e%trema parte del caso habitual de una compa.+a *ue desarrolla soft&are' normalmente a medida' en la *ue ha# diferentes roles< un e*uipo de (esti,n /o dise.o0' uno de desarrollo # los clientes finales) La relaci,n entre el e*uipo de dise.o' los *ue desarrollan el soft&are # clientes es totalmente diferente al *ue se ha producido en las metodolo(+as tradicionales' *ue se basaba en una fase de captura de los re*uisitos previa al desarrollo' # de una fase de validaci,n posterior al mismo)
2. Interacción con el cliente !n este tipo de pro(ramaci,n el cliente pasa a ser parte implicada en el e*uipo de desarrollo) 1u importancia es má%ima en el momento de tratar con los usuarios # en efectuar las reuniones de planificaci,n) ?iene un papel importante de interacci,n con el e*uipo de pro(ramadores' sobre todo después de cada cambio' # de cada posible problema localizado' mostrando las prioridades) !n este tipo de pro(ramaci,n e%istirán pruebas de aceptaci,n de la pro(ramaci,n *ue a#udarán a *ue su labor sea lo más provechosa posible) Al fin # al cabo' el cliente se encuentra mucho más cerca del proceso de desarrollo) 1e elimina la fase inicial de recopilaci,n de re*uerimientos' # se permite *ue éstos se va#an co(iendo a lo lar(o del pro#ecto' de una manera ordenada) De esta forma se posibilita *ue el cliente pueda ir cambiando de opini,n sobre la marcha' pero a cambio han de estar siempre disponibles para solucionar las dudas del e*uipo de desarrollo)
3. Historia de +suario !n FP aparece un nuevo concepto llamado 2-istoria de usuario3) 1e trata de una lista de caracter+sticas *ue el cliente necesita *ue e%istan en el producto final) !stas constan de dos fases)
3.1. (n la primera ase !l cliente describe con sus propias palabras las caracter+sticas #' es el responsable del e*uipo' el encar(ado de informarlo de las dificultades técnicas de cada una de ellas # de su coste) A consecuencia de este diálo(o' el cliente de9a por escrito un con9unto de historias # las ordena en funci,n de la prioridad *ue tienen para él) De esta manera #a es posible definir unas fechas apro%imadas para ellos)
3.2. (n la se'unda ase !l cliente co(erá las primeras historias a implementar # las dividirá en traba9os a realizar) !l cliente también participa' pero ha# más peso por parte del e*uipo de desarrolladores' esto dará como resultado una planificaci,n más e%acta) !ste método se repetirá para cada historia) A diferencia de otras técnicas' como puede ser UML' en el caso de FP' se e%i(e *ue sea el cliente el encar(ado de escribir los documentos con las especificaciones de lo *ue realmente *uiere' como un documento de re*uisitos de usuario) !n esta fase' el e*uipo técnico será el encar(ado de catalo(ar las historias del cliente # asi(narles una duraci,n) La norma es *ue cada historia de usuario tiene *ue poder ser realizable en un espacio entre una # tres semanas de pro(ramaci,n) Las *ue re*uieran menos tiempo serán a(rupadas' # las *ue necesiten más serán modificadas o divididas) >inalmente decir *ue las historias de los usuarios serán escritas en tar9etas' lo *ue facilitará *ue el cliente pueda especificar la importancia relativa entre las diferentes historias de usuario' as+ como el traba9o de los pro(ramadores *ue podrán catalo(arlas correctamente) !ste formato también es mu# "til en el momento de las pruebas de aceptaci,n)
9abla 3. Historia de +suario -istoria de Usuario B"mero< 6 Usuario< Autor Modificaci,n de -istoria B"mero< Prioridad en Be(ocio<
Bombre< !nviar art+culo teraci,n Asi(nada< 8 Alta Puntos !stimados<
/Alta;Media;Ha9a0 ies(os en Desarrollo< Descripci,n
Puntos eales<
1e introducen los datos del art+culo /t+tulo' fichero ad9unto' resumen' t,picos0 # de los autores /nombre' email' afiliaci,n0) Uno de los autores debe indicarse como autor de contacto) !l sistema confirma la correcta recepci,n del art+culo enviando un email al autor de contacto con un userid # pass&ord para *ue el autor pueda posteriormente acceder al art+culo) @bservaciones<
)uente0 E(laboración propia, 261$F !. "laniicación del proyecto !n este punto se tendrá *ue elaborar la planificaci,n por etapas' donde se aplicarán diferentes iteraciones) Para hacerlo será necesaria la e%istencia de re(las *ue se han de se(uir por las partes implicadas en el pro#ecto para *ue todas las partes ten(an voz # se sientan realmente part+cipes de la decisi,n tomada) Las entre(as se tienen *ue hacer cuanto antes me9or' # con cada iteraci,n' el cliente ha de recibir una nueva versi,n) Cuanto más tiempo se tarde en introducir una parte esencial' menos tiempo se tendrá para traba9ar con ella después) 1e aconse9a muchas entre(as # mu# frecuentes) De esta manera un error en la parte inicial del sistema tiene más posibilidades de detectarse rápidamente) Una de las má%imas a aplicar es' los cambios' no han de suponer más horas de pro(ramaci,n para el pro(ramador' #a *ue el *ue no se termina en un d+a' se de9a para el d+a si(uiente) 1e ha de tener asumido *ue en el proceso de planificaci,n habrán errores' es más' serán comunes' # por esto esta metodolo(+a #a los tiene previstos' por lo tanto se establecerán
mecanismos de revisi,n) Cada tres o cinco iteraciones es normal revisar las historias de los usuarios' # rene(ociar la planificaci,n) Cada iteraci,n necesita también ser planificada' es lo *ue se llama planificaci,n iterativa' en la *ue se anotarán las historias de usuarios *ue se consideren esenciales # las *ue no han pasado las pruebas de aceptaci,n) !stas planificaciones también se harán en tar9etas' en las *ue se escribirán los traba9os *ue durarán entre uno # tres d+as) !s por esto *ue el dise.o se puede clasificar como continuo) A.ade a(ilidad al proceso de desarrollo # evita *ue se mire demasiado hacia delante' desarrollando traba9os *ue a"n no han estado pro(ramados) !ste tipo de planificaci,n en iteraciones # el dise.o iterativo' hace *ue aparezca una práctica *ue no e%ist+a en la pro(ramaci,n tradicional) 1e trata de las discusiones diarias informales' para fomentar la comunicaci,n' # para hacer *ue los desarrolladores ten(an tiempo de hablar de los problemas a los *ue se enfrentan # de ver c,mo van con sus traba9os)
$. Diseño, desarrollo, pruebas !l desarrollo es la parte más importante en el proceso de la pro(ramaci,n e%trema) ?odos los traba9os tienen como ob9etivo *ue se pro(ramen lo más rápidamente posible' sin interrupciones # en direcci,n correcta) ?ambién es mu# importante el dise.o' # se establecen los mecanismos' para *ue éste sea revisado # me9orado de manera continuada a lo lar(o del pro#ecto' se("n se van a.adiendo funcionalidades al mismo) La clave del proceso de desarrollar FP es la comunicaci,n) La ma#or+a de los problemas en los pro#ectos son por falta de comunicaci,n en el e*uipo)
-. et&ora !n FP' aparece un nuevo concepto llamado Metáfora) 1u principal ob9etivo es me9orar la comunicaci,n entre todos los inte(rantes del e*uipo' al crear una visi,n (lobal # com"n de lo *ue se *uiere desarrollar) La metáfora tiene *ue ser e%presada en términos conocidos por los inte(rantes del e*uipo' por e9emplo comparando el sistema *ue se desarrollará con al(una cosa de la vida real)
Antes de empezar a codificar se tienen *ue hacer pruebas unitarias' es decir< Cada vez *ue se *uiere implementar una parte de c,di(o' en FP' se tiene *ue escribir una prueba sencilla' # después escribir el c,di(o para *ue la pase) Una vez pasada se ampl+a # se contin"a) !n FP ha# una má%ima *ue dice $?odo el c,di(o *ue puede fallar tiene *ue tener una prueba$) Con estas normas se obtiene un c,di(o simple # funcional de manera bastante rápida) Por esto es importante pasar las pruebas al 6O especto a la inte(raci,n del soft&are' en FP se ha de hacer una inte(raci,n continua' es decir' cada vez se tienen *ue ir inte(rando pe*ue.os fra(mentos de c,di(o' para evitar *ue al finalizar el pro#ecto se ten(a *ue invertir (randes esfuerzos en la inte(raci,n final) !n todo buen pro#ecto de FP' tendr+a *ue e%istir una versi,n al d+a inte(rada' de manera *ue los cambios siempre se realicen en esta "ltima versi,n) @tra peculiaridad de FP es *ue cada pro(ramador puede traba9ar en cual*uier parte del pro(rama) De esta manera se evita *ue ha#a partes $propietarias de cada pro(ramador$) Por esto es tan importante la inte(raci,n diaria) Para terminar' otra peculiaridad *ue tiene la FP) La de fomentar la pro(ramaci,n en pare9as' es decir' hacer *ue los pro(ramadores no traba9en en solitario' sino *ue siempre estarán con otra persona) Una pare9a de pro(ramadores ha de compartir el teclado' el monitor # el rat,n) !l principio fundamental de este hecho es realizar de manera continua # sin parar el desarrollo de c,di(o) Las pare9as tienen *ue ir cambiando de manera peri,dica' para hacer *ue el conocimiento se difunda en el (rupo) !stá demostrado *ue de esta manera el traba9o es más eficaz # también se consi(ue más # me9or c,di(o)
)i'ura 3 )uente0 E(laboración propia, 261$F
/. )ases de la metodolo'ía *" /.1. )ase0 "laniicación del proyecto /.1.1. Historias de usuario !l primer paso de cual*uier pro#ecto *ue si(a la metodolo(+a F)P es definir las historias de usuario con el cliente) Las historias de usuario tienen la misma finalidad *ue los casos de uso pero con al(unas diferencias< •
Constan de o 5 l+neas escritas por el cliente en un len(ua9e no técnico sin
•
hacer mucho hincapié en los detalles) Bo se debe hablar ni de posibles al(oritmos para su implementaci,n ni de
•
dise.os de base de datos adecuados' etc) 1on usadas para estimar tiempos de desarrollo de la parte de la aplicaci,n
•
*ue describen) ?ambién se utilizan en la fase de pruebas' para verificar si el pro(rama
•
cumple con lo *ue especifica la historia de usuario) Cuando lle(a la hora de implementar una historia de usuario' el cliente # los desarrolladores se re"nen para concretar # detallar lo *ue tiene *ue hacer dicha historia) !l tiempo de desarrollo ideal para una historia de
• • • • •
usuario es entre 6 # semanas) 1imilar a los Casos de Uso Usadas para estimaciones de tiempo en la planificaci,n de las liberaciones Usados en lu(ar del Documento de e*uerimientos !scritas por el Cliente en términos del Cliente u+an la creaci,n de Pruebas de Aceptaci,n
/.1.2. Release "lannin' Después de tener #a definidas las historias de usuario es necesario crear un plan de publicaciones' en in(lés $elease plan$' donde se indi*uen las historias de usuario *ue se crearán para cada versi,n del pro(rama # las fechas en las *ue se publicarán estas versiones) Un $elease plan$ es una planificaci,n donde los desarrolladores # clientes establecen los tiempos de implementaci,n ideales de las historias de usuario' la prioridad con la *ue serán implementadas # las historias *ue serán implementadas en cada versi,n del pro(rama) Después de un $elease plan$ tienen *ue estar claros estos cuatro factores<
•
Los ob9etivos *ue se deben cumplir /*ue son principalmente las historias
•
*ue se deben desarrollar en cada versi,n0) !l tiempo *ue tardarán en desarrollarse # publicarse las versiones del
• •
pro(rama) !l n"mero de personas *ue traba9arán en el desarrollo) C,mo se evaluará la calidad del traba9o realizado) /=elease plan< Planificaci,n de publicaciones0)
/.1.3. Iteraciones ?odo pro#ecto *ue si(a la metodolo(+a F)P) se ha de dividir en iteraciones de apro%imadamente semanas de duraci,n) Al comienzo de cada iteraci,n los clientes deben seleccionar las historias de usuario definidas en el $elease plannin($ *ue serán implementadas) ?ambién se seleccionan las historias de usuario *ue no pasaron el test de aceptaci,n *ue se realiz, al terminar la iteraci,n anterior) !stas historias de usuario son divididas en tareas de entre 6 # d+as de duraci,n *ue se asi(narán a los pro(ramadores)
/.1.!. ;a #elocidad del proyecto !s una medida *ue representa la rapidez con la *ue se desarrolla el pro#ecto: estimarla es mu# sencillo' basta con contar el n"mero de historias de usuario *ue se pueden implementar en una iteraci,n: de esta forma' se sabrá el cupo de historias *ue se pueden desarrollar en las distintas iteraciones) Usando la velocidad del pro#ecto controlaremos *ue todas las tareas se puedan desarrollar en el tiempo del *ue dispone la iteraci,n) !s conveniente reevaluar esta medida cada o 5 iteraciones # si se aprecia *ue no es adecuada ha# *ue ne(ociar con el cliente un nuevo $elease Plan$)
/.1.$. "ro'ramación en "are4as La metodolo(+a F)P) aconse9a la pro(ramaci,n en pare9as pues incrementa la productividad # la calidad del soft&are desarrollado) !l traba9o en pare9a involucra a dos pro(ramadores traba9ando en el mismo e*uipo: mientras uno codifica haciendo hincapié en la calidad de la funci,n o método *ue está implementando' el otro analiza si ese método o funci,n es
adecuado # está bien dise.ado) De esta forma se consi(ue un c,di(o # dise.o con (ran calidad)
/.1.-. Reuniones Diarias !s necesario *ue los desarrolladores se re"nan diariamente # e%pon(an sus problemas' soluciones e ideas de forma con9unta) Las reuniones tienen *ue ser fluidas # todo el mundo tiene *ue tener voz # voto)
/.2. )ase0 Diseño /.2.1. Diseños imples La metodolo(+a F)P su(iere *ue ha# *ue conse(uir dise.os simples # sencillos) -a# *ue procurar hacerlo todo lo menos complicado posible para conse(uir un dise.o fácilmente entendible e *ue se pueda implementar *ue a la lar(a costará menos tiempo # esfuerzo desarrollar)
/.2.2. Glosarios de 9rminos Usar (losarios de términos # una correcta especificaci,n de los nombres de métodos # clases a#udará a comprender el dise.o # facilitará sus posteriores ampliaciones # la reutilizaci,n del c,di(o)
/.2.3. Ries'os 1i sur(en problemas potenciales durante el dise.o' F)P su(iere utilizar una pare9a de desarrolladores para *ue investi(uen # reduzcan al má%imo el ries(o *ue supone ese problema)
/.2.!. )uncionabilidad etra Bunca se debe a.adir funcionalidad e%tra al pro(rama aun*ue se piense *ue en un futuro será utilizada) 1,lo el 6O de la misma es utilizada' lo *ue implica *ue el desarrollo de funcionalidad e%tra es un desperdicio de tiempo # recursos)
/.2.$. Reactori
rehusar c,di(os #a creados *ue contienen funcionalidades *ue no serán usadas # dise.os obsoletos)
/.3. )ase0 Codiicación !l cliente es una parte más importante del e*uipo de desarrollo: su presencia es indispensable en las distintas fases de F)P) A la hora de codificar una historia de usuario su presencia es a"n más necesaria) Bo olvidemos *ue los clientes son los *ue crean las historias de usuario # ne(ocian los tiempos en los *ue serán implementadas) Antes del desarrollo de cada historia de usuario el cliente debe especificar detalladamente lo *ue ésta hará # también tendrá *ue estar presente cuando se realicen los test *ue verifi*uen *ue la historia implementada cumple la funcionalidad especificada) La codificaci,n debe hacerse ateniendo a estándares de codificaci,n #a creados) Pro(ramar ba9o estándares mantiene el c,di(o consistente # facilita su comprensi,n # escalabilidad)
/.!. )ase0 "ruebas Uno de los pilares de la metodolo(+a F)P es el uso de test para comprobar el funcionamiento de los c,di(os *ue va#amos implementando) !l uso de los test en F)P es el si(uiente< 1e deben crear las aplicaciones *ue realizarán los test con un entorno de desarrollo espec+fico para test) -a# *ue someter a tests las distintas clases del sistema omitiendo los métodos más triviales) 1e deben crear los test *ue pasarán los c,di(os antes de implementarlos: en el apartado anterior se e%plic, la importancia de crear antes los test *ue el c,di(o) Un punto importante es crear test *ue no ten(an nin(una dependencia del c,di(o *ue en un futuro evaluará) Como se coment, anteriormente los distintos test se deben subir al repositorio de c,di(o acompa.ados del c,di(o *ue verifican)
?est de aceptaci,n) Los test mencionados anteriormente sirven para evaluar las distintas tareas en las *ue ha sido dividida una historia de usuario) Al ser las distintas funcionalidades de nuestra aplicaci,n no demasiado e%tensas' no se harán test *ue analicen partes de las mismas' sino *ue las pruebas se realizarán para las funcionalidades (enerales *ue debe cumplir el pro(rama especificado en la descripci,n de re*uisitos)
)i'ura ! )i'ura ! )ases de la etodolo'ía *" )uente0 E(laboración propia, 261$F
)i'ura $ )ases de la etodolo'ía )i'ura $*" se'Jn Ian ommer#ille )uente0 E(laboración propia, 261$F
. alores de la metodolo'ía *" Los valores ori(inales de la pro(ramaci,n e%trema son< simplicidad' comunicaci,n' retroalimentaci,n /feedbac40 # cora9e) Un *uinto valor' respeto' fue a.adido en la se(unda edici,n de !%treme Pro(rammin( !%plained) Los cinco valores se detallan a continuaci,n<
.1. implicidad La simplicidad es la base de la pro(ramaci,n e%trema) 1e simplifica el dise.o para a(ilizar el desarrollo # facilitar el mantenimiento) Un dise.o comple9o del c,di(o 9unto a sucesivas modificaciones por parte de diferentes desarrolladores hace *ue la comple9idad aumente e%ponencialmente) Para mantener la simplicidad es necesaria la refactorizaci,n del c,di(o' ésta es la manera de mantener el c,di(o simple a medida *ue crece) ?ambién se aplica la simplicidad en la documentaci,n' de esta manera el c,di(o debe comentarse en su 9usta medida' intentando eso s+ *ue el c,di(o esté auto documentado) Para ello se deben ele(ir adecuadamente los nombres de las variables' métodos # clases) Los nombres lar(os no decrementan la eficiencia del c,di(o ni el tiempo de desarrollo (racias a las herramientas de autocompletado # refactorizaci,n *ue e%isten actualmente) Aplicando la simplicidad 9unto con la autor+a colectiva del c,di(o # la pro(ramaci,n por pare9as se ase(ura *ue cuanto más (rande se ha(a el pro#ecto' todo el e*uipo conocerá más # me9or el sistema completo)
.2. Comunicación La comunicaci,n se realiza de diferentes formas) Para los pro(ramadores el c,di(o comunica me9or cuanto más simple sea) 1i el c,di(o es comple9o ha# *ue esforzarse para hacerlo inteli(ible) !l c,di(o autodocumentado es más fiable *ue los comentarios #a *ue éstos "ltimos pronto *uedan desfasados con el c,di(o a medida *ue es modificado) Debe comentarse s,lo a*uello *ue no va a variar' por e9emplo el ob9etivo de una clase o la funcionalidad de un método) Las pruebas unitarias son otra forma de comunicaci,n #a *ue describen el dise.o de las clases # los métodos al mostrar e9emplos concretos de c,mo utilizar su funcionalidad)
Los pro(ramadores se comunican constantemente (racias a la pro(ramaci,n por pare9as) La comunicaci,n con el cliente es fluida #a *ue el cliente forma parte del e*uipo de desarrollo) !l cliente decide *ué caracter+sticas tienen prioridad # siempre debe estar disponible para solucionar dudas)
.3. Retroalimentación Al estar el cliente inte(rado en el pro#ecto' su opini,n sobre el estado del pro#ecto se conoce en tiempo real) Al realizarse ciclos mu# cortos tras los cuales se muestran resultados' se minimiza el tener *ue rehacer partes *ue no cumplen con los re*uisitos # a#uda a los pro(ramador esa centrarse en lo *ue es más importante) Considérense los problemas *ue derivan de tener ciclos mu# lar(os) Meses de traba9o pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del e*uipo de desarrollo) !l c,di(o también es una fuente de retroalimentaci,n (racias a las herramientas de desarrollo) Por e9emplo' las pruebas unitarias informan sobre el estado de salud del c,di(o) !9ecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el c,di(o)
.!. Cora4e o #alentía Muchas de las prácticas implican valent+a) Una de ellas es siempre dise.ar # pro(ramar para ho# # no para ma.ana) !sto es un esfuerzo para evitar empantanarse en el dise.o # re*uerir demasiado tiempo # traba9o para implementar todo lo demás del pro#ecto) La valent+a le permite a los desarrolladores *ue se sientan c,modos con reconstruir su c,di(o cuando sea necesario) !sto si(nifica revisar el sistema e%istente # modificarlo si con ello los cambios futuros se implementaran más fácilmente) @tro e9emplo de valent+a es saber cuándo desechar un c,di(o< valent+a para *uitar c,di(o fuente obsoleto' sin importar cuanto esfuerzo # tiempo se invirti, en crear ese c,di(o) Además' valent+a si(nifica persistencia< un pro(ramador puede permanecer sin avanzar en un problema comple9o por un d+a entero' # lue(o lo resolverá rápidamente al d+a si(uiente' s,lo si es persistente)
5. enta4as y Des#enta4as de la etodolo'ía *" 9abla !. enta4as y Des#enta4as de la etodolo'ía *" enta4as Pro(ramaci,n or(anizada)
Des#enta4as !s recomendable emplearlo solo en pro#ectos a corto plazo) Altas comisiones en caso de fallar)
Menor taza de errores) 1atisfacci,n del pro(ramador) )uente0 E(laboración propia, 261$F
16. Incon#enientes • • • •
!s recomendable emplearla solo en pro#ectos a corto plazo) !n caso de fallar' las comisiones son mu# altas) e*uiere de un r+(ido a9uste a los principios de FP) Puede no siempre ser más fácil *ue el desarrollo tradicional)
11. Herramientas empleadas en *" A continuaci,n se detalla cada una de estas planteando los motivos por los cuales fueron seleccionadas<
11.1.
7AA
1e trata de un poderos # fle%ible len(ua9e de pro(ramaci,n con el actual se puede desarrollar desde aplicaciones para celulares hasta pá(inas &eb) @bviamente se convierte en una herramienta ,ptima para desarrollar aplicativos de escritorio) !l primer motivo por el *ue se seleccion, JAEA como herramienta de desarrollo' es el amplio conocimiento *ue los pro(ramadores tienen del len(ua9e) !n se(undo lu(ar e%iste una AP de pruebas desarrolladas para traba9ar con JAEA especialmente dise.ada para pro#ectos desarrollados con FP
11.2.
8(9%eans
!s un D! de licenciado libre para desarrollar aplicaciones en JAEA) 1i bien no es el "nico D! disponible para JAEA' a 9uicio de los pro(ramadores' es el más adecuado' por lo cual se convirti, en la me9or elecci,n) Por otro lado cuenta con soporte para JUnit' herramienta seleccionada para realizar pruebas)
11.3.
7+nit
!s un AP para realizar pruebas *ue fue dise.ado para ser empleado en JAEA) Un aspecto importante es *ue cumple con la ma#or+a de las recomendaciones realizadas por FP en lo *ue a pruebas se refiere' de las cuales se destaca el permitir hacer pruebas aut,nomas) Por otro lado' al(unos autores lo recomiendan para desarrollar aplicaciones en JAEA empleando FP)
11.!.
7asperReport e IReport
!s una combinaci,n de librer+as de JAEA # soft&are libre *ue permiten el dise.o e implementaci,n de reportes impresos) !ntre las venta9as más importantes se resalta fle%ibilidad # facilidad de empleo
11.$.
"ost're:;
1e caracteriza por estar entre los motores de base de datos más estables # robustos' razones *ue motivaron su elecci,n)
12. 9ablas Comparati#as de las etodolo'ías CR+ y *" 12.1.
eme4an
!s un A(ile Manifiesto) !%isten una nteracci,n de Usuario a Usuario) ealizan los Pro#ectos en un Corto Periodo de ?iempo) ?raba9an en !*uipo)
12.2.
Dierencias 9abla $. Comparación entre etodolo'ías
CR+ *"E"ro'ramación (tremaF Las iteraciones de entre(as son de 8 a 5 Las iteraciones de entre(a son a 6 a semanas) Lo *ue se termina' funciona # este bien' se
semanas) Las tareas * se van entre(ando a los
aparta # #a no se toca)
diferentes clientes son susceptibles a las
Cada miembro del 1crum ?eam traba9a de
modificaciones) Los miembros del pro(raman en pare9a en
forma individual) !l 1crum ?eam trata de se(uir el orden de
un pro#ecto FP) !l e*uipo de desarrollo si(ue estrictamente
prioridad * marca el Product @&ner en el
el orden de prioridad de las tareas definidas
1print Hac4lo( pueden ser modificadas) !stá basada en la administraci,n del
por el cliente) 1e centra más en la propia pro(ramaci,n o
pro#ecto)
creaci,n del producto) )uente0 E(laboración propia, 261$F
13. "ersonas =ue inter#ienen en la etodolo'ía *" e'Jn Bent %ecK La metodolo(+a FP se encuentra en una frecuente inte(raci,n del e*uipo de pro(ramaci,n con el cliente o usuario< se recomienda *ue un representante del cliente traba9e 9unto al e*uipo de desarrollo) Los pro(ramadores se comunican constantemente (racias a la pro(ramaci,n por pare9as) La comunicaci,n con el cliente es fluida #a *ue el cliente forma parte del e*uipo de desarrollo: el cliente decide *ué caracter+sticas tienen prioridad # siempre debe estar disponible para solucionar dudas)
e'Jn Ian ommer#ille !n un proceso FP' los clientes están fuertemente implicados en la especificaci,n # establecimiento de prioridades de los re*uerimientos del sistema) Los re*uerimientos no se especifican como una lista de funciones re*ueridas del sistema) Más bien' los clientes del sistema son parte del e*uipo de desarrollo # discuten escenarios con otros miembros del e*uipo) Desarrollan con9untamente una tar9eta de historia *ue
reco(e las necesidades del cliente) !l e*uipo de desarrollo intentara entonces implementar ese escenario en una entre(a futura del soft&are) La participaci,n del cliente se lleva a cabo a través del compromiso a tiempo completo del cliente en el e*uipo de desarrollo) Los representantes de los clientes participan en el desarrollo # son los responsables de definir las pruebas de aceptaci,n del sistema)
"racticas %&sicas del *" De forma aislada' cual*uier práctica individual de Fp tiene poco sentido' pero en con9unto' unas compensan las carencias *ue las otras puedan tener) Bos dice *ue para evaluar Fp ha# *ue mirar la (ran foto' es decir' todo el con9unto de prácticas<
•
!l 9ue(o de la Planificaci,n /Plannin( ame0
!l alcance de la si(uiente versi,n esta definido por las consideraciones de ne(ocios /prioridad de los m,dulos' fechas de entre(a0 # estimaciones técnicas /estimaciones de funciones' consecuencias0)
!l ob9etivo del 9ue(o es ma%imizar el valor del soft&are producido' La estrate(ia es poner en producci,n las caracter+sticas más importantes lo antes posible' Las Piezas clave son las 1tor# Cards' Los Ju(adores son los desarrolladores # el cliente # las Movidas son !%ploraci,n' 1elecci,n # Actualizaci,n) •
Eersiones Pe*ue.as /1hort eleases0
Un sistema simple se pone rápidamente en producci,n) Peri,dicamente' se producen nuevas versiones a(re(ando en cada iteraci,n a*uellas funciones consideradas valiosas para el cliente •
Metáfora del 1istema /Metaphor0
Cada Pro#ecto es (uiado por una historia simple de c,mo funciona el sistema en (eneral' reemplaza a la ar*uitectura # debe estar en len(ua9e com"n' entendible para todos /Cliente # Desarrolladores0' esta puede cambiar permanentemente) •
Dise.o 1imple /1imple Desi(ns0
!l sistema se dise.a con la má%ima simplicidad posible /AB $Bo vas a necesitarlo$0' 1e plasma el dise.o en tar9etas CC /Clase Q esponsabilidad Colaboraci,n0' no se implementan caracter+sticas *ue no son necesarias' con esta técnica' las clases descubiertas durante el análisis pueden ser filtradas para determinar *ué clases son realmente necesarias para el sistema) •
Pruebas Continuas /?estin(0
Los casos de prueba se escriben antes *ue el c,di(o) Los desarrolladores escriben pruebas unitarias # los clientes especifican pruebas funcionales) •
efactorizaci,n /efactorin(0
!s posible reestructurar el sistema sin cambiar su comportamiento' por e9emplo eliminando c,di(o duplicado' simplificando funciones' Me9orando el c,di(o constantemente' si el c,di(o se esta volviendo complicado se deber+a modificar el dise.o # volver a uno más simple) efactorin( /Modificar la forma del c,di(o sin cambiar su funcionamiento0)
•
Pro(ramaci,n por pare9as /Pair Pro(rammin(0
!l c,di(o es escrito por dos personas traba9ando en el mismo computador) $Una sola ma*uina con un teclado # un mouse$ •
Posesi,n Colectiva del C,di(o /Collective Code @&nership0
Badie es due.o de un modulo) Cual*uier pro(ramador puede cambiar cual*uier parte del sistema en cual*uier momento' siempre se utilizan estándares # se e%clu#en los comentarios' Los test siempre deben funcionar al 6O para realizar inte(raciones con todo el c,di(o permanentemente) •
nte(raci,n continua /Continuous nte(ration0
Los cambios se inte(ran en el c,di(o base varias veces por d+a) ?odos lo casos de prueba se deben pasar antes # después de la inte(raci,n' se dispone de una ma*uina para la inte(raci,n # se realizan test funcionales en donde participa el cliente) •
1emana laboral de 5 horas /5-our Wee40
Cada ?raba9ador traba9a no más de 5 -oras por semana) 1i fuera necesario hacer horas e%tra' esto no deber+a hacerse dos semanas consecutivas) 1in héroes' esto hace *ue se reduzca la rotaci,n del personal # me9ora la calidad del producto) •
Cliente en el 1itio /@n 1ite Customer0
!l e*uipo de desarrollo tiene acceso todo el tiempo al cliente' el cual esta disponible para responder pre(untas' fi9ar prioridades' etc) !sto no siempre se consi(ue: Un cliente mu# Junior no sirve # un cliente mu# 1énior no es disponible) $Lo ideal es un cliente Analista$) •
!stándares de Codificaci,n /Codin( 1tandard0
?odo el c,di(o debe estar escrito de acuerdo a un estándar de codificaci,n
Ciclo de ida
!l ciclo de vida de Fp se enfatiza en el carácter interactivo e incremental del desarrollo' 1e("n una iteraci,n de desarrollo es un per+odo de tiempo en el *ue se realiza un con9unto de funcionalidades determinadas *ue en el caso de Fp corresponden a un con9unto de historias de usuarios) Las iteraciones son relativamente cortas #a *ue se piensa *ue entre más rápido se le entre(uen desarrollos al cliente' más retroalimentaci,n se va a obtener # esto va a representar una me9or calidad del producto a lar(o plazo) !%iste una fase de análisis inicial orientada a pro(ramar las iteraciones de desarrollo # cada iteraci,n inclu#e dise.o' codificaci,n # pruebas' fases superpuestas de tal manera *ue no se separen en el tiempo) La si(uiente fi(ura muestra las fases en las *ue se subdivide el ciclo de vida Fp<
Ciclo de vida de eFtreme Pro(rammin(
Ahora nos describen cada una de las fases en las *ue se subdivide el ciclo de vida de eFtreme Pro(rammin(<
)ase de la eploración0 !n esta fase' los clientes plantean a (randes ras(os las historias de usuario *ue son de interés para la primera entre(a del producto) Al mismo tiempo el e*uipo de desarrollo se familiariza con las herramientas' tecnolo(+as # prácticas *ue se utilizarán en el pro#ecto) 1e prueba la tecnolo(+a # se e%ploran las posibilidades de la ar*uitectura del sistema constru#endo un prototipo) La fase de e%ploraci,n toma de pocas semanas a pocos meses' dependiendo del tama.o # familiaridad *ue ten(an los pro(ramadores con la tecnolo(+a)
)ase del planeamiento< se priorizan las historias de usuario # se acuerda el alcance del release) Los pro(ramadores estiman cuánto esfuerzo re*uiere cada historia # a partir de all+ se define el crono(rama) La duraci,n del crono(rama del primer release no e%cede normalmente dos meses) La fase de planeamiento toma un par de d+as) 1e deben incluir varias iteraciones para lo(rar un release) !l crono(rama fi9ado en la etapa de planeamiento se realiza a un n"mero de iteraciones' cada una toma de una a cuatro semanas en e9ecuci,n) La primera iteraci,n crea un sistema con la ar*uitectura del sistema completo) !sto es alcanzado seleccionando las historias *ue harán cumplir la construcci,n de la estructura para el sistema completo) !l cliente decide las historias *ue se seleccionarán para cada iteraci,n) Las pruebas funcionales creadas por el cliente se e9ecutan al final de cada iteraci,n) Al final de la "ltima iteraci,n el sistema está listo para producci,n)
)ase de producción0 re*uiere prueba # comprobaci,n e%tra del funcionamiento del sistema antes de *ue éste se pueda liberar al cliente) !n esta fase' los nuevos cambios pueden todav+a ser encontrados # debe tomarse la decisi,n de si se inclu#en o no en el release actual) Durante esta fase' las iteraciones pueden ser aceleradas de una a tres semanas) Las ideas # las su(erencias pospuestas se documentan para una puesta en práctica posterior por e9emplo en la fase de mantenimiento) Después de *ue se realice el primer release productivo para uso del cliente' el pro#ecto de Fp debe mantener el funcionamiento del sistema mientras *ue realiza nuevas iteraciones)
)ase de mantenimiento0 re*uiere de un ma#or esfuerzo para satisfacer también las tareas del cliente) As+' la velocidad del desarrollo puede desacelerar después de *ue el sistema esté en la producci,n) La fase de mantenimiento puede re*uerir la incorporaci,n de nueva (ente # cambiar la estructura del e*uipo)
)ase de muerte0 !s cuando el cliente no tiene más historias para ser incluidas en el sistema) !sto re*uiere *ue se satisfa(an las necesidades del cliente en otros aspectos como rendimiento # confiabilidad del sistema) 1e (enera la documentaci,n final del sistema # no se realizan más cambios en la ar*uitectura) La muerte del pro#ecto también ocurre cuando el sistema no (enera los beneficios esperados por el cliente o cuando no ha# presupuesto para mantenerlo)
Actores y Responsabilidades de *"
!%isten diferentes roles /actores0 # responsabilidades en Fp para diferentes tareas # prop,sitos durante el proceso< Pro(ramador /Pro(rammer0 • • • •
esponsable de decisiones técnicas esponsable de construir el sistema 1in distinci,n entre analistas' dise.adores o codificadores !n Fp' los pro(ramadores dise.an' pro(raman # realizan las pruebas
Cliente /Customer0 • • •
!s parte del e*uipo Determina *ué construir # cuándo !scribe tests funcionales para determinar cuándo está completo un determinado aspecto
!ntrenador /Coach0 • •
!l l+der del e*uipo toma las decisiones importantes Principal responsable del proceso
•
?iende a estar en un se(undo plano a medida *ue el e*uipo madura
astreador /?rac4er0 • • •
Metric Man @bserva sin molestar Conserva datos hist,ricos
Probador /?ester0 • •
A#uda al cliente con las pruebas funcionales 1e ase(ura de *ue los tests funcionales se e9ecutan
Arteactos
A continuaci,n describimos los artefactos de Fp' entre los *ue se encuentran< -istorias de Usuario' ?areas de n(enier+a # ?ar9etas CC)
•
-istoria de usuario
epresentan una breve descripci,n del comportamiento del sistema' emplea terminolo(+a del cliente sin len(ua9e técnico' se realiza una por cada caracter+stica principal del sistema' se emplean para hacer estimaciones de tiempo # para el plan de lanzamientos' reemplazan un (ran documento de re*uisitos # presiden la creaci,n de las pruebas de aceptaci,n)
-istoria de usuario Bumero<
Bombre -istoria de usuario<
Modificaci,n de historia de Usuario /Bro) # Bombre<0
Usuario
teraci,n Asi(nada <
Prioridad en ne(ocio
Puntos estimados <
/Alta ; Media ; Ha9a0
ies(o en desarrollo < /Alto ; Medio ; Ha9o 0
Descripci,n<
@bservaciones<
Puntos eales<
?abla Bo)6) Modelo propuesto para una historia de usuario !stas deben proporcionar s,lo el detalle suficiente como para poder hacer razonable la estimaci,n de cuánto tiempo re*uiere la implementaci,n de la historia' difiere de los casos de uso por*ue son escritos por el cliente' no por los pro(ramadores' empleando terminolo(+a del cliente) $Las historias de usuario son más $ami(ables$ *ue los casos de uso formales$) Las -istorias de Usuario tienen tres aspectos< ?ar9eta< en ella se almacena suficiente informaci,n para identificar # detallar la historia) Conversaci,n< cliente # pro(ramadores discuten la historia para ampliar los detalles /verbalmente cuando sea posible' pero documentada cuando se re*uiera confirmaci,n0 Pruebas de Aceptaci,n< permite confirmar *ue la historia ha sido implementada correctamente) Caso de prueba de Aceptaci,n C,di(o< Bombre<
Descripci,n <
Condiciones de !9ecuci,n<
-istoria de usuario /Bro) Bombre0<
!ntrada ; pasos de e9ecuci,n<
esultado esperado<
!valuaci,n de prueba<
?abla Bo)8) Modelo propuesto para una prueba de aceptaci,n •
?as4 Card
?area de n(enier+a B"mero tarea
Bombre ?area<
-istoria de usuario /Bro) Bombre0<
?ipo de ?area< Desarrollo
;
Puntos !stimados< Correcci,n
;
Me9ora
;@tra/especificar0
>echa nicio<
>echa >in<
Pro(ramador esponsable< Descripci,n
Modelo propuesto para una tarea de in(enier+a
•
?ar9etas CC /Clase Q esponsabilidad Colaborador0
!stas tar9etas se dividen en tres secciones *ue contienen la informaci,n del nombre de la clase' sus responsabilidades # sus colaboradores) !n la si(uiente fi(ura se muestra c,mo se distribu#e esta informaci,n)
Bombre de la Clase esponsabilidades
Colaboradores
Modelo de tar9eta CC Una clase es cual*uier persona' cosa' evento' concepto' pantalla o reporte) Las responsabilidades de una clase son las cosas *ue conoce # las *ue realiza' sus atributos # métodos) Los colaboradores de una clase son las demás clases con las *ue traba9a en con9unto para llevar a cabo sus responsabilidades) !n la práctica conviene tener pe*ue.as tar9etas de cart,n' *ue se llenarán # *ue son mostradas al cliente' de manera *ue se pueda lle(ar a un acuerdo sobre la validez de las abstracciones propuestas) Los pasos a se(uir para llenar las tar9etas son los si(uientes< •
!ncontrar clases
• • •
!ncontrar responsabilidades Definir colaboradores Disponer las tar9etas
Para encontrar las clases debemos pensar *ué cosas interact"an con el sistema /en nuestro caso el usuario0' # *ué cosas son parte del sistema' as+ como las pantallas "tiles a la aplicaci,n /un desplie(ue de datos' una entrada de parámetros # una pantalla (eneral' entre otros0) Una vez *ue las clases principales han sido encontradas se procede a buscar los atributos # las responsabilidades' para esto se puede formular la pre(unta RSué sabe la claseT # RSué hace la claseT >inalmente se buscan los colaboradores dentro de la lista de clases *ue se ten(a)
Criticas a (treme "ro'ramin' Al(unas de las cr+ticas recopiladas de Fp son< Fp tiene muchas cr+ticas especialmente contra la pro(ramaci,n por pare9as por parte de muchos pro(ramadores con (ran sentimiento de posesi,n del c,di(o' piensan *ue ellos son los me9ores conocedores de las herramientas # len(ua9es *ue utilizan # *ue si al(uien no lo entiende es por*ue no sabe lo suficiente) ?ambién se critica el mito de las 5 horas semanales #a *ue es un lu9o para las e%i(encias del mercado) ?ambién ha# cr+ticas hacia Fp *ue dicen *ue solo puede funcionar con pro(ramadores mu# buenos' como Gent Hec4' *ue son capaces de hacer un buen dise.o' sencillo # fácilmente e%tensible) Fp es más una filosof+a de traba9o *ue una metodolo(+a) Por otro lado nin(una de las practicas defendidas por Fp son invenci,n de este método' Fp lo *ue hace es ponerlas todas 9untas) Fp está dise.ado para (rupos de pe*ue.os pro(ramadores' más de 6 #a ser+a mu# complicado' # más a"n para *ue estén en el mismo centro de traba9o)
Capítulo III Conclusiones y Recomendaciones 1!. Conclusiones Bo e%iste una metodolo(+a universal para hacer frente con é%ito a cual*uier pro#ecto de desarrollo de soft&are) ?oda metodolo(+a debe ser adaptada al conte%to del pro#ecto /recursos técnicos # humanos' tiempo de desarrollo' tipo de sistema' etc) -ist,ricamente' las metodolo(+as tradicionales han intentado abordar la ma#or cantidad de situaciones de conte%to del pro#ecto' e%i(iendo un esfuerzo considerable para ser adaptadas' sobre todo en pro#ectos pe*ue.os # con re*uisitos mu# cambiantes) Las metodolo(+as á(iles ofrecen una soluci,n casi a medida para una (ran cantidad de pro#ectos *ue tienen estas caracter+sticas) Una de las cualidades más destacables en una metodolo(+a á(il es su sencillez' tanto en su aprendiza9e como en su aplicaci,n' reduciéndose as+ los costos de implantaci,n en un e*uipo de desarrollo) !sto ha llevado hacia un interés creciente en las metodolo(+as á(iles) 1in embar(o' ha# *ue tener presente una serie de inconvenientes # restricciones para su aplicaci,n' tales como< están diri(idas a e*uipos pe*ue.os o medianos /Hec4 su(iere *ue el tama.o de los e*uipos se limite de a 8 como má%imo' otros dicen no más de 6 participantes0' el entorno f+sico debe ser un ambiente *ue permita la comunicaci,n # colaboraci,n entre todos los miembros del e*uipo durante todo el tiempo' cual*uier resistencia del cliente o del e*uipo de desarrollo hacia las prácticas # principios puede llevar al proceso al fracaso /el clima de traba9o' la colaboraci,n # la relaci,n contractual son claves0' el uso de tecnolo(+as *ue no ten(an un ciclo rápido de realimentaci,n o *ue no soporten fácilmente el cambio' etc) >alta a"n un cuerpo de conocimiento consensuado respecto de los aspectos te,ricos # prácticos de la utilizaci,n de metodolo(+as á(iles' as+ como una ma#or consolidaci,n de los resultados de aplicaci,n) La actividad de investi(aci,n está orientada hacia l+neas tales como< métricas # evaluaci,n del proceso' herramientas espec+ficas para apo#ar prácticas á(iles' aspectos humanos # de traba9o en e*uipo) !ntre estos esfuerzos destacan pro#ectos como BAM!68 /Bet&or4 for A(ile Methodolo(ies !%perience0)
!s FP la metodolo(+a *ue resalta por contar con la ma#or cantidad de informaci,n disponible # es con diferencia la más popular)
1$. Recomendaciones Debe hacerse lo posible por no realizar modificaciones a FP demasiado drásticas #a *ue se corre el ries(o de alterar la esencia de la metodolo(+a) Debe plantearse una estrate(ia para afrontar el dise.o de datos en FP) 1e deben afi9ar una serie de re(las (enerales en la comunicaci,n con el cliente #a *ue por el (rado de informalidad *ue la metodolo(+a presenta puede sur(ir diferencias *ue pon(an en peli(ro la culminaci,n e%itosa del pro#ecto) Debe hacerse una capacitaci,n al cliente sobre FP antes de iniciar el pro#ecto debido *ue este hace parte del e*uipo de desarrollo) Plantear una estrate(ia especial de refactorin( para las bases de datos) ?ener un buen conocimiento de las herramientas para la implementaci,n antes de iniciar dicha etapa) Plantear como unidad de tiempo horas en lu(ar de d+as para la asi(naci,n de tareas) Considerar el internet # herramientas basadas en él como mecanismos de comunicaci,n válidos dentro de FP # discutir la necesidad de un "nico sitio (eo(ráfico de traba9o) -acer una e%periencia realizando un mismo pro#ecto por dos (rupos de desarrollo independientes empleando una metodolo(+a pesada # FP con el fin de comparar los resultados obtenidos) !mplear FP en un pro#ecto de ma#or enver(adura con el fin de evaluar el desempe.o de la metodolo(+a en ese tipo de pro#ectos)
