UniversidadORTUruguay · UniversidadORTUruguay CátedradeIngenieríadeSoftware MetodologíaXP...

Universidad ORT UruguayFacultad de Ingenieriacutea

ndashndashndashMMMeeetttooodddooolllooogggiacuteiacuteiacuteaaa XXXPPPndashndashndash

Caacutetedra de Ingenieriacutea de SoftwareDocente Responsable Gastoacuten Mousques

AutoresLuis Calabria ndash 122919Pablo Piacuteriz ndash 123348

2003

Universidad ORT Uruguay Caacutetedra de Ingenieriacutea de SoftwareMetodologiacutea XP Octubre del 2003

Luis Calabria ndash Pablo Piacuteriz Paacutegina 1

Iacutendice GeneralIacutendice General_________________________________________________________________________________ 1Resumen _____________________________________________________________________________________ 3La filosofiacutea de XP ______________________________________________________________________________ 4Valores en XP _________________________________________________________________________________ 5Comunicacioacuten_______________________________________________________________________________________5Simplicidad_________________________________________________________________________________________5Feedback___________________________________________________________________________________________5Coraje _____________________________________________________________________________________________6

Principios de XP _______________________________________________________________________________ 7Raacutepida retroalimentacioacuten _____________________________________________________________________________7Asumir la simplicidad ________________________________________________________________________________7Cambios incrementales _______________________________________________________________________________7Aceptar el cambio ___________________________________________________________________________________7Trabajo de calidad___________________________________________________________________________________7Otros principios _____________________________________________________________________________________7

Principales conceptos ___________________________________________________________________________ 9Story Cards_________________________________________________________________________________________9Iteracioacuten ___________________________________________________________________________________________9Refactoring________________________________________________________________________________________10Release ___________________________________________________________________________________________10Test de aceptacioacuten __________________________________________________________________________________10Test unitario _______________________________________________________________________________________10

El ciclo de vida _______________________________________________________________________________ 11Exploracioacuten _______________________________________________________________________________________12Planificacioacuten_______________________________________________________________________________________12Iteraciones por entregas _____________________________________________________________________________12Produccioacuten ________________________________________________________________________________________13Mantenimiento _____________________________________________________________________________________13Muerte____________________________________________________________________________________________13

Ciclo de vida del programador___________________________________________________________________ 14Roles y responsabilidades ______________________________________________________________________ 16Cliente____________________________________________________________________________________________16Coach ____________________________________________________________________________________________16Consultant ________________________________________________________________________________________16Manager __________________________________________________________________________________________16Programador ______________________________________________________________________________________16Tester ____________________________________________________________________________________________16Tracker ___________________________________________________________________________________________16

Praacutecticas ____________________________________________________________________________________ 1740 horas semanales__________________________________________________________________________________17



Cliente On-Site_____________________________________________________________________________________17Disentildeo simple ______________________________________________________________________________________17El juego de la planificacioacuten ___________________________________________________________________________18Estaacutendares de codificacioacuten ___________________________________________________________________________18Integracioacuten continua ________________________________________________________________________________18Metaacutefora __________________________________________________________________________________________19Pequentildeos release ___________________________________________________________________________________19Programacioacuten por pares _____________________________________________________________________________19Propiedad colectiva _________________________________________________________________________________19Testing____________________________________________________________________________________________19Refactoring________________________________________________________________________________________20

Herramientas para el testeo automaacutetico ___________________________________________________________ 21JUnit _____________________________________________________________________________________________21

Conclusiones _________________________________________________________________________________ 23Palabras Claves_______________________________________________________________________________ 24Glosario _____________________________________________________________________________________ 25Bibliografiacutea __________________________________________________________________________________ 26



ResumenEl objetivo principal de este documento es resumir los principales aspectos de la metodologiacutea de ExtremeProgramming

Entre otros puntos se mencionaraacuten cuales son los valores y principios que se siguen en XP asiacute como tambieacuten losprincipales conceptos que se deben tener en cuenta a la hora de llevarla a la praacutectica

Luego se haraacute un anaacutelisis del ciclo de vida que se utiliza en el cual se veraacute cuales son las etapas y las actividadesmaacutes importantes

Tambieacuten se menciona cuales son los principales roles dentro de esta metodologiacutea asiacute como tambieacuten susresponsabilidades y ademaacutes analizaremos las praacutecticas maacutes importantes que se deben seguir

Por uacuteltimo haremos referencia a las herramientas de testeo automaacutetico haciendo hincapieacute en la herramienta JUnit



La filosofiacutea de XPXP es una metodologiacutea aacutegil para pequentildeos y medianos equipos desarrollando software cuando los requerimientosson ambiguos o raacutepidamente cambiantes

A diferencia de los procesos tradicionales para desarrollar software XP asume el cambio como algo natural y queindefectiblemente en alguna etapa de un proyecto sucede En XP se realiza el software que el cliente solicita ynecesita en el momento que lo precisa alentando a los programadores a responder a los requerimientos cambiantesque plantea el cliente en cualquier momento Esto es posible porque estaacute disentildeado para adaptarse en formainmediata a los cambios con bajos costos asociados en cualquier etapa del ciclo de vida En pocas palabras XPldquoabrazardquo el cambio



Valores en XPPara poder implementar las praacutecticas que presenta XP hay que conocer cuales son los valores principales que hacena esta mitologiacutea Estos valores son

uuml Comunicacioacutenuuml Simplicidaduuml Feedbackuuml Coraje

ComunicacioacutenUno de los valores maacutes importantes en XP es la comunicacioacuten La mala comunicacioacuten no surge por casualidad en unproyecto y pueden aparecer muchas circunstancias que hagan que esta falle un programador le da malas noticias algerente y este lo castiga un cliente le dice al programador algo importante y este no le presta atencioacuten

En cualquiera de los casos la comunicacioacuten es un factor importante en cualquier tipo de proyecto En XP se trata demantener una buena comunicacioacuten mediante un conjunto de praacutecticas que no se pueden realizar sin tener una buenacomunicacioacuten en el equipo Muchas de estas praacutecticas hacen corto circuito si no hay buena comunicacioacuten como enel caso de los testing unitarios programacioacuten por pares el uso de estaacutendares o la estimacioacuten de las tareas Trabajaren espacios abiertos hace que la comunicacioacuten mejore al contrario de otras metodologiacuteas en las cuales losprogramadores trabajan en espacios reducidos

La comunicacioacuten con el cliente es de vital importancia en XP y es por este motivo que el cliente es integrado alequipo De esta forma cualquier duda sobre los requerimientos puede ser evacuada inmediatamente Ademaacutes seplanifica con el cliente y este puede estar al tanto del avance del proyecto (Extreme Programming explinedCapiacutetulo 7 Four Values Paacuteg 15)XP ha sido disentildeada para minimizar el grado de documentacioacuten como forma de comunicacioacuten haciendo eacutenfasis enla interaccioacuten personal De esta manera se puede avanzar raacutepidamente y de forma efectiva realizando solo ladocumentacioacuten necesaria

