PRCTICA 2: MEMORIA

SIMULACIN XP
Metodologa XP: Es una metodologa para el desarrollo de software, que se basa en la comunicacin interna entre programadores y en la comunicacin externa entre el equipo (programadores) y el cliente. Evidentemente, para que esto sea posible, hay que tener un buen clima dentro del equipo de trabajo, trabajo en equipo, ya sean parejas o tros que comprueben los tiempos de desarrollo de errores. Es esencial que haya una buena relacin entre el equipo a la hora de negociar y hablar con el cliente. Los programadores deben aprender constantemente de las actividades desarrolladas. XP viene muy bien para todos aquellos proyectos en los que las condiciones o requisitos bsicos no estn claramente especificados. Tambin es apropiado para proyectos que cambien sobre la marcha y en los que hay posibilidades de riesgo tcnico.

En que consiste la metodologa XP? La metodologa XP se desarrolla en diferentes fases: 1. Exploracin: El cliente define todas las funcionalidades del software. 2. Planificacin: el programador calcula por encima lo que va a costar, en tiempo y esfuerzo, la realizacin de cada funcionalidad. 3. Iteraciones: Basndose en la estimacin la funcionalidad que se va a desarrollar, el cliente elige. 4. Produccin: El programador crea o desarrolla lo necesario para esa funcionalidad. 5. Mantenimiento: El sistema siempre debe mantenerse estable. Para ello se crean una serie de tareas que nos hagan no perder la funcionalidad. 6. Fin del proyecto: Cuando todas las funcionalidades ha sido cubiertas y una vez el cliente est contento, se dan por finalizados los ciclos de los que consta el proyecto de desarrollo y como resultado de esto obtenemos un nuevo sistema que se ajusta fielmente a la realidad y a la funcionalidad requerida por el cliente.

Roles de la metodologa XP Cliente: Escribe historias de usuario para generar el cdigo. Encargado de pruebas: Su tarea es la de ayudar al cliente a crear las historias de usuario y la de probar cada iteracin. Encargado de seguimiento: Se encarga de gestionar la calidad de la historia de usuario que se est trabajando. Entrenador: Es el experto en metodologas de desarrollo. Es el que gua al equipo y le ayuda a seguir la metodologa de manera correcta. Consultor: Ayuda ocasionalmente en algunos temas. Gestor: Coordina la comunicacin y cooperacin entre el cliente y los programadores. Programador: Es quien crea el software

En el desarrollo de la prctica no hubo tantos roles, figuras como la del consultor o la del gestor no fueron utilizadas. Bsicamente se redujeron a programadores y un cliente, que tambin haca de encargado de pruebas.

2. Juego de simulacin
2.1 Rol de desarrollador
La funcin de un desarrollador durante el transcurso la actividad consiste en la asignacin de tiempo y dificultad para cada historia. Es imprescindible una buena comprensin de las historias a la hora de evaluar estos parmetros. Una vez evaluados, son entregados al cliente y este debe decidir el orden de realizacin de las historias. El papel del desarrollador ahora consiste en la implementacin de las historias dentro del plazo pensado y bajo la supervisin del cliente. Las mayores dificultades que hemos tenido han sido valorar que tareas debamos realizar en el tiempo estimado. Para ello, valoramos su dificultad, tiempo requerido en su realizacin y por ltimo el coste. Antes de realizar cada prueba, se debata el procedimiento que debamos seguir. Una vez elegido el mtodo por todos los miembros del grupo, se asignaban las distintas funciones a cada miembro dependiendo de la tarea. En todas las tareas se ha consultado al cliente para adecuar el trabajo a lo solicitado por el mismo, de manera que el resultado se ajuste lo mayor posible. A la hora de realizar las historias, en general han ido bien y el resultado era lo solicitado por el cliente salvo en dos. En la historia de realizar aviones y inflar los globos con el dimetro preciso. Por mal entendimiento entre ambos, quizs el resultado a la hora de presentar los aviones al cliente no eran vlidos al no estar correctamente acabado. Por ltimo, en la historia de los globos ajustarse al dimetro pedido nos result muy costoso al tratar de atarlos con el clip. Siempre haba una perdida de aire, por lo que adems de la perdida de tiempo en atarlos su dimetro variaba con el paso del tiempo. En general las estimaciones previstas en un principio han sido bastante correctas. Nos hemos guiado por la experiencia personal a la hora de asignar las distintas puntuaciones a cada tarea. La puntuacin ha sido elegida en consenso de los miembros del grupo. A la hora de decidir las puntuaciones hay dos historias que nos parecieron las ms difciles realizar las 40 sumas en el menor tiempo posible y realizar el castillo de cartas. El castillo de cartas fue desestimado el primero, los motivos fueron el tiempo requerido y su alta dificultad. Tal vez no se puede considerar como prueba, pero si es cierto que en las historias de encontrar las cartas faltantes se hicieron algunos ensayos sobre la forma de repartirlas con el propsito de encontrar la ms eficaz. La velocidad de desarrollo de las pruebas aunque no de manera exacta se ha aproximado mucho a las previsiones hechas en un primer momento. Una vez se haba completado la primera iteracin, la segunda fue ms fcil al tener ya la experiencia con las historias y conocer sus ventajas e inconvenientes. Es lgico que en la primera fuera peor en comparacin. En ningn momento se han abandonado las pruebas previstas. Nos hemos ajustado a lo planeado en principio e incluso hemos incluido alguna ms. Una estimacin incorrecta de la velocidad de desarrollo de la prueba puede afectar a la planificacin total. Si se valora una actividad considerando la velocidad de desarrollo inferior a lo que en realidad se necesita, producir un atraso en el tiempo estimado. Por lo que el tiempo total restante ser inferior y es posible que no podamos acabar alguna tarea de las planificadas en principio. De manera contraria, si se valora una actividad considerando la velocidad de desarrollo superior a lo que en realidad se necesita, el tiempo restante podr ser utilizado posteriormente en otra prueba distinta.

