Simulacin de la metodologa XP

Prctica 2

#AESMultimedia - aesmultimedia.blogspot.com
Jos Lus Contreras Martnez Ana Garca Domene Daniel Martnez Espadas Begoa Morillas Guijarro @DkLawis @agado92 @danielme91 @begomori

ndice
1. Introduccin 2. Juego de simulacin 2.1 Rol de desarrollador 2.2 Rol de cliente 2.3 Rol de coach 2.4 La figura del coach 3. Conclusiones Bibliografa

Memoria prctica 2. Simulacin XP

1. Introduccin
XP o eXtreme Programming es una metodologa para proyectos que favorece las relaciones interpersonales que requiere que entre la relacin cliente-desarrolladores est presente en todo momento una buena realimentacin. Esto se debe a que esta metodologa est pensada para proyectos con requisitos poco precisos y muy variables que presentan un alto riesgo. En esta prctica se ha simulado el trabajo mediante XP en grupos de trabajo. Cada grupo ha actuado de cliente y desarrollador, supervisado por un coach, para valorar y planificar el desarrollo de ciertas tareas predefinidas. Hemos realizado varias fases de XP: Fase 1: Exploracin. En la que se encuentra la presentacin de las historias de usuario a los desarrolladores. Debate sobre la definicin de las tareas entre el grupo de trabajo y el coach. Fase 2: Planificacin de la entrega. Prioridad de cada historia por parte del cliente. Valoracin por puntos de las historias y decisin de cantidad contenido de la primera entrega por parte de los desarrolladores. El cliente decide que tareas se realizarn en la iteracin. Fase 3: Iteraciones. Realizacin de las distintas pruebas elegidas por el cliente en el tiempo estipulado. La prctica constaba de 3 iteraciones, slo dio tiempo a completar la primera y la segunda. Para cada fase tenamos un tiempo preestablecido: 15 minutos para las fases 1 y 2 , adems de 3 minutos para realizar las distintas pruebas de cada iteracin de la fase 3.

2. Juego de simulacin
2.1 Rol de desarrollador
El trabajo del desarrollador consiste en que ,a partir de los datos proporcionados por el cliente, se debe organizar el tiempo disponible e intentar obtener los mejores resultados posibles. La mayor dificultad que hemos tenido, ha sido elegir qu tareas realizaramos y cules descartaramos, teniendo en cuenta el poco tiempo del que disponamos, el grado de dificultad de la tarea y el valor de negocio que sta aportaba. Para planificar las tareas a realizar por el equipo, hicimos una tormenta de ideas en las que se hablaba de cada historia en general y entre todos proponamos ideas para hacer la prueba de la forma ms ptima posible. Tambin, consultbamos con el coach nuestras dudas para as entender bien qu debamos hacer en cada historia. Evitando as errar haciendo algo distinto a lo que el cliente esperaba y perder tiempo en su ejecucin. Las estimaciones fueron bastante precisas en ambas iteraciones porque nos ajustamos bastante al tiempo disponible, aunque eso s, sobrndonos muy pocos segundos en ambos casos, pero pudiendo realizar todas las historias seleccionadas. Como estrategia para escoger las historias, las ordenamos por puntos de dificultad, dejando para el final las historias en las que estimamos que el tiempo sobrepasaba los 3 minutos o que estaban por encima de nuestra capacidad. Para estimar los puntos de las historias, en la mayora de casos nos basamos en experiencias anteriores y en otras hicimos alguna pequea prueba, para as sopesar si ejecutarla o no. Despus escogimos las que pensamos ms factibles y descartamos las complejas y con menor valor para la empresa porque no merecan la pena de perder el tiempo con ellas. La primera iteracin result ser algo peor que la segunda debido a que, a pesar de habernos organizado, no contamos con algunos problemas que podran surgir como por ejemplo, colocar el clip a los globos que algunos se pusieron mal. Pero como suele ocurrir, la experiencia hizo que perfeccionsemos las tcnicas de trabajo para llevar a cabo las historias en la segunda iteracin. Por suerte, no nos vimos obligados a tener que abandonar ninguna historia planificada por el cliente. Eso se debi a que no sobreestimamos la velocidad de desarrollo, lo que provoca que no se cumplan los plazos y a que tampoco infravaloramos la velocidad de desarrollo, lo que conlleva a que no se realicen las tareas. En la segunda iteracin nos replanteamos los puntos de esfuerzo de alguna historia ya que al principio las cremos ms sencillas, pero nos dimos cuenta de que costaban ms. Gracias a la simulacin de la metodologa del extreme programing (XP) hemos aprendido, a parte de hinchar globos, encontrar cartas, hacer papiroflexia y realizar operaciones todo ello en un tiempo justo, a valorar lo importante que es saber que limitaciones tenemos para nuestro trabajo y ajustarlo. 4

