Universidad ORT Uruguay

Universidad ORT UruguayFacultad de Ingeniería

–––MMMeeetttooodddooolllooogggíííaaa XXXPPP–––

Cátedra de Ingeniería de Software.Docente Responsable: Gastón Mousques.

Autores:Luis Calabria – 122919Pablo Píriz – 123348

2003

Universidad ORT Uruguay Cátedra de Ingeniería de SoftwareMetodología XP Octubre del 2003

Luis Calabria – Pablo Píriz Página 1

Índice GeneralÍndice General_________________________________________________________________________________ 1Resumen _____________________________________________________________________________________ 3La filosofía de XP ______________________________________________________________________________ 4Valores en XP _________________________________________________________________________________ 5Comunicación_______________________________________________________________________________________5Simplicidad_________________________________________________________________________________________5Feedback___________________________________________________________________________________________5Coraje _____________________________________________________________________________________________6

Principios de XP _______________________________________________________________________________ 7Rápida retroalimentación _____________________________________________________________________________7Asumir la simplicidad ________________________________________________________________________________7Cambios incrementales _______________________________________________________________________________7Aceptar el cambio ___________________________________________________________________________________7Trabajo de calidad___________________________________________________________________________________7Otros principios _____________________________________________________________________________________7

Principales conceptos ___________________________________________________________________________ 9Story Cards_________________________________________________________________________________________9Iteración ___________________________________________________________________________________________9Refactoring________________________________________________________________________________________10Release ___________________________________________________________________________________________10Test de aceptación __________________________________________________________________________________10Test unitario _______________________________________________________________________________________10

El ciclo de vida _______________________________________________________________________________ 11Exploración _______________________________________________________________________________________12Planificación_______________________________________________________________________________________12Iteraciones por entregas _____________________________________________________________________________12Producción ________________________________________________________________________________________13Mantenimiento _____________________________________________________________________________________13Muerte____________________________________________________________________________________________13

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

Prácticas ____________________________________________________________________________________ 1740 horas semanales__________________________________________________________________________________17



Cliente On-Site_____________________________________________________________________________________17Diseño simple ______________________________________________________________________________________17El juego de la planificación ___________________________________________________________________________18Estándares de codificación ___________________________________________________________________________18Integración continua ________________________________________________________________________________18Metáfora __________________________________________________________________________________________19Pequeños release ___________________________________________________________________________________19Programación por pares _____________________________________________________________________________19Propiedad colectiva _________________________________________________________________________________19Testing____________________________________________________________________________________________19Refactoring________________________________________________________________________________________20

Herramientas para el testeo automático ___________________________________________________________ 21JUnit _____________________________________________________________________________________________21

Conclusiones _________________________________________________________________________________ 23Palabras Claves_______________________________________________________________________________ 24Glosario _____________________________________________________________________________________ 25Bibliografía __________________________________________________________________________________ 26



ResumenEl objetivo principal de este documento, es resumir los principales aspectos de la metodología de ExtremeProgramming.

Entre otros puntos se mencionarán cuales son los valores y principios que se siguen en XP, así como también, losprincipales conceptos que se deben tener en cuenta a la hora de llevarla a la práctica.

Luego se hará un análisis del ciclo de vida que se utiliza, en el cual se verá cuales son las etapas y las actividadesmás importantes.

También se menciona cuales son los principales roles dentro de esta metodología, así como también, susresponsabilidades, y además, analizaremos las prácticas más importantes que se deben seguir.

Por último haremos referencia a las herramientas de testeo automático, haciendo hincapié en la herramienta JUnit.



La filosofía de XPXP es una metodología ágil para pequeños y medianos equipos, desarrollando software cuando los requerimientosson ambiguos o rápidamente 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 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 está diseñado para adaptarse en formainmediata a los cambios, con bajos costos asociados, en cualquier etapa del ciclo de vida. En pocas palabras, XP“abraza” el cambio.



Valores en XPPara poder implementar las prácticas que presenta XP hay que conocer cuales son los valores principales que hacena esta mitología. Estos valores son:

ü Comunicaciónü Simplicidadü Feedbackü Coraje

ComunicaciónUno de los valores más importantes en XP es la comunicación. La mala comunicación 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 atención.

