Ingeniera multimedia ANLISIS Y ESPECIFICACIN DE SISTEMAS MULTIMEDIA

PRCTICA 2 Simulacin XP

Carlos Javier Lpez Lpez Cristina Palomares Crespo Rubn Martnez Vilar Vctor Puche Leal Grupo 4 (Mircoles 17:00 19:00)

ndice
1. Introduccin ........................................................................... 3 2. Juego de Simulacin ................................................................ 6 2.1. Rol de Desarrollador ...................................................... 6 2.2. Rol de Cliente ........................................................... 7 2.3. Rol de Coach ................................................................... 8 2.4. La Figura del Coach .................................................. 9 3. Conclusiones ......................................................................... 10 4. Bibliografa ............................................................................. 11

1. Introduccin
Las metodologas giles o ligeras se suelen aplicar a pequeos proyectos. Se caracterizan por afrontar el proyecto desde un punto de vista iterativo e incremental. Adems son adaptativas, se acoplan a cualquier cambio que se produzca durante el ciclo de vida. Entre los aos 80 y 90 comenz la poca Hardware. Eran las metodologas pesadas o tradicionales las que se desarrollaban. Se planificaba todo muy bien y se formalizaba la manera en que se iba a realizar el proyecto. Sin embargo, la documentacin era la parte en la que ms tiempo se inverta, en lugar de ser la de desarrollo. Esto provocaba una sobrecarga de trabajo y el resultado era un equipo frustrado y un cliente insatisfecho. La solucin a esto aparece a finales de los 90: se atiende ms al Software. Surgen las metodologas giles, que son ms livianas. Se llevan a cabo cuando las aplicaciones no son muy grandes, cuando sabemos que los requisitos van a cambiar a lo largo del proyecto. Es importante tener un software funcional que entregar y ser la medida principal del progreso. Hay que colaborar con el cliente, hacer que se implique en el proyecto para que los desarrolladores consigan exactamente aquello que pide. En cada iteracin, el cliente dar ms valor a algo que ser lo que los desarrolladores intentaremos implementar. Al ser una metodologa incremental, cada ciertas iteraciones conseguiremos que funcione. El grupo ha de estar unido y comunicado para esto, hay que motivarse de forma mutua. El trabajo se hace por igual, ha de ser sostenible, y se tiene que llevar un ritmo constante en todas las iteraciones. El equipo de desarrolladores busca la manera ms fcil de solucionar los problemas propuestos, y son los que deciden cmo y cundo lo van a hacer. La clave para el xito es una buena comunicacin. La metodologa gil que hemos llevado a cabo en esta prctica ha sido XP, eXtreme Programming. Es una metodologa con un ciclo de vida iterativo e incremental, donde en cada iteracin entregaremos algo en funcionamiento que habr sido planificado previamente. Los roles en XP son los siguientes: Programador: normalmente es por parejas. Escriben continuamente pruebas unitarias las cuales deben funcionar sin problemas para continuar el desarrollo. XP les impone un alto nivel de disciplina y les permite mantener un mnimo nivel de documentacin. Esto se traduce en una gran velocidad de desarrollo. Cliente: las historias de usuario que escribe son los requisitos, lo que los clientes quieren para su software. Tiene muy claras las caractersticas de los procesos iterativos. Es quien asigna prioridad a las historias a implementar en cada iteracin y se centra en el valor de negocio. Tester: har que sus requisitos sean aceptados y escribir pruebas funcionales junto con el cliente de forma paralela al desarrollo. Debern tener una estrecha comunicacin. Las pruebas se ejecutarn regularmente por el Encargado de pruebas. ste entender la arquitectura del sistema con su suficiente conocimiento tcnico.

Tracker: comprueba como avanza el equipo de desarrollo. Monitoriza lo que va haciendo el equipo para que, si hay problemas, lo solucionen lo antes posible. Por tanto proporciona realimentacin al equipo. Es el Encargado de seguimiento. Coach: el entrenador. Es quien guiar al equipo para un seguimiento correcto del proceso. Se responsabiliza del proceso global. Consultor: persona externa al proyecto con conocimiento sobre un rea en concreto de la ingeniera de software. El rol contar con aptitudes de sntesis y tendr que guiar al equipo para la resolucin de un problema especfico. Jefe o Gestor: es el vnculo entre clientes y desarrolladores. Elige el grupo de trabajo y coordina de forma que el equipo est convencido de que las prcticas optimizan el desarrollo. En el caso de la incorporacin de nuevos recursos, el gestor har un ajuste de stos rpidamente para no perjudicar el funcionamiento del grupo.

