Anlisis y Especificacin de Sistemas Multimedia

Memoria Prctica 2:
Simulacin XP

Carles Escriv Cant Rubn Dur Esquembre Antonio Mudarra Martnez Jorge Lilao Chinchilla #AESMcooking

1. Introduccin.
La programacin extrema o eXtreme Programming (XP) es una de las metodologas mas destacadas de los procesos giles. La programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad. Se considera que los cambios de requisitos en la marcha es un aspecto natural e inevitable. Creen que es mejor adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto que intentar definirlos al comienzo del proyecto. La programacin extrema es un conjunto de las mejores metodologas de desarrollo para llevar a cabo un proyecto. Los Valores principales de la programacin extrema son: Simplicidad. La simplicidad es la base de la programacin extrema. Se simplifica el diseo para agilizar el desarrollo y facilitar el mantenimiento. Comunicacin. La comunicacin se realiza de diferentes formas. En la parte de los programadores cuanto ms sencillo sea el cdigo mejor. La comunicacin con el cliente debe ser habitual y sencilla ya que el cliente forma parte del proyecto. El cliente es el que decide las caractersticas que tienen prioridad. Retroalimentacin. Al estar el cliente implicado en el proyecto, puede ir viendo el resultado de los ciclos y as opinar sobre como est y como lo quiere, esto hace que no se pierda tiempo cambiando cosas debido a un error en la comunicacin con el cliente. El cdigo tambin es una fuente de retroalimentacin gracias a las herramientas de desarrollo. Coraje o valenta. El programador debe ser valiente a la hora de programar. Debe ser valiente a la hora de desechar un cdigo por estar obsoleta, reconstruir su cdigo y en ser persistente con los problemas. Respeto. Los miembros del proyecto tiene que respetar a los compaeros y a su trabajo realizado. As aumentar la buena relacin entre los miembros y aumentar el ritmo de produccin.

Las caractersticas fundamentales del mtodo son: Desarrollo iterativo e incremental. Pequeas mejoras, unas tras otras. Pruebas unitarias continuas. De manera frecuente y automatizadas. Es aconsejable escribir el cdigo de la prueba unitaria antes de la codificacin Programacin por parejas. Las tareas de desarrollo se deben llevar a cabo por dos personas en un mismo puesto. Dos personas piensan ms que una y adems puede ir comentando el cdigo y viendo posibles errores. Fuerte relacin del equipo de programacin con el cliente. Si no es posible que est el cliente lo har un representante de este para que est con el equipo. Correccin de los errores antes de aadir una nueva funcin. Se deben hacer entregas de manera frecuente. Rescritura del cdigo. Se debe rescribir el cdigo para aumentar su legibilidad sin modificar su comportamiento.

Cdigo compartido. El cdigo tiene que ser compartido con todos los miembros de equipo, aunque no pertenezcan al mismo tipo de trabajo. As se conseguir que cualquiera pueda aadir o mejorar las funciones. Simplicidad. El cdigo debe ser simple y sencillo, es la mejor manera de ver si un cdigo funciona.

Historias de usuario Release planning Iteraciones

Planificacin
Velocidad proyecto Programacin en pareja

XP
Diseo

Simples Glosario Riesgos Extras Tarjetas CRC

Reuniones diarias

(extreme programming)

Codificacin

Pruebas

Tests

Grfico. Proceso eXtreme Programming

2. Juego de simulacin. 2.1. Rol de desarrollador.

Al comenzar con el papel de desarrolladores tenamos que comprobar todos los materiales del juego, lemos todas las historias y nos informamos sobre todo el proceso y requerimientos. Comprendidas todas las historias y teniendo claros todos los objetivos, procedimos a ordenar las historias por sencillez y marcamos una estimacin aproximada. Llegados a este punto, el objetivo era el establecer cuantos puntos podramos hacer en una iteracin, siento en este caso 180 segundos. Desde un principio y teniendo en cuenta que no sabamos exactamente nuestras capacidades reales a la hora de hacer las actividades que nos ha propuesto el coach las dificultades a priori no han sido sino de preparacin y conocimiento de nuestras posibilidades. Claramente nos hemos sobrevalorado y aunque hemos conseguido el objetivo propuesto, ha sido con muchos problemas y dificultades. Una cosa que hemos planteado bien ha sido la distribucin del trabajo y el cmo nos compenetrbamos para integrar el trabajo individual de cada uno en un bloque compacto que sera el trabajo final o historia acabada, una vez mas los problemas han llegado de parte de miembros del grupo que no estaban claras sus aptitudes. Claramente esta velocidad a la hora de organizarnos ha venido de la mano de la decisin comn de tomar entre todos todas las decisiones dando lugar a un entendimiento y familiaridad a la hora de trabajar entre nosotros. Antes de comenzar el desarrollo e incluso durante todas las iteraciones hemos estado hablando con el coach sobre las especificaciones y requerimientos del desarrollo y ello ha facilitado y agilizado todo el proceso, aun as las estimaciones no han sido todo lo precisas que tendran que haber sido. Para ordenar las historias nos hemos dejado guiar por nuestra intuicin y mediante una puesta en comn han quedado rpidamente ordenadas. Los puntos a asignar ha sido relativamente sencillo, aun sin tener claro completamente todas las historias el tenerlas ordenadas por dificultad ha hecho que la reparticin de puntos fuera automtica. Antes de proseguir, hay que remarcar que la distribucin de puntos si bien ha sido sencilla, no ha reflejado correctamente el verdadero coste que nos ha supuesto el hacer la historia. Quizs habra sido ms productivo hacer una prueba de todas las historias antes de asignar los puntos. En nuestro caso, y aun a sabiendas que acabamos todas las historias de manera correcta y dentro del tiempo establecido, s que pecamos, como ya he dicho, de una sobrestimacin de nuestras capacidades. Gracias a ciertas historias que logramos hacer en menor tiempo del propuesto y ello compens alguna historia que habamos considerado mucho ms fcil y result ser dura y pesada, y ms trabajando bajo presin. Por supuesto en la segunda iteracin corregimos el coste en puntos de ciertas historias y logramos planificar ms correctamente el tiempo y las historias a realizar. Aun a pesar de esta correccin posterior el tiempo sigui pisndonos los talones. Todo ello nos ha dejado una sensacin bastante agobiante. Hemos aprendido a predecir el tiempo que vamos a necesitar para realizar diversas tareas. Pareca ms fcil de lo que al final fue.