2.2 Rol de cliente

El cliente debe describir las historias de usuario a los desarrolladores para que el proyecto se pueda realizar correctamente. Adems, el cliente impone una prioridad a cada historia de usuario y decide cuales de ellas se realizan en cada iteracin teniendo en cuenta que le conviene en tener el mayor valor de negocio. Ha sido un poco difcil hacer un planning a partir de la velocidad estimada por los desarrolladores porque haba que cuadrar las tareas para llegar al tope de puntos de los desarrolladores, sin pasarse, para obtener un buen valor de negocio. Las historias se han elegido por mayor valor de negocio, que es lo que ms le interesa al cliente. Despus de esto, nos fijamos en los puntos de esfuerzo asignados por los desarrolladores para completar el total de puntos que haban marcado para realizar en los 3 minutos de los que disponan con el mayor nmero de pruebas posible. En las dos iteraciones tuvimos la suerte, o ms bien nos esforzamos tanto en conseguir llevarlas a cabo todas las que nos propusimos, que no se nos dio esta situacin. Pero si se hubiera dado el caso en mi grupo, supongo que nos hubiera sentado bastante mal y nos habra creado desconfianza y escepticismo con respecto al grupo de desarrolladores que va a llevar a cabo el proyecto que como clientes deseamos. A un cliente no se le puede decir que no a los deseos que tiene, por algo ests contratado por l y debes realizar todo lo que te pida dentro de lo posible. No cumplir algn punto que el cliente ha escogido supone una especie de penalizacin para el el grupo de desarrolladores.

2.3 Rol de coach

Controlar a un equipo ha sido una buena experiencia. Hemos podido observar como nuestros compaeros intentaban organizarse lo mejor posible para valorar la dificultad de las distintas tareas, calculando el tiempo mximo de trabajo, e intentando compenetrarse para realizarlas correctamente en el menor tiempo posible como desarrolladores y seleccionar las tareas que ofreciesen mayor valor, siendo clientes. Para calcular la dificultad de las tareas han ledo de que trataba cada una y han preguntado alguna duda que han tenido sobre el planteamiento o posibilidad de repartir tareas entre los miembros del grupo. Por ejemplo, han pedido ver el prototipo de avin de papel para comprobar cmo deba quedar y calcular cunto tiempo podan tardar en hacer uno y, a partir de eso, el total de aviones que peda la prueba. Al igual que con los globos, con los que probaron a hinchar alguno con la medida pedida y cerrarlos con clips. Tambin preguntaron si era posible repartir el trabajo en algunas pruebas o, por el contrario escoger al componente o componentes ms rpidos para optimizar. Se podran obtener mejores resultados en algunas tareas con una mejor planificacin adems de un buen reparto de tareas.

