Juego UL: experiencias

Otros resultados del juego

Grupo de implantación agile de Teracode La consigna fué "una letra, unos garabatos e incrementar el contador". Se trata de personas muy en el tema, asi que no me sorprende la poca variación. Cinco personas.

---

Comedor Teracode A6

Comedor de Teracode Dos rondas simultáneas con tarjetas A5 y A6 con 14 y 18 participantes respectivamente. Algunas personas participaron de ambas rondas. Los dos tamaños se utilizaron para medir si el espacio extra estimulaba el movimiento, pero lamentablemente los ejercicios no eran equivalentes, ya que el A5 tenia figuras fácilmente reconocibles que como se puede apreciar tardaron más en romperse. En cambio, A6 fué una fiesta. La consigna fue "una letra, unos garabatos,  una figura geométrica e incrementar el contador". Me resulta interesante en el caso de A5 que la rotura de la nube con el rayo comenzó en la persona 15 (la catorce es la que tiene el rayo bien marcado), que era la única persona no técnica que participaba.  Supongo que con dos o tres personas mas se convertía en una bota de papá noel.

Comedor Teracode A5

---

Conclusiones

• Diez parece ser un número mímino para garantizar la efectividad del juego.
• Aunque menos espectacular, funciona con cinco.
• Más de veinte es demasiado.
• Dado que es por turnos y lleva tiempo, no está bueno que sea de dedicación exclusiva. 
• Mejor explicarlo y mientras se juega hacer otra actividad.
• O como hicimos en Rosario: en el marco de otro juego donde el grupo se partía en dos, se le dió el juego a la mitad que estaba libre.
• Sin ofender a nadie, jeje, con grupos más calificados, la rotura es menor, considerar eso en relación a la cantidad de jugadores.
• La rotura es mayor y más veloz cuando no hay figuras o símbolos reconocibles.
• La enunciación del significado de las figuras, como es razonable esperar y es el objetivo de este juego, ayuda a conservarlas.

Gracias a Greta Luna por scannear y pegotear las imágenes.
http://www.lanilunatejidos.blogspot.com/
http://gretaluna.blogspot.com/

Juego agile: UL (Ubiquitous Language)

El juego

Se utiliza un block de hojas a5 (una a4 cortada por las mitades) o similar. 
En la primera se dibuja una letra, un número, un símbolo distorsionado y un par de huevadas más, por ejemplo:

 Luego, se le da la consigna al grupo, que consiste en:

• Evite ver el trabajo de las otras personas.
• Reciba el block con la tarjeta dibujada.
• Copie sin calcar la letra y los dibujos.
• Arriba a la derecha hay un número, recuérdelo.
• Al transcribirlo, auméntelo en uno
• Quédese con la tarjeta que recibió.
• Pase su dibujo con el block a la siguiente persona.

Cuando termina la ronda, se retiran los dibujos y se exhiben en orden para mostrar los resultados.

Es extremadamente importante recalcar y repetir muchas veces durante el transcurso del juego "la letra y los dibujos" ya que es la esencia del juego. A mi me resulta simple, quizas por ser programador, pero mi experiencia es que hay que explicar el juego varias veces, paciencia. Si alguien prueba este juego y encuentra una manera mejor de expresar el procedimiento, avíseme, por favor. De todos modos insisto en insistir "letra vs dibujo".


Es importante no mencionar el nombre completo del juego, para que los que conocen DDD no estén alertados.


Resultados


Se muestra que de existir un acuerdo acerca del significado de los dibujos, se distorsionan menos al comunicarlos. Dependiendo de los resultados, se puede mostrar la convergencia hacia conceptos.


Orígenes

Es basicamente el famoso teléfono descompuesto, pero para mi fue una relación retrospectiva, ya que, aunque sin duda ese juego forma parte del humus de mi mente, no llegué desde ahi. Estaba de colaborador ad-honorem de computación en fiuba, que es una introducción a la programación para estudiantes de ingeniería no informática, cuando pensé en como transmitirles la diferencia entre digital y analógico, como un mensaje digital se puede reconstruir pese al ruido y como el analógico se degrada irreversiblemente.

Descripción


La clave del asunto es que aunque son varias entidades, a la primera la identificamos como letra, de modo tal que quien hace la copia reconoce la letra y la transcribe como tal. El segundo, como es un número, es reconocido por algunos como tal pero otros no, asi que puede distorsionarse o no. El resto de los garabatos muere instantáneamente, no hay manera de que llegue al final de la ronda.

El objetivo es mostrar como el tener código común, en este caso el determinar que el primer dibujo es una letra, permite que los mensajes se distorsionen menos. Un punto para el "ubiquitous language" de Evans,  de ahi el nombre "UL".



