Developing Frogtek

El blog del Departamento de Tecnología

Categoría: metodología (página 2 de 4)

Tabla de kanban para las retrospectivas

Al principio nuestras reuniones de retrospectiva eran de lo más… cómo decirlo sin ofender a nadie… anárquico. Tanto en contenido como en periodicidad, es decir, las hacíamos cuando queríamos y como queríamos. Podían pasar meses entre una y otra, y cuando por fin hacíamos una nos dábamos cuenta de lo útiles que eran y la cantidad de cosas interesantes que surgían. Las ha habido incluso que han supuesto un punto de inflexión en nuestra manera de trabajar, como aquella que hicimos con la excusa de que algunos habían acudido a un evento llamado AOS en una ciudad llamada Barcelona.

Con el tiempo, y conforme te haces con todos los procesos y ellos dejan de dominarte a ti, hemos sido siendo más constantes y periódicos con estas reuniones. Incluso nos compramos un libro, Agile Retrospectives (del cual he de reconocer que sólo he leído los primeros capítulos) e investigamos por internet sobre la mejor manera de hacerlas. Hay infinidad de técnicas que se pueden aplicar. Nosotros optamos por una de lo más sencillo. Básicamente cada miembro del equipo escribe en uno o varios post-its las cosas que han ido bien y las cosas que han ido mal en el último mes. Se ponen en común y se agrupan por temas, de forma que podemos identificar cuales son las principales virtudes que debemos fortalecer y cuales los principales problemas que hay que paliar. Sigue una discusión sobre estos temas de la cual obtenemos una lista de puntos de acción que se revisan de retrospectiva en retrospectiva. Además de puntos de acción también salen sugerencias y recomendaciones (o lo que podríamos llamar puntos de acción “vagos“… del estilo de “sed todos buenos“). Estas recomendaciones son un problema porque no es fácil hacer un seguimiento de su cumplimiento ya que no son objetivos SMART. En la última parte de la reunión debatimos también sobre las ideas que cualquiera haya incluido en la excel que tenemos para “ideas a discutir durante la retrospectiva”.

Llevamos ya varios meses siendo muy regulares con este tema y ahora hemos decidido dar un paso más y crear una tabla de kanban para ilustrar el proceso. Nos gustan los post-its y ayudan a decorar la oficina… qué se le va a hacer!!.

En la foto podéis ver cómo en verde y rojo apuntamos las cosas buenas y las malas, para que a nadie se le olviden. Más importante aún son los puntos de acción cuyo seguimiento realizamos con una tabla que no puede ser más simple. Adicionalmente tenemos nuestro apartado de sugerencias del mes… a ver si teniéndolas en la sala de reuniones a la vista, las tenemos más presentes. Si esto no funciona optaremos por recitarlas todas la mañanas en plan mantra antes del stand-up. Algo del estilo de:

  • Ser QA no me da derecho a hacer cowboy committing
  • Me flagelaré de forma inmisericorde si el stand-up dura más de 25 minutos

Muchas veces hemos oído que la reunión de retrospectiva es la más importante de todas las reuniones que conforman el espíritu ágil. Encarna la esencia del Kaizen y da la oportunidad de debatir, aportar y enriquecerse (espiritualmente, claro). He de reconocer que, personalmente, veo como muchas de estas reuniones suponen un soplo de aire fresco en Frogtek. Y veo, no sin orgullo, como nuestro equipo se autogestiona y mejora de forma imparable, día tras día y mes tras mes. Supongo que son los pequeños placeres del Scrum Master que no programa, dado que no puedo hacer el baile de la victoria tras compilar por última vez la loser story de turno.

 

Pomodoros de verdad

La última semana tuvimos el placer de acoger en las oficinas de Frogtek al freelance y experto en craftmanship Enrique Comba (@ecomba), el cual trabajó codo con codo con nosotros para ayudarnos a mejorar nuestro proceso.