En cualquiera de los casos la comunicación es un factor importante en cualquier tipo de proyecto. En XP se trata demantener una buena comunicación mediante un conjunto de prácticas que no se pueden realizar sin tener una buenacomunicación en el equipo. Muchas de estas prácticas hacen corto circuito si no hay buena comunicación como enel caso de los testing unitarios, programación por pares, el uso de estándares o la estimación de las tareas. Trabajaren espacios abiertos hace que la comunicación mejore al contrario de otras metodologías en las cuales losprogramadores trabajan en espacios reducidos.

La comunicación 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. Además, seplanifica con el cliente y este puede estar al tanto del avance del proyecto. (Extreme Programming explined.Capítulo 7. Four Values. Pág. 15)XP ha sido diseñada para minimizar el grado de documentación como forma de comunicación, haciendo énfasis enla interacción personal. De esta manera se puede avanzar rápidamente y de forma efectiva, realizando solo ladocumentación necesaria.

SimplicidadLa simplicidad es el segundo valor que se utiliza en esta metodología. XP apuesta a realizar algo simple hoy ydestinar un poco más de esfuerzo para realizar un cambio en el futuro, a realizar algo más complicado hoy y noutilizarlo nunca.

XP propone una regla muy simple: “hacer algo que funcione de la manera más sencilla”. En el caso de tener queañadir nueva funcionalidad al sistema se deben examinar todas las posibles alternativas y seleccionar la mássencilla. En otras ocasiones se hace uso del refactoring1 que permite mantener el código en funcionamiento peromucho más simple y organizado. (Prácticas Extremas en ORTsf. Valores. Pag - 27)

Otra regla muy importante es: “realizar solo lo necesario”. 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 más segura y rápida en el proyecto.

FeedbackBrindar un feedback correcto y preciso hace que se pueda mantener una buena comunicación 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.



Comunicación

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 estimación 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 través de pequeñas entregas del sistema. De esta manera, el cliente está altanto del avance del proyecto. Además, el sistema es puesto en producción 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 interacción entre ellos. Como se ve en lasiguiente figura la comunicación, la simplicidad y el feedback forman el coraje, el cual se convierte en el objetivo deXP. Uno de los lemas de XP menciona: “Si no trabajas al tope de tu capacidad, alguien más lo está haciendo y si nollegas a tiempo se comerá tu almuerzo”. (Prácticas Extremas en ORTsf. Valores. Pag - 27)

Esto hace, a que por ejemplo, se tenga el coraje de modificar el código en cualquier momento por cualquiermiembro del equipo sabiendo que no se afectará el correcto funcionamiento del sistema.

Figura 1 – valores de XPEl coraje también es poder realizar cambios cuando algo no funciona del todo bien, diseñar 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 esténpresentes.

ReferenciasKENT, Beck. 2000. Extreme Programming explined. 1ra edición

ARRIETA, Sebastian. Prácticas 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 – comunicación, simplicidad, feedback y coraje – nos brindan unestándar para obtener buenos resultados. Sin embargo, los valores son muy vagos a la hora de ayudarnos a decidirque prácticas utilizar. Para ello se necesita destilar estos valores en principios que puedan ser utilizados.

A continuación se detallan los principios más importantes de XP.

ü Rápida retroalimentaciónü Asumir la simplicidadü Cambios incrementalesü Aceptar el cambioü Trabajo de calidad

Rápida retroalimentaciónEn la práctica el tiempo transcurrido entre una acción y su feedback es crítico. Tener una rápida retroalimentaciónnos permite interpretarla, aprender de ella y poner en práctica lo asimilado lo antes posible.

Asumir la simplicidadEste es uno de los principios más difíciles de llevar a la práctica. Casi siempre se planifica para el futuro y se diseñapara 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 solución. Cada problema debe ser resuelto conuna serie de cambios pequeños para poder atacar dicho problema mucho más 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 más precisos.

Trabajo de calidadUno de los objetivos más 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 principiosAdemás de los principios antes mencionados surgen algunos otros de menor trascendencia que pueden ayudar atomar buenas decisiones en situaciones específicas.

ü Aceptar la responsabilidadü Adaptación localü Comunicación abierta y honestaü Enseñar conocimientosü Experimentos concretosü Jugar para ganarü Mediciones honestasü Pequeña inversión inicialü Trabajar con los instintos de las personasü 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 más adelante y pierda su motivación. (ExtremeProgramming explined. Capítulo 8. Basic Principies. Pág. 37)