SimplicidadLa simplicidad es el segundo valor que se utiliza en esta metodologiacutea XP apuesta a realizar algo simple hoy ydestinar un poco maacutes de esfuerzo para realizar un cambio en el futuro a realizar algo maacutes complicado hoy y noutilizarlo nunca

XP propone una regla muy simple ldquohacer algo que funcione de la manera maacutes sencillardquo En el caso de tener queantildeadir nueva funcionalidad al sistema se deben examinar todas las posibles alternativas y seleccionar la maacutessencilla En otras ocasiones se hace uso del refactoring1 que permite mantener el coacutedigo en funcionamiento peromucho maacutes simple y organizado (Praacutecticas Extremas en ORTsf Valores Pag - 27)

Otra regla muy importante es ldquorealizar solo lo necesariordquo Con esto se pretende agregar nueva funcionalidad quecumpla con los objetivos actuales sin necesidad de preocuparse por futuros requerimientos Esto hace que seprogrese de manera maacutes segura y raacutepida en el proyecto

FeedbackBrindar un feedback correcto y preciso hace que se pueda mantener una buena comunicacioacuten y conocer el estadoactual del proyecto

1 Refactoring Un cambio al sistema que mantiene el mismo comportamiento del sistema pero aumenta algunos atributos decalidad como ser simplicidad flexibilidad mantenibilidad etc



Comunicacioacuten

Simplicidad Feedback

Coraje

El feedback trabaja a diferentes escalas de tiempo Uno es el feedback que se realiza minuto a minuto Cuando uncliente escribe sus stories1 los programadores realizan la estimacioacuten de cada una de ellas y el cliente puede obtenerinmediatamente el feedback sobre la calidad de dichas stories

El otro tipo de feedback que se realiza es a traveacutes de pequentildeas entregas del sistema De esta manera el cliente estaacute altanto del avance del proyecto Ademaacutes el sistema es puesto en produccioacuten en menor tiempo con lo cual losprogramadores saben si realizaron un buen trabajo y si sus decisiones fueron acertadas

CorajeObviamente cada uno de los valores antes mencionados tiene una gran interaccioacuten entre ellos Como se ve en lasiguiente figura la comunicacioacuten la simplicidad y el feedback forman el coraje el cual se convierte en el objetivo deXP Uno de los lemas de XP menciona ldquoSi no trabajas al tope de tu capacidad alguien maacutes lo estaacute haciendo y si nollegas a tiempo se comeraacute tu almuerzordquo (Praacutecticas Extremas en ORTsf Valores Pag - 27)

Esto hace a que por ejemplo se tenga el coraje de modificar el coacutedigo en cualquier momento por cualquiermiembro del equipo sabiendo que no se afectaraacute el correcto funcionamiento del sistema

Figura 1 ndash valores de XPEl coraje tambieacuten es poder realizar cambios cuando algo no funciona del todo bien disentildear e implementar solo lonecesario para el presente pedir ayuda o reducir el alcance de una entrega si el tiempo no alcanza

Si no hay coraje en un proyecto no se puede clasificar como extremo y es necesario que los otros tres valores esteacutenpresentes

ReferenciasKENT Beck 2000 Extreme Programming explined 1ra edicioacuten

ARRIETA Sebastian Praacutecticas Extremas en ORTsf 2002 Universidad ORT Uruguay

1 Storie Funcionalidad que el cliente quiere que haga el sistema



Principios de XPLos cuatro valores mencionados anteriormente ndash comunicacioacuten simplicidad feedback y coraje ndash nos brindan unestaacutendar para obtener buenos resultados Sin embargo los valores son muy vagos a la hora de ayudarnos a decidirque praacutecticas utilizar Para ello se necesita destilar estos valores en principios que puedan ser utilizados

A continuacioacuten se detallan los principios maacutes importantes de XP

uuml Raacutepida retroalimentacioacutenuuml Asumir la simplicidaduuml Cambios incrementalesuuml Aceptar el cambiouuml Trabajo de calidad

Raacutepida retroalimentacioacutenEn la praacutectica el tiempo transcurrido entre una accioacuten y su feedback es criacutetico Tener una raacutepida retroalimentacioacutennos permite interpretarla aprender de ella y poner en praacutectica lo asimilado lo antes posible

Asumir la simplicidadEste es uno de los principios maacutes difiacuteciles de llevar a la praacutectica Casi siempre se planifica para el futuro y se disentildeapara poder rehusar En lugar de esto XP dice que hay que hacer un buen trabajo para las necesidades actuales yconfiar en nuestra habilidad para solucionar problemas futuros

Cambios incrementalesRealizar grandes cambios en una sola oportunidad no es una buena solucioacuten Cada problema debe ser resuelto conuna serie de cambios pequentildeos para poder atacar dicho problema mucho maacutes en profundidad

Aceptar el cambioEn XP el cambio es asimilado como algo habitual e inevitable La mejor estrategia es aquella que preserva la mayorcantidad de opciones mientras resuelve los problemas maacutes precisos

Trabajo de calidadUno de los objetivos maacutes importantes en XP es realizar un producto de buena calidad Si cada integrante realiza sutrabajo de la mejor manera posible se puede asegurar la calidad del producto

Otros principiosAdemaacutes de los principios antes mencionados surgen algunos otros de menor trascendencia que pueden ayudar atomar buenas decisiones en situaciones especiacuteficas

uuml Aceptar la responsabilidaduuml Adaptacioacuten localuuml Comunicacioacuten abierta y honestauuml Ensentildear conocimientosuuml Experimentos concretosuuml Jugar para ganaruuml Mediciones honestasuuml Pequentildea inversioacuten inicialuuml Trabajar con los instintos de las personasuuml Viajar liviano



Aceptar la responsabilidad Es bueno permitir que cada uno de los integrantes se ofrezca de forma voluntaria parapoder realizar una tarea determinada y que esta se comprometa ante el resto del equipo Imponer una tarea hace queel miembro del equipo haga algo que pueda no cumplir maacutes adelante y pierda su motivacioacuten (ExtremeProgramming explined Capiacutetulo 8 Basic Principies Paacuteg 37)

Adaptacioacuten local Para que XP funcione de la mejor manera posible es necesario que se adapte a las condicionesparticulares de cada proyecto

Comunicacioacuten abierta y honesta La comunicacioacuten es uno de los pilares fundamentales en XP Es necesario quecada uno de los integrantes sepa exponer las consecuencias de sus propias decisiones y de las tomadas por losdemaacutes asiacute como tambieacuten comunicar los problemas sin miedo de anunciar malas noticias (Extreme Programmingexplined Capiacutetulo 8 Basic Principies Paacuteg 37)

Ensentildear conocimientos XP se concentra en ensentildear distintas estrategias para saber como adoptar esta metodologiacuteasin tratar de imponer ninguna de estas

Experimentos concretos Toda decisioacuten que se tome a lo largo del proyecto debe ser analizada y probada para evitarasiacute cualquier tipo de errores

