Archivo de la etiqueta: Agile

Precaución: el trabajo en equipo puede perjudicar al equipo

Estamos en una época de revolución de los métodos de trabajo. Se está demostrando que un equipo motivado, autoorganizado y con visión de producto es capaz de dar valor al cliente de forma rápida mientras aprende lo que va necesitando. Hemos aprendido a trabajar en equipo, colaborar, estimar en equipo, planificar en equipo…  Prácticas como el mob-programming en las que un grupo de desarrolladores trabajan en un mismo código con un mismo teclado están creando tendencia. Estamos abriendo las oficinas, quitando muros y juntando mesas para que haya comunicación entre todos los miembros, para que se vean y se oigan fácilmente y la comunicación osmótica fluya.

Sin embargo, todo esto tiene un límite. Estudios recientes están demostrando que la colaboración puede llegar a ser excesiva cuando impide conseguir los objetivos personales de los miembros del equipo. Actividades de colaboración (reuniones, responder preguntas, hacer coaching a un compañero, conectar por escritorio remoto para ayudar a un colega, etc …) puede llegar a suponer más del 50% del tiempo disponible de trabajo.

Además, se está demostrando que alrededor del 25-30% del valor añadido en estas colaboraciones es aportado por solamente el 3 ó 5% de los miembros. Son estas personas que están continuamente en reuniones o resolviendo preguntas. Su experiencia les ha convertido en personas indispensables a la hora de tomar cualquier decisión. Y esto desde cierto punto de vista está bien pero se acaba generando un círculo vicioso que hace que cada vez estas personas sean más indispensables y tengan menos tiempo para su trabajo personal.

Igualmente también nuestros adorados espacios abiertos se están convirtiendo en un problema. El ruido de conversaciones, notificaciones de los teléfonos móviles, sonidos de teclado pueden llegar a anular totalmente la capacidad de concentrarse en el trabajo. Según la comunicación osmótica es importante el valor añadido que puede dar una idea tuya que das por haber oído una conversación cercana o lo que puedes aprender de esa conversación. Pero estos hechos muchas veces son tan aislados que no compensa la falta de productividad que genera el no poder entrar en flujo por culpa del ruido ambiental.

La respuesta está en ser generoso  hacia el equipo con el tiempo personal pero también darle un gran valor. Cosas que se pueden hacer:

  • Saber decir que NO.
  • Priorizar las peticiones de ayuda (informativas, persuasivas y de tiempo).
  • Obligarse a tomar tiempo de concentración (pomodoros) con los auriculares puestos para evitar interrupciones.
  • Gestionar bien las reuniones. JGI
  • Gestionar correctamente el email y los sistemas de mensajería interna.

 

Fuentes

https://hbr.org/2016/01/collaborative-overload

http://time.com/money/4160139/collaboration-teamwork-lower-productivity/

https://hbr.org/2015/12/muting-unwanted-noise-in-an-open-office

Antipatrón, midiendo el esfuerzo

<ironic>

Es muy dificil encontrar una métrica que evalúe el rendimiento de los miembros del equipo por separado. Cualquier libro moderno de gestión de personas recomienda evaluar al equipo globalmente pero nosotros, los buenos jefes de equipo, tenemos que recompensar a los que se están dejando el pellejo y localizar a los que no tienen suficiente compromiso con el proyecto.

Una cosa que hacemos bien en España, y por eso somos de los países más competitivos, es nuestra orientación al esfuerzo. Si no dedicamos mil horas diarias a algo y nos dejamos hasta la ultima gota de energía de nuestro cuerpo, un trabajo no está bien hecho. Otros países “más modernos” prefieren buscar formas de hacer el trabajo más comodamente… ¡Nenazas!

El esfuerzo es algo muy dificil de medir. Lamentablemente, las leyes de privacidad nos impiden usar electrocardiogramas en los trabajadores. Con ellas podríamos obtener de manera muy fiable el ritmo de trabajo de cada uno.