El ciclo de desarrollo de la metodologa XP sigue 6 fases: 1. Exploracin. El cliente plantea las historias de usuario, define qu es lo que quiere. Se analizarn los materiales necesarios y se realizar un pequeo prototipo. Con una lista de las historias de usuario se hace una planificacin de todo el proyecto. 2. Planificacin. Para esta fase el cliente establecer la prioridad de cada historia y los desarrolladores estiman el tiempo y esfuerzo que les puede llevar realizarlas. Adems los programadores establecern la cantidad de historias (velocidad) que van a llevar a cabo dependiendo del tiempo del que dispongan. Para determinar los puntos que se pueden completar se multiplica el nmero de iteraciones por la velocidad del proyecto. 3. Iteraciones. Se establece una arquitectura del sistema en la primera iteracin y se seguir a lo largo del proyecto. Se tendrn en cuenta las historias de usuario no realizadas, la velocidad, las pruebas no superadas y las tareas no terminadas en la iteracin anterior. 4. Produccin. Habr que decidir si se incluyen nuevas caractersticas a la versin actual. Antes de presentar al cliente se realizarn pruebas adicionales y revisiones de rendimiento. 5. Mantenimiento. La primera versin del proyecto se encuentra en produccin. El equipo de desarrollo debe mantener el sistema en funcionamiento mientras se realizan nuevas iteraciones. Para esto hay que llevar a cabo unas tareas de soporte para el cliente. 6. Muerte del Proyecto. Se han desarrollado todas las historias de usuario propuestas por el cliente. Ahora los desarrolladores deben rematar la faena: mejorar el rendimiento y la confianza del sistema. Es la manera de satisfacer al cliente. Ya no es momento de realizar ms cambios y se generar un documento final del sistema. Esta fase tambin puede producirse si el sistema no genera los beneficios que el cliente esperaba o si no hay presupuesto suficiente.

2. Juego de simulacin 2.1 Rol de desarrollador

El desarrollador es el encargado de realizar las pruebas y producir el cdigo del sistema, as como las tareas que conlleva cada historia de usuario, estimando el tiempo que requerir cada una, adems debe existir una buena comunicacin y coordinacin entre los diferentes miembros del equipo. As en primer lugar se comprueban los recursos de los que se dispone y se comprueban las historias que nos facilita el cliente, estimando los recursos disponibles y la dificultad para la realizacin de estas. Una vez el cliente proporciona las historias escogidas el coach ser el encargado de dirigir el equipo para que todas las historias puedan realizarse dentro del lmite marcado por el cliente. Siguiendo el orden de historias establecido por el cliente se implementar cada una de las historias planificando el desarrollo de estas, comprobando as que el resultado de esta sea correcto. En la simulacin de XP hemos (Grupo: Cristina Palomares, Paula Benedicto, Vctor Puche, Pablo Arcos y Hctor Arce) planificado de forma correcta las tareas a realizar, pues disponamos de una buena comunicacin al marcar los puntos de estimacin en cada historia, llegando al punto de que se realizaron correctamente todas las historias propuestas incluso antes de finalizar el tiempo. Todo esto fue posible gracias a la figura del coach, que nos ayud a puntuar las diferentes historias gracias a una breve descripcin, no teniendo as ningn problema en el resultado final de la historia, siendo siempre lo que el coach esperaba. En cuanto a estimaciones no fuimos del todo precisos, ya que podramos haber aadido algunas historias de ms, si bien si que acertamos con la dificultad de las historias, poniendo como ejemplo la creacin de una casa de naipes, pues un miembro del grupo no quera otorgarle una gran dificultad y realizar esta prueba, pero el resto del grupo observamos que el desarrollo de esa historia podra influir en el resultado final, por lo que todo el grupo decidimos no realizar esa tarea y puntuarla con el grado mximo de dificultad. Tambin contamos con la ventaja de poder realizar alguna prueba antes de estimar los puntos, como la de realizar los aviones o la de hinchar los globos y ponerles el clip. Aunque la segunda iteracin no llegamos a completarla por falta de tiempo, el resultado iba siendo previsiblemente igual al de la primera iteracin, con tiempo de sobra para realizar las tareas, si bien es cierto que tuvimos algn pequeo problema, ya que las pruebas eran ms duras que en la primera iteracin, en la prueba de hinchar 10 globos, pues a un compaero del grupo le cost ponerle el clip al segundo globo hinchado, aunque los problemas no llegaron a ms. Finalmente, como desarrolladores, hemos aprendido a no sobreestimar la velocidad de desarrollo, pues en ambas iteraciones nos sobr tiempo, pensando as que quizs deberamos arriesgarnos un poco ms y establecer menos dificultad a las historias ofrecidas por el cliente, aunque de una forma responsable.