Siendo un experto en la materia como es él, aprovechamos para preguntarle cómo mejorar nuestros pomodoros. La técnica del pomodoro es un método de timeboxing (administración del tiempo) para realizar tareas en periodos alternos de trabajo exhaustivo y pausas. Nosotros ya habíamos integrado esta técnica a nuestro trabajo habitual, y esto era lo que sabíamos:

  • Cada pomodoro consiste en un periodo de trabajo continuo de 25 minutos.
  • Durante ese tiempo, hay que trabajar concentrándose en la tareaevitando cualquier distracción (correo, twitter, etc.). Algunas distracciones, sin embargo, son inevitables, como otros compañeros preguntando una duda, una llamada al teléfono, etc.
  • Un pomodoro es indivisible (no existe medio pomodoro). Lo utilizamos como unidad atómica de trabajo.
  • Después de cada pomodoro, hay que tomar una pausa breve de 5 minutos.
  • Después de un cierto número de pomodoros (entre 3 y 5 en nuestro caso) hay que tomar un descanso largo, de entre 15 y 25 minutos.
  • Al principio de cada jornada de trabajo, hay que planificar los pomodoros y descansos que se van a realizar.
  • Además hay que estimar cuánto tiempo (medido en pomodoros) va a costar realizar una tarea determinada.

Sin embargo, Enrique nos dio algunos consejos sobre las pausas, que no estabamos aplicando:

  • Es muy importante levantarse del asiento e incluse hacer ejercicios para evitar contracturas.
  • Debe intentar dejarse la mente en blanco. Esto es debido a que nuestro cerebro almacena la información y crea conexiones o momentos de inactividad, como durante el sueño.
  • No vale mirar el correo o twitter. Si es necesario utilizarlo, mejor tomar un pomodoro de “comunicación” de 25 minutos para realizar este tipo de tareas.

Sobre las distracciones:

  • Cualquier distracción (tanto interna como externa) debe anotarse en un papel, indicando su procedencia.
  • Al acabar la jornada, habrá que revisar la lista de distracciones y comprobar si pueden reducirse de alguna manera. En caso contrario, intentar agruparlas dentro de un mismo pomodoro.

Para más información, recomiendo leer este PDF del propio creador de la Técnica Pomodoro, Francesco Cirillo.

Sprints fijos, entregables adaptables (I)

Cualquiera que nos haya seguido desde el inicio sabe que hemos cambiado de metodología varias veces. Unos lo llamarán Kaizen, otros lo llamarán “culo veo culo quiero”, otros lo llamarán “vagabundeos por la el mundo de la agilidad”. La cuestión es que empezamos con un SCRUM chapucero, evolucionamos a un Kanban de postal y ahora estamos con un ScrumBan del que nos podemos sentir bastante orgullosos.

El tamaño del sprint también ha sufrido alguna que otra modificación. Empezamos, como mandan los cánones, haciendo sprints de 2 semanas (casi tan difíciles de estimar como de implementar), el resultado, por novatos, fue tan malo que nuestra evolución por reacción nos llevo al lado contrario, “¿un sprint largo? ¡no!, mejor”, fuera sprints y viva el despliegue continuo. El despliegue continuo (también llamado bug continuo por aquellos tiempos), funcionó mientras teníamos una aplicación beta en un puñado de tiendas alrededor de nuestro apartamento de Bogotá. En cuanto nuestra red de tiendas y nuestra exigencia aumentó volvimos a los sprints, esta vez largos, de 2 meses, dada la gran dificultad para actualizar todas y cada una de las tiendas a mano y volvimos, por tanto, a Scrum pero con un toque de Kanban: Scrumban.

Pronto nos dimos cuenta de que el entorno real en el que se ejecutaba nuestra aplicación no era comparable al de nuestra oficina, ni a nada que pudiéramos reproducir en ella, así que seleccionamos una tienda como beta tester y decidimos instalarle antes las versiones que producíamos. Concretamente decidimos dividir nuestro sprint de dos meses en tres mini-sprints de 3 semanas e instalar la versión resultante de cada uno de esos mini-sprints en la tienda de nuestro compañero Boris para que él nos diera feedback temprano.