Jugar para ganar Todos los integrantes deben trabajar en equipo de manera agresiva y con mucho coraje paralograr el objetivo comuacuten que es el eacutexito de todo el proyecto

Mediciones honestas Toda estimacioacuten o meacutetrica realizada debe ser lo maacutes loacutegica posible ya que no tiene sentido daralgo tan exacto que quizaacutes nunca se cumpla

Pequentildea inversioacuten inicial Al igual que la realizacioacuten de un sistema en pequentildeas entregas es bueno realizarinversiones de igual manera e ir avanzando de forma progresiva

Trabajar con los instintos de las personas XP estaacute a favor de trabajar con los instintos de las personas y no encontra de ellos Los instintos de las personas aquello que los incentiva son principalmente hacer bien su trabajo yrealizar las tareas en grupo interactuando con el resto del equipo (Extreme Programming explined Capiacutetulo 8Basic Principies Paacuteg 37)

Viajar liviano Para poder adaptarse raacutepidamente a los cambios constantes es bueno llevar solo lo indispensable





Principales conceptosAntes de comenzar a profundizar sobre la forma de trabajo de XP es bueno tener en claro algunos conceptos que sonbaacutesicos en esta metodologiacutea

A continuacioacuten se detallan los maacutes importantes

uuml Story cardsuuml Iteracioacutenuuml Refactoringuuml Releaseuuml Test de aceptacioacutenuuml Test unitario

Story CardsLas story cards sirven para registrar los requerimientos de los clientes y son utilizadas para poder realizar laestimacioacuten de cada una de las iteraciones durante la fase de planificacioacuten

Las story cards son escritas por los clientes en base a lo que se estima es necesario para el sistema Estaacuten escritas enun formato de oraciones en la terminologiacutea del cliente sin necesidad de sintaxis teacutecnicas

Tambieacuten son utilizadas para poder crear los test de aceptacioacuten Por lo general se necesitan uno o maacutes test deaceptacioacuten para verificar que la story ha sido implementada correctamente (Extreme Programming Story Cards)

Una de las malas impresiones que generan las story cards es su diferencia con la especificacioacuten de requerimientostradicional La mayor diferencia es su nivel de detalle Las story cards solo proveen suficiente detalle para poderrealizar la estimacioacuten de cuando tardaraacute en ser implementada dicha funcionalidad Cuando el tiempo es calculado elprogramador se encarga de solicitarle al cliente una descripcioacuten maacutes detallada de los requerimientos

Otra diferencia entre las stories y los documentos tradicionales es que se centran en lo que el cliente necesita Hayque tratar de evitar en detallar la tecnologiacutea o los algoritmos Se deben mantener las stories focalizadas en lasnecesidades y los beneficios que le pueden brindar al cliente (Extreme Programming Story Cards)

Cada story puede llevar entre 1 a 3 semanas en ser desarrollada en un desarrollo ideal Este desarrollo ideal escuanto tiempo se tarda en implementar una story si no hay distracciones no hay otras asignaciones y se sabeexactamente que hacer Maacutes de tres semanas significa que la story debe ser dividida para ser implementada Si tomamenos de una semana se pueden combinar con otras stories Entre 20 y 80 stories es el nuacutemero ideal para podercrear un plan de entregas

IteracioacutenConsta de un periacuteodo de una a dos semanas en las cuales el cliente selecciona las stories en ser desarrolladas Luegode ser implementadas este cliente corre sus test funcionales para ver si la iteracioacuten puede terminar de maneraexitosa

Otro punto que no debe ser pasado por alto es el tema de la duracioacuten de cada iteracioacuten Con iteraciones cortas sepretende que el equipo tenga objetivos a corto plazo y pueda ver el resultado de su trabajo cada cierto tiempo y noesperar varios meses para ver si lo que se hizo estuvo bien o no El poder tener un reconocimiento de que se estaacutenhaciendo bien las cosas cada cierto tiempo hace que la persona se mantenga motivada Ademaacutes el poder tenerretroalimentacioacuten constante con el cliente permite tener un mejor nivel en el trabajo

Tambieacuten debemos considerar que las iteraciones cortas permiten hacer un diagnoacutestico prematuro de la situacioacuten delproyecto con lo cual no se debe esperar mucho tiempo en detectar posibles problemas



RefactoringOtro concepto muy importante es el refactoring Consiste en realizar cambios al sistema sin modificar lafuncionalidad del mismo para poder hacer el sistema maacutes simple para aumentar la eficiencia o para que el coacutedigosea mucho maacutes entendible Sea cual sea el objetivo del refactoring no hay que olvidar que en XP el coacutedigo es ladocumentacioacuten maacutes importante del proyecto y por ende debe estar bien desarrollado

ReleaseUn release puede ser definido como un conjunto de funcionalidad que es integrada para realizar un programaejecutable La idea de cada release es poder tener un producto intermedio al final de cada iteracioacuten en la cual elcliente pueda testear la funcionalidad pedida Con esto los clientes pueden ademaacutes ver el avance del proyecto ypoder realizar comentarios a los programadores y no esperar hasta el final del mismo cuando esteacute todo integrado

Test de aceptacioacutenLos test de aceptacioacuten representan alguacuten tipo de resultado por parte del sistema Los clientes son los responsables deverificar la exactitud de estos test y de revisar los resultados para poder asiacute priorizar los test que fracasaron Tambieacutenson utilizados como test regresivos antes de entrar a la fase de produccioacuten (Extreme Programming Acceptance test)

Una story no es aceptada hasta que haya pasado su test de aceptacioacuten Esto significa que en cada iteracioacuten se debenrealizar nuevos test de aceptacioacuten o de lo contrario el equipo tendraacute una avance de cero

Estos test suelen ser automatizados para que puedan ser ejecutados frecuentemente El resultado de cada test espublicado para el resto del equipo

El nombre de test de aceptacioacuten refleja la verdadera intencioacuten la cual es garantizar a los clientes que losrequerimientos han sido realizados y el sistema es aceptable

Test unitarioLos testing unitarios son tan importantes como los test de aceptacioacuten Son realizados desde el punto de vista delprogramador y sirven ademaacutes de testear el coacutedigo para poder realizar el refactoring del mismo

Cada programador antes de comenzar a programar debe preparar los test unitarios Esto hace que dichos test esteacutenpreparados para ser corridos durante la codificacioacuten y ademaacutes hace que al programador le surjan dudas y puedaevacuarlas con el cliente antes de empezar con la codificacioacuten

ReferenciasExtreme Programming lthttpwwwextremeprogrammingorggt



El ciclo de vidaEl ciclo de vida de XP consiste baacutesicamente de seis fases Exploracioacuten Planificacioacuten Iterations to ReleaseProduccioacuten Mantenimiento y Muerte

1- ExploracioacutenEn esta fase los clientes realizan las story cards que desean que esteacuten para la primera entrega Cada story describeuna de las funcionalidades que el programa tendraacute Al mismo tiempo el equipo de desarrollo se familiariza con lasherramientas la tecnologiacutea y las praacutecticas a ser utilizadas durante el proyecto En algunos casos se utiliza unprototipo para testear la nueva tecnologiacutea y explorar algunos aspectos de la arquitectura a ser implementada Laduracioacuten de esta fase puede extenderse desde unas pocas semanas a varios meses dependiendo de la adaptacioacuten delequipo de desarrollo