2.2 Rol de cliente

El cliente es el protagonista en la accin comercial. Es el que realiza las demandas y propone dudas, sugerencias o propuestas de mayor peso. Es una parte del negocio, no ha de ser tratado como a un extrao. La obligacin del desarrollador es cumplir sus deseos, dentro de lo razonable, tratar con el cliente para cubrir sus necesidades comerciales de la mejor manera posible. Un cliente es alguien que posiblemente no entienda sobre el trabajo que deben realizar los desarrolladores, y muchas veces ni siquiera tiene claro como quiere que se lleven a cabo o se vean finalmente los objetivos del producto. Por ello se debe mantener siempre una comunicacin cliente-desarrollador y aportar consejos y servir de gua segn la experiencia de cada lado. En este caso vamos a comentar la experiencia del otro grupo (Ruben Martinez Vilar, Laura, Manuel, Victor y Romulo como coach) : En la primera iteracin, como clientes, sufrimos una mala valoracin de la dificultad de ciertas tareas por parte de los desarrolladores, de modo que, buscando la manera maximizar el valor de negocio fue difcil realizar una buena distincin entre las tareas ms crticas y las que en realidad no aportaban demasiado. Al finalizar la iteracin algunas de las tareas quedaron sin realizar y esto repercuti gravemente sobre el valor final. Esto produjo una decepcin general en el grupo. En la segunda iteracin fue diferente, se consigui, por parte de los desarrolladores, una buena eleccin y valoracin de la dificultad de las tareas. As que como clientes nos result mucho ms fcil escoger un orden y combinacin ptimo, a las historias con operaciones matemticas se les estim mayor tiempo y otras como los pisos de cartas o construir barcos de papel se dejaron para el final en caso de haber tiempo suficiente. Tambin se decidi que las historias con valores de 300 deberan priorizarse por encima de las de 100 o 500, ya que mantenan un buen equilibrio entre el valor y esfuerzo o tiempo. Al final de esta iteracin el valor se haba duplicado con respecto a la primera. Despus de cada actividad, el coach acta como cliente, adems de nosotros mismos, decidiendo si el resultado es aceptable. En ciertas tareas este cliente ha tenido que ser ms indulgente con respecto al resultado. Como ejemplo, los globos deban ser cerrados mediante clips, pero se comprob que estos no servan para tapar la salida del aire, por lo que se tuvieron que presentar al cliente sujeto con los mismos dedos o atado. En otras tareas tuvo que ser ms paciente, ya que por ejemplo, en las sumas de la primera iteracin, uno de los desarrolladores tuvo problemas con las suyas y el tiempo total bastante ms del estimado. A pesar de esto, creemos que desde el punto de vista del cliente, quedamos bastante satisfechos los resultados de la segunda iteracin.

2.3 Rol de coach

