Diferencia entre revisiones de «Juegos Agiles»

Revisión del 18:28 16 mar 2009

Jugar es una de las mejores formas de transmitir conceptos. Aprender jugando es la mejor manera de fijar conocimientos y técnicas, ya que estimulan las capacidades kinestésicas de los participantes. Las cosas que se aprenden "haciendo" perduran por mucho más tiempo en la memoria de los participantes, les permite explorar y conocer más a fondo los conceptos nuevos y, además, se pasa un rato muy divertido.

A continuación veremos una serie de diversos juegos que ayudan a enseñar distintos aspectos referidos a prácticas y conceptos del Desarrollo Agil De Software. Estos juegos apuntan a facilitar la adopción de los conceptos ágiles, de una manera interactiva y divertida.

Los juegos

Había una vez...

Lo aprendí de Tobias Mayer. El objetivo del juego es armar y contar una historia entre todos los participantes. La cantidad de participantes puede variar, aunque mientras más personas, mejor. Al menos se necesitarían 4 personas para jugarlo; con 20 o más funciona realmente bien.

La consigna es contar una historia sobre cualquier tema: puede ser una experiencia personal, algo ficticio, fantasioso o lo que salga. La consiga es utilizar la siguiente plantilla: Había una vez... y todos los días... hasta que un día... y por eso... y por eso... y por eso... (repetir cuántas veces se quiera) hasta que finalmente... y desde entonces...

Para empezar el juego, armar una ronda entre todos los participantes, de forma que todos puedan verse la cara y nadie quede "oculto". Mostrar en algún afiche o pizarra la plantilla de la historia, y pedirle a alguna personan que cuente a voz alta una historia completa, en forma individual y sin ayuda de nadie. No importa la historia, sino el esfuerzo que en general le tienen que poner para que surja algo. Repetir estas "historias individuales" con otras personas.

Luego, repetir el juego, pero esta vez se creará una "historia colectiva": cada persona será responsable de decir sólamente una línea de la plantilla. Nadie tiene el control de la historia, ya que cada persona sólo puede decir una línea.

Después de una vuelta, destacar el hecho de mirar a los ojos a la persona que continua la historia, y que la persona que escucha también preste atención ("las palabras que nos dirigen son un regalo que la persona nos hace, tratémoslo como tal"). Repetir la historia colectiva un par de vueltas.

El juego permite sacar varias conclusiones y temas para debatir:

• diseño emergente
• el poder de la simpleza por sobre lo "inteligente y complejo"* la suma de ideas permite generar algo nuevo e inesperado
• cómo elaborar y crecer a partir de las ideas de otros
• el tomar pequeños pasos para seguir avanzando, sin preocuparse tanto por el resultado general (muy útil cuando alguien se encuentra "trabado" sin saber para dónde avanzar)
• la colaboración como forma de trabajo
• el animarse a tomar riesgos (seguramente varios van a tener "miedo" al principio de hablar, por miedo a hacer el ridículo)

Spaghetti

Lo aprendí de Tobias Mayer. El objetivo del juego es mostrar la dinámica de equipos auto-gestionados. La cantidad de participantes directos es de 8-10 personas, y el resto de las personas juega como analistas o líderes.

Para comenzar el juego se elijen 8-10 personas para que se tomen de las manos (ambas manos) como para armar una ronda eventualmente (es decir, mano derecha de una persona tomando la mano izquierda de otra, y así), pero de manera cruzada y mezclada, de forma que quede un "spaghetti" de personas. Se siente raro e incómodo. Los otros participantes actuan como analistas y líderes. Se ofrece una visión de un círculo abierto, donde todos estén cómodos. Se agrega la restricción de que para llegar a este estado no se deben soltar de las manos.

El juego procede en 3 etapas:

1. Se le pide a los analistas que escriban una especificación: un grupo de pasos que el equipo debe seguir para resolver el problema. Los analistas no pueden tocar ni mover al "spaghetti", quienes permanecen inmóviles. Para armar la especificación tienen 4 minutos. Al finalizar seguramente apenás tendrán uno o dos pasos a seguir, instrucciones obviamente insuficientes para armar la ronda.
2. Se le pide a los líderes que le den instrucciones a cada miembro del equipo, sin tocarlos, quien sólo se moverá si se lo indican. Cada miembro del spaghetti debe recibir instrucciones específicas y precisas para moverse, sino deberá permanecer quieto. Los miembros que no reciban instrucciones no deben moverse. Es posible que tarden 2 minutos para resolver el spaghetti y logren armar la ronda.
3. Por último se vuelve a armar un nuevo spaghetti de personas, pero esta vez se le pide al equipo que resuelva el problema por si mismo. El resto de los analistas y líderes esta vez se transforman en observadores pasivos. Aquí es donde se ve la conclusión del juego; lo que pasa a continuación es un ejemplo casi de libro sobre la auto-gestión: ocurre un comportamiento colaborativo, emergente y el problema se resuelve rápidamente. Se pueden sacar paralelos con análisis de requerimientos incompletos, micro-gestión vs. auto-gestión y más.