Adaptación local: Para que XP funcione de la mejor manera posible es necesario que se adapte a las condicionesparticulares de cada proyecto.

Comunicación abierta y honesta: La comunicación 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 losdemás, así como también, comunicar los problemas sin miedo de anunciar malas noticias. (Extreme Programmingexplined. Capítulo 8. Basic Principies. Pág. 37)

Enseñar conocimientos: XP se concentra en enseñar distintas estrategias para saber como adoptar esta metodologíasin tratar de imponer ninguna de estas.

Experimentos concretos: Toda decisión que se tome a lo largo del proyecto debe ser analizada y probada para evitarasí cualquier tipo de errores.

Jugar para ganar: Todos los integrantes deben trabajar en equipo de manera agresiva y con mucho coraje paralograr el objetivo común que es el éxito de todo el proyecto.

Mediciones honestas: Toda estimación o métrica realizada debe ser lo más lógica posible ya que no tiene sentido daralgo tan exacto que quizás nunca se cumpla.

Pequeña inversión inicial: Al igual que la realización de un sistema en pequeñas entregas, es bueno realizarinversiones 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 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. Capítulo 8.Basic Principies. Pág. 37)

Viajar liviano: Para poder adaptarse rápidamente a los cambios constantes es bueno llevar solo lo indispensable.

ReferenciasKENT, Beck. 2000. Extreme Programming explined. 1ra edición




Principales conceptosAntes de comenzar a profundizar sobre la forma de trabajo de XP es bueno tener en claro algunos conceptos que sonbásicos en esta metodología.

A continuación se detallan los más importantes.

ü Story cardsü Iteraciónü Refactoringü Releaseü Test de aceptaciónü Test unitario

Story CardsLas story cards sirven para registrar los requerimientos de los clientes y son utilizadas para poder realizar laestimación de cada una de las iteraciones durante la fase de planificación.

Las story cards son escritas por los clientes en base a lo que se estima es necesario para el sistema. Están escritas enun formato de oraciones en la terminología del cliente, sin necesidad de sintaxis técnicas.

También son utilizadas para poder crear los test de aceptación. Por lo general se necesitan uno o más test deaceptación 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 especificación de requerimientostradicional. La mayor diferencia es su nivel de detalle. Las story cards solo proveen suficiente detalle para poderrealizar la estimación de cuando tardará en ser implementada dicha funcionalidad. Cuando el tiempo es calculado elprogramador se encarga de solicitarle al cliente una descripción más 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 tecnología 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. Más 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 número ideal para podercrear un plan de entregas.

IteraciónConsta de un período 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 iteración puede terminar de maneraexitosa.

Otro punto que no debe ser pasado por alto es el tema de la duración de cada iteración. 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 estánhaciendo bien las cosas cada cierto tiempo, hace que la persona se mantenga motivada. Además, el poder tenerretroalimentación constante con el cliente permite tener un mejor nivel en el trabajo.

También debemos considerar que las iteraciones cortas permiten hacer un diagnóstico prematuro de la situación 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 más simple, para aumentar la eficiencia o para que el códigosea mucho más entendible. Sea cual sea el objetivo del refactoring, no hay que olvidar que en XP el código es ladocumentación más 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 iteración en la cual elcliente pueda testear la funcionalidad pedida. Con esto los clientes pueden, además, ver el avance del proyecto ypoder realizar comentarios a los programadores y no esperar hasta el final del mismo cuando esté todo integrado.

Test de aceptaciónLos test de aceptación representan algún 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 así priorizar los test que fracasaron. Tambiénson utilizados como test regresivos antes de entrar a la fase de producción. (Extreme Programming. Acceptance test)

Una story no es aceptada hasta que haya pasado su test de aceptación. Esto significa que en cada iteración se debenrealizar nuevos test de aceptación 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 espublicado para el resto del equipo.

El nombre de test de aceptación refleja la verdadera intención, 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 aceptación. Son realizados desde el punto de vista delprogramador y sirven, además de testear el código, para poder realizar el refactoring del mismo.

