Lo que aprendimos con The Marshmallow Challenge
Buenas a todos tras estas largas vacaciones, para quien las haya tenido, que no es mi caso :-) pero ya llegarán, aunque el blog si que ha estado de vacaciones, no lo puedo negar. He estado retirado en la montaña (dígase la zona de relax de la oficina) buscando la inspiración y ... bueno no ha llegado tampoco, pero se hará lo que se pueda ;-)
En la reunión realizada en Julio por el grupo Agile Canarias, mi compañero Gregorio Mena y yo quisimos darle un nuevo enfoque y propusimos la realización de algún juego que demostrase algún fundamento relacionado con el agilismo. La verdad es que no hubo ninguna duda, y desde el primer momento que vimos la página de Tom Wujec acerca de The Marshmallow Challenge sabíamos que esta era la opción adecuada, un juego divertido y con unas lecciones asombrosas.
La verdad es que no hay nada mejor que revisar la documentación propuesta por Tom Wujec para entenderlo todo, pero haré un breve resumen antes de pasar a las conclusiones que obtuvimos en el grupo. Bien, el juego es muy sencillo, a cada equipo compuesto como mínimo por dos personas (aunque lo ideal es que sean grupos de 4 como mínimo), se le entrega el siguiente material.
Vaya, ¿y qué tiene que ver esto con el agilismo o con construir software? Pues nada de nada y todo a la vez, tanto en las transparencias de Tom Wujec como en nuestra propia experiencia pudimos observar muchos aspectos interesantes.
La importancia del prototipado y reducción de la incertidumbre.
Gregorio y yo ya habíamos leído el material del Sr. Wujec y creíamos que mucha gente pasaría gran parte del tiempo diseñando y luego empezaría a construir, pero nos equivocábamos. Todos los asistentes eran en realidad de aspecto técnico por lo que prefirieron empezar a construir y hacer pruebas, lo cual está muy bien, ¿por qué? Pues porque ninguno de ellos era arquitecto, ingeniero de estructuras o similar, no tenían conocimientos previos sobre diseño de estructuras o reparto de cargas, por lo que haciendo estas pruebas reducían la incertidumbre del problema y tenían más posibilidades de llegar a una solución, aunque en el siguiente punto veremos otro aspecto importante que había que tener en cuenta.
En el desarrollo de software la reducción de la incertidumbre es fundamental, mucha gente se dedica a estar un año haciendo documentos de word y diagramas UML, pero a la hora de la verdad la incertidumbre de cara a la construcción no se ha reducido, lo que en el futuro generalmente hace que el proyecto se retrase porque empiezan a aparecer los problemas que no se vieron al principio. Es mejor que el análisis y el desarrollo vayan de la mano y sean fases que se solapen y no en el estilo clásico en cascada, por lo menos es mi opinión.
Hay que conocer el objetivo real del proyecto.
Vaya, ¿pero el objetivo no era construir la estructura más alta posible? Si y no, en realidad si analizamos el enunciado correctamente, el objetivo es situar la nube lo más lejos de la base posible y esto lo cambia todo. Los participantes de Agile Canarias hicieron un gran trabajo pero tan solo al final empezaron a hacer pruebas colocando la nube en lo alto de la estructura ¿sabéis que pasó? pues si, muchas estructuras no resistieron el peso.
Esto tiene mucho que ver con el desarrollo iterativo, es mejor ir construyendo una solución completa desde el principio e ir añadiendo mejoras que construir las piezas por separado y después unirlas. Volvemos al mismo problema del punto anterior, si no sabemos como trabajan las piezas juntas seguimos teniendo una incertidumbre del 100% y eso se debe evitar.
Los equipos multidisciplinares funcionan mejor.
Por desgracia nosotros no pudimos comprobar este punto porque todos los asistentes eran técnicos, pero para todo el que este leyendo este blog seguro que sabe que hay que encontrar el equilibrio entre la gestión y la parte técnica. Construir software de calidad es mucho más complicado que esta torre de spaghettis y sin las personas apropiadas con los conocimientos apropiados de cada una de ellas, se hace más complicado.
Existen otras conclusiones por parte de Tom Wujec, pero esas os las dejo a vosotros porque es mejor oírlas expuestas por él en su vídeo :-) el tío es un crack presentando las ideas.
Mis propias conclusiones.
Ya se que lo que voy a decir a continuación es trivial y todo el mundo lo sabe, pero por si acaso lo voy a decir igualmente. Con el paso del tiempo los equipos empezaban a tener levantadas sus estructuras (o no, depende del caso :-) y como es obvio unos se fijaban en los otros. Cuando empezaron a quedar pocos minutos algunos grupos añadían más spaghettis para que su torre fuese más alta que la de los contrarios, pero en muchos casos resultó en una caída de la estructura. Cual es la moraleja, pues que habían equipos que podían haber tenido por ejemplo la segunda o tercera estructura más alta pero la competitividad y la presión del tiempo hicieron que no tuvieran una solución. Volvamos, ¿y qué quiero decir con esto?, pues que para el cliente, incluso en momentos de presión, siempre será mejor tener una solución que un montón de líneas de código y documentos que no hacen nada o que hacen cosas que no solucionan su problema.
Antes de terminar, dar las gracias a todas las personas que hacen posible Agile Canarias y que pasemos estos momentos tan divertidos, espero que os haya gustado el artículo y sino pues podéis insultarme y esas cosas en los comentarios :-P
En la reunión realizada en Julio por el grupo Agile Canarias, mi compañero Gregorio Mena y yo quisimos darle un nuevo enfoque y propusimos la realización de algún juego que demostrase algún fundamento relacionado con el agilismo. La verdad es que no hubo ninguna duda, y desde el primer momento que vimos la página de Tom Wujec acerca de The Marshmallow Challenge sabíamos que esta era la opción adecuada, un juego divertido y con unas lecciones asombrosas.
La verdad es que no hay nada mejor que revisar la documentación propuesta por Tom Wujec para entenderlo todo, pero haré un breve resumen antes de pasar a las conclusiones que obtuvimos en el grupo. Bien, el juego es muy sencillo, a cada equipo compuesto como mínimo por dos personas (aunque lo ideal es que sean grupos de 4 como mínimo), se le entrega el siguiente material.
- 20 spaghettis
- 1 yarda de cinta aislante (optamos al final por 1 metro)
- 1 yarda de cordel (también usamos 1 metro)
- 1 marshmallow (aquí en España es mejor optar por una nube de azucar)
Vaya, ¿y qué tiene que ver esto con el agilismo o con construir software? Pues nada de nada y todo a la vez, tanto en las transparencias de Tom Wujec como en nuestra propia experiencia pudimos observar muchos aspectos interesantes.
La importancia del prototipado y reducción de la incertidumbre.
Gregorio y yo ya habíamos leído el material del Sr. Wujec y creíamos que mucha gente pasaría gran parte del tiempo diseñando y luego empezaría a construir, pero nos equivocábamos. Todos los asistentes eran en realidad de aspecto técnico por lo que prefirieron empezar a construir y hacer pruebas, lo cual está muy bien, ¿por qué? Pues porque ninguno de ellos era arquitecto, ingeniero de estructuras o similar, no tenían conocimientos previos sobre diseño de estructuras o reparto de cargas, por lo que haciendo estas pruebas reducían la incertidumbre del problema y tenían más posibilidades de llegar a una solución, aunque en el siguiente punto veremos otro aspecto importante que había que tener en cuenta.
 |