2- PlanificacioacutenEl objetivo de esta fase es fijar la prioridad de cada una de las stories y se establece cual va a ser el contenido de laprimera entrega Los programadores estiman cuanto esfuerzo requiere cada story y se establece el cronograma Laduracioacuten del calendario para la entrega del primer release no suele superar los dos meses Duracioacuten de la fase deplanificacioacuten en siacute no toma maacutes de dos diacuteas

3- Iteraciones por entregasEsta fase incluye varias iteraciones del sistema antes de la entrega del primer release El calendario es dividido enun nuacutemero iteraciones de tal manera de que cada iteracioacuten tome de una a cuatro semanas de implementacioacuten En laprimera iteracioacuten se crea un sistema que abarca los aspectos maacutes importantes de la arquitectura global Esto se lograseleccionando las stories que hagan referencia a la construccioacuten de la estructura de todo el sistema

El cliente decide que stories van a ser implementadas para cada iteracioacuten Ademaacutes se realizan los test funcionalesrealizados por el cliente al final de cada iteracioacuten Al final de la uacuteltima iteracioacuten el sistema estaacute listo para ser puestoen produccioacuten

4- ProduccioacutenLa fase de produccioacuten requiere realizar muchos maacutes chequeos y testing antes que el sistema sea entregado al clienteEn esta fase aparecen nuevos cambios y se tiene que decidir si seraacuten incorporados o no en dicha entrega Duranteesta fase suele suceder que las iteraciones se aceleren de tres a una semana Las ideas pospuestas y las sugerenciasson documentadas para luego ser implementadas maacutes adelante por ejemplo en la fase de mantenimiento

Luego que el primer release es creado el proyecto debe mantener el sistema en produccioacuten corriendo mientas setrabaja en las nuevas iteraciones

5- MantenimientoEn esta fase por lo general se necesita un esfuerzo extra de los programadores para satisfacer los requerimientos delcliente Por este motivo la velocidad de desarrollo suele disminuir una vez que el sistema es puesto en produccioacuten Araiacutez de esto se requiere incorporar nuevos integrantes al equipo y cambiar la estructura del equipo

6- MuerteEsta uacuteltima fase se acerca una vez que el cliente no tiene ninguna story a ser implementada Los requerimientos delsistema deben ser satisfechos en otros aspectos como ser la performance o la confiabilidad del mismo Esta es laetapa en la cual no hay maacutes cambios en la arquitectura el disentildeo o el coacutedigo y aquiacute es cuando se realiza ladocumentacioacuten correspondiente Esta fase aparece tambieacuten cuando el sistema no da los resultados deseados o sevuelve demasiado caro para seguir siendo desarrollado



Figura 2 ndash Ciclo de vida de XP

ExploracioacutenDurantes esta fase los programadores utilizan cada parte de la tecnologiacutea a ser usada durante el proyecto Seexploran todas las posibilidades que puede tener la arquitectura del sistema Se utilizan una o dos semanas paraconstruir prototipos que implementen la funcionalidad baacutesica pero de dos o tres formas distintas (Agile softwardevelopment methods Reviews and analysis Extreme ProgrammingProcess Pag - 19)

Si una semana no alcanza para explorar una parte de la tecnologiacutea esto puede clasificarse como un riesgo Esto nosignifica que no se pueda utilizar pero siacute seriacutea bueno explorarla con maacutes detalle y considerar alternativas

Los programadores suelen estimar la duracioacuten de cada tarea realizada durante esta fase Cuando finaliza una tarea sereporta en el calendario el tiempo requerido

Mientras los programadores trabajan con la tecnologiacutea los clientes escriben las stories Al principio las stories noson las que se esperan La clave es darle raacutepidamente al cliente una feedback de las primeras stories para queaprendan en seguida a como especificar lo que los programadores necesitan

PlanificacioacutenEl propoacutesito de esta fase es el de llegar a un acuerdo entre los clientes y los programadores en cuales seraacuten lasstories a ser implementadas durante cada iteracioacuten Si se hace una buena preparacioacuten durante la fase de exploracioacutenesta actividad no suele llevar maacutes de un diacutea o dos

La entrega del primer release debe tomar entre dos a seis meses de duracioacuten Si se planifica realizarla en menostiempo es probable que no se tengan los elementos necesarios para solucionar los problemas maacutes significativos Perosi se tarda maacutes de este periacuteodo se corre el riesgo que el cliente no quede satisfecho

Iteraciones por entregasUna vez elegido el orden en el cual se implementaraacuten las stories se procede a definir cuantas iteraciones seraacutennecesarias para el proyecto Cada iteracioacuten tiene una duracioacuten de una a cuatro semanas en las cuales se realizan lostest funcionales para cada una de las stories a ser implementadas (Agile softwar development methods Reviews andanalysis Extreme ProgrammingProcess Pag - 19)



La primera iteracioacuten suele servir para definir la arquitectura de todo el sistema Es por este motivo que seseleccionan las stories que definen la arquitectura aunque solo formen una base del mismo

La seleccioacuten de las stories para las siguientes iteraciones suele quedar al criterio del cliente El cliente debeseleccionar las stories que tengan maacutes intereacutes para eacutel de las que falten ser implementadas

Ademaacutes de la implementacioacuten se debe llevar un control con respecto a las desviaciones del calendario Cuando sedetectan desviaciones es necesario tomar medidas Quizaacutes se deba agregar o remover stories o quizaacutes deba encontraruna mejor manera para utilizar la tecnologiacutea e incluso para utilizar XP

Al final de cada iteracioacuten el cliente debe analizar que todas las stories esteacuten implementadas Debe tambieacuten corrertodos los test funcionales y que estos resulten ser exitosos

ProduccioacutenEn esta fase es donde el producto se pone en produccioacuten y se realizan todas las pruebas de preformase del sistemaEste es el momento en donde se afinan los detalles del sistema debido a que se tiene un gran conocimiento deldisentildeo y ademaacutes se dispone del hardware en donde se va a correr el sistema

Durante esta fase se debe ir maacutes despacio a medida que se desarrollando el software Esto no significa que eldesarrollo se detenga pero si es de considerar que el riesgo se vuelve maacutes importante a medida que los cambiosafecten al release

MantenimientoEn esta fase se debe agregar nueva funcionalidad mantener el sistema corriendo e incorporar nuevos integrantes alequipo

Se hacen los refactoring que no se pudieron realizar anteriormente Ademaacutes se prueba la nueva tecnologiacutea que se vaa utilizar en el proacuteximo release o migrar a nuevas versiones de la tecnologiacutea que se estaacute utilizando Tambieacuten se sueleexperimentar con nuevas ideas para la arquitectura actual y el cliente suele escribir nuevas stories que puedanmejorar el sistema (Agile softwar development methods Reviews and analysis Extreme ProgrammingProcess Pag- 19)