Cada programador, antes de comenzar a programar, debe preparar los test unitarios. Esto hace que dichos test esténpreparados para ser corridos durante la codificación y además, hace que al programador le surjan dudas y puedaevacuarlas con el cliente antes de empezar con la codificación.

ReferenciasExtreme Programming <http://www.extremeprogramming.org>



El ciclo de vidaEl ciclo de vida de XP consiste básicamente de seis fases: Exploración, Planificación, Iterations to Release,Producción, Mantenimiento y Muerte.

1- ExploraciónEn esta fase los clientes realizan las story cards que desean que estén para la primera entrega. Cada story describeuna de las funcionalidades que el programa tendrá. Al mismo tiempo el equipo de desarrollo se familiariza con lasherramientas, la tecnología y las prácticas a ser utilizadas durante el proyecto. En algunos casos se utiliza unprototipo para testear la nueva tecnología y explorar algunos aspectos de la arquitectura a ser implementada. Laduración de esta fase puede extenderse desde unas pocas semanas a varios meses dependiendo de la adaptación delequipo de desarrollo.

2- PlanificaciónEl 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. Laduración del calendario para la entrega del primer release no suele superar los dos meses. Duración de la fase deplanificación en sí no toma más de dos días.

3- Iteraciones por entregasEsta fase incluye varias iteraciones del sistema antes de la entrega del primer release. El calendario es dividido enun número iteraciones de tal manera de que cada iteración tome de una a cuatro semanas de implementación. En laprimera iteración se crea un sistema que abarca los aspectos más importantes de la arquitectura global. Esto se lograseleccionando las stories que hagan referencia a la construcción de la estructura de todo el sistema.

El cliente decide que stories van a ser implementadas para cada iteración. Además, se realizan los test funcionales,realizados por el cliente, al final de cada iteración. Al final de la última iteración el sistema está listo para ser puestoen producción.

4- ProducciónLa fase de producción requiere realizar muchos más chequeos y testing antes que el sistema sea entregado al cliente.En esta fase aparecen nuevos cambios y se tiene que decidir si serán 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 más adelante, por ejemplo, en la fase de mantenimiento.

Luego que el primer release es creado, el proyecto debe mantener el sistema en producción 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 producción. Araíz de esto se requiere incorporar nuevos integrantes al equipo y cambiar la estructura del equipo.

6- MuerteEsta última 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 más cambios en la arquitectura, el diseño o el código y aquí es cuando se realiza ladocumentación correspondiente. Esta fase aparece también, cuando el sistema no da los resultados deseados o sevuelve demasiado caro para seguir siendo desarrollado.



Figura 2 – Ciclo de vida de XP

ExploraciónDurantes esta fase los programadores utilizan cada parte de la tecnología 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 básica pero de dos o tres formas distintas. (Agile softwardevelopment methods. Reviews and analysis. Extreme Programming/Process. Pag - 19)

Si una semana no alcanza para explorar una parte de la tecnología esto puede clasificarse como un riesgo. Esto nosignifica que no se pueda utilizar pero sí sería bueno explorarla con más detalle y considerar alternativas.

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

Mientras los programadores trabajan con la tecnología, los clientes escriben las stories. Al principio las stories noson las que se esperan. La clave es darle rápidamente al cliente una feedback de las primeras stories para queaprendan en seguida a como especificar lo que los programadores necesitan.

PlanificaciónEl propósito de esta fase es el de llegar a un acuerdo entre los clientes y los programadores en cuales serán lasstories a ser implementadas durante cada iteración. Si se hace una buena preparación durante la fase de exploraciónesta actividad no suele llevar más de un día o dos.

La entrega del primer release debe tomar entre dos a seis meses de duración. Si se planifica realizarla en menostiempo es probable que no se tengan los elementos necesarios para solucionar los problemas más significativos. Perosi se tarda más de este período se corre el riesgo que el cliente no quede satisfecho.

Iteraciones por entregasUna vez elegido el orden en el cual se implementarán las stories se procede a definir cuantas iteraciones seránnecesarias para el proyecto. Cada iteración tiene una duración 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 Programming/Process. Pag - 19)



La primera iteración 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 selección de las stories para las siguientes iteraciones suele quedar al criterio del cliente. El cliente debeseleccionar las stories que tengan más interés para él de las que falten ser implementadas.