Afortunadamente hay otras formas más legales:

Medidor de sudor. Es una sencilla banda adhesiva que se pone en la frente de los trabajadores. Esta banda tiene un pequeño chip y un emisor bluetooth. La banda obtiene el nivel de sudoración en tiempo real y lo envía al servidor central. Cada día los trabajadores tienen que cambiar la banda adhesiva ya que queda (debería quedar) llena de sudor. Es importante tener consumibles  disponibles para que no haya trabajador sin banda. El único problema es que  cada persona sudora de manera distinta y el dispositivo es difícil de calibrar.

Medidor de sudor
Medidor de sudor

Dinamómetro de nalgas. Este es el más fiable  Es un sencillo dispositivo que se coloca entre las nalgas de cada trabajador. Mide la presión ejercida durante el trabajo por su parte trasera y se envía igualmente por bluetooth. A más presión recibida, mayor esfuerzo es el que está efectuando el trabajador. El dinamómetro es personal y cada trabajador debe ser responsable de su limpieza diaria.

Dinamometro de nalgas
Dinamometro de nalgas

Los datos recibidos del esfuerzo son monitorizados en tiempo real. De este modo, nosotros como jefes podemos alentar o castigar a esos trabajadores que no tienen los valores esperados. Se puede definir un máximo y mínimo para que el sistema genere una alarma en tiempo real. Todos los valores son almacenados por un servidor y pueden servir para una recompensa en retribución variable o ascensos. Igualmente, si los datos no son buenos, si por ejemplo no ha ocurrido ninguna presión de nalgas en un mes, con estos datos se dispone de una herramienta objetiva para un despido.

Naturalmente usando este sistema hay que evitar cualquier cambio que suponga una reducción en el esfuerzo. Iría en contra de nuestra política de recompensar el esfuerzo. Las metodologías ágiles son totalmente contraproducentes ya que se ha demostrado que su uso continuado puede bajar el nivel de esfuerzo global. Hay que evitarlas a toda costa.

</ironic>

Los tres primeros pasos en la gestión Ágil/Lean

Cuando uno empieza a querer organizar su forma de trabajar quizá lo que aporta Internet es demasiada información. Hace falta saber qué buscar para conseguir lo que necesitas para empezar a cambiar. Después de todos los años que llevo estudiando y aplicando las metodologías ágiles lo que aconsejo siempre es empezar con 3 sencillas cosas. El ABC de la gestión Agil.

1.- Daily Standup. Reuniones de máximo 15 minutos con los miembros del equipo en posición de pie en la cual cada uno comparte en qué trabajo el día anterior, en qué va a trabajar y qué obstáculos o problemas tiene en su camino.

Consejos:

  • No debe ser un informe al jefe. La información es de todos para todos
  • Debe empezar lo antes posible para que de pistoletazo al día pero que este presente el máximo número de personas
  • Si se abre un tema que necesite discusión larga se deja para después del daily.
  • Gente fuera del equipo puede hacer participaciones cortas que ayuden a algún problema. Lo fundamental es no pasarse de los 15 minutos.

2.- Tablero kanban. Panel en el cual hay una columna por fase por la que pasa cada elemento de trabajo representadas por etiquetas. Estos elementos pueden ser historias de usuario, diseños que hay que hacer, máquinas que montar, arreglar, etc.. Cada mes se limpian las etiquetas completadas en la última fase. Cada miembro del equipo mueve la etiqueta de una columna a otra según se va completando. Permite una visión común de cómo va el trabajo y permite tomar decisiones de mejora y de eliminar los bloqueos.

Consejos

  • Ponerlo en un lugar visible y accesible para todos
  • No debe haber más de 20 etiquetas por equipo para que se pueda ver de modo más sencillo
  • Debería haber límites máximo por columna aunque sean altos a principio. Si llega un momento en el que se supera ese límite debería analizarse la causa del problema y mejorar.
  • Ir bajando ese límite máximo según se va mejorando para conseguir un sistema más lineal y eficiente.