El resultado ha sido que las primeras historias que se implementan en el sprint no tienen que esperar dos meses para llegar a una tienda de verdad, sólo 3 semanas, de forma que detectamos los errores antes y los corregimos antes, además de que repartimos los tests exhaustivos pre-release durante todo el sprint en lugar de acumularlos todos al final y mantenemos la tensión (la buena, se entiende) del equipo de forma constante. No hemos, no obstante, modificado la estructura del sprint, que se planifica para dos meses, es decir, no hacemos planficación, demo y retrospectiva en cada uno de los mini-sprints, sino sólo en el sprint principal. Los mini-sprints nos marcan los hitos en los que es necesario alimentar a nuestro beta-tester para ir cazando errores complicados, (para los fáciles tenemos el TDD, los test de integración y demás) que de otra manera se macerarían durante unas cuantas semanas provocando una infección de las buenas al final del sprint.

Así llevamos varios meses y varios meses nos quedan por delante. Hasta que llegue un momento en el que el ritmo de añadir funcionalidad a TiendaTek disminuya, la necesidad de nuevas versiones también y todos nuestros esfuerzos pasen a un entorno mucho más amigable y actualizable como es la web, entonces… ¿qué haremos?

Carta abierta a una historia de usuario

Estimada Historia de Usuario:

Empezamos mal. Tú y yo sabemos que de estimada nada de nada. Algo de cariño, cierta relación amor-odio, un respeto mutuo inquebrantable… eso sí. Pero de estimarte en Frogtek poco o nada.

Es posible que los gurús del agilismo no comprendan nuestra relación, demasiado liberal quizá, poco comprometida dirán. Me llamarán poco ortodoxo, hereje y hasta libertino. Pero es lo que hay, en Frogtek no te estimamos. Y no me refiero a tus tareas internas o a tus detalles más íntimos, me refiero en general, al objeto que centra la atención de cada uno de nuestros programadores cada día por un periodo indeterminado de entre media hora a cinco días.

Sé que te preguntas qué me has hecho, porqué cuando todas las empresas ágiles debaten interminablemente cual es la mejor manera de estimar una historia de usuario, yo te pago con el desprecio. Ellos te asignan puntos, te dedican tiempo, algunos hasta te compran ropa y tú disfrutas del momento orgullosa, coqueta, probándote las distintas tallas. Y yo nada, pasas discretamente por mi tabla, sin grandes entradas, sin protagonismo, sin que hablen los programadores demasiado de ti hasta que no te llevan al huerto. Aquí te pillo, aquí te mato. Y la salida es peor, si te visto no me acuerdo.  En el fondo no sé de qué te extrañas, todas sois similares y a largo plazo me parecéis todas idénticas. Además mis sprints son largos, así que es mejor para los dos mantener las distancias, es que no sólo sois todas iguales, es que encima sois muchas. Dirás que tengo miedo al compromiso, que para llevar dos años en esto de agilismo soy uno inmaduro, que soy caprichoso e infiel, que soy, en definitiva, un cerdo sólo interesado en coleccionar una historia de usuario tras otra, una muesca más en mi revólver… y algo de razón no te falta.

Hubo un tiempo en el que te estimé, lo sabes. Y no funcionó. Era una relación demasiado absorbente, suponía demasiada dedicación, horas y horas hablando de ti, alimentando tu ego cuando tan sólo habíamos empezado a conocernos y nada sabíamos el uno del otro… me agobié. Lo intenté y fue mal, te estimé y tú siempre te quejabas, te sentías, a veces, sobre-estimada, otras, las más, era todo lo contrario. Así que ya ves, para hacerlo mal, mejor no lo hacemos. Además en Aragón siempre hemos sido más de guiñote.

Ahora me va mejor. Soy más feliz y estoy centrado en lo que realmente me gusta. Os trato a todas por igual y al final del sprint he tenido tiempo para todas vosotras que esperáis desde el principio de cada sprint, para muchas otras que vienen sin avisar y para mi mismo, sin comerme la cabeza. Quizá algún día estime una historia de usuario, quizá algún día le vea el valor a una relación más estable, profunda y comprometida, pero de momento… esto es lo que hay.

Siempre podemos ser amigos.

Atentamente,  Frogtek.

Revisión de código

Code Review

¿Revisar código?

¿Para qué?

¿Lo has probado?

Pues ya está ¿no?

Pues no. O al menos en Frogtek no nos vale. Y se agradece, la verdad. Veamos cómo y cuándo hacemos las revisiones de código.