Además de la implementación, se debe llevar un control con respecto a las desviaciones del calendario. Cuando sedetectan desviaciones es necesario tomar medidas. Quizás se deba agregar o remover stories o quizás deba encontraruna mejor manera para utilizar la tecnología e incluso para utilizar XP.

Al final de cada iteración el cliente debe analizar que todas las stories estén implementadas. Debe también corrertodos los test funcionales y que estos resulten ser exitosos.

ProducciónEn esta fase es donde el producto se pone en producción 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 deldiseño y además, se dispone del hardware en donde se va a correr el sistema.

Durante esta fase se debe ir más 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 más 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. Además, se prueba la nueva tecnología que se vaa utilizar en el próximo release o migrar a nuevas versiones de la tecnología que se está utilizando. También 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 Programming/Process. Pag- 19)

El trabajar sobre un sistema que está en producción no es lo mismo que hacerlo sobre un sistema que aún está 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 incorporación de nuevos integrantes al equipo dedesarrollo. Es bueno darle dos o tres iteraciones donde ellos hagan muchas preguntas, trabajen en parejas y leanmucho código y casos de prueba. Cuando ellos se sientan listos, pueden ser puestos a trabajar en algunas tareas deprogramación y así hasta que queden completamente integrados. Si el equipo va cambiando gradualmente duranteun año se puede reemplazar sin desestabilizar la forma de trabajo que se lleva. (Extreme Programming explined.Capítulo 21. Lifecycle of an ideal XP Proyect. Pág. 131)

MuerteHay 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 razón suele serque el sistema no termina de ser liberado. El cliente necesita más 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: <http://www.info.vtt.fi.pdf/>

KENT, Beck. 2000. Extreme Programming explined. 1ra edición



Ciclo de vida del programadorAdemás del ciclo de vida común de XP podemos encontrar otro ciclo de vida dentro de este que indica comotrabajan los programadores para poder codificar.

Figura 3 – Ciclo de vida del programadorEl triángulo 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, codificación y luego refactoring. Esto es lo opuesto a la programación tradicional endonde primero se diseña, 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:

· Elección de pareso Toda la producción se realiza en pares.o El encargado de escribir piensa tácticamente, su pareja piensa estratégicamente.o Se rotan los roles periódicamente.

· Testingo Se escriben los testing unitarios.o Se verifica que los test fallen antes de codificar.o Se testea todo lo que posiblemente puede fallar.

· Codificacióno “Hacer algo que funcione de la manera más sencilla”o Implementar lo suficiente para hacer que el test pase.o Seguir el estándar de codificación.

· Refactoringo Quitar toda porción de código que no parezcan estar bien y luego verificar si el código aún pasa

los test unitarios.o El código debe ser claro, no tener partes duplicadas y tener la menor cantidad de clases y métodos

posibles.o Realizar cambios pequeños y luego realizar los test unitarios.

TESTING Q & A

CODIFICACIÓN REFACTORING

INTEGRACIÓN

ELECCIÓN DE PARES



· Q & Ao El cliente puede proveer rápidamente 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 aceptación que captura sus preguntas.

· Integracióno Llevar el código a la máquina donde se realiza la integración, unir el sistema y correr todos los

test.o Arreglar todos los errores para que pasen todos los test unitarios.o Si no es fácil la integración es mejor tirar todo y comenzar nuevamente al día siguiente.

· Retornar al inicio.o Si resta tiempo, se puede elegir otra pareja o cambiar de roles y comenzar con otra actividad.

ReferenciasExtreme Programming < http://www.xp123.com>

http://www.xp123.com>



Roles y responsabilidades.Dentro de la mitología de XP existen variados roles. A continuación se detallan cuales son los roles másimportantes.

ClienteEs quien establece que es lo que debe realizar el sistema, tomando la decisión de cuando se debe implementardeterminada funcionalidad, así como también en el orden a ser implementadas. Además, el cliente escribe las storycards y los test funcionales y decide cuando cada requerimiento está satisfecho. Los clientes también priorizan cadauno de los requerimientos. (Prácticas Extremas en ORTsf. Roles. Pág. 57)

CoachEs el encargado de asegurar el cumplimiento de todas las prácticas, transmitiendo sus conocimientos y experienciaal resto del equipo.