3.- Retrospectivas. Reunión a final de mes en cual se junta el equipo para ver qué han hecho bien y qué pueden mejorar. Se puede usar el método del barco  para además identificar las minas, es decir, los elementos externos que os afectan como equipo y para las que tenéis que estar preparados. No debería durar más de una hora u hora y media.

Consejos:

  • Sinceridad pero sin buscar culpables. Algo mal hecho es porque no se tenía conocimientos o herramientas para hacerlo mejor. Esta reunión sirve para buscar estas cosas.
  • Los problemas encontrados deberían buscarse soluciones. Asignar responsables para trabajar en ellas.
  • Se puede usar para dar pequeñas formaciones que ayuden al equipo. Club de lectura, vídeos de Internet, etc..

Con estas tres herramientas cualquier equipo puede empezar a trabajar mejor y de forma más organizada. Es posible que se vean nuevos problemas y se piense que antes no estaban, pero seguramente sea porque antes no se veían. Surgirán problemas que estaban ocultos y que ahora salen a la luz. Permitirá que surjan nuevas necesidades para ir mejorando cada vez más vuestro método de trabajo. Es posible que necesitéis nuevas herramientas para cubrir esas necesidades pero estas tres herramientas básicas os acompañarán día tras día.

Conseguir el ISO y el CMMI3 sin dejar de ser Ágiles, interesante reto

Este año en VSN nos hemos propuesto a pasar la certificación ISO para poder optar a proyectos en que lo requieren. Estamos con la ayuda de un consultor que nos va diciendo lo que tenemos que hacer.

De momento lo que vamos haciendo consiste en documentar todos nuestros procesos internos. No parece más que dejar bien por escrito todo lo que hacemos de manera corporativa. En desarrollo es concreto me toca escribir cómo manejamos los requerimientos en sprints, cómo hacemos seguimiento mediante los dailys y el Diagrama de Flujo Acumulado, como aseguramos la calidad mediante los tests automáticos y manuales. Como hemos ido escribiendo todo lo que ibamos estandarizando en las retrospetivas tenemos bastante escrito.  Sobre todo parece que hay que tener manual de todo lo que se desarrolle. No puede salir un desarrollo nuevo sin un escrito en el que se dice qué y cómo funciona. Yo espero que lo que escribimos como procedimiento de test para que otro desarrollador lo pruebe sea suficiente documentación.

Aparte del ISO se nos recomienda tener una certificación concreta de software. Yo estoy seguro que podemos optar a un CMMI 3 también con el modo ágil en el que trabajamos. De momento me toca ir empollando bien qué piden y si nos falta algo más que gestionar. Cuento con que mejoremos sin dejar de ser ágiles. Veremos si en lo que escribí a mediados de 2009 tenía razón.

Iré contando los avances…

¿Está TDD muerto? Resumen del videodebate

Mientras hacen subtitulos para el Hangout entre David Heinemeier Hansson, Kent Beck y Martin Fowler, voy a escribir un poco lo que han hablado para que los que no entiendan el inglés, o no tienen los 30 minutos para verlo entero, puedan quedarse con las claves. En mi anterior artículo hablo de los artículos y tweets que empezaron la discusión.

El link al video es éste.

Empieza David hablando de los 3 problemas que ve al TDD: la insistencia en que los tests tienen que correr en milisegundos, que termina creando un diseño feo y complejo y que el bucle de rojo-verde-refactor es poco natural para el programador.

Kent cuenta que el TDD le da la confianza que necesita a la hora de dar un desarrollo por completado y funcionando. Sin TDD, uno se va a casa sin la seguridad de que el código que ha escrito funcione bien. Además le ayuda a pensar primero en el problema. Cuando no se tienen especificaciones concretas TDD sirve para empezar de lo más concreto (ejemplos en los tests) a la implementación más genérica.