| Los chicos AvanTIC pensando en el problema |
En el desarrollo de software la reducción de la incertidumbre es fundamental, mucha gente se dedica a estar un año haciendo documentos de word y diagramas UML, pero a la hora de la verdad la incertidumbre de cara a la construcción no se ha reducido, lo que en el futuro generalmente hace que el proyecto se retrase porque empiezan a aparecer los problemas que no se vieron al principio. Es mejor que el análisis y el desarrollo vayan de la mano y sean fases que se solapen y no en el estilo clásico en cascada, por lo menos es mi opinión.
 | ||
| Carlos Blé y Dani Latorre manos a la obra |
 |
| Estos chicos tienen futuro, paso a paso |
Hay que conocer el objetivo real del proyecto.
Vaya, ¿pero el objetivo no era construir la estructura más alta posible? Si y no, en realidad si analizamos el enunciado correctamente, el objetivo es situar la nube lo más lejos de la base posible y esto lo cambia todo. Los participantes de Agile Canarias hicieron un gran trabajo pero tan solo al final empezaron a hacer pruebas colocando la nube en lo alto de la estructura ¿sabéis que pasó? pues si, muchas estructuras no resistieron el peso.
 |
| Ubay y Yurena empiezan a dar nivel :-) |
Esto tiene mucho que ver con el desarrollo iterativo, es mejor ir construyendo una solución completa desde el principio e ir añadiendo mejoras que construir las piezas por separado y después unirlas. Volvemos al mismo problema del punto anterior, si no sabemos como trabajan las piezas juntas seguimos teniendo una incertidumbre del 100% y eso se debe evitar.
 |
| IM-PRESIONANTE |
Los equipos multidisciplinares funcionan mejor.
Por desgracia nosotros no pudimos comprobar este punto porque todos los asistentes eran técnicos, pero para todo el que este leyendo este blog seguro que sabe que hay que encontrar el equilibrio entre la gestión y la parte técnica. Construir software de calidad es mucho más complicado que esta torre de spaghettis y sin las personas apropiadas con los conocimientos apropiados de cada una de ellas, se hace más complicado.
Existen otras conclusiones por parte de Tom Wujec, pero esas os las dejo a vosotros porque es mejor oírlas expuestas por él en su vídeo :-) el tío es un crack presentando las ideas.
Mis propias conclusiones.
Ya se que lo que voy a decir a continuación es trivial y todo el mundo lo sabe, pero por si acaso lo voy a decir igualmente. Con el paso del tiempo los equipos empezaban a tener levantadas sus estructuras (o no, depende del caso :-) y como es obvio unos se fijaban en los otros. Cuando empezaron a quedar pocos minutos algunos grupos añadían más spaghettis para que su torre fuese más alta que la de los contrarios, pero en muchos casos resultó en una caída de la estructura. Cual es la moraleja, pues que habían equipos que podían haber tenido por ejemplo la segunda o tercera estructura más alta pero la competitividad y la presión del tiempo hicieron que no tuvieran una solución. Volvamos, ¿y qué quiero decir con esto?, pues que para el cliente, incluso en momentos de presión, siempre será mejor tener una solución que un montón de líneas de código y documentos que no hacen nada o que hacen cosas que no solucionan su problema.
Antes de terminar, dar las gracias a todas las personas que hacen posible Agile Canarias y que pasemos estos momentos tan divertidos, espero que os haya gustado el artículo y sino pues podéis insultarme y esas cosas en los comentarios :-P
Comentarios