ConsultantEs una persona externa al equipo que posee el conocimiento técnico necesario para poder ayudar al equipo condeterminados problemas.

ManagerToma las decisiones más importantes del proyecto. Es el encargado de comunicarse con el equipo para determinarcual es la situación 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 código lo más simple y definitivo posible. Elprimer aspecto a tener en cuenta para que XP sea exitoso es la coordinación entre los programadores y el resto delequipo.

TesterLos tester ayudan a los clientes a escribir los test funcionales del sistema. Además, corren dichos testingregularmente, envían los informes con los resultados y realizan el mantenimiento a las herramientas de testing.

TrackerTiene como principal responsabilidad realizar las mediciones y la recolección de métricas. Mide el progreso delproyecto y lo compara con lo estimado. También observa el desempeño del equipo, haciendo énfasis en elcumplimiento de los plazos y aconsejando al equipo si deben realizar cambios para lograr los objetivos. Además 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 Programming/Roles and Responsabilities. Pág- 21)

ReferenciasABRAHAMSSON, Pekka; SALO, Outi; JUSSI. “Agile softwar development methods. Reviews andanalysis”[online]. Disponible en Internet: <http://www.info.vtt.fi.pdf/>




PrácticasUno de los factores que hacen que XP sea tan utilizado y efectivo son las prácticas que se realizan durante elproyecto. XP es un conjunto de ideas y prácticas de metodologías ya existente y por eso deben ser muy tenidas encuenta a la hora de su implementación. A continuación se presentan las prácticas más utilizadas.

ü 40 Horas semanalesü Cliente on-siteü Diseño simpleü El juego de la planificaciónü Estándares de codificaciónü Integración continuaü Metáforaü Pequeñas entregasü Programación por paresü Propiedad colectivaü Testingü Refactoring

40 horas semanalesComo máximo 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 está 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 solución.

El realizar horas extras más de una semana seguida hace que se comentan más errores tanto en el código como en eldiseño. 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. ExtremeProgramming/Practices. Pág. - 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. Además 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 comunicación fluida con el cliente sin necesidad de gastartiempo en documentación formal. Esta comunicación constante reduce el tiempo de desarrollo al reducir las esperaspor respuesta y los malentendidos entre ambas partes. (Agile softwar development methods. Reviews and analysis.Extreme Programming/Practices. Pág. - 22)

Diseño simpleSe hace mucho énfasis en el diseño de una solución lo más simple posible que pueda ser implementada en elmomento. El código complejo o innecesario es eliminado inmediatamente.

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

§ Corre todo los casos de prueba



§ Enuncia todas las ideas que se quieren exhibir.§ No tiene código duplicado§ Posee el menor número de clases y métodos posibles.

Para poder obtener un diseño simple se descartan todos aquellos elementos innecesarios mientras que los tresprimeros puntos se cumplan.

El juego de la planificaciónPara poder realizar una buena planificación se necesita una buena interacción entre los clientes y los programadores.Los 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 más importantes para implementar. Cada entregadebe tener una duración máxima de dos meses y se estima la duración suponiendo que no hay retrasos o imprevistos.

Cada entrega consta de varias iteraciones, cuya duración 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 aceptación para cada story. Losprogramadores dividen cada story en tareas, que luego son aceptadas por cada programador, estimadas,implementadas y por último integradas al sistema. (Prácticas Extremas en ORTsf. Roles. Pág. 40)

Las tareas tienen una duración promedio de uno a dos días. En ellas los programadores establecen todos los casos deprueba posibles antes de comenzar con la implementación. Luego se pasa a la implementación en el cual el clienteestá disponible para poder evacuar cualquier duda que surja.

Estándares de codificaciónEl código es la mejor documentación 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 estándar para el código, dejando de lado estilos deprogramación particulares. Todos deben conocer y seguir el estándar 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:

§ Mantener métodos pequeños (el código puede ser visto en una sola pantalla)§ Ser coherentes en el uso de mayúsculas.§ Solo comentar el código cuando sea realmente es necesario.§ Usar formatos de nombres consistentes y similares.§ Utilizar siempre el mismo formato de sangría.

Integración continuaUna nueva pieza de código debe ser integrada al resto del sistema tan pronto como sea posible. De ese modo, elsistema es integrado y reconstruido varias veces por día.