Experiencia Computación FIUBA 2009

El objetivo en este caso era mostrar como la información analógica, el dibujo, se degrada irremediablemente en cada paso, mientras la digital, al tener una referencia se puede corregir indefinidamente. Esto es sin considerar ruidos mayores, para los cuales están los códigos autocorrectores y toda la lata.

Antes hice una prueba con cinco integrantes en mi trabajo, en la Secretaría de Educación del GCBA pero como eran todos programadores, sólo me aportó la demostración de que funcionaba.

En clase tuve que hacer dos rondas, ya que la consigna no fue comprendida y cada integrante pasó el original en lugar de su copia, asi que se redujo a unos ocho participantes pues ya me habia quedado sin tiempo. Esto me permitió percibir que hay que explicar muchas veces la consigna y de paso aprovechar en recalcar letra/dibujo.


Fue interesante que la letra "A" se convirtió en "a", en el resto no hubo sorpresas.

Experiencia Agile Open Rosario 2011

Lo presenté en sociedad agile en este evento con los resultados esperados y más.


Lo probé en dos grupos, de diez y quince integrantes, con una A, en 1, un signo + con una linea redondeada cerrando en tercer cuadrante, una tormenta en un plato arriba de una espiral y el contador arriba a la derecha encerrado en un círculo. Ah, justo lo que hay en la imagen más arriba, es que estoy escribiendo en orden distinto al que estás viendo.


La letra sobrevivió intacta. El número en un caso desapareció, impresionante. De los restantes, el + se convirtió en una gama y en una jota, la espiral en una G y el otro no recuerdo, perdón, no me llevé las tarjetas para scannearlas. ¿Se vé como sigue activo el juego? Me parece que en un grupo desapareció y en el otro se pegó al contador. En un caso el contador perdió el círculo.


Me resultó muy interesante como los dibujos se convirtieron en símbolos y una vez ahi se estabilizaron. Con más concurrentes, con dos seguidos que no conocieran la letra gama, seguro se hubiera distorsionado tambien.

Otro fenómeno fue que en un caso la hoja fue rotada y luego corregida.




Gracias a Christian Badenas por sus aportes a este texto.



Como siempre, es open source, pero si los lleva a la fama y el dinero, dejen caer sus migajas...



// Se podrá ver la versión profesional en http://tastycupcakes.org/ cuando junte ganas de adaptarlo a su formato

[offtopic] Exam Oriented Programming

Al tratar de comprender algoritmos de compresión para rendir exitosamente un examen, me he hallado ante una encrucijada:

Hacer todo en papel a manito: sin duda es lo mejor para un examen, pero cuesta mucho saber si lo que uno hizo funciona correctamente.

Implementar: bárbaro, asi sabemos si funciona o no, pero es inaplicable para un examen, ya que no se pueden ver los estados intermedios con representación humana. Uh, ¿que dije?

Supongamos AABBAA en LzHuff, que para el examen es "A(0)B(0)E(0)eof", que luego se traduce a asc("A") + 00b + asc("B") + 00b + asc("E") + 00b + 257d, todo esto pasado por dos árboles de huffman, claro. Termina en algo tipo 3FADD023.


La implementación en ningún momento me muestra algo asi. Además tengo que resolver un montón de problemas que no me sirven para el examen, ya que para este sólo necesito un "programa mental", mucho menos riguroso que el de la computadora.


La solución se halla en el medio y consiste en implementar un programa que haga lo que necesitamos para el examen, o sea que tome AABBAA y emita "A(0)B(0)E(0)eof" , en lugar de 3FADD023.  "A(0)B(0)E(0)eof" pasado por los árboles de Huffman es otro programa mental, que lo necesitamos de todos modos para el punto de compresión Huffman. Luego, la conversión a la representación hexadecimal es otro programa mental, que es trivial.

Ahora bien, para que esto no sea tan offtopic, podemos implementar ese programa con TDD. Comenzamos con:

void CompressorTest::testCompress_A(){
 string reference="A'0eof";
 MockedFileReader* in = new MockedFileReader("A");
 MockedFileWriter* out = new MockedFileWriter();
 Compressor *c = new Compressor(6,2,5);
 c->compress(in, out);
 CPPUNIT_ASSERT_EQUAL(reference, out->get());

 delete in;
 delete out;
 delete c;
} 

Luego con

void CompressorTest::testCompress_ABE(){
 string reference="A'0B'0E'0eof";
 ...
 CPPUNIT_ASSERT_EQUAL(reference, out->get());
 ...
} 

y asi... la buena práctica de TDD, elemento fundamental de la programación segura, es tambien útil para el estudio (malabares para no abrir otro blog con el tema de esta entrada)