Actualmente realizamos tres tipos de revisión de código:

  • Revisiones de código de las User Stories. Una vez terminadas y subidas al repositorio se revisan usando ReviewBoard, dando feedback, cuando sea necesario, a través de la herramienta. Dicha revisión se realiza dos veces. La primera por un programador y la segunda, por el tester antes de realizar el testing y verificación de la User Story.
  • Reuniones de revisión de código. Consisten en unas reuniones semanales en las cuales nos juntamos todos a ver, revisar, comentar… una funcionalidad nueva o un refactor especialmente delicado. Cualquier programador puede proponer código para ser revisado y nos animamos unos a los otros a ello.
  • Pair programinng de User Stories o parte de ellas. Aunque lo realizamos menos de lo deseado, lo usamos sobre todo cuando la funcionalidad que programar es complicada o propensa a errores. Nos ha dado muy buenos resultados siempre que lo hemos utilizado.

Solo llevamos alrededor de un año aplicando estás técnicas de manera exhaustiva, pero creo que las mejoras han sido sustanciales en la calidad de nuestro código y de nuestras habilidades.

Personalmente, lo que más me ha gustado es el conocimiento que se adquiere de toda la aplicación gracias a las revisiones. Ya no solo sabes lo que tú has hecho, sino gran parte de lo que el resto ha programado también.

Como nota final, un vídeo gracioso sobre Pair programing. En Inglés, lo siento.

Los 10 ranamientos

Al igual que existen los 10 Mandamientos de Java que indican como usar el lenguaje de programación de manera eficiente, igual que Google tiene sus 10 Design Guidelines que marcan las reglas fundamentales que cualquier producto de Google tiene que cumplir, Frogtek, como no podía ser menos, tiene sus “10 ranamientos“. ¿Y qué es un ranamiento?, pues básicamente son una serie de reglas que nos hemos dado para diseñar productos para nuestros queridos tenderos de la base de la pirámide.

Mientras las guidelines de Google son genéricas y de alto nivel, las nuestras son bastante concretas y se centran en la experiencia de usuario que una persona de un país emergente (no necesariamente acostumbrada a la tecnología) debe tener con un dispositivo tan particular como un teléfono móvil. Así que perfecto, realmente podemos completar las Guidelines de Google con nuestras prácticas concretas para tener buen compendio de reglas y guías al encarar el diseño de un nuevo producto. El libro de cabecera que todo buen Product Owner y diseñador gráfico debe tener para trabajar en Frogtek (cortesía de nuestra PO favorita cuyo apellido tiene 2 vocales y 9 consonantes, Yael Schwartzman).