2.2.

Rol de cliente

El cliente es el encargado de escribir las historias de usuario y las pruebas funcionales para validar su implementacin. Tambin es aquel que asigna la prioridad a las historias de usuario una vez hayan sido valoradas por los desarrolladores, y decide cules se implementan en cada iteracin centrndose en aportar el mximo valor al negocio. No ha sido demasiado fcil ser el cliente, no somos nosotros los que vamos a trabajar, pero si es complicado establecer el orden o la prioridad a las diferentes historias de usuario. El principal problema fue establecer ese orden en las diferentes tareas. Porque no es fcil establecer un valor de negocio a algo que an no est desarrollado. Si nos fue fcil hacer ese planning. Si los desarrolladores consiguen dar una velocidad estimada bastante coherente a la que despus ser en realidad, es mucho ms fcil para los clientes establecer un orden real y as mejorar nuestro producto. Hemos decidido realizar primero las historias de mayor ratio de valor de negocio/puntos de esfuerzo, para ser ms equilibrados. Porque si escogemos primero la de mayor valor de negocio pero cuesta mucho esfuerzo realizar, a la larga, no nos saldr rentable. As que establecimos un equilibrio entre el valor de negocio y el esfuerzo para los desarrolladores. Si algo que has planeado no se va a llevar a cabo, el cliente se siente bastante frustrado y si para el cliente es bastante importante, probablemente suspenda el proyecto y los desarrolladores se queden sin tareas a realizar, buscndonos as otros desarrolladores capaces de realizarlo.

2.4. La figura del coach

El coach es la figura responsable del proceso en general, de forma global lo controla todo. Es aquel que guiar a los miembros del equipo de desarrolladores para seguir el proceso correctamente. Intentar evitar cualquier confusin en las tareas a realizar por los desarrolladores. Es muy necesaria la figura del coach, porque nos gua durante todo el proceso. Es un pieza fundamental en un proyecto para que salga todo correctamente y conforme se ha establecido en un principio. Pensamos que el coach no debe intervenir en nuestro trabajo. Es una figura de apoyo y gua para conseguir de una forma ms eficaz nuestros objetivos. Debe servirnos siempre de ayuda en nuestras decisiones y no aquel que las tome. El coach ni acta como jefe, dado que no lo es, y tampoco nos da una libertad total para hacer lo que nosotros queramos. Hay un cierto equilibrio entre ambas posturas. Actuar como segundo jefe para darnos alguna informacin sobre algo y nos parar cuando no lo estemos haciendo bien. Pero tambin nos da una pequea libertad para hacer nosotros las tareas de la mejor forma que creamos.

3. Conclusiones
Hemos podido observar que cuando intentas preveer la duracin de algn proceso si no conoces bien a tu equipo sueles equivocarte. Mantener una comunicacin con los dems miembros es necesaria para poder ajustarte al tiempo especificado. Tambin es muy importante mantener la comunicacin con el cliente ya que as puedes estar a tiempo de rectificar errores por algn tipo de confusin. Al cliente no suele importarle lo que cuesta desarrollar un proceso y si mantienes una comunicacin con l, podrs elegir mejor los procesos sabiendo el coste de estos por parte de los programadores.

Desconocamos esta tcnica y con la prctica nos ha quedado todo bastante claro, no hay mejor forma de aprender algo que practicando. Sacamos varios puntos positivos de aqu, entre los que podemos destacar el saber trabajar en equipo y el saber prever el tiempo estimado en la realizacin de nuestro trabajo. Siempre el trabajar en equipo trae algunos problemas, pero si tu equipo es bueno, siempre conseguirs objetivos ms ambiciosos, varias cabezas piensan mejor que una sola. Nos sorprendi la prctica, pero podemos afirmar que nos ha servido de aprendizaje, pasndolo relativamente bien y aprendiendo, no hay mejor forma de hacerlo.