La experiencia de simular a la figura del coach y controlar a un equipo ha sido plenamente satisfactoria. A priori ponerse en la piel del gua del grupo parece bastante fcil, en la simulacin claro, pero en el mundo real no lo es tanto, puesto que estas trabajando con dinero y tiempo real. Esta figura es la que ms responsabilidad tiene durante el transcurso de un proyecto. Respecto al grupo (formado por: Cristina Palomares, Paula Benedicto, Vctor Puche, Pablo Arcos y Hctor Arce) no puedo tener queja alguna. Haba una buena comunicacin entre ellos y hacia m. Se ponan de acuerdo, daban su opinin respetando la de los dems miembros del grupo y cuando alguien tena problemas con su parte del trabajo no dudaban en echarle un cable. Si algo sala mal no pasaba nada, seguamos hacia delante. En mi opinin, los resultados no podran haber sido mejores con los componentes del grupo que ramos. La nica forma de haber superado los resultados, ya no solo dentro de nuestro grupo, si no en general, hubiera sido a la hora de crearlos. Me explico: por ejemplo en nuestro grupo no haba nadie que supiera hacer los barcos de papel que aparecan en alguna de las historias propuestas ni tampoco los castillos de cartas. Por el contrario en otros grupos varios de sus componentes saba hacer estas tareas. En conclusin, si los grupos hubieran sido ms heterogneos (respecto a las habilidades), se podran haber desarrollado ms cantidad de historias. Por otro lado eso es algo bastante difcil de conseguir ya que no sabamos las tareas que se nos iban a encomendar y en concordancia tampoco las habilidades de nuestros compaeros que nos iban a resultar tiles para cumplirlas.

2.3 La figura del coach

El coach es quien ha de guiar el proyecto y responder a las posibles cuestiones/dudas que surjan a los miembros del equipo. Esta figura al tratarse de uno de los miembros con ms experiencia del grupo hara las veces de mentor. Es una figura con mucha responsabilidad ya que se podra decir es que predica con el ejemplo y se hace respetar. Tambin puede servir como intermediario entre el equipo de desarrollo y el equipo de gestin del proyecto. Respecto a su forma de comportarse, ha de mantener una actitud grupal y nada individualista, tanto a nivel personal como grupal. Ha de fomentar las relaciones laborales entre los miembros del grupo (coach incluido). El coach ha de asumir las siguientes funciones: Visualizacin: formular y visualizar la visin de la meta para que el grupo pueda trabajar encaminada hacia ella. Unir: debe unir al grupo para trabajar en cohesin y armona Metdico: tiene que elegir que metodolgias llevar son las adecuadas, comunicarlas y adaptarlas al proyecto.

Mentor: como seguramente en el grupo los niveles de habilidad y capaciad sea diferente entre sus componentes, el coach ha de ayudar a las personas con menos experiencia y encontrar las indicaciones para que sean relevantes en el proyecto de desarrollo. Lenguaje: el coach ha de controlar su lenguaje ya que tiene que comunicarse de manera continua con el entorno.

Esta figura no solo es necesaria, es natural en un grupo. Aunque no existiera como tal dentro de un grupo, esta figura siempre surgira espontneamente debido a la experiencia, al carcter o a las habilidades de alguno de sus miembros.

3. Conclusin
Despus de haber hecho la simulacin y de haber investigado la metodologa, as como sus roles. Se puede concluir que est mtodo gil de desarrollo se basa en la cohesin del grupo. La clave para un buen trabajo son las relaciones dentro de l. Tambin la comunicacin, ya no solo del grupo de desarrollo, si no tambin entre los distintos agentes que hay en el contexto de desarrollo. Hay que decir que esta metodologa tambin favorece al rendimiento, ya que los trabajadores observan resultados a corto plazo, adems de proporcionar a los clientes un mayor seguimiento de los resultados y el camino que est tomando el proyecto. La naturaleza iterativa de esta metodologa nos ha permitido mejorar y proporcionar una mejor respuesta en la segunda ronda de tareas. Al haber un fuerte retroalimentacin por parte del cliente es idnea para proyectos que no estn o bien no pueden tener todos los puntos definidos desde el principio.

4. Bibliografa
Ciclo de vida de la metodologa XP: http://oness.sourceforge.net/proyecto/html/ch05s02.html Informacin ms general sobre metodologas: http://www.google.com/url?q=http%3A%2F%2Fmaterias.fi.uba.ar%2F7500%2Fschenonetesisdegradoingenieriainformatica .pdf&sa=D&sntz=1&usg=AFQjCNHWTpvddiDnG0u-a6cCP647AUxeYQ Informacin sobre Metodologas giles: http://materias.fi.uba.ar/7500/schenone-tesisdegradoingenieriainformatica.pdf