A saber:

  1. No pensarás que tú eres el usuario – Los tenderos no tienen por qué necesariamente estar familiarizados con la tecnología y desde luego no tienen tanto tiempo como nosotros en la oficina. No podemos diseñar pensando que nosotros somos los usuarios finales!
  2. Entenderás el contexto de uso – Los tenderos quieren vender y ponen su atención en vender, nuestra aplicación es una herramienta, no el centro de su universo. Nuestra aplicación los debe de ayudar a hacer estas tareas sin estorbarles.
  3. Escucharás al tendero – El equipo de diseño tiene como obligación visitar alguna tienda por lo menos una vez cada dos semanas con alguna pregunta clara en mente y dispuestos a escuchar recomendaciones generales. Todas las recomendaciones, sugerencias y problemas que veamos a través de la aplicación y del equipo de operaciones serán también tomadas en consideración.
  4. No harás al tendero esperar – La interacción con el lector y con la aplicación tiene que ser lo más rápida posible. Si no el tendero se desespera y lo deja de usar por que tiene que atender a varios clientes impacientes a la vez.
  5. No pondrás texto menor a 12 puntos – No queremos que nuestros tenderos se queden ciegos!!
  6. No sacarás cosas de la aplicación sin pedirle permiso al tendero – Su opinión es a que vale, no la nuestra.
  7. No meterás cosas en la aplicación a menos que añada un valor claro para el usuario final – Sólo podemos añadir funcionalidad que claramente añada valor al tendero, empresas fabricantes o equipo de operaciones.
  8. Seguirás principios de diseño establecidos para el diseño de interfaces
    1. Coherencia – con el mundo real y el resto de la aplicación (Usar terminología sacada de la boca del tendero, usar metáforas del mundo real cuando aplique, coherencia interna entre pantallas).
    2. Flexibilidad – varias maneras para hacer lo mismo si los usuarios lo piden.
    3. Eficiencia – encontrar el menor número de pasos para completar una tarea. Proveer “wizards” para simplificar tareas difíciles.
    4. Simplicidad – Encontrar el diseño (tanto gráfico como interactivo) más simple… que no le sobre nada.
    5. Buenos sistemas de retroalimentación y ayuda – entender en que estado está el sistema y proporcionar ayuda en contexto todo el tiempo, hacer siempre accesible la ayuda y trata de educar en cada ocasión posible
    6. Transparencia – no esconder información que el usuario necesita conocer.
    7. Sistemas de prevención y recuperación de errores – evitar errores pero proporcionar al usuario con una manera de recuperarse de ellos si los hay. No queremos callejones sin salida.
    8. Uso de estándares – utilizar elementos de la UI de Android  siempre que sea posible.
    9. Baja carga de memoria del usuario – el interfaz debe ayudar y guiar al usuario al realizar una tarea, no dejar el peso en el usuario.
    10. Aprendible – el uso de la aplicación se aprende de manera orgánica con su manejo.
    11. Satisfactoria – una experiencia satisfactoria que guste la aplicación para que nunca dejen de usarla!
  9. Seguirás principios de diseño establecidos para el diseño de interfaces móviles y touch screens
    1. Minimizar input de usuario (uso mínimo del teclado)
    2. Minimizar el scroll vertical y evitar scroll horizontal
    3. Minimizar el número de pasos a ejecutar
    4. Proveer mensajes de error útiles
    5. Priorizar la información en cada pantalla (qué es lo más importante que quieres que el usuario vea)
    6. Controlar los cambios de orientación
    7. Apoyar uso de trackball
    8. Visibilidad de efectos causados por acciones (presionar botones, seleccionar, etc)
  10. Un botón no debe tener más de 2 palabras (palabra + conectivo + palabra).
  11. EXTRA: Seguirás los lineamientos de diseño de interface de Google :

    1. Useful: focus on people – their lives, their work, their dreams.
    2. Fast: every millisecond counts.
    3. Simple: simplicity is powerful.
    4. Engaging: engage beginners and attract experts.
    5. Innovative: dare to be innovative.
    6. Universal: design for the world.
    7. Profitable: plan for today’s and tomorrow’s business.
    8. Beautiful: delight the eye without distracting the mind.
    9. Trustworthy: be worthy of people’s trust.
    10. Personable: add a human touch.

 

Bloqueo de SVN en caso de build fallida

Hace poco tuvimos una agradable visita aquí en Frogtek. Una de las muchas aportaciones de Emma fue hacernos replantear nuestro sistema de lanzamiento de builds en Jenkins, pasando de uno más pesado en recursos a otro más eficiente. A raíz de dicho cambio hemos aprovechado y mejorado el procedimiento de bloqueo que tenemos configurado en Jenkins y la forma en la que lo realizamos. Vamos a explicarlo para que nos ayudéis a mejorarlo todavía mas.

En sí, el procedimiento consiste en no permitir commits al servidor SVN si hay una build rota. Excepto al usuario que haya provocado dicha rotura. De esta forma nos aseguramos de varias cosas:

  • No se avanza en el desarrollo si el código subido no es de una calidad mínima, pasa los test y se construye correctamente.
  • Los desarrolladores se hacen responsables de los problemas que ellos han generado y los arreglan.
  • Cuando existe un problema en una parte del proyecto, y dicho problema tarda en resolverse, todo el equipo se preocupa por saber qué pasa y ayudar a resolverlo para poder seguir avanzando.

Seguir leyendo

Segundo Coding Dojo de Frogtek en Walqa

Tras el éxito del Primer Coding Dojo y la resaca de la visita de Richard Stallman ya va siendo hora de presentar el Segundo Coding Dojo de Frogtek en Walqa.