Para poder realizar esta integración se selecciona una computadora determinada. Luego, al finalizar cada pareja deprogramadores se dirige a dicha máquina para integrar sus cambios al sistema existente. Posteriormente se ejecutantodos los casos de prueba establecidos, hasta que cada uno de ellos sea aprobado. (Prácticas Extremas en ORTsf.Roles. Pág. 40)

Lo bueno de este sistema es que no ocurren problemas de integración ya que los errores se encuentran y sesolucionan al momento de ser integrados por los mismos programadores que tienen en la cabeza en códigoimplementado. Esto evita que se pasen meses para la integración y tener que solucionar estos problemas másadelante.



MetáforaEl sistema es definido en base a una metáfora o conjuntos de metáforas entre el cliente y los programadores.

Para XP la metáfora equivale a la arquitectura en otras metodologías, pero es más 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 metáfora es creada, se pasa al establecimiento de clases, métodos y relaciones primordiales delsistema.

Además, de servir como fuente de comunicación entre los clientes y los programadores sirve para poder mantener eldiseño del sistema lo más simple posible. También se utiliza para comunicar las bases del sistema a los nuevosintegrantes.

Pequeños releaseLos release deben ser los más pequeños posibles con una duración 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 características 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 además hace que los programadores mantengan su nivel de motivación ya que lo más agradable deprogramar es poder entregar un producto terminado. (Prácticas Extremas en ORTsf. Roles. Pág. 40)

Programación por paresUno de los pilares de XP es la programación en pareja o programación por pares. Básicamente lo que se quiere conesto es poder eliminar posibles errores debido a distracciones o errores conceptuales. Al tener dos personasconcentradas sobre el mismo código 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 código. La otra persona, el “copiloto”,participa verbalmente. El “conductor” tiene una visión de cómo implementar el código de la mejor manera mientrasque el “copiloto” tiene una visión global del sistema y se encarga de sugerir posibles alternativas y nuevos casos deprueba. Es bueno que los dos integrantes se turnen en la conducción. (Prácticas Extremas en ORTsf. Roles. Pág. 40)

Propiedad colectivaCualquier persona está en condiciones de cambiar cualquier parte del código en cualquier momento.

En XP nadie tiene propiedad sobre ningún módulo o clase. Cada uno de los integrantes puede realizar cambios omejoras a cualquier parte del código 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 aceptación.

Los testing unitarios son implementados por los programadores antes de comenzar con la implementación. Seestablecen todos los casos en el que el código puede fallar. Una vez que se termina con la implementación se correndichas pruebas y se verifica que no haya ningún test que falle. Hasta que pasen todos los test el programador debeseguir mejorando el código. Estas pruebas son automatizadas e implementadas por el propio programador, lo cualhace que la prueba pueda ser más rápida y efectiva.



Los testing funcionales o de aceptación son definidos y escritos por el cliente al inicio de cada iteración 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 código hace que este sea fácil 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 diseño se mantiene simple ypermite a los programadores desarrollar más rápido.

ReferenciasABRAHAMSSON, Pekka; SALO, Outi; JUSSI. Agile softwar development methods. Reviews and analysis [online].Disponible en Internet: <http://www.info.vtt.fi.pdf/>




Herramientas para el testeo automáticoDebido a que el testing es una de las actividades más importantes en la programación de XP es necesario poseer unabuena herramienta de testeo automático según el tipo de lenguaje en el cual se desarrolle.

Una de las herramientas más conocida para realizar el testing automático 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 sección no es mostrar el funcionamiento de JUnit, sino que se desea ejemplificar como se puedeimplementar el testeo automático.

JUnitCaso simplePara poder realizar un test simple en algún método simplemente se debe hacer lo siguiente:

· Crear una instancia de TestCase· Crear un constructor el cual acepte un String como parámetro y pasar este como superclase.· Reescribir el método runTest()· Cuando se quiere chequear un valor, llamar al método assertTrue() y pasarle un boolean que sea

verdadero cuando el test sea correcto.

Por ejemplo, para poder testear el funcionamiento del método “concatenar” de la clase “Cadena” se puedeimplementar el siguiente método.

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));}

