Simulacion XP

Simulación XP

La programación extrema o eXtreme Programming (XP) es una metodología que se centra en potenciar las relaciones entre los diferentes miembros del equipo de desarrollo y los clientes del software a desarrollar.

Gracias a estas relaciones se mantiene una retroalimentación continua en todo momento, siendo esta la clave para el éxito del proyecto.

Esta metodología es idónea para proyectos con requisitos imprecisos y que a medida que pasa el tiempo varían.

El ciclo de vida ideal de esta metodología consiste en 6 fases estas son:

1. Exploración.
2. Planificación de la entrega.
3. Iteraciones.
4. Producción.
5. Mantenimiento.
6. Muerte del proyecto.

En la clase de practicas realizamos una simulación de todo el proceso, incluyendo todos los roles que componen la metodología, esto nos ayudo a entender de manera mas clara su funcionamiento, y a continuación detallaremos nuestra experiencia con cada uno de estos roles.

Juego

 Cliente (Profesora)

- Nos proporciona las historias

 Desarrolladores: (15 minutos)

- Estimamos la complejidad

- Estimamos el tiempo

- Ordenamos

 Clientes (5 minutos)

- Seleccionamos las historias con la mejor relación entre la complejidad y el valor de negocio.

- Apuntamos en la tabla de puntuación el número de las historias y las estimaciones realizadas como desarrolladores.

 Desarrolladores (3 minutos)

- Realizamos las historias escogidas en la anterior fase

Rol realizado como Desarrolladores

- Se han requerido algunas especificaciones por parte del Coach en algunas historias para su correcto desarrollo. Han surgido algunos imprevistos en algunas pruebas que no podíamos haber previsto como la fuga de un globo, excediendo el tiempo de dicha prueba que se había estimado. El resto de pruebas se han ensayado previamente.

- Dependiendo de la historia, la planificación de cada tarea ha variado en cuanto a la participación de todos los miembros (Globos) o la subdivisión de las tareas (Cartas), también hemos planificado el entorno de trabajo para optimizar el desarrollo de las tareas.

- Las decisiones tomadas respecto a la realización de cada tarea provenían de un miembro que tomaba la iniciativa, éste iba cambiando dependiendo de la naturaleza de la tarea, junto con el resto del grupo se perfilaba la idea, intentando conseguir un desarrollo óptimo.

- Una especificación incompleta en una de las historias (Aviones) por parte del Coach, nos llevó a repetir dicha tarea dado el incorrecto resultado, ya que los aviones resultantes no eran exactamente igual que el prototipo.

- Los puntos asignados a cada historia han sido asignados en base a su duración temporal, las tareas de similar trabajo y duración eran agrupadas en un mismo nivel de complejidad.

• - La historia de construir casas de diversas plantas con cartas, se descartaron directamente debido a su grado de dificultad y el tiempo que requería, ya que el mínimo fallo en la construcción podría llevarnos a empezar la construcción de nuevo.

- Los puntos de esfuerzo estimados y obtenidos son los siguientes, en la primera estimación se ha tardado más de lo previsto por eso la velocidad es menor de la esperada, mientras que en la segunda iteración hemos sido más rápidos de lo previsto.

	Puntos de Esfuerzo Estimados	Puntos de Esfuerzo Resultantes
Iteración 1	36	15,7
Iteración 2	18	45

• Si se infravaloran los puntos de esfuerzo, el tiempo de desarrollo real será menor que el previsto por lo que el tiempo restante se puede dedicar para perfilar o mejorar el producto, mientras que si sobrevaloramos los puntos de esfuerzo, la planificación se quedará corta y no cumpliremos con los plazos previstos. Es recomendable establecer un margen de error en la mayoría de las tareas, para poder solventar los problemas que puedan surgir y ajustarse mejor a una planificación real.

Primera Iteracion:

Segunda Iteracion:

Rol realizado como Cliente

         -El cliente escribe las historias de usuario y las pruebas para validar su implementación. Les da una prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio.

        - Actuar como cliente no ha llevado muchas complicaciones, aunque no ha sido tan sencillo como parecía al principio. Hemos tenido varios problemas a la hora de realizar las historias ya que los tiempos estimados por los desarrolladores eran muy optimistas.

         -Desarrollar un planning a partir de los datos de los desarrolladores no ha sido una tarea muy difícil, lo único difícil ha sido adaptarse a los tiempos de los desarrolladores.

        - A la hora de desarrollar la planificación de las historias se pusieron al principio las de menor esfuerzo, y dentro de el mismo nivel de esfuerzo se les dio preferencia a las de mayor valor de negocio. Ésto se planificó de esta forma porque se marcó como objetivo el hacer el mayor número de historias posibles, ya que pensamos que si una prueba de alto valor de negocio tenia una dificultad moderada, igual no merecía la pena arriesgar perder mas tiempo del establecido por ella, sino dejarla para el final y ver si daba tiempo una vez hechas el resto.

         - Como clientes, la planificación que hicimos fue un poco conservadora, y nos sobró algo de tiempo en las dos iteraciones que efectuamos. De todas maneras, en el caso de no haber podido cumplir alguna de las historias nos habríamos sentido algo estafados, ya que se podría haber planificado de forma distinta si los desarroladores hubieran dado valores mas exactos.

       

La figura del Coach

          -El coach es responsable del proceso global. Experto en XP, guía e informa a los miembros del equipo para que se apliquen las historias(pruebas) y se siga el proceso correctamente. Determina la tecnología y metodologías a usar por el equipo de desarrollo.

          - La figura del coach es necesaria, es muy útil tener a un experto que te explique las historias y la metodología a usar ya que te facilita el trabajo.

           -El coach informa y supervisa que todo se haga correctamente, pero sin opinar ni ayudar a la hora de realizar la planificación. Además una vez se ha determinado la tecnología y metodología a seguir, actúa más como un árbitro que supervisa que todo se haga correctamente.

Conclusion 

          - XP es una metodología de programación muy ágil, útil para pequeños o medianos equipos a la hora de desarrollar software que posea requerimientos muy ambiguos o que cambien rápidamente. - En cuanto a la programación con grandes equipos o con requerimientos estáticos, no es muy útil, ya que los tiempos son muy inexactos y pueden provocar retrasos en la planificación del desarrollo del proyecto o inlcuso que se planifique mas tiempo del necesario y hayan desbarajustes a lo largo del desarrollo del software.

-Carlos Ferrando Galiana  

-Vicente Ferrandez Lopez 

-Lionel Giro Lopez