Rubén Bernárdez de Biko2 será nuestro maestro de ceremonias. Aquellos que estuvisteis en el primer dojo recordaréis a Rubén ya que fue uno de los dos valientes (el otro era Dani Latorre) que retados por Carlos Ble se marcaron un refactor de la kata de Carlos, improvisado, sin red y ante la admiración de todos los asistentes.

Así que no hacen falta más presentaciones, ahora ya todos sabemos lo que es un Coding Dojo y por lo tanto, sin más, os dejamos con los detalles de nuestra próxima cita. Os esperamos.

  • Día: viernes, 8 de abril de 2011
  • Lugar: Parque Tecnológico Walqa, Edificio de Servicios Generales
  • Horario: de 16:00 a 21:00 aproximadamente
  • Precio: Totalmente gratuito
  • Quién puede apuntarse: cualquier persona, independientemente de que trabaje o no en Walqa
  • Agenda:
    • Rubén propondrá uno o varios problemas sobre los que se trabajará en parejas.
    • Se realizarán varias iteraciones.
    • Al final de la sesión Rubén presentará y explicará su solución a todos los asistentes.
  • Plazas: Limitado a 35 personas, por riguroso orden de inscripción
  • Inscripción: Mandando un mail a Walqa (walqa@ptwalqa.com)

¡¡Animaos que seguro que lo pasamos muy bien!!.

Prototipado con Google Spreadsheets y Fusion Tables

Confome avanzan nuestros proyectos, va aumentando el volumen y calidad de la información subida por los usuarios desde sus dispositivos Android. Toda esta información se va agregando en la nube y poquito a poco vamos entrando en una nueva etapa en la que el data mining va cobrando más importancia. De momento, tenemos claros ciertos tipos de informes y gráficas imprescindibles para nuestro negocio, pero las posibilidades de jugar con los datos son enormes y, por eso, necesitábamos un modelo que nos permitiera diseñar de forma ágil prototipos funcionales para ser mostrados y estudiados por nuestro equipo, clientes y colaboradores.

Es necesario explicar que, aunque ya tenemos varios agregados e informes mostrados en la propia nube, también  descargamos y desnormalizamos los datos sobre una MySQLinstalada en un servidor local, ya que, las posibilidades de “retorcer” los datos en una base de datos relacional son mucho mayores que en un sistema como Big Table . Por tanto, llegados a este punto, contamos con un servidor local, una base de datos MySQL y un equipo de ingenieros preparados para torturar a los datos con las más despiadadas queries.

Una vez obtenida la información que pensamos que interesa a nuestros usuarios, las posibilidades de representarla son muchas, existiendo innumerables librerías Javascript para mostrar tablas y gráficos, (o incluso empresas ofreciendo herramientas SaaS muy potentes).  El problema es que todas ellas requieren preparar los datos con un formato concreto y cierto trabajo de programación y maquetación para integrarlas en una web.  En nuestro caso, pensamos que es pronto para emplear tiempo en ese tipo de tareas, puesto que no estamos seguros de qué tipo de representaciones van a ser valiosas y cuáles no. Aquí es donde entra en juego una gran idea de nuestro CEO: tanto Google Spreadsheets como Fusion Tables permiten importar datos desde CSV y la generación de listados, figuras y gráficas es potente y muy sencilla.

Las ventajas son muchas:

  • Ambas herramientas permiten importar los datos desde CSV. Y cualquier cliente SQL permite exportar los resultados de una query en dicho formato, por lo que la tarea de formato de datos estaría resuelta.
  • Ambas permiten generar automáticamente un script para incrustar los datos en cualquier web.
  • Los datos generados en el prototipo, aunque estáticos, son reales. Y su actualización (manualmente o usando las APIs proporcionadas) sería muy sencilla. Tan fácil como ejecutar de nuevo la consulta y exportar el CSV.