El trabajar sobre un sistema que estaacute en produccioacuten no es lo mismo que hacerlo sobre un sistema que auacuten estaacute siendodesarrollado Hay que ser muy cuidadoso sobre los cambios a ser realizados

Otros de los puntos que se debe considerar en esta fase es la incorporacioacuten de nuevos integrantes al equipo dedesarrollo Es bueno darle dos o tres iteraciones donde ellos hagan muchas preguntas trabajen en parejas y leanmucho coacutedigo y casos de prueba Cuando ellos se sientan listos pueden ser puestos a trabajar en algunas tareas deprogramacioacuten y asiacute hasta que queden completamente integrados Si el equipo va cambiando gradualmente duranteun antildeo se puede reemplazar sin desestabilizar la forma de trabajo que se lleva (Extreme Programming explinedCapiacutetulo 21 Lifecycle of an ideal XP Proyect Paacuteg 131)

MuerteHay dos buenas razones por la cual el sistema entre en esta fase La primera puede ser debido a que el cliente esteacutemuy satisfecho con el sistema y no tenga ninguna otra funcionalidad que agregar en el futuro La otra razoacuten suele serque el sistema no termina de ser liberado El cliente necesita maacutes funcionalidades y es imposible costearlas Otromotivo puede ser que los defectos detectados alcancen un nivel intolerable

ReferenciasABRAHAMSSON Pekka SALO Outi JUSSI Agile softwar development methods Reviews and analysis [online]Disponible en Internet lthttpwwwinfovttfipdfgt

KENT Beck 2000 Extreme Programming explined 1ra edicioacuten



Ciclo de vida del programadorAdemaacutes del ciclo de vida comuacuten de XP podemos encontrar otro ciclo de vida dentro de este que indica comotrabajan los programadores para poder codificar

Figura 3 ndash Ciclo de vida del programadorEl triaacutengulo que se encuentra en el medio de la figura 3 es la clave principal en la idea de XP En ellas se muestra laforma de trabajo Testing codificacioacuten y luego refactoring Esto es lo opuesto a la programacioacuten tradicional endonde primero se disentildea luego se codifica y por uacuteltimo se testea (Extreme Programming XP Programmers Cube -A Day in the Life)

Veamos en detalle cada una de las actividades

middot Eleccioacuten de pareso Toda la produccioacuten se realiza en pareso El encargado de escribir piensa taacutecticamente su pareja piensa estrateacutegicamenteo Se rotan los roles perioacutedicamente

middot Testingo Se escriben los testing unitarioso Se verifica que los test fallen antes de codificaro Se testea todo lo que posiblemente puede fallar

middot Codificacioacuteno ldquoHacer algo que funcione de la manera maacutes sencillardquoo Implementar lo suficiente para hacer que el test paseo Seguir el estaacutendar de codificacioacuten

middot Refactoringo Quitar toda porcioacuten de coacutedigo que no parezcan estar bien y luego verificar si el coacutedigo auacuten pasa

los test unitarioso El coacutedigo debe ser claro no tener partes duplicadas y tener la menor cantidad de clases y meacutetodos

posibleso Realizar cambios pequentildeos y luego realizar los test unitarios

TESTING Q amp A

CODIFICACIOacuteN REFACTORING

INTEGRACIOacuteN

ELECCIOacuteN DE PARES



middot Q amp Ao El cliente puede proveer raacutepidamente cualquier respuesta on-siteo Muchas preguntas requieren decisiones y el cliente debe estar preparado para poder hacerlaso El cliente suele escribir una story o un test de aceptacioacuten que captura sus preguntas

middot Integracioacuteno Llevar el coacutedigo a la maacutequina donde se realiza la integracioacuten unir el sistema y correr todos los

testo Arreglar todos los errores para que pasen todos los test unitarioso Si no es faacutecil la integracioacuten es mejor tirar todo y comenzar nuevamente al diacutea siguiente

middot Retornar al inicioo Si resta tiempo se puede elegir otra pareja o cambiar de roles y comenzar con otra actividad

ReferenciasExtreme Programming lt httpwwwxp123comgt



Roles y responsabilidadesDentro de la mitologiacutea de XP existen variados roles A continuacioacuten se detallan cuales son los roles maacutesimportantes

ClienteEs quien establece que es lo que debe realizar el sistema tomando la decisioacuten de cuando se debe implementardeterminada funcionalidad asiacute como tambieacuten en el orden a ser implementadas Ademaacutes el cliente escribe las storycards y los test funcionales y decide cuando cada requerimiento estaacute satisfecho Los clientes tambieacuten priorizan cadauno de los requerimientos (Praacutecticas Extremas en ORTsf Roles Paacuteg 57)

CoachEs el encargado de asegurar el cumplimiento de todas las praacutecticas transmitiendo sus conocimientos y experienciaal resto del equipo

ConsultantEs una persona externa al equipo que posee el conocimiento teacutecnico necesario para poder ayudar al equipo condeterminados problemas

ManagerToma las decisiones maacutes importantes del proyecto Es el encargado de comunicarse con el equipo para determinarcual es la situacioacuten actual y distinguir cualquier dificultad o deficiencia en el proceso y poder solucionarlo

ProgramadorEs el responsable de escribir los testing del sistema y mantener el coacutedigo lo maacutes simple y definitivo posible Elprimer aspecto a tener en cuenta para que XP sea exitoso es la coordinacioacuten entre los programadores y el resto delequipo

TesterLos tester ayudan a los clientes a escribir los test funcionales del sistema Ademaacutes corren dichos testingregularmente enviacutean los informes con los resultados y realizan el mantenimiento a las herramientas de testing

TrackerTiene como principal responsabilidad realizar las mediciones y la recoleccioacuten de meacutetricas Mide el progreso delproyecto y lo compara con lo estimado Tambieacuten observa el desempentildeo del equipo haciendo eacutenfasis en elcumplimiento de los plazos y aconsejando al equipo si deben realizar cambios para lograr los objetivos Ademaacutes detodo esto mantiene los registros de los casos de prueba ejecutados los defectos encontrados y sus responsables(Agile softwar development methods Reviews and analysis Extreme ProgrammingRoles and Responsabilities Paacuteg- 21)

ReferenciasABRAHAMSSON Pekka SALO Outi JUSSI ldquoAgile softwar development methods Reviews andanalysisrdquo[online] Disponible en Internet lthttpwwwinfovttfipdfgt




PraacutecticasUno de los factores que hacen que XP sea tan utilizado y efectivo son las praacutecticas que se realizan durante elproyecto XP es un conjunto de ideas y praacutecticas de metodologiacuteas ya existente y por eso deben ser muy tenidas encuenta a la hora de su implementacioacuten A continuacioacuten se presentan las praacutecticas maacutes utilizadas