SuiteA medida que se avanza con la implementación es lógico 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 (“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();

TestRunnerUna vez que los test suite están implementados es hora de recolectar la información de cada uno de dichos test. Paraesto es necesario implementar un método estático llamado suite que retorna un test suite. (JUnit. JUnit CookBook )



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 más rápido de ejecutar y puede ser utilizado cuando no es necesario

tener información gráfica de los resultados del testing.· Graphical TestRunner: Este muestra un simple diálogo en el cual se elige el test a ejecutar y provee una

gráfica de progresión de los test realizados.

El Graphical TesRunner muestra una ventana con la siguiente información:· Un campo donde se indica el nombre de la clase con el método suite.· Un botón 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 más fácil de implementar y se obtienen los beneficios que hemosexplicado anteriormente, como por ejemplo, el refactoring.

ReferenciasJUnit <http://www.junit.com>



ConclusionesComo hemos visto en este documento hay aspectos en XP que lo hacen diferente a otras metodologías.

Comenzamos con sus valores (Comunicación, Simplicidad, Feedback y Coraje). En XP la comunicación es vitaltanto entre el grupo de desarrollo como con el cliente, el cual debe formar parte del equipo para mantener unacomunicación 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 más de esfuerzo para realizar un cambio en elfuturo, a realizar algo más 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 así tomar decisiones mucho más acertadas. Porúltimo, la comunicación, la simplicidad y el feedback forman el coraje, el cual se convierte en el objetivo de XP. Elcoraje también es poder realizar cambios cuando algo no funciona del todo bien, diseñar 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 estándar para obtener buenos resultados. Sinembargo, los valores son muy vagos a la hora de ayudarnos a decidir que prácticas utilizar. Para ello se necesitadestilar estos valores en principios que puedan ser utilizados, como ser, una rápida retroalimentación, asumir lasimplicidad, realizar cambios incrementales, aceptar el cambio y realizar un trabajo de calidad.

Por último debemos mencionar las prácticas que se utilizan, las cuales hacen que XP sea tan utilizado y efectivo.XP es un conjunto de ideas y prácticas de metodologías ya existente y por eso deben ser muy tenidas en cuenta a lahora de su implementación. De la gran cantidad de prácticas destacamos:

ü 40 Horas semanalesü Cliente on-siteü Diseño simpleü El juego de la planificaciónü Estándares de codificaciónü Integración continuaü Metáforaü Pequeñas entregasü Programación por paresü Propiedad colectivaü Testingü Refactoring

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 ágil 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 ningún tipo de concepto sino que al contrario deben servir como una guía según el tipo deproyecto que se quiera realizar.



Palabras Clavesü 40 Horas semanalesü Aceptar el cambioü Aceptar la responsabilidadü Adaptación localü Asumir la simplicidadü Cambios incrementalesü Clienteü Cliente on-siteü Coachü Comunicaciónü Comunicación abierta y honestaü Consultantü Corajeü Diseño simpleü El juego de la planificaciónü Enseñar conocimientosü Entregaü Estándares de codificaciónü Fase de exploraciónü Fase de iteraciones por entregasü Fase de mantenimientoü Fase de muerteü Fase de planificaciónü Fase de producciónü Feedbackü Integración continuaü Jugar para ganarü Managerü Mediciones honestasü Metáforaü Pequeña inversión inicialü Pequeñas entregasü Programación por paresü Programación por paresü Programadorü Propiedad colectivaü Rápida retroalimentaciónü Refactoringü Simplicidadü Sotriesü Story cardsü Test funcionalü Testerü Testing unitariosü Trabajar con los instintos de las personasü Trabajo de calidadü Trackerü Viajar liviano



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 aceptación: Test escrito desde la perspectiva del cliente.

ü Test unitario: Test escrito desde la perspectiva del programador.



BibliografíaArtículosABRAHAMSSON, Pekka; SALO, Outi; JUSSI. Agile softwar development methods. Reviews and analysis [online].Disponible en Internet: <http://www.info.vtt.fi.pdf/>


LibrosKENT, Beck. 2000. Extreme Programming explined. 1ra edición

Sitios WebExtreme Programming <http://www.extremeprogramming.org>

Extreme Programming < http://www.xp123.com>

JUnit <http://www.junit.com>

http://www.xp123.com>

Universidad ORT Uruguay

Documents

Transcript of Universidad ORT Uruguay