¿Qué usamos entonces para tener listo un conjunto de listados y gráficos demo con información real?

  • Google App Engine con Django: La facilidad de despliegue de una nueva aplicación en el GAE unida a la rapidez de desarrollo en Django nos permitieron montar la estructura de navegación del nuevo portal en una sola mañana (reutilizando plantillas y  diseños que ya teníamos).
  • Listados y gráficas:  Una vez obtenida la consulta sql con los datos que nos interesaban, la exportamos a CSV y la importamos en una de las dos herramientas comentadas:
  • Google Spreadsheets: una vez importado el CSV y obtenida la URL, podemos hacer uso de los múltiples google gadgets disponibles para  incrustar en nuestras webs. Por ejemplo, tablas, gráficos de líneas o de tarta.
  • Fusion Tables: una vez importado el CSV y obtenida la URL, podemos probar los distintos tipos de visualizaiones a partir del menú Visualize. Las opciones son variadas y potentes. Alguna de ellas bastante espectacular (Motion, Timeline, Story Line…).

Normalmente utilizamos Balsamiq para proptotipar y hacer pruebas de usabilidad en la fase de diseño, pero en este caso necesitábamos algo más real. Con todo lo anterior, en muy poco tiempo, logramos desplegar un prototipo operativo que permite mostrar el potencial de los datos recogidos y experimentar con distintas formas de mostrar la información. ¿Qué ventajas e inconvenientes le veis? ¿Qué alternativas usáis vosotros para esta tarea?

Primer Walqa Coding Dojo

Así es, el viernes pasado, día 21 de enero, se celebró el primer coding dojo realizado en el Parque Tecnológico Walqa, dirigido por Carlos Ble.

Un dojo (道場, literalmente “el lugar de la senda”) es un sitio donde poder practicar y entrenar una disciplina concreta. Simplemente son centros donde se pueden reunir personas con ganas de aprender. Como en todos sitios, es normal que haya gente con más conocimientos que otros, pero esto es precisamente lo que se busca: que el conocimiento puede transmitirse entre los asistentes.

En nuestro caso, las características de nuestro dojo eran las siguientes:

  • Se va a diseñar y programar un problema (o kata) llamado FluentAPI.
  • Debe realizarse por parejas (pair programming).
  • Debe utilizarse TDD.
  • Se realizará en periodos de tiempo determinados, tras lo cuales deberemos cambiar de pareja.
  • No se indicará cuánto tiempo dura cada periodo (así tampoco hay ansias por terminar)

Al evento asistieron más de 30 personas de distintos perfiles y distintas procedencias (Indra, Tafyesa, Universidad de San Jorge, Telefónica I+D,…)

El problema o kata elegido para la ocasión fue el siguiente:

Queremos conseguir una API para acceder a una lista de objetos que sea fácil de leer al ojo humano, al estilo de:

  1. select(“name”).from(users)
  2. select(“name”).from(users).where(“age”).greater_than(18)
  3. select(“name”).from(users).where(“surname”).contains(“rodriguez”)
  4. select(“name”).from(users).where(“age”).greater_than(18).and(“location”).is(“san francisco”)

Y a ello nos pusimos. En el primer periodo parecía que la cosa no terminaba de arrancar, ya que el problema era difícil de abordar en un principio. Por las mesas se veían lenguajes tan dispares como Java, Ruby, PHP, .Net o Python.

Al sonar la alarma y acabar el primer pomodoro, nos dirigimos a una sala habilitada por Walqa con aperitivos y bebidas, que de seguro nos sirvió para descansar y consultar algunas dudas (como el uso de import static en Java, que resultó fundamental para la resolución del problema)

Acabadas las sesiones de programación, nuestro sensei Carlos Ble se puso a los mandos del portátil y se dispuso a ejecutar una forma de resolver el problema en Python. Mientras, los asistentes observaban el proyector con lo que iba realizando, en medio de un silencio solemne.

Tras lo cual, Carlos dejó continuar la resolución a dos de los presentes: Dani y Rubén, que se enfrentaron a una modificación del problema ante todos los asistentes.

Y hasta aquí dio tiempo. Los participantes salimos muy contentos con la experiencia y alguien llegó a decir que había sido el coding dojo con más afluencia de los realizados en España. ¿Será verdad? 🙂

P.D: nuestra intención es que este sea el primero de una larga lista de eventos.

P.P.D: tenemos nuestro propio hashtag: #codingdojohuesca

Antiguas entradas Recientes entradas