David entiende en que Kent piense en la seguridad como un factor de felicidad del programador. Él mismo dice que le da prioridad a la felicidad del programador cuando empezó Ruby on Rails. Sin embargo, la seguridad de que todo va a funcionar es sólo un factor de felicidad del programador pero hay otros. El tener que cambiar el flujo de pensamiento a pensar primero el test antes de empezar lo ve como una forma de confundir al programador y no dejarle crear del modo que le es más natural. Además dice que la seguridad de que el código funciona no debería venir unicamente del TDD

Ante un ejemplo reciente de Kent sobre un uso idoneo del TDD, David responde que en los desarrollos que él hace no es normal tener un código tan aislado como el que Kent comenta. Que para poder conseguir un codigo perfecto testeable típico de un input consigue un output tiene que separar capas y capas y crear muchos mocks. Que tiene que hacer un gran sacrificio para conseguir ese código perfecto para TDD.

Kent afirma que en todo esto tiene que haber un balance. Hay que tener en cuenta el coste de aislarlo todo para testearlo de manera independiente y su beneficio. Que no hace falta hacer mocks de todo. Si tienes unos tests de objetos que usan otros objetos reales o un sistema real y se es capaz de tener así la prueba de si va o no va, es suficiente. Cuenta que mucha gente se queja de que el Unit Test no le deja refactorizar. Esto ocurre porque sus tests complejos que tienen mocks que devuelven mocks y como fruto estos tests están muy acoplados a la implementación.

Segun David, el problema está en la definicion de TDD segun algunos sectores del desarrollo. Estos sectores afirman cosas como que cualquier test tiene que estar basado en mocks y que si no usas TDD no eres buen profesional. Incluso que si el diseño del programa no está dirigido por tests, no es buen diseño. Para David es al contrario, TDD fuerza a tener un diseño no natural.

Martin Fowler, quedandose un poco en medio y actuando un poco como arbitro del debate, también dando su opinión más pragmática. Dice que hay en la calle muchas definiciones de TDD. Algunas de ellas dicen que todo tiene que estar con mocks. Sin embargo la realidad es que si no usa mocks y el test es util, perfecto. Dice que el TDD y el Unit test son dos cosas aisladas y hay que tratarlas como tal. Se puede hacer TDD sin que todo el codigo testeado esté aislado. Para él, como ya dijo en su artículo, lo importante es que el código sea autotesteable, que haya un botón que pueda probar todo el código. TDD está bien porque ofrece esto como uno de sus beneficios.  Está de acuerdo en que en ocasiones no se puede usar TDD, cosa que le apena ya que dice que es una herramienta que le gusta. También opina que incluso hay que separar conceptualmente el Unit testing aislado y el no aislado.

El debate termina barajando un posible futuro debate hablando unicamente de si el TDD crea un buen diseño o no.

 

 

 

To TDD or not to TDD. That is the question

Menuda guerra ha ocurrido esta semana. Cómo decía un compañero, parecía una discusión de Salvame Deluxe pero en el mundo del desarrollo.

Todo empezó cuando David Heinemeier Hansson, padre del Ruby on Rails,  escribió un artículo sobre los problemas de usar TDD. David afirma que hacer TDD no es conveniente, que obliga a separar demasiados intefaces  y que es mejor hacer tests de integración más lentos que de todos modos, con paralelización y test en la nube se pueden hacer muchos a la vez.

Al poco, Bob Martin (Uncle Bob) respondió en su blog que unicamente cuando se aplica TDD se consigue reducir el tiempo de depuración, una documentación unequivoca en los tests y un desacoplamiento entre clases muy valioso por sí mismo. Poco después volvió a escribir explicando un poco más dónde no se puede usar TDD y dónde sí. De este modo respondía a las críticas que suelen surgir sobre la falta de aplicabilidad en algunos entornos.

El propio  Kent Beck, padre del TDD, escribió en facebook un supuesta nota postuma sobre el TDD, echando de menos la técnica y rogando poder encontrar otra que le diera la misma seguridad a la hora de escribir, la misma documentación y enfoque a la hora de escribir.