Triángulos equiláteros

Lo aprendí de Tobias Mayer. El objetivo del juego es armar triángulos equilateros entre todos los participantes.

Es un ejercicio muy rápido y dinámico que sirve como introducción a una sesión. La cantidad de participantes puede variar, pero mientras más personas mejor (con más de 20 personas puede ser muy divertido).

Los participantes se ubican en una ronda, y se les pide que elijan mentalmente a otros dos participantes. Esta elección la hace cada participante, de forma secreta de forma que sólo él la conoce. Luego, los participantes empiezan a moverse para crear un triángulo equilátero entre ellos mismos y los dos participantes que elijieron... y todos están haciendo esto a la vez! Es un juego caótico, desordenado y frustrante... hasta que comienzan a encontrar una forma de resolverlo.

La conclusión es abierta. Nunca se sabe qué dirección va a tomar el juego, pero durante la retrospectiva la mayoría de los participantes encuentra algunos paralelos ágiles. Es un buen juego para anclar con los medios de comunicación, mostrando que la comunicación verbal no siempre es la más apropiada.

Pelotas aéreas

Este es un juego de Boris Gloger. El objetivo del juego es tratar de que el equipo pase la mayor cantidad de pelotas posibles en una iteración de 2 minutos. La cantidad de participantes puede ser de 20 a 50 personas (mientras más, mejor!).

Se comienza juntando a todo el grupo y se explican las reglas del juego. Se le entregarán pelotas al equipo (del tamaño de pelotitas de tenis), las cuales las deberán "procesar" entre ellos, pasándoselas unos a otros, hasta finalizar en la misma persona que tuvo la pelota al principio. Se dejan en claro también las siguientes reglas:

• todos juegan como un único gran equipo
• todas las pelotas tienen que tener "tiempo de aire"
• no se puede pasar una pelota a un vecino "directo" (a la izquierda o derecha)
• el punto de inicio es el punto de fin
• todos los participantes tienen que haber tocado la pelota al menos una vez
• la iteración es de 2 minutos
• hay 1 minuto de retrospectiva entre iteraciones
• se juegan 5 iteraciones

Antes de comenzar, pedirle al equipo que de un estimado de cuántas pelotas creen poder pasar en 2 minutos. Al finalizar cada iteración, ver qué ocurrió. Preguntarle al equipo:

• ¿qué ocurrió?
• ¿qué fue lo mejor de la iteración?
• ¿sintieron que se logró ritmo y Fluir?

Hay muchas conclusiones de este juego. Durante el juego se deben recalcar:

• concepto de "inspeccionar y avanzar", de Scrum
• un sistema tiene una velocidad natural, la cual se alcanza rompiendo las barreras (o sea, los impedimentos)
• se logra un flujo constante (Fluir) sólo si: el desafío es realizable, no se molesta a las personas durante la ejecución, el trabajo tiene sentido.

Garabato del proceso

El objetivo del juego es tener una visión general del proceso de desarrollo del equipo.

Dividir a los participantes en grupos. Darles una hoja grande y marcadores, y pedirles que representen gráficamente el proceso de desarrollo actual. Hacerlos pensar en roles, artefactos generados, desafios. Invitarlos a ser creativos y a no preocuparse por usar ninguna notación formal (UML, Gantt, RUP, etc.). Pedirle que no usen nombres de personas en el diagrama, ni que hagan críticas personales.

Cada equipo tiene 20 minutos para realizar su dibujo, y luego presentan su creación al resto del grupo.

Este ejercicio es una forma divertida para que el facilitador puede ver en qué trabaja el equipo y qué desafios enfrentan en el proceso de desarrollo de la organización. Además, el ejercicio crea más transparencia dentro del equipo, ya que todos pueden ver lo que otros piensan del proceso, y cómo lo entienden.

Finalización: tranquilizarse

Lo aprendí de Tobias Mayer. Formando una ronda, hacer que el grupo cierre los ojos, esté en silencio y simplemente respire por un minuto, sintiendo la presencia del resto del grupo. Luego, pedirle al grupo que comience a contar hasta 10, como grupo. Cualquiera puede empezar, en cualquier momento. Alguien dice "uno", luego alguien más dice "dos", y así. Si dos personas hablan a la vez, el grupo tiene que empezar otra vez desde "uno". Este es un ejercicio que fomenta las capacidades auditivas, la empatía y el respeto; en una forma agradable y tranquila para terminar una sesión. No necesita ninguna explicación o resumen, con esto se puede despedir al grupo.

Ver también

• Desarrollo Agil De Software
• Tasty Cupcakes - Juegos ágiles (en inglés)
• The Ball Point Game
• Team building activities