Documentos de Académico
Documentos de Profesional
Documentos de Cultura
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.
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