Personalmente el TDD es una herramienta que vale la pena conocer bien. Entiendo sus dificultades. En más dificil hacerlo bien que cualquier framework, IDE o incluso lenguaje. Requiere que el desarrollador dedique tiempo no a crear, que es lo que más le gusta, sino a poner redes de seguridad a lo que aún no ha empezado a escribir. En VSN no lo hacemos el 100% de las veces. Tenemos “sólo” un 40% de cobertura que nos ofrece ya una gran seguridad a la hora de añadir nuevas funcionalidades o refactorizar. Sin embargo, nada no nos impide intentar tener cada vez más cobertura y usar TDD cada vez en más ocasiones. Como alguien me dijo una vez, si intentas saltar tan alto como para tocar la luna lo más seguro es que nunca lo consigas, pero llegarás muchísimo más alto que si nunca lo hubieses intentado.

Motores, lastres y minas en retrospectivas

¿Cuánto tiempo tardas en ir de casa al trabajo? Normalmente ese tiempo varía un poco cada día. Por ejemplo un día tardas 20 minutos, otro 23, otro 19, 20,… Esa variación de tiempo que ya tienes asumida se llama “Variación de causa común“. Ahora piensa en la última vez que llegaste tarde. Pudo ser por un problema de tráfico, tu hijo estaba enfermo y hubo que llevarlo a casa de la abuela… Esa vez tardaste 40 minutos. Ese tipo de variación se llama “Variación de causa asignable“. Es asignable porque puedes asignarle una razón (o una excusa).

En VSN trabajamos desde hace unos meses  la retrospectiva con la analogía de la lancha. El equipo es una lancha en la que los motores representan aquellas cosas que nos hacen ir rápidos y con calidad.  Los lastres atados son las cosas que nos hacen ir más lentos. Desde hoy tenemos un elemento nuevo. Ahora identificamos también las minas con las que se encuentra esta lancha por el camino. Estas minas representan esos problemas de causa asignable, esos problemas ocasionales que han ocurrido y pueden volver a ocurrir, o no.

20140411_145919_pq

Cuando trabajamos estas retrospectivas, el equipo escribe en los Post-It amarillos los elementos a destacar del sprint: los motores, los lastres y ahora las minas. Una vez están todas las etiquetas en la pizarra las organizamos juntando las comunes y las analizamos. Primero buscamos soluciones para los lastres, después confirmamos que los motores que tenemos siguen siendo útiles y debemos seguir usandolos y por último analizamos las minas para ver cómo actuar cuando nos las volvamos a encontrar.

Primero indicamos la posibilidad de encontrarnosla. Podría ser eventual, esto quiere decir que el problema ha ocurrido y ya está, que es raro que vuelva a ocurrir.Podría ser frecuente, una vez cada sprint o cada pocos sprints. Si es un problema constante lo más normal es que se encuentre en la parte de lastres.  Despues recordamos el efecto que ha causado en el equipo. En qué nos ha afectado. Ha sido una molestia o ha sido un gran trauma. Por último definimos el plan de defensa, qué hacer con la mina la próxima vez que nos la encontremos. Aquí tenemos 3 opciones:

  1. Preparar contramedida para destruir la mina la próxima vez. Se piensa cómo eliminar el riesgo para que no vuelva a afectar lo más mínimo al equipo.
  2. Mitigar el daño cuando ocurra el choque. Podría ser que lo mejor es que cuando el problema ocurra de nuevo estar preparado para que afecte lo menos posible.
  3. Ignorar la mina. Cerrar los ojos, apretar el culo y sencillamente aceptarla tal cual llega. Esto se decide así cuando las consecuencias de tener un plan de acción podrían sobrepasan el efecto de la propia mina.