uuml 40 Horas semanalesuuml Cliente on-siteuuml Disentildeo simpleuuml El juego de la planificacioacutenuuml Estaacutendares de codificacioacutenuuml Integracioacuten continuauuml Metaacuteforauuml Pequentildeas entregasuuml Programacioacuten por paresuuml Propiedad colectivauuml Testinguuml Refactoring

40 horas semanalesComo maacuteximo se puede trabajar un promedio de 40 horas semanales No se permite trabajar tiempo extra durantedos semanas seguidas Si esto ocurre se trata de un problema a ser solucionado

El no tener que realizar horas extras hace que los integrantes puedan disponer de tiempo libre para poder descansar yrealizar otras actividades De esta forma la productividad del equipo se mantiene alta y se reducen los problemas porfalta de descanso

Como en los proyectos suelen haber retrasos se estaacute permitido poder realizar en una semana una mayor cantidad dehoras que las establecidas Pero solamente durante una semana ya que si sigue el atraso es un indicador de que algomalo sucede con el proyecto y el tener mayor carga horaria a la larga no es la solucioacuten

El realizar horas extras maacutes de una semana seguida hace que se comentan maacutes errores tanto en el coacutedigo como en eldisentildeo Esto hace que la calidad del producto realizado sea menor y a largo plazo ese tiempo supuestamenterecuperado se pierde debido a estos problemas (Agile softwar development methods Reviews and analysis ExtremeProgrammingPractices Paacuteg - 22)

Cliente On-SiteEl cliente debe estar presente y disponible en todo momento para el equipo

El contar con el cliente on-site permite al equipo poder evacuar cualquier tipo de duda que pueda surgir Ademaacutes deesto el cliente puede observar cual el grado de avance del proyecto mientras se construye el sistema

La mayor ventaja de todas es que se puede crear una comunicacioacuten fluida con el cliente sin necesidad de gastartiempo en documentacioacuten formal Esta comunicacioacuten constante reduce el tiempo de desarrollo al reducir las esperaspor respuesta y los malentendidos entre ambas partes (Agile softwar development methods Reviews and analysisExtreme ProgrammingPractices Paacuteg - 22)

Disentildeo simpleSe hace mucho eacutenfasis en el disentildeo de una solucioacuten lo maacutes simple posible que pueda ser implementada en elmomento El coacutedigo complejo o innecesario es eliminado inmediatamente

En XP el disentildeo se hace en forma progresiva lo cual evita que se cree un disentildeo altamente complejo por quererabarcar todos los aspectos posibles de una sola vez Un buen disentildeo debe cumplir los siguientes puntos

sect Corre todo los casos de prueba



sect Enuncia todas las ideas que se quieren exhibirsect No tiene coacutedigo duplicadosect Posee el menor nuacutemero de clases y meacutetodos posibles

Para poder obtener un disentildeo simple se descartan todos aquellos elementos innecesarios mientras que los tresprimeros puntos se cumplan

El juego de la planificacioacutenPara poder realizar una buena planificacioacuten se necesita una buena interaccioacuten entre los clientes y los programadoresLos programadores estiman el esfuerzo necesario para cada una de las stories y los clientes deciden sobre el alcancey el momento en el que debe realizar cada entrega

En el plan de entregas el cliente elige aquellas stories que crea son maacutes importantes para implementar Cada entregadebe tener una duracioacuten maacutexima de dos meses y se estima la duracioacuten suponiendo que no hay retrasos o imprevistos

Cada entrega consta de varias iteraciones cuya duracioacuten no debe superar las dos semanas En el plan de iteracionesel cliente selecciona las stories a ser implementadas y se detallan las pruebas de aceptacioacuten para cada story Losprogramadores dividen cada story en tareas que luego son aceptadas por cada programador estimadasimplementadas y por uacuteltimo integradas al sistema (Praacutecticas Extremas en ORTsf Roles Paacuteg 40)

Las tareas tienen una duracioacuten promedio de uno a dos diacuteas En ellas los programadores establecen todos los casos deprueba posibles antes de comenzar con la implementacioacuten Luego se pasa a la implementacioacuten en el cual el clienteestaacute disponible para poder evacuar cualquier duda que surja

Estaacutendares de codificacioacutenEl coacutedigo es la mejor documentacioacuten que tiene el sistema Es por este motivo que se deben establecer reglas para losprogramadores y estas deben ser seguidas estrictamente

En un equipo de desarrollo los programadores acuerdan un estaacutendar para el coacutedigo dejando de lado estilos deprogramacioacuten particulares Todos deben conocer y seguir el estaacutendar de manera tal que al final el sistema parezcaser programado por una sola persona

Algunos de los puntos a tener en cuenta son los siguientes

sect Mantener meacutetodos pequentildeos (el coacutedigo puede ser visto en una sola pantalla)sect Ser coherentes en el uso de mayuacutesculassect Solo comentar el coacutedigo cuando sea realmente es necesariosect Usar formatos de nombres consistentes y similaressect Utilizar siempre el mismo formato de sangriacutea

Integracioacuten continuaUna nueva pieza de coacutedigo debe ser integrada al resto del sistema tan pronto como sea posible De ese modo elsistema es integrado y reconstruido varias veces por diacutea

Para poder realizar esta integracioacuten se selecciona una computadora determinada Luego al finalizar cada pareja deprogramadores se dirige a dicha maacutequina para integrar sus cambios al sistema existente Posteriormente se ejecutantodos los casos de prueba establecidos hasta que cada uno de ellos sea aprobado (Praacutecticas Extremas en ORTsfRoles Paacuteg 40)

Lo bueno de este sistema es que no ocurren problemas de integracioacuten ya que los errores se encuentran y sesolucionan al momento de ser integrados por los mismos programadores que tienen en la cabeza en coacutedigoimplementado Esto evita que se pasen meses para la integracioacuten y tener que solucionar estos problemas maacutesadelante



MetaacuteforaEl sistema es definido en base a una metaacutefora o conjuntos de metaacuteforas entre el cliente y los programadores

Para XP la metaacutefora equivale a la arquitectura en otras metodologiacuteas pero es maacutes formal y sencilla Es utilizada porlos programadores para describir a grandes rasgos la estructura del sistema de manera tal que pueda ser comprendidapor todos los integrantes

Una vez que la metaacutefora es creada se pasa al establecimiento de clases meacutetodos y relaciones primordiales delsistema

Ademaacutes de servir como fuente de comunicacioacuten entre los clientes y los programadores sirve para poder mantener eldisentildeo del sistema lo maacutes simple posible Tambieacuten se utiliza para comunicar las bases del sistema a los nuevosintegrantes

Pequentildeos releaseLos release deben ser los maacutes pequentildeos posibles con una duracioacuten no mayor a dos meses Esto permite que losclientes puedan ver el avance del proyecto y los programadores puedan retroalimentarse de las opiniones de losclientes

Por lo general estos release comienzan implementando las caracteriacutesticas primordiales del sistema Luego a medidaque avanza el proyecto se van agregando el resto de las funcionalidades

El poder tener un producto terminado cada cierto tiempo hace que el cliente vea como va tomando forma suproducto y ademaacutes hace que los programadores mantengan su nivel de motivacioacuten ya que lo maacutes agradable deprogramar es poder entregar un producto terminado (Praacutecticas Extremas en ORTsf Roles Paacuteg 40)