Los puntos de esfuerzo han variado en algunas historias al replantear de nuevo su dificultad, una vez terminada la primera iteracin. A modo de conclusin, una vez hemos terminado la simulacin somos conscientes de como una buena planificacin de tareas puede afectar completamente al resultado. Tener claras nuestras limitaciones es fundamental a la hora de decidir a qu tareas enfocarnos.

2.2 Rol de cliente

El cliente da las historias y una vez establecida la complejidad de ellas, elige las tareas en funcin del valor de negocio y del tiempo. A la hora de actuar como clientes, lo ms difcil fue hacernos pasar por ellos en s, ya que al ser tambin desarrolladores, barramos un poco para casa y seleccionbamos las historias pensando excesivamente en el desarrollador. El problema principal fue a la hora de comparar las historias. Comparando el valor de negocio y los costes. En realidad esto no fue ningn problema extra ya que el cliente siempre debe de hacer esta tarea, pero, como se menciona anteriormente, al reunir todos los papeles en una misma persona esta tarea se dificulta. Fue difcil, porque haba algunas historias que no sabamos cuanto tiempo bamos a tardar en hacerlas y tuvimos que ir intuyendo el tiempo empleado en funcin de lo bien que se nos dieran las actividades. A la hora de elegir las historias primero las ordenamos segn su valor de negocio. El siguiente paso fue escoger las historias que menos tiempo nos costaban en cada valor de negocio repitiendo aquellas con el valor de negocio ms alto. Finalmente, las ordenamos todas de mayor valor de negocio a menor. Como clientes, no nos sentimos satisfechos cuando algo no puede salir respecto a lo planificado. A su vez, reflexionamos sobre los hechos para la prxima vez que tengamos que planificar algo con el equipo.

2.3 Rol de coach (aquellos que hayan sido coach)

Cmo ha sido la experiencia de controlar a un equipo? La comunicacin ha sido efectiva o el equipo se centraba en sus tareas y no planteaba sus dudas antes de estimar una historia? Se podran mejorar los resultados obtenidos por vuestro equipo de alguna forma? Cmo?

2.4 La figura del coach

Dentro de las caractersticas que debe tener un Coach tenemos: El lder del equipo - toma las decisiones importantes Principal responsable del proceso Tiende a estar en un segundo plano a medida que el equipo madura Es responsable del proceso global. Es necesario que conozca a fondo el proceso XP para proveer guas a los miembros del equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente.

Esta figura es necesaria ya que se encarga guiar al equipo hacia una correcta finalizacin del proyecto. Sin ella, internamente en el equipo habra demasiado caos.

El coach interfiere en cierto grado en el desarrollo del proyecto. Acta como filtro y toma decisiones sobre lo correcto y lo incorrecto del proceso. Acta como jefe coordinando y poniendo orden sobre los dems integrantes. Una figura necesaria. Se encarga de dar como correcta una fase del proyecto.

3. Conclusiones
Una vez hemos finalizado la simulacin podemos sacar algunas conclusiones del desarrollo de la misma: - La distribucin de los valores de dificultad y tiempo son fundamentales para su posterior evaluacin. Por ello, cuanto ms precisos seamos menor sern los errores cometidos y las dudas sobre la eleccin de las pruebas. - Ante cualquier duda es mejor preguntar al cliente antes de desarrollar la actividad. De esa manera, no se desperdiciar el tiempo de los desarrolladores y por tanto no afectar negativamente al tiempo de la planificacin. - Podremos ser buenos a la hora de valorar las actividades pero nunca totalmente precisos. Por tanto, siempre habrn errores o imprevistos que afectarn a su desarrollo. Se debe tener en cuenta un margen de error. - Se debera elegir un lder de grupo. Lo primero para ayudar en la toma de decisiones de manera decisiva (si hace falta) y tambin como interlocutor entre el equipo de desarrolladores y cliente.

Daniel Lpez Paterna Pedro Lpez Jimnez Jorge Torregrosa Lloret ngel Gonzlez Redondo