Los planes que se hacen con las minas las vamos a recoger en un documento accesible por todo el equipo. Cuando en un análisis de sprint, de historia o en algún Daily asome la sospecha de que se nos acerca una mina conocida, sabremos cómo actuar. Con esta sencilla analogía de las minas vamos a tener  lo que se llama en gestión de proyectos tradicional, Gestión de Riesgos. Sin embargo lo hacemos de una manera Ágil. Primero porque lo hace el propio equipo y segundo porque se minimiza el tiempo gestionando este nuevo artefacto respecto a la mejora en el equipo que esperamos que produzca.

El sabor de la buena UX

Los programas de TV de moda van cambiando año tras año. Reality shows, concursos de talento de canto, de baile, de salto en trampolín (sigh!). Ahora estan de moda los concursos de cocina como Master Chef, Top Chef y otros…

Tengo que admitir que a estos últimos sí estoy algo enganchado porque me siento identificado con los concursantes en los momentos en los que los jueces van a probar el plato, lo miran, lo prueban y lo juzgan. Todo lo aprendido por el cocinero antes de esa elaboración junto con la suerte y pericia en el momento de la elaboración se plasman en el plato.

Sé que es la enésima analogía del desarrollo de software, pero me vais a permitir usarla. Voy a analizar las tres partes de un software bien desarrollado.

La receta es la historia de usuario.
Cuando se define la historia de usuario es cuando el cocinero piensa qué va a cocinar. Puede ser lomo de atún, muslos de pollo a la pimienta o pastel de boniato con cintas de chocolate. El cocinero piensa qué es lo que le va a gustar al cliente y pasa a su ejecución. Igualmente un equipo de trabajo se enfrenta con una historia de usuario. La definición de esa historia indica cómo va a dar valor al cliente.

La presentación del plato es la estética del software
Tanto cuando se presenta un plato como cuando el cliente va a usar el software, el producto tiene que entrar por los ojos.  En cocina es muy importante aspectos el corte de los ingredientes, su color, cómo están alineados en el plato,… . En software igualmente hay que prestar atención a las fuentes que se usan, los bordes, los colores, los iconos,… Todo tiene que tener un aspecto cuidado.

Y para terminar…
El sabor es la Experiencia de Usuario, la UX
Aqui es donde el cocinero y el equipo de software más se la juegan. En cocina un plato puede estar bien planificado y con una cuidadisima estética pero pueden pasar cosas como una textura de un ingrediente que no es la que te habías imaginado, como algo que cruje y no debería, una combinación de sabores que no encajan,… Cuando el usuario usa la característica desarrollada pueden sucederle cosas muy parecidas: información que falta y hace que no sepa usarla, tener que hacer muchos clicks, tener que ir abriendo y cerrando interfaces, tener elementos de interfaz muy pequeños o muy grandes,…

Me faltan dos páginas para terminar el libro de Lean UX (mi mente ya no procesaba letra escrita). En breve hablaré un poco cómo se trabajan esos dos aspectos, la estética y la experiencia de usuario. En un equipo Ágil se trabajan de forma completamente distinta y en momentos distintos. Lo veremos.

Algo llamado “Declaración de Interdependencia”

De nuevo en el libro de David J Anderson, descubrí algo llamado “Declaration of Interdependence” DOI. En español, Declaración de Interdependencia. Esto fue una redefinición del manifiesto Agil pero centrado solamente en la gestión de proyectos. Sus autores forman la creme de la creme en gestión de proyectos ágiles con nombres como el propio David J Anderson, Alistar Cockburn o Mike Cohn.

Sus puntos son:

Incrementamos el retorno de la inversión (ROI) centrándonos en un flujo contínuo de valor.
Habla de dar valor al cliente de forma más continua posible. Mejor iteraciones de 2 semanas que de 3. Mejor aportaciones diarias que cada 2 semanas. Lo que necesita de forma más rápida posible desde el momento que lo necesita.

Entregamos resultados fiables haciendo participes a los clientes en interacciones frecuentes y compartiendo la propiedad.
El cliente debe formar parte activa del resultado. Cuando más participe en la definición de producto y en su revisión frecuente mejor adaptado estará a sus necesidades.