Programacioacuten por paresUno de los pilares de XP es la programacioacuten en pareja o programacioacuten por pares Baacutesicamente lo que se quiere conesto es poder eliminar posibles errores debido a distracciones o errores conceptuales Al tener dos personasconcentradas sobre el mismo coacutedigo se evitan estos errores y se ahorra tiempo en futuras correcciones

Una de las dos personas es el ldquoconductorrdquo que es el encargado de escribir el coacutedigo La otra persona el ldquocopilotordquoparticipa verbalmente El ldquoconductorrdquo tiene una visioacuten de coacutemo implementar el coacutedigo de la mejor manera mientrasque el ldquocopilotordquo tiene una visioacuten global del sistema y se encarga de sugerir posibles alternativas y nuevos casos deprueba Es bueno que los dos integrantes se turnen en la conduccioacuten (Praacutecticas Extremas en ORTsf Roles Paacuteg 40)

Propiedad colectivaCualquier persona estaacute en condiciones de cambiar cualquier parte del coacutedigo en cualquier momento

En XP nadie tiene propiedad sobre ninguacuten moacutedulo o clase Cada uno de los integrantes puede realizar cambios omejoras a cualquier parte del coacutedigo en cualquier momento Esto hace que el sistema cuente con una menor cantidadde defectos y por ende una mejor calidad

TestingOtro de los puntos importantes de XP son los testing los cuales se realizan continuamente Existen dos tipos detesting testing unitario y testing funcionales o de aceptacioacuten

Los testing unitarios son implementados por los programadores antes de comenzar con la implementacioacuten Seestablecen todos los casos en el que el coacutedigo puede fallar Una vez que se termina con la implementacioacuten se correndichas pruebas y se verifica que no haya ninguacuten test que falle Hasta que pasen todos los test el programador debeseguir mejorando el coacutedigo Estas pruebas son automatizadas e implementadas por el propio programador lo cualhace que la prueba pueda ser maacutes raacutepida y efectiva



Los testing funcionales o de aceptacioacuten son definidos y escritos por el cliente al inicio de cada iteracioacuten para cadauna de las stories establecidas El objetivo es demostrar al cliente que el requerimiento implementado realmentefunciona como el cliente lo desea

RefactoringEl refactoring del coacutedigo hace que este sea faacutecil de entender y de mantener sin modificar su comportamiento

En XP el refactoring se realiza permanentemente en base a estar respaldados por efectivos casos de prueba Comoresultados la cantidad de errores disminuye lo cual mejora la calidad del software El disentildeo se mantiene simple ypermite a los programadores desarrollar maacutes raacutepido





Herramientas para el testeo automaacuteticoDebido a que el testing es una de las actividades maacutes importantes en la programacioacuten de XP es necesario poseer unabuena herramienta de testeo automaacutetico seguacuten el tipo de lenguaje en el cual se desarrolle

Una de las herramientas maacutes conocida para realizar el testing automaacutetico es JUnit Esta herramienta sirve para losprogramadores que desarrollan en JAVA pero en el mercado hay otros tipo de JUnit para los distintos lenguajes

El objetivo de esta seccioacuten no es mostrar el funcionamiento de JUnit sino que se desea ejemplificar como se puedeimplementar el testeo automaacutetico

JUnitCaso simplePara poder realizar un test simple en alguacuten meacutetodo simplemente se debe hacer lo siguiente

middot Crear una instancia de TestCasemiddot Crear un constructor el cual acepte un String como paraacutemetro y pasar este como superclasemiddot Reescribir el meacutetodo runTest()middot Cuando se quiere chequear un valor llamar al meacutetodo assertTrue() y pasarle un boolean que sea

verdadero cuando el test sea correcto

Por ejemplo para poder testear el funcionamiento del meacutetodo ldquoconcatenarrdquo de la clase ldquoCadenardquo se puedeimplementar el siguiente meacutetodo

Public void testConcatenar()

Cadena cadena1 = new Cadena (ldquoHola rdquo)Cadena cadena2 = new Cadena (ldquoJuanrdquo)Cadena resultado = cadena1concatenar(cadena2)

Cadena valorEsperado = new Cadena(ldquoHola Juanrdquo)

asserTrue(valorEsperadoequals(resultado))

SuiteA medida que se avanza con la implementacioacuten es loacutegico que aparezca la necesidad de realizar varios test y esbueno poder correrlos todos a la vez si necesidad de correrlos uno por uno Para ello JUnit provee un objeto llamadoTestSuite el cual permite correr cualquier cantidad de test al mismo tiempo

Por ejemplo para correr un test simple se ejecuta

TestResult resultado = (new CadenaTest (ldquotestConcatenar()rdquo))run()

Pero para poder realizar el testeo de dos casos al mismo tiempo se debe realizar lo siguiente

