SIMULACRO DE EXTREME PROGRAMING

Team Berry Javier Sánchez Riquelme Carlos Meca López Carlos Sanchís Server Álvaro Yuste Torregrosa

1. Introducción
La eXtreme Programming (XP) es una filosofía del desarrollo del software basada en la comunicación entre desarrolladores y clientes. Consiste en un conjunto de prácticas que a lo largo de los años han demostrado ser las mejores prácticas de desarrollo de software, llevadas al extremo, fundamentadas en un conjunto de valores. Estas prácticas son: – – – – – – – – – – – – Desarrollo guiado por pruebas. Planificación. Participación total del cliente. Programación por parejas. Interacción continua. Refactoración o reestructuración del código. Ciclos de trabajo cortos. Diseño simple. Propiedad colectiva del código. Metáforas del sistema, una historia compartida simple de cómo el sistema trabaja. Convenciones del código. Paso sostenible, es decir, limitar las horas de trabajo semanales.

La Programación Extrema fue un proyecto que empezó en 1996, sugerido por Kent Beck, como una manera arriesgada de desarrollo de software. Funcionó, y ahora es una de las más importantes dentro del grupo de las metodologías ágiles. Los objetivos de XP son muy simples: la satisfacción del cliente. Esta metodología trata de dar al cliente el software que él necesita y cuando lo necesita. Por tanto, debemos responder muy rápido a las necesidades del cliente, incluso cuando los cambios sean al final de ciclo de la programación. El segundo objetivo es potenciar al máximo el trabajo en grupo. Tanto los jefes de proyecto, los clientes y desarrolladores, son parte del equipo y están involucrados en el desarrollo del software.

2.1. Rol del Desarrollador:
Nuestras obligaciones se basan en ponderar cada historia con un nivel de dificultad y estimar en segundos el tiempo que el equipo tardaría en llevarla a cabo. Una vez realizadas estas tareas, el cliente planifica qué historias y en qué orden se desarrollarán en la iteración. Una vez que esta se inicia nuestro papel pasa a ser implementarlas en el menor tiempo posible y con la corrección que el cliente exigió ya que, finalmente, éste realiza unos test de aceptación para dar el visto bueno a cada uno de los productos finales que se entregan de cada historia en cada una de las etapas de la iteración. En general, como conclusión de la experiencia, hemos extraído, por un lado, la dificultad que esconde el, aparentemente sencillo, rol de predecir el tiempo que se utilizará para completar cualquier tarea. Sobre todo en la primera iteración, ha habido desajustes, por no tener en cuenta los imprevistos posibles, pensando que todo saldría según lo deseable. También es cierto que tanto los ensayos previos como las aclaraciones del cliente (coach) nos ayudaron en gran medida a acotar la predicción. Aún así, por falta de concentración a causa del limitado tiempo disponible, ha habido resultados que no se adecuaban al 100% a las expectativas del coach, pero se han corregido, con su correspondiente suplemento temporal, en la misma iteración.

A la hora de ponderar las historias con su tiempo, nos poníamos en común e intentábamos figurar lo que tardaríamos, sin seguir una estrategia concreta. Y para asignarle dificultad tampoco nos ceñimos a un procedimiento fijado, lo hicimos siempre con respecto al tiempo que nos llevaría realizarla. Hemos encontrado pruebas que hubieran sido imposibles de cumplir en el tiempo de una iteración, como por ejemplo el castillo de cartas de 4 pisos, y las supimos identificar a tiempo. De esta manera, ninguna historia planificada por el cliente tuvo que ser rechazada a posteriori. Sí que es cierto que a veces nos hemos visto apurados con el tiempo, por haber sobreestimado nuestra velocidad, aunque se ha visto corregido por otras veces en las que quizás la infravaloramos. En general hemos aprendido a tener en cuenta los riesgos y contrastar todas las variables para realizar una predicción correcta. A comunicarnos con el cliente y saber extraerle datos concretos que se deberían tener en cuenta en el desarrollo. Y a subsanar los errores que pudieran trastocar la continuidad de una iteración.

2.2 . El Rol del Cliente:
Descripción de las obligaciones del cliente: Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Asigna la 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 el cliente ha sido fácil para ti? No ha sido difícil, el único problema radica en la dificultad de elegir correctamente el orden de las historias que van a ser implementadas para maximizar el valor de negocio.

¿Qué problemas habéis tenido? Nos sobró tiempo al acabar de implementar todas las historias que habíamos acordado previamente, aunque realizamos algunas extras en ese tiempo.

¿Ha sido fácil hacer un planning a partir de la velocidad estimada por los desarrolladores? No, es más, diría que la mayor dificultad de esta metodología es esto mismo. Creo que el limite entre que falte tiempo y que sobre es muy pequeño, y para maximizar el valor de negocio hay que minimizar el tiempo sobrante. Con un equipo pequeño en el que todo el mundo se conozca, y conozca la forma de trabajar de los compañeros el tiempo sobrante debería de ser mínimo.

¿Cómo habéis decidido qué historias hacer primero? ¿Las de mayor valor de negocio? ¿Las de mayor ratio valor de negocio/puntos de esfuerzo? ¿Las de menor esfuerzo? ¿Por qué? Las de mayor ratio valor negocio/puntos de esfuerzo, pero siempre fijándonos en que su dificultad no fuera elevada, ya que, en mi opinión es mejor hacer 5 bien que 2 mal, siempre y cuando esas 5 sumen lo mismo o mas que las otras 2.

Como clientes, ¿cómo os sentís cuando os dicen que algo que habíais planificado no se va a llevar a cabo? Decepcionados por el hecho de ser una historia a descartar pero es una posibilidad que se tiene que contemplar desde un principio, aunque lo normal es que se realice la mayor cantidad de historias que se proponen.

