M MMe eet tto ood ddo ool llo oog gg a aa X XXP PP
Ctedra de Ingeniera de Software.
Docente Responsable: Gastn Mousques. Autores: Luis Calabria 122919 Pablo Priz 123348 2003 Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 1 ndice General ndice General_________________________________________________________________________________ 1 Resumen _____________________________________________________________________________________ 3 La filosofa de XP ______________________________________________________________________________ 4 Valores en XP _________________________________________________________________________________ 5 Comunicacin_______________________________________________________________________________________5 Simplicidad_________________________________________________________________________________________5 Feedback___________________________________________________________________________________________5 Coraje _____________________________________________________________________________________________6 Principios de XP _______________________________________________________________________________ 7 Rpida retroalimentacin _____________________________________________________________________________7 Asumir la simplicidad ________________________________________________________________________________7 Cambios incrementales _______________________________________________________________________________7 Aceptar el cambio ___________________________________________________________________________________7 Trabajo de calidad___________________________________________________________________________________7 Otros principios _____________________________________________________________________________________7 Principales conceptos ___________________________________________________________________________ 9 Story Cards_________________________________________________________________________________________9 Iteracin ___________________________________________________________________________________________9 Refactoring________________________________________________________________________________________10 Release ___________________________________________________________________________________________10 Test de aceptacin __________________________________________________________________________________10 Test unitario _______________________________________________________________________________________10 El ciclo de vida _______________________________________________________________________________ 11 Exploracin _______________________________________________________________________________________12 Planificacin_______________________________________________________________________________________12 Iteraciones por entregas _____________________________________________________________________________12 Produccin ________________________________________________________________________________________13 Mantenimiento _____________________________________________________________________________________13 Muerte____________________________________________________________________________________________13 Ciclo de vida del programador___________________________________________________________________ 14 Roles y responsabilidades. ______________________________________________________________________ 16 Cliente____________________________________________________________________________________________16 Coach ____________________________________________________________________________________________16 Consultant ________________________________________________________________________________________16 Manager __________________________________________________________________________________________16 Programador ______________________________________________________________________________________16 Tester ____________________________________________________________________________________________16 Tracker ___________________________________________________________________________________________16 Prcticas ____________________________________________________________________________________ 17 40 horas semanales__________________________________________________________________________________17 Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 2 Cliente On-Site_____________________________________________________________________________________17 Diseo simple ______________________________________________________________________________________17 El juego de la planificacin ___________________________________________________________________________18 Estndares de codificacin ___________________________________________________________________________18 Integracin continua ________________________________________________________________________________18 Metfora __________________________________________________________________________________________19 Pequeos release ___________________________________________________________________________________19 Programacin por pares _____________________________________________________________________________19 Propiedad colectiva _________________________________________________________________________________19 Testing____________________________________________________________________________________________19 Refactoring________________________________________________________________________________________20 Herramientas para el testeo automtico ___________________________________________________________ 21 JUnit _____________________________________________________________________________________________21 Conclusiones _________________________________________________________________________________ 23 Palabras Claves_______________________________________________________________________________ 24 Glosario _____________________________________________________________________________________ 25 Bibliografa __________________________________________________________________________________ 26 Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 3 Resumen El objetivo principal de este documento, es resumir los principales aspectos de la metodologa de Extreme Programming. Entre otros puntos se mencionarn cuales son los valores y principios que se siguen en XP, as como tambin, los principales conceptos que se deben tener en cuenta a la hora de llevarla a la prctica. Luego se har un anlisis del ciclo de vida que se utiliza, en el cual se ver cuales son las etapas y las actividades ms importantes. Tambin se menciona cuales son los principales roles dentro de esta metodologa, as como tambin, sus responsabilidades, y adems, analizaremos las prcticas ms importantes que se deben seguir. Por ltimo haremos referencia a las herramientas de testeo automtico, haciendo hincapi en la herramienta JUnit. Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 4 La filosofa de XP XP es una metodologa gil para pequeos y medianos equipos, desarrollando software cuando los requerimientos son ambiguos o rpidamente cambiantes. A diferencia de los procesos tradicionales para desarrollar software, XP asume el cambio como algo natural, y que, indefectiblemente, en alguna etapa de un proyecto sucede. En XP se realiza el software que el cliente solicita y necesita, en el momento que lo precisa, alentando a los programadores a responder a los requerimientos cambiantes que plantea el cliente en cualquier momento. Esto es posible porque est diseado para adaptarse en forma inmediata a los cambios, con bajos costos asociados, en cualquier etapa del ciclo de vida. En pocas palabras, XP abraza el cambio. Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 5 Valores en XP Para poder implementar las prcticas que presenta XP hay que conocer cuales son los valores principales que hacen a esta mitologa. Estos valores son: Comunicacin Simplicidad Feedback Coraje Comunicacin Uno de los valores ms importantes en XP es la comunicacin. La mala comunicacin no surge por casualidad en un proyecto y pueden aparecer muchas circunstancias que hagan que esta falle; un programador le da malas noticias al gerente y este lo castiga, un cliente le dice al programador algo importante y este no le presta atencin. En cualquiera de los casos la comunicacin es un factor importante en cualquier tipo de proyecto. En XP se trata de mantener una buena comunicacin mediante un conjunto de prcticas que no se pueden realizar sin tener una buena comunicacin en el equipo. Muchas de estas prcticas hacen corto circuito si no hay buena comunicacin como en el caso de los testing unitarios, programacin por pares, el uso de estndares o la estimacin de las tareas. Trabajar en espacios abiertos hace que la comunicacin mejore al contrario de otras metodologas en las cuales los programadores trabajan en espacios reducidos. La comunicacin con el cliente es de vital importancia en XP y es por este motivo que el cliente es integrado al equipo. De esta forma, cualquier duda sobre los requerimientos puede ser evacuada inmediatamente. Adems, se planifica con el cliente y este puede estar al tanto del avance del proyecto. (Extreme Programming explined. Captulo 7. Four Values. Pg. 15) XP ha sido diseada para minimizar el grado de documentacin como forma de comunicacin, haciendo nfasis en la interaccin personal. De esta manera se puede avanzar rpidamente y de forma efectiva, realizando solo la documentacin necesaria. Simplicidad La simplicidad es el segundo valor que se utiliza en esta metodologa. XP apuesta a realizar algo simple hoy y destinar un poco ms de esfuerzo para realizar un cambio en el futuro, a realizar algo ms complicado hoy y no utilizarlo nunca. XP propone una regla muy simple: hacer algo que funcione de la manera ms sencilla. En el caso de tener que aadir nueva funcionalidad al sistema se deben examinar todas las posibles alternativas y seleccionar la ms sencilla. En otras ocasiones se hace uso del refactoring 1 que permite mantener el cdigo en funcionamiento pero mucho ms simple y organizado. (Prcticas Extremas en ORTsf. Valores. Pag - 27) Otra regla muy importante es: realizar solo lo necesario. Con esto se pretende agregar nueva funcionalidad que cumpla con los objetivos actuales sin necesidad de preocuparse por futuros requerimientos. Esto hace que se progrese de manera ms segura y rpida en el proyecto. Feedback Brindar un feedback correcto y preciso hace que se pueda mantener una buena comunicacin y conocer el estado actual del proyecto. 1 Refactoring: Un cambio al sistema que mantiene el mismo comportamiento del sistema, pero aumenta algunos atributos de calidad, como ser: simplicidad, flexibilidad, mantenibilidad, etc. Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 6 Comunicacin Simplicidad Feedback Coraje El feedback trabaja a diferentes escalas de tiempo. Uno es el feedback que se realiza minuto a minuto. Cuando un cliente escribe sus stories 1 los programadores realizan la estimacin de cada una de ellas y el cliente puede obtener inmediatamente el feedback sobre la calidad de dichas stories. El otro tipo de feedback que se realiza es a travs de pequeas entregas del sistema. De esta manera, el cliente est al tanto del avance del proyecto. Adems, el sistema es puesto en produccin en menor tiempo, con lo cual los programadores saben si realizaron un buen trabajo y si sus decisiones fueron acertadas. Coraje Obviamente cada uno de los valores antes mencionados tiene una gran interaccin entre ellos. Como se ve en la siguiente figura la comunicacin, la simplicidad y el feedback forman el coraje, el cual se convierte en el objetivo de XP. Uno de los lemas de XP menciona: Si no trabajas al tope de tu capacidad, alguien ms lo est haciendo y si no llegas a tiempo se comer tu almuerzo. (Prcticas Extremas en ORTsf. Valores. Pag - 27) Esto hace, a que por ejemplo, se tenga el coraje de modificar el cdigo en cualquier momento por cualquier miembro del equipo sabiendo que no se afectar el correcto funcionamiento del sistema. Figura 1 valores de XP El coraje tambin es poder realizar cambios cuando algo no funciona del todo bien, disear e implementar solo lo necesario 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 estn presentes. Referencias KENT, Beck. 2000. Extreme Programming explined. 1ra edicin ARRIETA, Sebastian. Prcticas Extremas en ORTsf. 2002. Universidad ORT Uruguay 1 Storie: Funcionalidad que el cliente quiere que haga el sistema. Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 7 Principios de XP Los cuatro valores mencionados anteriormente comunicacin, simplicidad, feedback y coraje nos brindan un estndar para obtener buenos resultados. Sin embargo, los valores son muy vagos a la hora de ayudarnos a decidir que prcticas utilizar. Para ello se necesita destilar estos valores en principios que puedan ser utilizados. A continuacin se detallan los principios ms importantes de XP. Rpida retroalimentacin Asumir la simplicidad Cambios incrementales Aceptar el cambio Trabajo de calidad Rpida retroalimentacin En la prctica el tiempo transcurrido entre una accin y su feedback es crtico. Tener una rpida retroalimentacin nos permite interpretarla, aprender de ella y poner en prctica lo asimilado lo antes posible. Asumir la simplicidad Este es uno de los principios ms difciles de llevar a la prctica. Casi siempre se planifica para el futuro y se disea para poder rehusar. En lugar de esto XP dice que hay que hacer un buen trabajo para las necesidades actuales y confiar en nuestra habilidad para solucionar problemas futuros. Cambios incrementales Realizar grandes cambios en una sola oportunidad no es una buena solucin. Cada problema debe ser resuelto con una serie de cambios pequeos para poder atacar dicho problema mucho ms en profundidad. Aceptar el cambio En XP el cambio es asimilado como algo habitual e inevitable. La mejor estrategia es aquella que preserva la mayor cantidad de opciones mientras resuelve los problemas ms precisos. Trabajo de calidad Uno de los objetivos ms importantes en XP es realizar un producto de buena calidad. Si cada integrante realiza su trabajo de la mejor manera posible se puede asegurar la calidad del producto. Otros principios Adems de los principios antes mencionados surgen algunos otros de menor trascendencia que pueden ayudar a tomar buenas decisiones en situaciones especficas. Aceptar la responsabilidad Adaptacin local Comunicacin abierta y honesta Ensear conocimientos Experimentos concretos Jugar para ganar Mediciones honestas Pequea inversin inicial Trabajar con los instintos de las personas Viajar liviano Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 8 Aceptar la responsabilidad: Es bueno permitir que cada uno de los integrantes se ofrezca de forma voluntaria para poder realizar una tarea determinada y que esta se comprometa ante el resto del equipo. Imponer una tarea hace que el miembro del equipo haga algo que pueda no cumplir ms adelante y pierda su motivacin. (Extreme Programming explined. Captulo 8. Basic Principies. Pg. 37) Adaptacin local: Para que XP funcione de la mejor manera posible es necesario que se adapte a las condiciones particulares de cada proyecto. Comunicacin abierta y honesta: La comunicacin es uno de los pilares fundamentales en XP. Es necesario que cada uno de los integrantes sepa exponer las consecuencias de sus propias decisiones y de las tomadas por los dems, as como tambin, comunicar los problemas sin miedo de anunciar malas noticias. (Extreme Programming explined. Captulo 8. Basic Principies. Pg. 37) Ensear conocimientos: XP se concentra en ensear distintas estrategias para saber como adoptar esta metodologa sin tratar de imponer ninguna de estas. Experimentos concretos: Toda decisin que se tome a lo largo del proyecto debe ser analizada y probada para evitar as cualquier tipo de errores. Jugar para ganar: Todos los integrantes deben trabajar en equipo de manera agresiva y con mucho coraje para lograr el objetivo comn que es el xito de todo el proyecto. Mediciones honestas: Toda estimacin o mtrica realizada debe ser lo ms lgica posible ya que no tiene sentido dar algo tan exacto que quizs nunca se cumpla. Pequea inversin inicial: Al igual que la realizacin de un sistema en pequeas entregas, es bueno realizar inversiones de igual manera e ir avanzando de forma progresiva. Trabajar con los instintos de las personas: XP est a favor de trabajar con los instintos de las personas y no en contra de ellos. Los instintos de las personas, aquello que los incentiva, son principalmente, hacer bien su trabajo y realizar las tareas en grupo, interactuando con el resto del equipo. (Extreme Programming explined. Captulo 8. Basic Principies. Pg. 37) Viajar liviano: Para poder adaptarse rpidamente a los cambios constantes es bueno llevar solo lo indispensable. Referencias KENT, Beck. 2000. Extreme Programming explined. 1ra edicin ARRIETA, Sebastian. Prcticas Extremas en ORTsf. 2002. Universidad ORT Uruguay Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 9 Principales conceptos Antes de comenzar a profundizar sobre la forma de trabajo de XP es bueno tener en claro algunos conceptos que son bsicos en esta metodologa. A continuacin se detallan los ms importantes. Story cards Iteracin Refactoring Release Test de aceptacin Test unitario Story Cards Las story cards sirven para registrar los requerimientos de los clientes y son utilizadas para poder realizar la estimacin de cada una de las iteraciones durante la fase de planificacin. Las story cards son escritas por los clientes en base a lo que se estima es necesario para el sistema. Estn escritas en un formato de oraciones en la terminologa del cliente, sin necesidad de sintaxis tcnicas. Tambin son utilizadas para poder crear los test de aceptacin. Por lo general se necesitan uno o ms test de aceptacin 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 especificacin de requerimientos tradicional. La mayor diferencia es su nivel de detalle. Las story cards solo proveen suficiente detalle para poder realizar la estimacin de cuando tardar en ser implementada dicha funcionalidad. Cuando el tiempo es calculado el programador se encarga de solicitarle al cliente una descripcin ms detallada de los requerimientos. Otra diferencia entre las stories y los documentos tradicionales es que se centran en lo que el cliente necesita. Hay que tratar de evitar en detallar la tecnologa o los algoritmos. Se deben mantener las stories focalizadas en las necesidades 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 es cuanto tiempo se tarda en implementar una story si no hay distracciones, no hay otras asignaciones y se sabe exactamente que hacer. Ms de tres semanas significa que la story debe ser dividida para ser implementada. Si toma menos de una semana se pueden combinar con otras stories. Entre 20 y 80 stories es el nmero ideal para poder crear un plan de entregas. Iteracin Consta de un perodo de una a dos semanas en las cuales el cliente selecciona las stories en ser desarrolladas. Luego de ser implementadas este cliente corre sus test funcionales para ver si la iteracin puede terminar de manera exitosa. Otro punto que no debe ser pasado por alto es el tema de la duracin de cada iteracin. Con iteraciones cortas se pretende que el equipo tenga objetivos a corto plazo y pueda ver el resultado de su trabajo cada cierto tiempo y no esperar varios meses para ver si lo que se hizo estuvo bien o no. El poder tener un reconocimiento de que se estn haciendo bien las cosas cada cierto tiempo, hace que la persona se mantenga motivada. Adems, el poder tener retroalimentacin constante con el cliente permite tener un mejor nivel en el trabajo. Tambin debemos considerar que las iteraciones cortas permiten hacer un diagnstico prematuro de la situacin del proyecto, con lo cual no se debe esperar mucho tiempo en detectar posibles problemas. Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 10 Refactoring Otro concepto muy importante es el refactoring. Consiste en realizar cambios al sistema sin modificar la funcionalidad del mismo para poder hacer el sistema ms simple, para aumentar la eficiencia o para que el cdigo sea mucho ms entendible. Sea cual sea el objetivo del refactoring, no hay que olvidar que en XP el cdigo es la documentacin ms importante del proyecto y por ende debe estar bien desarrollado. Release Un release puede ser definido como un conjunto de funcionalidad que es integrada para realizar un programa ejecutable. La idea de cada release es poder tener un producto intermedio al final de cada iteracin en la cual el cliente pueda testear la funcionalidad pedida. Con esto los clientes pueden, adems, ver el avance del proyecto y poder realizar comentarios a los programadores y no esperar hasta el final del mismo cuando est todo integrado. Test de aceptacin Los test de aceptacin representan algn tipo de resultado por parte del sistema. Los clientes son los responsables de verificar la exactitud de estos test y de revisar los resultados para poder as priorizar los test que fracasaron. Tambin son utilizados como test regresivos antes de entrar a la fase de produccin. (Extreme Programming. Acceptance test) Una story no es aceptada hasta que haya pasado su test de aceptacin. Esto significa que en cada iteracin se deben realizar nuevos test de aceptacin o de lo contrario el equipo tendr una avance de cero. Estos test suelen ser automatizados para que puedan ser ejecutados frecuentemente. El resultado de cada test es publicado para el resto del equipo. El nombre de test de aceptacin refleja la verdadera intencin, la cual es garantizar a los clientes que los requerimientos han sido realizados y el sistema es aceptable. Test unitario Los testing unitarios son tan importantes como los test de aceptacin. Son realizados desde el punto de vista del programador y sirven, adems de testear el cdigo, para poder realizar el refactoring del mismo. Cada programador, antes de comenzar a programar, debe preparar los test unitarios. Esto hace que dichos test estn preparados para ser corridos durante la codificacin y adems, hace que al programador le surjan dudas y pueda evacuarlas con el cliente antes de empezar con la codificacin. Referencias Extreme Programming <http://www.extremeprogramming.org> Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 11 El ciclo de vida El ciclo de vida de XP consiste bsicamente de seis fases: Exploracin, Planificacin, Iterations to Release, Produccin, Mantenimiento y Muerte. 1- Exploracin En esta fase los clientes realizan las story cards que desean que estn para la primera entrega. Cada story describe una de las funcionalidades que el programa tendr. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, la tecnologa y las prcticas a ser utilizadas durante el proyecto. En algunos casos se utiliza un prototipo para testear la nueva tecnologa y explorar algunos aspectos de la arquitectura a ser implementada. La duracin de esta fase puede extenderse desde unas pocas semanas a varios meses dependiendo de la adaptacin del equipo de desarrollo. 2- Planificacin El objetivo de esta fase es fijar la prioridad de cada una de las stories y se establece cual va a ser el contenido de la primera entrega. Los programadores estiman cuanto esfuerzo requiere cada story y se establece el cronograma. La duracin del calendario para la entrega del primer release no suele superar los dos meses. Duracin de la fase de planificacin en s no toma ms de dos das. 3- Iteraciones por entregas Esta fase incluye varias iteraciones del sistema antes de la entrega del primer release. El calendario es dividido en un nmero iteraciones de tal manera de que cada iteracin tome de una a cuatro semanas de implementacin. En la primera iteracin se crea un sistema que abarca los aspectos ms importantes de la arquitectura global. Esto se logra seleccionando las stories que hagan referencia a la construccin de la estructura de todo el sistema. El cliente decide que stories van a ser implementadas para cada iteracin. Adems, se realizan los test funcionales, realizados por el cliente, al final de cada iteracin. Al final de la ltima iteracin el sistema est listo para ser puesto en produccin. 4- Produccin La fase de produccin requiere realizar muchos ms chequeos y testing antes que el sistema sea entregado al cliente. En esta fase aparecen nuevos cambios y se tiene que decidir si sern incorporados o no en dicha entrega. Durante esta fase suele suceder que las iteraciones se aceleren de tres a una semana. Las ideas pospuestas y las sugerencias son documentadas para luego ser implementadas ms adelante, por ejemplo, en la fase de mantenimiento. Luego que el primer release es creado, el proyecto debe mantener el sistema en produccin corriendo mientas se trabaja en las nuevas iteraciones. 5- Mantenimiento En esta fase por lo general se necesita un esfuerzo extra de los programadores para satisfacer los requerimientos del cliente. Por este motivo la velocidad de desarrollo suele disminuir una vez que el sistema es puesto en produccin. A raz de esto se requiere incorporar nuevos integrantes al equipo y cambiar la estructura del equipo. 6- Muerte Esta ltima fase se acerca una vez que el cliente no tiene ninguna story a ser implementada. Los requerimientos del sistema deben ser satisfechos en otros aspectos como ser la performance o la confiabilidad del mismo. Esta es la etapa en la cual no hay ms cambios en la arquitectura, el diseo o el cdigo y aqu es cuando se realiza la documentacin correspondiente. Esta fase aparece tambin, cuando el sistema no da los resultados deseados o se vuelve demasiado caro para seguir siendo desarrollado. Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 12 Figura 2 Ciclo de vida de XP Exploracin Durantes esta fase los programadores utilizan cada parte de la tecnologa a ser usada durante el proyecto. Se exploran todas las posibilidades que puede tener la arquitectura del sistema. Se utilizan una o dos semanas para construir prototipos que implementen la funcionalidad bsica pero de dos o tres formas distintas. (Agile softwar development methods. Reviews and analysis. Extreme Programming/Process. Pag - 19) Si una semana no alcanza para explorar una parte de la tecnologa esto puede clasificarse como un riesgo. Esto no significa que no se pueda utilizar pero s sera bueno explorarla con ms detalle y considerar alternativas. Los programadores suelen estimar la duracin de cada tarea realizada durante esta fase. Cuando finaliza una tarea se reporta en el calendario el tiempo requerido. Mientras los programadores trabajan con la tecnologa, los clientes escriben las stories. Al principio las stories no son las que se esperan. La clave es darle rpidamente al cliente una feedback de las primeras stories para que aprendan en seguida a como especificar lo que los programadores necesitan. Planificacin El propsito de esta fase es el de llegar a un acuerdo entre los clientes y los programadores en cuales sern las stories a ser implementadas durante cada iteracin. Si se hace una buena preparacin durante la fase de exploracin esta actividad no suele llevar ms de un da o dos. La entrega del primer release debe tomar entre dos a seis meses de duracin. Si se planifica realizarla en menos tiempo es probable que no se tengan los elementos necesarios para solucionar los problemas ms significativos. Pero si se tarda ms de este perodo se corre el riesgo que el cliente no quede satisfecho. Iteraciones por entregas Una vez elegido el orden en el cual se implementarn las stories se procede a definir cuantas iteraciones sern necesarias para el proyecto. Cada iteracin tiene una duracin de una a cuatro semanas, en las cuales se realizan los test funcionales para cada una de las stories a ser implementadas. (Agile softwar development methods. Reviews and analysis. Extreme Programming/Process. Pag - 19) Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 13 La primera iteracin suele servir para definir la arquitectura de todo el sistema. Es por este motivo que se seleccionan las stories que definen la arquitectura aunque solo formen una base del mismo. La seleccin de las stories para las siguientes iteraciones suele quedar al criterio del cliente. El cliente debe seleccionar las stories que tengan ms inters para l de las que falten ser implementadas. Adems de la implementacin, se debe llevar un control con respecto a las desviaciones del calendario. Cuando se detectan desviaciones es necesario tomar medidas. Quizs se deba agregar o remover stories o quizs deba encontrar una mejor manera para utilizar la tecnologa e incluso para utilizar XP. Al final de cada iteracin el cliente debe analizar que todas las stories estn implementadas. Debe tambin correr todos los test funcionales y que estos resulten ser exitosos. Produccin En esta fase es donde el producto se pone en produccin y se realizan todas las pruebas de preformase del sistema. Este es el momento en donde se afinan los detalles del sistema debido a que se tiene un gran conocimiento del diseo y adems, se dispone del hardware en donde se va a correr el sistema. Durante esta fase se debe ir ms despacio a medida que se desarrollando el software. Esto no significa que el desarrollo se detenga pero si es de considerar, que el riesgo se vuelve ms importante a medida que los cambios afecten al release. Mantenimiento En esta fase se debe agregar nueva funcionalidad, mantener el sistema corriendo e incorporar nuevos integrantes al equipo. Se hacen los refactoring que no se pudieron realizar anteriormente. Adems, se prueba la nueva tecnologa que se va a utilizar en el prximo release o migrar a nuevas versiones de la tecnologa que se est utilizando. Tambin se suele experimentar con nuevas ideas para la arquitectura actual y el cliente suele escribir nuevas stories que puedan mejorar el sistema. (Agile softwar development methods. Reviews and analysis. Extreme Programming/Process. Pag - 19) El trabajar sobre un sistema que est en produccin no es lo mismo que hacerlo sobre un sistema que an est siendo desarrollado. Hay que ser muy cuidadoso sobre los cambios a ser realizados. Otros de los puntos que se debe considerar en esta fase es la incorporacin de nuevos integrantes al equipo de desarrollo. Es bueno darle dos o tres iteraciones donde ellos hagan muchas preguntas, trabajen en parejas y lean mucho cdigo y casos de prueba. Cuando ellos se sientan listos, pueden ser puestos a trabajar en algunas tareas de programacin y as hasta que queden completamente integrados. Si el equipo va cambiando gradualmente durante un ao se puede reemplazar sin desestabilizar la forma de trabajo que se lleva. (Extreme Programming explined. Captulo 21. Lifecycle of an ideal XP Proyect. Pg. 131) Muerte Hay dos buenas razones por la cual el sistema entre en esta fase. La primera puede ser debido a que el cliente est muy satisfecho con el sistema y no tenga ninguna otra funcionalidad que agregar en el futuro. La otra razn suele ser que el sistema no termina de ser liberado. El cliente necesita ms funcionalidades y es imposible costearlas. Otro motivo puede ser que los defectos detectados alcancen un nivel intolerable. Referencias ABRAHAMSSON, Pekka; SALO, Outi; JUSSI. Agile softwar development methods. Reviews and analysis [online]. Disponible en Internet: <http://www.info.vtt.fi.pdf/> KENT, Beck. 2000. Extreme Programming explined. 1ra edicin Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 14 Ciclo de vida del programador Adems del ciclo de vida comn de XP podemos encontrar otro ciclo de vida dentro de este que indica como trabajan los programadores para poder codificar. Figura 3 Ciclo de vida del programador El tringulo que se encuentra en el medio de la figura 3 es la clave principal en la idea de XP. En ellas se muestra la forma de trabajo: Testing, codificacin y luego refactoring. Esto es lo opuesto a la programacin tradicional en donde primero se disea, luego se codifica y por ltimo se testea. (Extreme Programming. XP Programmer's Cube - A Day in the Life) Veamos en detalle cada una de las actividades: Eleccin de pares o Toda la produccin se realiza en pares. o El encargado de escribir piensa tcticamente, su pareja piensa estratgicamente. o Se rotan los roles peridicamente. Testing o Se escriben los testing unitarios. o Se verifica que los test fallen antes de codificar. o Se testea todo lo que posiblemente puede fallar. Codificacin o Hacer algo que funcione de la manera ms sencilla o Implementar lo suficiente para hacer que el test pase. o Seguir el estndar de codificacin. Refactoring o Quitar toda porcin de cdigo que no parezcan estar bien y luego verificar si el cdigo an pasa los test unitarios. o El cdigo debe ser claro, no tener partes duplicadas y tener la menor cantidad de clases y mtodos posibles. o Realizar cambios pequeos y luego realizar los test unitarios. TESTING Q & A CODIFICACIN REFACTORING INTEGRACIN ELECCIN DE PARES Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 15 Q & A o El cliente puede proveer rpidamente cualquier respuesta on-site. o Muchas preguntas requieren decisiones y el cliente debe estar preparado para poder hacerlas. o El cliente suele escribir una story o un test de aceptacin que captura sus preguntas. Integracin o Llevar el cdigo a la mquina donde se realiza la integracin, unir el sistema y correr todos los test. o Arreglar todos los errores para que pasen todos los test unitarios. o Si no es fcil la integracin es mejor tirar todo y comenzar nuevamente al da siguiente. Retornar al inicio. o Si resta tiempo, se puede elegir otra pareja o cambiar de roles y comenzar con otra actividad. Referencias Extreme Programming < http://www.xp123.com> Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 16 Roles y responsabilidades. Dentro de la mitologa de XP existen variados roles. A continuacin se detallan cuales son los roles ms importantes. Cliente Es quien establece que es lo que debe realizar el sistema, tomando la decisin de cuando se debe implementar determinada funcionalidad, as como tambin en el orden a ser implementadas. Adems, el cliente escribe las story cards y los test funcionales y decide cuando cada requerimiento est satisfecho. Los clientes tambin priorizan cada uno de los requerimientos. (Prcticas Extremas en ORTsf. Roles. Pg. 57) Coach Es el encargado de asegurar el cumplimiento de todas las prcticas, transmitiendo sus conocimientos y experiencia al resto del equipo. Consultant Es una persona externa al equipo que posee el conocimiento tcnico necesario para poder ayudar al equipo con determinados problemas. Manager Toma las decisiones ms importantes del proyecto. Es el encargado de comunicarse con el equipo para determinar cual es la situacin actual y distinguir cualquier dificultad o deficiencia en el proceso y poder solucionarlo. Programador Es el responsable de escribir los testing del sistema y mantener el cdigo lo ms simple y definitivo posible. El primer aspecto a tener en cuenta para que XP sea exitoso es la coordinacin entre los programadores y el resto del equipo. Tester Los tester ayudan a los clientes a escribir los test funcionales del sistema. Adems, corren dichos testing regularmente, envan los informes con los resultados y realizan el mantenimiento a las herramientas de testing. Tracker Tiene como principal responsabilidad realizar las mediciones y la recoleccin de mtricas. Mide el progreso del proyecto y lo compara con lo estimado. Tambin observa el desempeo del equipo, haciendo nfasis en el cumplimiento de los plazos y aconsejando al equipo si deben realizar cambios para lograr los objetivos. Adems de todo esto, mantiene los registros de los casos de prueba ejecutados, los defectos encontrados y sus responsables. (Agile softwar development methods. Reviews and analysis. Extreme Programming/Roles and Responsabilities. Pg - 21) Referencias ABRAHAMSSON, Pekka; SALO, Outi; JUSSI. Agile softwar development methods. Reviews and analysis[online]. Disponible en Internet: <http://www.info.vtt.fi.pdf/> ARRIETA, Sebastian. Prcticas Extremas en ORTsf. 2002. Universidad ORT Uruguay Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 17 Prcticas Uno de los factores que hacen que XP sea tan utilizado y efectivo son las prcticas que se realizan durante el proyecto. XP es un conjunto de ideas y prcticas de metodologas ya existente y por eso deben ser muy tenidas en cuenta a la hora de su implementacin. A continuacin se presentan las prcticas ms utilizadas. 40 Horas semanales Cliente on-site Diseo simple El juego de la planificacin Estndares de codificacin Integracin continua Metfora Pequeas entregas Programacin por pares Propiedad colectiva Testing Refactoring 40 horas semanales Como mximo se puede trabajar un promedio de 40 horas semanales. No se permite trabajar tiempo extra durante dos 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 y realizar otras actividades. De esta forma la productividad del equipo se mantiene alta y se reducen los problemas por falta de descanso. Como en los proyectos suelen haber retrasos se est permitido poder realizar, en una semana, una mayor cantidad de horas que las establecidas. Pero solamente durante una semana, ya que si sigue el atraso, es un indicador de que algo malo sucede con el proyecto y el tener mayor carga horaria a la larga no es la solucin. El realizar horas extras ms de una semana seguida hace que se comentan ms errores tanto en el cdigo como en el diseo. Esto hace que la calidad del producto realizado sea menor y a largo plazo ese tiempo supuestamente recuperado se pierde debido a estos problemas. (Agile softwar development methods. Reviews and analysis. Extreme Programming/Practices. Pg. - 22) Cliente On-Site El 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. Adems de esto, 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 comunicacin fluida con el cliente sin necesidad de gastar tiempo en documentacin formal. Esta comunicacin constante reduce el tiempo de desarrollo al reducir las esperas por respuesta y los malentendidos entre ambas partes. (Agile softwar development methods. Reviews and analysis. Extreme Programming/Practices. Pg. - 22) Diseo simple Se hace mucho nfasis en el diseo de una solucin lo ms simple posible que pueda ser implementada en el momento. El cdigo complejo o innecesario es eliminado inmediatamente. En XP el diseo se hace en forma progresiva lo cual evita que se cree un diseo altamente complejo por querer abarcar todos los aspectos posibles de una sola vez. Un buen diseo debe cumplir los siguientes puntos: Corre todo los casos de prueba Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 18 Enuncia todas las ideas que se quieren exhibir. No tiene cdigo duplicado Posee el menor nmero de clases y mtodos posibles. Para poder obtener un diseo simple se descartan todos aquellos elementos innecesarios mientras que los tres primeros puntos se cumplan. El juego de la planificacin Para poder realizar una buena planificacin se necesita una buena interaccin entre los clientes y los programadores. Los programadores estiman el esfuerzo necesario para cada una de las stories y los clientes deciden sobre el alcance y el momento en el que debe realizar cada entrega. En el plan de entregas, el cliente elige aquellas stories que crea son ms importantes para implementar. Cada entrega debe tener una duracin mxima de dos meses y se estima la duracin suponiendo que no hay retrasos o imprevistos. Cada entrega consta de varias iteraciones, cuya duracin no debe superar las dos semanas. En el plan de iteraciones, el cliente selecciona las stories a ser implementadas, y se detallan las pruebas de aceptacin para cada story. Los programadores dividen cada story en tareas, que luego son aceptadas por cada programador, estimadas, implementadas y por ltimo integradas al sistema. (Prcticas Extremas en ORTsf. Roles. Pg. 40) Las tareas tienen una duracin promedio de uno a dos das. En ellas los programadores establecen todos los casos de prueba posibles antes de comenzar con la implementacin. Luego se pasa a la implementacin en el cual el cliente est disponible para poder evacuar cualquier duda que surja. Estndares de codificacin El cdigo es la mejor documentacin que tiene el sistema. Es por este motivo que se deben establecer reglas para los programadores y estas deben ser seguidas estrictamente. En un equipo de desarrollo los programadores acuerdan un estndar para el cdigo, dejando de lado estilos de programacin particulares. Todos deben conocer y seguir el estndar de manera tal que al final el sistema parezca ser programado por una sola persona. Algunos de los puntos a tener en cuenta son los siguientes: Mantener mtodos pequeos (el cdigo puede ser visto en una sola pantalla) Ser coherentes en el uso de maysculas. Solo comentar el cdigo cuando sea realmente es necesario. Usar formatos de nombres consistentes y similares. Utilizar siempre el mismo formato de sangra. Integracin continua Una nueva pieza de cdigo debe ser integrada al resto del sistema tan pronto como sea posible. De ese modo, el sistema es integrado y reconstruido varias veces por da. Para poder realizar esta integracin se selecciona una computadora determinada. Luego, al finalizar cada pareja de programadores se dirige a dicha mquina para integrar sus cambios al sistema existente. Posteriormente se ejecutan todos los casos de prueba establecidos, hasta que cada uno de ellos sea aprobado. (Prcticas Extremas en ORTsf. Roles. Pg. 40) Lo bueno de este sistema es que no ocurren problemas de integracin ya que los errores se encuentran y se solucionan al momento de ser integrados por los mismos programadores que tienen en la cabeza en cdigo implementado. Esto evita que se pasen meses para la integracin y tener que solucionar estos problemas ms adelante. Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 19 Metfora El sistema es definido en base a una metfora o conjuntos de metforas entre el cliente y los programadores. Para XP la metfora equivale a la arquitectura en otras metodologas, pero es ms formal y sencilla. Es utilizada por los programadores para describir a grandes rasgos la estructura del sistema de manera tal que pueda ser comprendida por todos los integrantes. Una vez que la metfora es creada, se pasa al establecimiento de clases, mtodos y relaciones primordiales del sistema. Adems, de servir como fuente de comunicacin entre los clientes y los programadores sirve para poder mantener el diseo del sistema lo ms simple posible. Tambin se utiliza para comunicar las bases del sistema a los nuevos integrantes. Pequeos release Los release deben ser los ms pequeos posibles con una duracin no mayor a dos meses. Esto permite que los clientes puedan ver el avance del proyecto y los programadores puedan retroalimentarse de las opiniones de los clientes. Por lo general estos release comienzan implementando las caractersticas primordiales del sistema. Luego a medida que 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 su producto y adems hace que los programadores mantengan su nivel de motivacin ya que lo ms agradable de programar es poder entregar un producto terminado. (Prcticas Extremas en ORTsf. Roles. Pg. 40) Programacin por pares Uno de los pilares de XP es la programacin en pareja o programacin por pares. Bsicamente lo que se quiere con esto es poder eliminar posibles errores debido a distracciones o errores conceptuales. Al tener dos personas concentradas sobre el mismo cdigo se evitan estos errores y se ahorra tiempo en futuras correcciones. Una de las dos personas es el conductor, que es el encargado de escribir el cdigo. La otra persona, el copiloto, participa verbalmente. El conductor tiene una visin de cmo implementar el cdigo de la mejor manera mientras que el copiloto tiene una visin global del sistema y se encarga de sugerir posibles alternativas y nuevos casos de prueba. Es bueno que los dos integrantes se turnen en la conduccin. (Prcticas Extremas en ORTsf. Roles. Pg. 40) Propiedad colectiva Cualquier persona est en condiciones de cambiar cualquier parte del cdigo en cualquier momento. En XP nadie tiene propiedad sobre ningn mdulo o clase. Cada uno de los integrantes puede realizar cambios o mejoras a cualquier parte del cdigo en cualquier momento. Esto hace que el sistema cuente con una menor cantidad de defectos y por ende una mejor calidad. Testing Otro de los puntos importantes de XP son los testing, los cuales se realizan continuamente. Existen dos tipos de testing; testing unitario y testing funcionales o de aceptacin. Los testing unitarios son implementados por los programadores antes de comenzar con la implementacin. Se establecen todos los casos en el que el cdigo puede fallar. Una vez que se termina con la implementacin se corren dichas pruebas y se verifica que no haya ningn test que falle. Hasta que pasen todos los test el programador debe seguir mejorando el cdigo. Estas pruebas son automatizadas e implementadas por el propio programador, lo cual hace que la prueba pueda ser ms rpida y efectiva. Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 20 Los testing funcionales o de aceptacin son definidos y escritos por el cliente al inicio de cada iteracin para cada una de las stories establecidas. El objetivo es demostrar al cliente que el requerimiento implementado realmente funciona como el cliente lo desea. Refactoring El refactoring del cdigo hace que este sea fcil 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. Como resultados, la cantidad de errores disminuye, lo cual mejora la calidad del software. El diseo se mantiene simple y permite a los programadores desarrollar ms rpido. Referencias ABRAHAMSSON, Pekka; SALO, Outi; JUSSI. Agile softwar development methods. Reviews and analysis [online]. Disponible en Internet: <http://www.info.vtt.fi.pdf/> ARRIETA, Sebastian. Prcticas Extremas en ORTsf. 2002. Universidad ORT Uruguay Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 21 Herramientas para el testeo automtico Debido a que el testing es una de las actividades ms importantes en la programacin de XP es necesario poseer una buena herramienta de testeo automtico segn el tipo de lenguaje en el cual se desarrolle. Una de las herramientas ms conocida para realizar el testing automtico es JUnit. Esta herramienta sirve para los programadores que desarrollan en JAVA pero en el mercado hay otros tipo de JUnit para los distintos lenguajes. El objetivo de esta seccin no es mostrar el funcionamiento de JUnit, sino que se desea ejemplificar como se puede implementar el testeo automtico. JUnit Caso simple Para poder realizar un test simple en algn mtodo simplemente se debe hacer lo siguiente: Crear una instancia de TestCase Crear un constructor el cual acepte un String como parmetro y pasar este como superclase. Reescribir el mtodo runTest() Cuando se quiere chequear un valor, llamar al mtodo assertTrue() y pasarle un boolean que sea verdadero cuando el test sea correcto. Por ejemplo, para poder testear el funcionamiento del mtodo concatenar de la clase Cadena se puede implementar el siguiente mtodo. Public void testConcatenar() { Cadena cadena1 = new Cadena (Hola ); Cadena cadena2 = new Cadena (Juan); Cadena resultado = cadena1.concatenar(cadena2); Cadena valorEsperado = new Cadena(Hola Juan); asserTrue(valorEsperado.equals(resultado)); } Suite A medida que se avanza con la implementacin es lgico que aparezca la necesidad de realizar varios test y es bueno poder correrlos todos a la vez si necesidad de correrlos uno por uno. Para ello JUnit provee un objeto llamado TestSuite el cual permite correr cualquier cantidad de test al mismo tiempo. Por ejemplo, para correr un test simple, se ejecuta: TestResult resultado = (new CadenaTest (testConcatenar())).run(); Pero para poder realizar el testeo de dos casos al mismo tiempo se debe realizar lo siguiente: TestSuite suite = new TestSuite(); suite.addTest(new CadenaTest(testEquals); suite.addTest(new CadenaTest(testConcatenar); TestResult resultado = suite.run(); TestRunner Una vez que los test suite estn implementados es hora de recolectar la informacin de cada uno de dichos test. Para esto es necesario implementar un mtodo esttico llamado suite que retorna un test suite. (JUnit. JUnit CookBook ) Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 22 Por ejemplo, para el caso de la Cadena es necesario implementar lo siguiente: Public static Test suite() { TestSuite suite = new TestSuite(); suite.addTest(new CadenaTest(testEquals); suite.addTest(new CadenaTest(testConcatenar); TestResult resultado = suite.run(); } JUnit provee distintos tipos de testing (TestRunner): Textual TestRunner: Este es mucho ms rpido de ejecutar y puede ser utilizado cuando no es necesario tener informacin grfica de los resultados del testing. Graphical TestRunner: Este muestra un simple dilogo en el cual se elige el test a ejecutar y provee una grfica de progresin de los test realizados. El Graphical TesRunner muestra una ventana con la siguiente informacin: Un campo donde se indica el nombre de la clase con el mtodo suite. Un botn Run que comienza el testeo. Una barra de progreso la cual se torna de roja a verde en el caso que un test falle. 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 ms fcil de implementar y se obtienen los beneficios que hemos explicado anteriormente, como por ejemplo, el refactoring. Referencias JUnit <http://www.junit.com> Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 23 Conclusiones Como hemos visto en este documento hay aspectos en XP que lo hacen diferente a otras metodologas. Comenzamos con sus valores (Comunicacin, Simplicidad, Feedback y Coraje). En XP la comunicacin es vital tanto entre el grupo de desarrollo como con el cliente, el cual debe formar parte del equipo para mantener una comunicacin fluida y poder de esta forma, evacuar cualquier tipo de duda que surja con los requerimientos. La simplicidad apuesta a realizar algo simple hoy y destinar un poco ms de esfuerzo para realizar un cambio en el futuro, a realizar algo ms complicado hoy y no utilizarlo nunca. El feedback constante entre el equipo y el cliente hace que se pueda conocer el estado actual del proyecto y poder as tomar decisiones mucho ms acertadas. Por ltimo, la comunicacin, la simplicidad y el feedback forman el coraje, el cual se convierte en el objetivo de XP. El coraje tambin es poder realizar cambios cuando algo no funciona del todo bien, disear e implementar solo lo necesario 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 estndar para obtener buenos resultados. Sin embargo, los valores son muy vagos a la hora de ayudarnos a decidir que prcticas utilizar. Para ello se necesita destilar estos valores en principios que puedan ser utilizados, como ser, una rpida retroalimentacin, asumir la simplicidad, realizar cambios incrementales, aceptar el cambio y realizar un trabajo de calidad. Por ltimo debemos mencionar las prcticas que se utilizan, las cuales hacen que XP sea tan utilizado y efectivo. XP es un conjunto de ideas y prcticas de metodologas ya existente y por eso deben ser muy tenidas en cuenta a la hora de su implementacin. De la gran cantidad de prcticas destacamos: 40 Horas semanales Cliente on-site Diseo simple El juego de la planificacin Estndares de codificacin Integracin continua Metfora Pequeas entregas Programacin por pares Propiedad colectiva Testing Refactoring Todos estos puntos antes mencionados hacen permiten que se realice el software que el cliente solicita y necesita, en el momento que lo precisa, alentando a los programadores a responder a los requerimientos cambiantes que plantea dicho cliente en cualquier momento. No debemos olvidar que la base de XP es que el proceso se mantenga gil en todo momento, lo cual significa que se pueda adaptar al cambio sin mayores complicaciones. Por este motivo los conceptos antes mencionados no deben ser impuestos bajo ningn tipo de concepto sino que al contrario deben servir como una gua segn el tipo de proyecto que se quiera realizar. Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 24 Palabras Claves 40 Horas semanales Aceptar el cambio Aceptar la responsabilidad Adaptacin local Asumir la simplicidad Cambios incrementales Cliente Cliente on-site Coach Comunicacin Comunicacin abierta y honesta Consultant Coraje Diseo simple El juego de la planificacin Ensear conocimientos Entrega Estndares de codificacin Fase de exploracin Fase de iteraciones por entregas Fase de mantenimiento Fase de muerte Fase de planificacin Fase de produccin Feedback Integracin continua Jugar para ganar Manager Mediciones honestas Metfora Pequea inversin inicial Pequeas entregas Programacin por pares Programacin por pares Programador Propiedad colectiva Rpida retroalimentacin Refactoring Simplicidad Sotries Story cards Test funcional Tester Testing unitarios Trabajar con los instintos de las personas Trabajo de calidad Tracker Viajar liviano Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 25 Glosario Refactoring: Un cambio al sistema que mantiene el mismo comportamiento del sistema, pero aumenta algunos atributos de calidad, como ser: simplicidad, flexibilidad, mantenibilidad, etc. Release: Conjunto de funcionalidad que es integrada para realizar un programa ejecutable. Story cards: Ficha en la cual el cliente especifica una funcionalidad en particular. Story: Funcionalidad que el cliente quiere que haga el sistema. Test de aceptacin: Test escrito desde la perspectiva del cliente. Test unitario: Test escrito desde la perspectiva del programador. Universidad ORT Uruguay Ctedra de Ingeniera de Software Metodologa XP Octubre del 2003 Luis Calabria Pablo Priz Pgina 26 Bibliografa Artculos ABRAHAMSSON, Pekka; SALO, Outi; JUSSI. Agile softwar development methods. Reviews and analysis [online]. Disponible en Internet: <http://www.info.vtt.fi.pdf/> ARRIETA, Sebastian. Prcticas Extremas en ORTsf. 2002. Universidad ORT Uruguay Libros KENT, Beck. 2000. Extreme Programming explined. 1ra edicin Sitios Web Extreme Programming <http://www.extremeprogramming.org> Extreme Programming < http://www.xp123.com> JUnit <http://www.junit.com>