TestSuite suite = new TestSuite()suiteaddTest(new CadenaTest(ldquotestEqualsrdquo)suiteaddTest(new CadenaTest(ldquotestConcatenarrdquo)TestResult resultado = suiterun()

TestRunnerUna vez que los test suite estaacuten implementados es hora de recolectar la informacioacuten de cada uno de dichos test Paraesto es necesario implementar un meacutetodo estaacutetico llamado suite que retorna un test suite (JUnit JUnit CookBook )



Por ejemplo para el caso de la ldquoCadenardquo es necesario implementar lo siguiente

Public static Test suite()


JUnit provee distintos tipos de testing (TestRunner)middot Textual TestRunner Este es mucho maacutes raacutepido de ejecutar y puede ser utilizado cuando no es necesario

tener informacioacuten graacutefica de los resultados del testingmiddot Graphical TestRunner Este muestra un simple diaacutelogo en el cual se elige el test a ejecutar y provee una

graacutefica de progresioacuten de los test realizados

El Graphical TesRunner muestra una ventana con la siguiente informacioacutenmiddot Un campo donde se indica el nombre de la clase con el meacutetodo suitemiddot Un botoacuten Run que comienza el testeomiddot Una barra de progreso la cual se torna de roja a verde en el caso que un test fallemiddot Una lista de los test fallados

En el caso que un test falle se reporta este caso en la lista de abajo

Con este tipo de herramientas el testing es mucho maacutes faacutecil de implementar y se obtienen los beneficios que hemosexplicado anteriormente como por ejemplo el refactoring

ReferenciasJUnit lthttpwwwjunitcomgt



ConclusionesComo hemos visto en este documento hay aspectos en XP que lo hacen diferente a otras metodologiacuteas

Comenzamos con sus valores (Comunicacioacuten Simplicidad Feedback y Coraje) En XP la comunicacioacuten es vitaltanto entre el grupo de desarrollo como con el cliente el cual debe formar parte del equipo para mantener unacomunicacioacuten fluida y poder de esta forma evacuar cualquier tipo de duda que surja con los requerimientos Lasimplicidad apuesta a realizar algo simple hoy y destinar un poco maacutes de esfuerzo para realizar un cambio en elfuturo a realizar algo maacutes complicado hoy y no utilizarlo nunca El feedback constante entre el equipo y el clientehace que se pueda conocer el estado actual del proyecto y poder asiacute tomar decisiones mucho maacutes acertadas Poruacuteltimo la comunicacioacuten la simplicidad y el feedback forman el coraje el cual se convierte en el objetivo de XP Elcoraje tambieacuten es poder realizar cambios cuando algo no funciona del todo bien disentildear e implementar solo lonecesario para el presente pedir ayuda o reducir el alcance de una entrega si el tiempo no alcanza

Los cuatro valores mencionados anteriormente nos brindan un estaacutendar para obtener buenos resultados Sinembargo los valores son muy vagos a la hora de ayudarnos a decidir que praacutecticas utilizar Para ello se necesitadestilar estos valores en principios que puedan ser utilizados como ser una raacutepida retroalimentacioacuten asumir lasimplicidad realizar cambios incrementales aceptar el cambio y realizar un trabajo de calidad

Por uacuteltimo debemos mencionar las praacutecticas que se utilizan las cuales hacen que XP sea tan utilizado y efectivoXP es un conjunto de ideas y praacutecticas de metodologiacuteas ya existente y por eso deben ser muy tenidas en cuenta a lahora de su implementacioacuten De la gran cantidad de praacutecticas destacamos


Todos estos puntos antes mencionados hacen permiten que se realice el software que el cliente solicita y necesita enel momento que lo precisa alentando a los programadores a responder a los requerimientos cambiantes que planteadicho cliente en cualquier momento

No debemos olvidar que la base de XP es que el proceso se mantenga aacutegil en todo momento lo cual significa que sepueda adaptar al cambio sin mayores complicaciones Por este motivo los conceptos antes mencionados no debenser impuestos bajo ninguacuten tipo de concepto sino que al contrario deben servir como una guiacutea seguacuten el tipo deproyecto que se quiera realizar



Palabras Clavesuuml 40 Horas semanalesuuml Aceptar el cambiouuml Aceptar la responsabilidaduuml Adaptacioacuten localuuml Asumir la simplicidaduuml Cambios incrementalesuuml Clienteuuml Cliente on-siteuuml Coachuuml Comunicacioacutenuuml Comunicacioacuten abierta y honestauuml Consultantuuml Corajeuuml Disentildeo simpleuuml El juego de la planificacioacutenuuml Ensentildear conocimientosuuml Entregauuml Estaacutendares de codificacioacutenuuml Fase de exploracioacutenuuml Fase de iteraciones por entregasuuml Fase de mantenimientouuml Fase de muerteuuml Fase de planificacioacutenuuml Fase de produccioacutenuuml Feedbackuuml Integracioacuten continuauuml Jugar para ganaruuml Manageruuml Mediciones honestasuuml Metaacuteforauuml Pequentildea inversioacuten inicialuuml Pequentildeas entregasuuml Programacioacuten por paresuuml Programacioacuten por paresuuml Programadoruuml Propiedad colectivauuml Raacutepida retroalimentacioacutenuuml Refactoringuuml Simplicidaduuml Sotriesuuml Story cardsuuml Test funcionaluuml Testeruuml Testing unitariosuuml Trabajar con los instintos de las personasuuml Trabajo de calidaduuml Trackeruuml Viajar liviano



Glosariouuml Refactoring Un cambio al sistema que mantiene el mismo comportamiento del sistema pero aumenta

algunos atributos de calidad como ser simplicidad flexibilidad mantenibilidad etc

uuml Release Conjunto de funcionalidad que es integrada para realizar un programa ejecutable

uuml Story cards Ficha en la cual el cliente especifica una funcionalidad en particular

uuml Story Funcionalidad que el cliente quiere que haga el sistema

uuml Test de aceptacioacuten Test escrito desde la perspectiva del cliente

uuml Test unitario Test escrito desde la perspectiva del programador



BibliografiacuteaArtiacuteculosABRAHAMSSON Pekka SALO Outi JUSSI Agile softwar development methods Reviews and analysis [online]Disponible en Internet lthttpwwwinfovttfipdfgt


LibrosKENT Beck 2000 Extreme Programming explined 1ra edicioacuten

Sitios WebExtreme Programming lthttpwwwextremeprogrammingorggt

Extreme Programming lt httpwwwxp123comgt

JUnit lthttpwwwjunitcomgt



Iacutendice GeneralIacutendice General_________________________________________________________________________________ 1Resumen _____________________________________________________________________________________ 3La filosofiacutea de XP ______________________________________________________________________________ 4Valores en XP _________________________________________________________________________________ 5Comunicacioacuten_______________________________________________________________________________________5Simplicidad_________________________________________________________________________________________5Feedback___________________________________________________________________________________________5Coraje _____________________________________________________________________________________________6

Principios de XP _______________________________________________________________________________ 7Raacutepida retroalimentacioacuten _____________________________________________________________________________7Asumir la simplicidad ________________________________________________________________________________7Cambios incrementales _______________________________________________________________________________7Aceptar el cambio ___________________________________________________________________________________7Trabajo de calidad___________________________________________________________________________________7Otros principios _____________________________________________________________________________________7

Principales conceptos ___________________________________________________________________________ 9Story Cards_________________________________________________________________________________________9Iteracioacuten ___________________________________________________________________________________________9Refactoring________________________________________________________________________________________10Release ___________________________________________________________________________________________10Test de aceptacioacuten __________________________________________________________________________________10Test unitario _______________________________________________________________________________________10

El ciclo de vida _______________________________________________________________________________ 11Exploracioacuten _______________________________________________________________________________________12Planificacioacuten_______________________________________________________________________________________12Iteraciones por entregas _____________________________________________________________________________12Produccioacuten ________________________________________________________________________________________13Mantenimiento _____________________________________________________________________________________13Muerte____________________________________________________________________________________________13

Ciclo de vida del programador___________________________________________________________________ 14Roles y responsabilidades ______________________________________________________________________ 16Cliente____________________________________________________________________________________________16Coach ____________________________________________________________________________________________16Consultant ________________________________________________________________________________________16Manager __________________________________________________________________________________________16Programador ______________________________________________________________________________________16Tester ____________________________________________________________________________________________16Tracker ___________________________________________________________________________________________16

Praacutecticas ____________________________________________________________________________________ 1740 horas semanales__________________________________________________________________________________17































Comunicacioacuten


Coraje












































































































TESTING Q amp A


INTEGRACIOacuteN


































































































































































Comunicacioacuten


Coraje












































































































TESTING Q amp A


INTEGRACIOacuteN






































































































































































































































TESTING Q amp A


INTEGRACIOacuteN




































































































































UniversidadORTUruguay · UniversidadORTUruguay CátedradeIngenieríadeSoftware MetodologíaXP...

Documents

Transcript of UniversidadORTUruguay · UniversidadORTUruguay CátedradeIngenieríadeSoftware MetodologíaXP...