2.3 . El Rol del Coach:
¿Cómo ha sido la experiencia de controlar a un equipo? Ha sido interesante aunque es un tanto agobiante la responsabilidad de saber que si al explicar algo al comienzo del proceso esto no se entiende o se hace erróneamente será por culpa del coordinador. El intentar resolver las dudas del equipo era un trabajo muy importante y debía de hacerse correctamente. El mantener la comunicación entre los miembros del equipo es una de las cosas más difíciles, el conseguir la atención de todos es complicado y más conseguir que comprendan las pautas a seguir. Ha sido una buena experiencia pero es algo que debería estar a mano de los expertos en el medio de trabajo, no de coordinadores espontáneos.

-

-

¿La comunicación ha sido efectiva o el equipo se centraba en sus tareas y no planteaba sus dudas antes de estimar una historia? En este caso el equipo planteaba sus preguntas y mostraba algo de desconfianza en el coach, quizás por falta de contacto con él. Como poco las dudas principales se manifestaron y hubo que resolverlas. La comunicación entre ellos fue efectiva se compenetraron con rapidez y atendieron fielmente las indicaciones que se les dio.

-

¿Se podrían mejorar los resultados obtenidos por vuestro equipo de alguna manera? ¿Cómo? Se podrían haber mejorado si hubiésemos tenido algo más de tiempo en la explicación o si hubiesen podido entablar un mayor contacto con los elementos de las pruebas. El coach podría haber estado mejor enterado (en este caso yo) y podría haber tenido más tiempo para organizarse y establecer el orden en el que explicar el proyecto.

-

Se podrían haber evaluado las habilidades de los sujetos que forman el equipo para establecer que ejercicios eran más ajustados a estas y por lo tanto hacerlos era una opción mejor.

2.4. La figura del coach
La figura del coach realiza los siguientes roles: Visionario, para formular y comunicar una visión de la meta que los desarrolladores deben alcanzar con su trabajo, incluyendo la planificación de todas y cada una de las tareas que van a realizarse. Elemento de cohesión entre los integrantes del grupo de desarrolladores. Actúa de esta manera como una especie de líder, por tanto debe apoyar y motivar al resto del equipo. Elige entre diferentes metodologías cuales pueden ser óptimas para la programación del producto, las comunica y las adapta a los desarrolladores. El coach debe esforzarse en las necesidades del cliente, equipo o conflictos de personalidad, nuevas tecnologías y la más reciente sabiduría sobre la XP y otros métodos ágiles. Mentor, ya que debe también asegurar que el aprendizaje continuo sucede regularmente. Y puede requerir un poco de valor no cancelar una reunión de un grupo de estudio encarando una fecha de entrega próxima.

-

-

-

-

El coach, además, debe estar aprendiendo continuamente, tanto dentro como fuera del desarrollo proyecto, y aplicando estos conocimientos a futuros trabajos. El coach es un elemento más, y por tanto necesario, de la eXtreme Programming. Sus tareas de apoyo y coordinación son realmente importantes dentro de esta mecánica para evitar que el equipo se atasque y poder garantizar que el plazo de entrega del producto que estamos desarrollando pueda cubrirse sin percances. Es muy importante que no surjan problemas entre los integrantes del equipo de desarrollo, y el coach está ahí para mediar en ellos y evitarlos. También el hecho de que facilite el proceso utilizando su conocimiento en la materia para encaminar las tareas y aportar material útil para los programadores. Por estas razones antes mencionadas deducimos que la tarea del coach no es interferir en el trabajo, puesto que podría verse obstaculizado. Más bien es un apoyo a la hora de tomar decisiones en caso de duda o discrepancia dentro del equipo, un mediador, un árbitro.

El coach, por otro lado, tampoco debe verse como una especie de jefe o una persona a la que hay que rendir cuentas. La principal característica del eXtreme Programming es que todos sus miembros valen lo mismo, y ninguno está por encima del otro en el equipo, por lo que ver al coach como un jefe ya es un concepto erróneo que choca con la descripción del método. Es mucho más acertado verlo como los letreros de dirección que hay en el camino, que es el desarrollo del software, para llegar al destino, es decir, el software totalmente terminado. Por tanto el coach deja a los desarrolladores trabajar según su criterio, sin poner pegas, y sólo dirigiendo cuando se le solicita o dando su opinión o sugiriendo maneras de hacer las cosas en algunos casos, pero nunca interfiriendo en el trabajo del equipo.

3. Conclusiones:
Las conclusiones que hemos obtenido del desarrollo de esta simulación y del desarrollo de este informe son las siguientes: El papel del coach debe ser ejercido por una persona instruida en el plan de desarrollo y con conocimientos firmes en relación al proyecto que se va a llevar a cabo. El equipo debe comprender las órdenes e indicaciones del coach y preguntar todo lo que se necesite o cualquier duda de planteamiento a este. El cliente debe estar presente durante todo el desarrollo del proyecto, exponiendo sus necesidades a lo largo del proceso, junto a sus preferencias y algunas indicaciones que ayudan a que en caso de haber cambios en el proyecto sean más fáciles de solventar, además habrá de realizar pruebas para comprobar el correcto funcionamiento del pedido. La comunicación debe ser constante y abierta entre los miembros del equipo. Todos deben escuchar las sugerencias de los demás y valorarlas como propias. Debe existir una fase de análisis donde separar los problemas y seleccionar el orden en que se van a solucionar y en qué medida importa su solución.

-

-

-

-

Esta metodología es óptima para proyectos abiertos a cambios en las especificaciones y formados por equipos de trabajo medianamente reducidos. Ya que a gran escala no se podrá mantener una correcta comunicación.

Sign up to vote on this title
UsefulNot useful