Esperamos lo inesperado y lo gestionamos mediante iteraciones, anticipación y adaptación.
El mundo es caotico por naturaleza. Lo que es cierto por la mañana deja de serlo por la tarde. Los procedimientos de trabajo tiene que ser flexibles y con ciclos cortos para poder seguir dando valor en estas condiciones.

Damos rienda suelta a la creatividad y la innovación reconociendo que los individuos son la fuente última de valor, y creando un entorno en el que puedan diferenciarse.
Los desarrolladores son los que crean. Cárgalos de stress en un entorno de trabajo restringido y obtendrás resultados mediocres.  Déjalos que disfruten con lo que hacen y dales los medios oportunos y crearán grandezas.

Disparamos el rendimiento mediante la responsabilidad  común sobre los resultados y sobre la propia efectividad del equipo.
No hay equipo más eficiente que aquel que está motivado y se le dan las herramientas para que ellos mismos hagan su trabajo más rápido y con mejor calidad.

Mejoramos la efectividad y la fiabilidad mediante estrategias, procesos y prácticas especificas para cada situación.
Existen muchas metodologías pero no hay una sola que funcione para todos los entornos. Hay que probar, medir y adaptar hasta encontrar el sistema que mejor funcione (mientras funcione).

Estos son los 6 puntos que habla la DOI. Puntos para reflexionar e interiorizar poco a poco. Puntos muy importante para quien quiere agilizar el desarrollo de software pero… David tiene razón.¡ Qué pena de nombre !.

Nuestro humilde Coderetreat

El pasado sábado 14 de Diciembre celebramos en Alicante nuestro primer Coderetreat. Si quieres detalles de qué es un Coderetreat aquí los tienes.

Gracias a Santiago Melía conseguimos un aula muy buena en la Universidad de Alicante y fue el pistoletazo de salida para empezar a prepararlo. Creé el evento en la web del Coderetreat y en Eventbrite para que la gente se pudiera apuntar de manera sencilla.  Sabía que debía conseguir que algún patrocinador que pagara el almuerzo o la comida del día y poder traer la comida a la propia aula. Para ello contacté con empresas locales de papelería, componentes informáticos, bancos, el ayuntamiento, la diputación… “Rien de rien”. Lo único que conseguí fue alguna respuesta diciendo “No vamos a patrocinar nada pero suerte en el evento”.

Angel Armenta se propuso prepararse el papel de facilitador. Así yo podría estar en las conexiones con otras ciudades del mundo, actualizando el estado de nuestras sesiones, poniendo la publicidad y estar atento al evento. Los días pasaban y pocos apuntados iban apareciendo. Llégó la fecha del 14 de Diciembre con sólo 6 inscritos. Sin embargo, tras hacer cancelado un par de eventos por ser poca gente y haberme arrepentido despues,  tiré millas hacia delante con el evento.

Llegó el día. Como no conseguimos patrocinador yo compré unas empanadillas y dulces para comer allí y Ángel se encargaba de las bebidas y el café. Puse los carteles para indicar bien cómo se llegaba al aula (no sea que alguien se fuera a perder). Cuando llegó la hora de comenzar nos encontramos 4 personas en el aula: Angel, dos inscritos y yo.

Total, que tanto Ángel como yo hicimos parejas con ellos y dejé aparcado el tema de conexiones globales y hangouts. Como dicen los mismos organizadores, lo más importante es la gente que hay dentro. Fueron unas sesiones muy interesantes. Abordamos el juego de la vida desde todos los puntos de vista posibles: la vida y muerte de la celula, cómo contar sus vecinos, qué criterio se elige para que sobreviva o no. Al medio día nos fuimos a comer a un restaurante y cerramos las sesiones de tarde con un Randori compartiendo la pantalla con un proyectos y resolviendo entre todos una vez más el juego.

Resultado: A la vista está. Esperamos repetir el próximo año. IMG_20131214_173632