Como ejemplo pondremos la tarea que consista en encontrar las dos cartas de oros que faltaban de la baraja. El grupo reparti la baraja en cuatro, por lo que cuatro buscaban las cartas del palo oros, mientras el trabajador restante deba vigilar cul faltaba de las que le iban dando. Rpidamente encontraron todas las cartas de oros, pero todas dejadas encima de la mesa en orden aleatorio, por lo que acabaron los cinco intentando ver que dos faltaban de memoria. Podran haber ganado tiempo si entre todos o algunos de ellos hubiesen colocado las cartas en un orden lgico. En otra ejecucin de la misma prueba mejoraron, prepararon una lista con los nmeros del palo y conforme se dejaba un oro en la mesa decan el nmero en voz alta y se tachaba de la lista de posibles cartas. Viendo esto, supongo que con la repeticin de tareas en las siguientes iteraciones, puesto que este grupo slo realiz una, tambin mejoraran en su trabajo en general. Pero no nos quedemos con una suposicin. Veamos que ocurri en el grupo de nuestro otro coach y cul fue su experiencia y opinin sobre este rol. El papel de coach tiene la responsabilidad de presentarles al equipo los objetivos a cumplir y enumerarles las herramientas de las que disponen para ellos. Tambin deben aclarar cualquier duda que pueda presentarles y controlar que se van cumpliendo las tareas en el tiempo estimado. Al principio representar este rol supona un reto, porque supone tener muy claro cmo funciona el proyecto e intentar explicarles a 6 personas de la forma ms clara posible lo que deben hacer. Pero la experiencia despus result ser mejor de la esperada, el grupo de personas a quien me toc controlar siguieron correctamente las instrucciones que haba que seguir y atendan cuando yo explicaba las cosas. Se puede decir que la comunicacin fue muy efectiva y fluida con el grupo, comprendieron lo que se deba hacer en cada fase, y formulaban preguntas cuando no les haba quedado clara alguna cosa o queran saber si estaba permitido hacer algn truco para hacer ms tareas en el menor tiempo posible. En la primera iteracin parecieron ms nerviosos, pues no tenan experiencia ninguna, y aunque consiguieron hacer todas las tareas que se propusieron, fueron demasiado justos y agobiados. Adems, en algunas pruebas no se organizaron de la forma ms ptima y tardaron ms tiempo del necesario (y del pensado) en finalizarla. En la segunda iteracin, tras tener la experiencia de la primera, fueron ms sensatos y analizaron mejor la dificultad de las tareas, y las ordenaron y realizaron de forma ms eficiente. Se puede decir que la experiencia es un factor clave. Aunque lo cierto es que en las dos iteraciones se organizaron muy bien desde el principio y fueron muy rpidos, cosa que como coach me sorprendi, pues me esperaba ms desorganizacin y fallos. Pudieron haber ahorrado tiempo eligiendo a los ms especializados en cada tarea; por ejemplo, en la de hinchar globos, todos se pusieron a hincharlos a la vez. A priori puede ser la forma ms efectiva, organizarse entre todos, pero haban un par de miembros que tardaban mucho ms que el resto en inflar un globo. Por lo tanto, si slo se hubieran encargado los ms rpidos, aunque fueran menos cantidad de personas, habran acabado antes.

2.4 La figura del coach

El coach o entrenador vigila y gua a grupo de desarrolladores para que el proyecto se desarrolle correctamente. Es el responsable del proceso global y responsable de proveer de las guas a seguir a los miembros del equipo para que se apliquen las tareas XP y de que

se siga el proceso de forma adecuada, presentndoles las herramientas y la metodologas que pueden usar. Es una figura necesaria porque en un grupo de trabajo siempre tiene que haber alguien a cargo de ellos, para controlar que consigan cumplir los objetivos del proyecto de forma adecuada, y solucionando los posibles problemas con los que se puedan encontrar. Muchas veces al ser tantas personas, pueden perder el tiempo donde no deben, y el coach (entrenador) debe de darles un toque para que una tarea no se alargue ms tiempo del que debe. El coach nos sirve de ayuda y nos da apoyo para tomar decisiones. A parte tambin nos da consejos sobre como hacer el trabajo y nos da libertad para que actuemos segn nuestro criterio.

3. Conclusiones
XP est diseado para grupos reducidos y proyectos a corto plazo, donde el tiempo disponible para realizar el proyecto sea muy corto y donde es ms importante tenerlo acabado antes del fin de plazo que la calidad. La metodologa consiste en una programacin muy rpida, donde la base para el xito es la correcta comunicacin entre los miembros del equipo y su entrenador (coach). Es una de las metodologas ms usadas porque es sencilla de implementar, aunque no sea con la que obtenemos resultados ms ptimos. XP es una metodologa pensada para proyectos con requisitos cambiantes. La simulacin prctica que realizamos en clase sobre esta metodologa fue muy til para comprender el papel que debe hacer cada uno en el XP, los riesgos a los que se tiene que enfrentar y, aunque estbamos en plan competicin con los dems grupos, nos lo pasamos muy bien al intentar conseguir el mayor nmero de pruebas con xito en cada iteracin, y salimos con la impresin de que en esta metodologa sobretodo lo que cuenta es la buena comunicacin entre los miembros del grupo.

Bibliografa
Introduccin: Diapositivas del tema 2 apartado 3 de la asignatura AESM (2012) La figura del coach: http://es.scribd.com/doc/58405046/19/Roles-XP Extreme Programming (XP) Conclusiones: http://www.informatizate.net/articulos/metodologias_de_desarrollo_de_software_07062004. html http://www.willydev.net/descargas/masyxp.pdf