Developing Frogtek

El blog del Departamento de Tecnología

Etiqueta: frogtek (página 2 de 4)

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!!.

Frogtek: Empresa Junior 2010 en la Noche Teleco de Aragón

Este viernes pasado durante la XI Noche de las Telecomunicaciones en Aragón, Frogtek recibió el Premio a la Empresa Junior 2010 en Aragón.

Todos los ingenieros de Frogtek España nos pusimos nuestras mejores galas y asistimos a la cena y entrega de premios en el Espacio Ebro, al lado mismo del espectacular recinto de la EXPO de Zaragoza, y pasamos una noche muy entretenida, entre felicitaciones, viejos amigos y gente que conocimos en el evento (cenamos cerca de 400 personas).

Estamos muy contentos de haber recibido semejante reconocimiento, sobre todo dada nuestra todavía corta trayectoria y todo lo que nos queda por demostrar, y damos las gracias también desde aquí a los organizadores, el Colegio Oficial y la Asociación de Ingenieros de Telecomunicación de Aragón.

Os dejo algunas fotos de la cena y posterior fiesta.

Aquí todos, menos Alberto que hacía la foto, esperando a que empezaran con los entrantes.

Aquí, esta vez sí, todos probándonos las gafas 3D, que los de Canal+ repartieron para amenizar la velada. La cosa se empezaba a animar.

Y en esta foto, ya más relajados, con el trofeo y posando con José Luís Latorre, Director del Parque Tecnológico Walqa y buen amigo de Frogtek.

La celebración continuó hasta altas horas de la madrugada, pero de esa parte no han quedado documentos gráficos

Carlos Ble Tour 2011: Primera parada Frogtek

Pues sí. A principios de diciembre Carlos Ble anunció una gran iniciativa, se ofrecía a trabajar un par de días en distintas empresas que le pillaran a mano simplemente a cambio de los gastos de manutención y parte del viaje. Por aquel entonces ya estábamos en contacto con él por que en Frogtek teníamos la ilusión de que Walqa acogiera su curso de TDD, así que nos faltó tiempo para ofrecernos a ser la primera parada de un viaje que seguro va a ser muy provechoso para las empresas que visite y para él. Es un win-win claro (sin tecnología de Redmon de por medio). Para Carlos tiene que ser muy enriquecedor visitar distintas empresas, con distintos productos, distintas metodologías, problemas y personas. Para las empresas es una gran oportunidad de someterse al escrutinio de alguien externo con gran conocimiento de la tecnología y el eXtreme Programming. Fuimos los más rápidos, así que aunque el curso de TDD al final no se llevó a cabo en Walqa, sino en Zaragoza, al acabar Carlos tomó rumbo al norte y recaló en nuestras oficinas por un par de días que se nos hicieron realmente cortos.

El proceso empezó el mismo miércoles por la noche cenando en el Café del Arte una pizza que estaba muy buena pero que era muy difícil de cortar. Hablamos largo y tendido sobre Frogtek y MavenCharts, las fases por las que habíamos pasado, los logros y dificultades que había encontrado por el camino. Me temo que monopolicé un poco la conversación, el problema es que cuando me pongo a contar la historia de Frogtek puedo estar horas y horas y además quería aprovechar los dos días siguientes a tope y para ello tenía que ponerle al día de demasiadas cosas. Mucha información en muy poco tiempo, me temo. 🙂

El jueves empezó la movida. Primero ponte a explicar la tabla de Kanban y date, enseguida, cuenta de que hemos ido complicando las cosas poco a poco, hasta el punto de que explicar el funcionamiento de una simple tabla deja de ser algo trivial. El tiempo dirá si las sucesivas evoluciones de nuestra metodología han sido para bien o hemos complicado demasiado el proceso. De momento estamos bastante satisfechos. Después tuvimos nuestro stand-up (un poco tarde, me costó 1€ que pagué bien a gusto). Decidimos, en honor de nuestro invitado, que no íbamos a hacer nada especial por su visita así que le obsequiamos con nuestro habitual spanglish. Mr. Ble aguantó el tipo (y la risa) sin problemas así que al final del stand-up accedimos a rellenar un pequeño formulario de preguntas que pretendía chequear la “salud” de nuestro grupo y nuestras expectativas ante su visita.

Lo siguiente fue hablar sobre nuestro sistema de integración continua basado en HUDSON y que Carlos le echara un primer vistazo a la realidad de nuestras baterías de tests. Mucho test de integración pero poco unitario, también algunos funcionales pero todos mezclados y poco ágiles. Es difícil hacer TDD si los tests unitarios tardan varios minutos en pasar. Diagnóstico: grandes dosis de buena voluntad pero mucho por mejorar.

Carlos y Alberto peleándose con el GAE

El resto del jueves y viernes tocaba Pair Programming. Primero Javier Linares y nuestro proyecto para Android TiendaTek, luego Alberto Gualis y los tests de lado de servidor en Python y sobre Google App Engine. Tanto Javi como Alberto pueden dar su propia opinión pero sin duda fueron unas horas muy provechosas durante las que pudimos entender como evolucionar nuestra arquitectura y discriminar y organizar nuestros tests para hacer un TDD realmente útil y no “de postal”.

También hubo tiempo para revisar el código de Linares y Carlos el viernes por la mañana.

Al filo de las 3 de la tarde del viernes acabamos la sesión con una retrospectiva que nos reveló distintas cosas:

  • Que dos días escasos habían sido muy cortos para todo lo que nos hubiera gustado aprovechar.
  • Que podríamos mejorar nuestro nivel de calidad pidiéndole a alguien externo pero cercano que usara nuestro producto (¿quizá la tienda de ultramarinos de Cuarte?, ¿la cafetería de Walqa ;)?…)
  • Que nuestra manera de trabajar podría verse beneficiada del uso de repositorios de código distribuidos (nuestro objetivo de migrar a GIT o similar es como el arco iris, que por mucho que camines hacia él nunca lo alcanzas).
  • Que Eclipse es lento para el TDD.
  • Que deberíamos hacer alguna retrospectiva de código (algo parecido hacemos con nuestra reunión mensual de “Nuestros mejores bugs“, pero no tenemos muchos reparos en ignorar la reunión a poco trabajo que tengamos).
  • Que intentáramos desligar funcionalidad transversal para integrarlo en librerías (estamos en proceso ya que Android solo hace muy poco lo permite).
  • Que el código que nunca falla es el que no existe (por eso yo nunca creo bugs).
  • Y que habláramos y habláramos y habláramos… la (buena) comunicación es siempre la base para que algo funcione (bien).

Y de ahí disparados al Dojo… pero eso será otra historia.


Frogtek organiza un Coding Dojo en Walqa con Carlos Ble de invitado

El próximo viernes 21 por la tarde en Walqa, Frogtek organiza un Coding Dojo de la mano del experto en Test-Driven DevelopmentMetodologías Ágiles y Cloud Computing, Carlos Ble.

Un Coding Dojo es un evento informal y divertido en el que un grupo de programadores se reúne para poner en práctica sus habilidades de programación, resolviendo pequeños problemas programando por parejas en diferentes lenguajes. Es una oportunidad muy buena para aprender nuevas técnicas, nuevos lenguajes, conocer gente interesada en el mundo de la programación y obtener consejo de un experto como Carlos.

  • Día: 21 de enero 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:
    • Carlos propondrá uno o varios problemas sobre los que se trabajará en parejas.
    • Se realizarán varias iteraciones.
    • Al final de la sesión Carlos presentará y explicará su solución a todos los asistentes.
  • Plazas: Limitado a 25 personas, por riguroso orden de inscripción
  • Inscripción: Mandando un mail a Beatriz Lorente (blorente@ptwalqa.com)

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

El post-mortem del Ranatón

Volvimos de Morillo. Sanos y salvos y ahora estamos disfrutando todos de unas merecidas Navidades. Aunque, bueno, siempre tiene que haber alguien al pie del cañón, también es cierto que se trabaja muy tranquilo cuando todo el resto del mundo está de vacaciones. Es como un pomodoro continuo.

El Ranatón fue una gran experiencia. El sitio resultó muy apropiado (estábamos solos y aislados), la relación calidad precio fue lo más ajustado que pudimos encontrar y la conexión WiFi, el gran miedo que teníamos, funcionó más que aceptablemente para 9 personas que estábamos continuamente conectados.

El acabar el tercer día hicimos una especie de Stand-up retrospectivo. Sirvió para que cada uno presentara los avances conseguidos; notorios fueron los del equipo “Portal” que nos presentaron toda una serie de páginas web con unas gráficas más que jugosas, menos obvios pero tan o más importantes fueron los conseguidos por el equipo “Inframundo” (de infraestructura) que se dedicó a la no muy agradecida tarea de optimizar nuestra querida TiendaTek. Enhorabuena a los dos equipos.

Las conclusiones del Ranatón fueron las siguientes:

  • A todo el mundo le gustó, sobre todo porque rompe la rutina y es una buena manera de hacer equipo y de que todos nos conozcamos un poco más.
  • Es muy muy útil hacer una sesión intensiva en la que PO y programador tengan conexión directa y puedan trabajar juntos codo con codo. Esta vez sólo teníamos a David, pero ójala en nuestro siguiente Ranatón podamos traer también a Yael, Mark y Kristel. Puede parecer una obviedad pero es que nosotros tenemos a POs y programadores separados por miles de kilómetros en nuestro día a día.
  • Aunque durante un Ranatón se puede llevar a cabo cualquier tipo de tarea es mucho mejor aprovechar para implementar US que necesiten de mucho feed-back por parte del PO y de los compañeros. También es mejor no hacer US que sean supercomplicadas, son preferibles las tareas cortas y también aquellas que tengan un reflejo rápido y grande en el producto. Anima mucho ver que se avanza rápido y que los avances son muy visibles. Esto lo conseguimos con el equipo Portal, con el equipo Inframundo fue más complicado (el pobre Pablo se pegó tres días optimizando listas), lo haremos mejor la próxima vez.

  • Es muy útil tener una pizarra donde apuntar las US y tareas y poder registrar los avances. Nosotros además utilizábamos un timbre (de estos hotel) para dar cuenta de los US terminadas y de los cerditos que iban cayendo.
  • No fue el típico kick-off para hacer team-building ya que fuimos a Morillo a currar y no hubo las típicas excursiones o actividades lúdicas oficiales. Tres días fue la duración adecuada, acabamos todo bastante cansados.
  • Sí que hubo actividades lúdicas oficiosas como hacer alguna pausa para ir a arreglar el mundo al salón de al lado (el hotel entero estaba a nuestra disposición ya que estábamos solos), echar una o dos cervezas mientras se programa (nada de drunk-programming) o jugar un partido de tenis a dobles en la Wii.

  • La comida fue muy buena pero demasiado abundante, costaba un poco reenganchar después de un típica comida montañesa o de las deliciosas pizzas que tomamos las dos noches en Aínsa. Restaurante con loro incluido, por cierto… muy apropiado para el señor Stallman.
  • Trasnochar trabajando es un arma de doble filo. Por un lado es divertido y todo un reto estar programando hasta las 3:30 de la mañana. Cuando a partir de cierta hora el ambiente se relaja y se pone música de fondo para todos o se comparten unas cervezas uno tiene la impresión de estar una start-up al más puro estilo americano (los que hayan visto “La red social” que no se lleven a engaño, lo nuestro fue mucho más tranquilo… ni sexo, ni drogas). Por otro lado el oficio de programador tiene mucho de artesano y cirujano y, por lo tanto, la falta de sueño no es buena compañera y los grandes alardes se pagan de un día para otro… aquí como en muchas otras facetas de la vida lo importante es la regularidad y la constancia.
  • Concentrar a todos los “roncadores” en la misma habitación hizo que el resto del equipo descansara a pierna suelta… pero condenó al insomnio a buena parte de los primeros en la “habitación del pánico“.

Y esto es todo. Felices Navidades a todo el mundo.

Evolucionando hacia Scrumban

Creo que fue Heráclito el que dijo que “todo fluye”, bueno según Wikipedia dijo “En un río entramos y no entramos, pues somos y no somos”, mucho más poético y críptico… Pues bien, en Frogtek no sabemos si todo fluye o no, si somos o dejamos de ser, y de momento, lo de entrar en el río, dado que fuera (en Morillo) a la orilla del río Cinca, hay unos tres grados bajo cero, no nos lo planteamos. Lo que no ha dejado de cambiar desde que empezamos con los método Ágiles ha sido nuestra tabla de Kanban, ni nuestra forma de trabajar. Resumamos en unas lineas nuestros “vagabundeos” por este mundo de las metodologías ágiles.

Tras darnos cuenta enseguida de que Waterfall no nos servía para Frogtek, empezamos queriendo implementar Scrum, y con toda nuestra buena voluntad tratamos de adquirir todos y cada uno de los artefactos que Scrum define. Nos surgieron varios problemas, a saber, reuniones interminables de planificación, estimaciones poco afortunadas, cliente ausente… Lo del cliente merece una explicación, nosotros creamos software para pequeños tenderos en países emergentes, hay millones de ellos pero nunca se van a involucrar real y profundamente en un proceso de diseño como el nuestro (suficiente trabajo y problemas tienen), además nuestro potencial cliente no era uno sólo de ellos o un grupo de tenderos, si no los tenderos del mundo en general, casi nada. El resultado es que David, el CEO, hacía de PO, diseñaba las funcionalidades en función del feed-back informal que recibía en sus visitas por las calles de Bogotá y las empaquetaba en Sprints para que nosotros programáramos.

Pronto nos dimos cuenta que necesitábamos algo más flexible, las reuniones de planificación no es que fueran muy útiles (3 horas de reunión es la receta perfecta para el aburrimiento), no entendíamos bien los datos, burn-down charts, que nos proporcionaba nuestra excesivamente completa herraminenta AgileBuddy, no dábamos ni una con las estimaciones y sobretodo el feed-back recibido por los tenderos no era ni formal, ni periódico, ni definitivo, por lo que las prioridades cambiaban rápido, incluso demasiado para Scrum. Así que Kanban nos pareció más adecuado: implementemos sobre la marcha lo que el PO decida que necesitamos en cada momento y saquemos 10 ó 20 versiones de pre-producción al día (gracias a Dios, bueno y a Julio, por la Integración Continua y HUDSON) y versiones de producción bajo demanda. Perfecto cuando tienes 5 tiendas. Además puedes diferenciar entre US y Bugs, medir la velocidad semanal.

El problema surge cuando en lugar de 5 tiendas alrededor de nuestro apartamento de Bogotá tenemos 25, 30 o más repartidas por toda la ciudad. Y qué ciudad. Moverse de una tienda a otra puede costar cerca de dos horas en algunos casos, la conexión para que los tenderos puedan actualizarse automáticamente TiendaTek (como hacemos en segundos en España) funciona de pena. En resumen aunque la tecnología esté preparada para escalar sin problemas, los temas operativos a pie de calle son un verdadero reto, y cada vez que sacábamos una nueva versión era un dolor de cabeza considerable, primero por lo costoso del despliegue y segundo porque aparecían bugs que nos complicaban todo más si cabe.

Así que se acabó el aquí te pillo aquí te mato (fue bonito mientras duró) y empezamos a plantearnos evolucionar poco a poco hacia Scrum de nuevo. Básicamente retomamos los Sprints de entre 1 y 2 meses, ya no era viable hacer versiones del software del teléfono cada 2 semanas, nos olvidamos de herramientas personalizadas online y recuperamos las reuniones de planificación, aunque seguimos sin estimar de manera propiamente dicha (ya hablaremos de esto pronto), sin embargo la manera que tiene Kanban de tratar con la gestión de Bugs nos seguía gustando… Y en estas apareció Medinilla, su presentación de Scrumban en la Agile Open Spain y casi nos “corren a gorrazos” porque el pobre Pedro definió lo que hacíamos en Frogtek en una de las sesiones como “Kanban puro“. Puro, el que nos metieron.

La consecuencia fue una magnífica reunión de retrospectiva donde dimos unos cuantos pasos adelante y entre los más importantes, el pomodoro síncrono (¡que funciona!) y migrar a un Scrumban más académico. O “lo que es lo mismo” una nueva versión de nuestra tabla, con dos filas (por proyecto, aunque esto realmente da igual) una para las US de Scrum (las que hemos planificado para el Sprint), la superior, otra para los Bugs (los errores que surgen sin previo aviso) y US de Kanban (las que no estaban planificadas, pero surgen por urgencias de todo tipo o mala planificación), la inferior.

Esto nos permite medir nuestra velocidad de Scrum, nuestra velocidad de Kanban “bueno” y la de Kanban “malo“. O lo que es lo mismo, si definimos:

  • [VS], velocidad Scrum
  • [VK+], velocidad Kanban bueno
  • [VK-], velocidad Kanban malo
  • [VT] = [VS] + [VK+] + [VK-]

podemos saber cosas como:

  • El nivel de trabajo máximo al que nos podemos comprometer en un momento dado, [VS] + [VK+]
  • El nivel de trabajo medio que sacamos normalmente adelante, [VS].
  • La tasa de fallos que tenemos, [VK-] / [VT].
  • El “focus factor”, o cómo de enfocados estamos, [VS] / ([VS] + [VK+])

Con un buen equipo de programadores [VK-] debería ser pequeño, con un buen PO y Scrum/Kanban Manager (y un buen cliente, por pedir que no quede) [VK+] debería ser pequeño y por lo tanto el Focus Factor grande cercano al 100%. El objetivo, acercarse al Nirvana de cualquier start-up, “hacemos lo que estaba previsto hacer y a la primera lo hacemos bien“. Si ya encima te pudieras asegurar de que la US en cuestión era lo que quería el cliente y la va usar realmente…

Al final del proceso y si cuentas las US y Bugs que se terminan cada semana te sale una gráfica como la siguiente*.

* En la gráfica a parte de ver los puntos de Scrum (en azul y morado), los de Kanban bueno (en amarillo y naranja) y los de Kanban malo (en rojo) tenemos una diferenciación más: entre US que aportan nueva funcionalidad al usuario y US de infraestructura que que no aportan directamente pero son necesarias para optimizar o como base tecnológica para hacer luego alguna otra cosa. Tuvimos que meter esa diferenciación para controlar el trabajo en las “catacumbas” de nuestros productos, ya que a veces pasar la escoba es necesario y hasta divertido, pero no tenemos que olvidar que nuestra prioridad es el cliente y que “lo mejor es enemigo de lo bueno“.

Jose B. Cortés ganador de la segunda edición de la carrera del cerdito

Tras un mano a mano apasionante con el maestro Linares y un emocionante e imprevisible sprint Jose se ha alzado con el segundo cerdito de nuestra andadura. Lo cierto que es que podría haber ganado cualquiera de los dos así que vaya desde aquí la felicitación para ambos.

Hemos aprovechado el Ranatón y la presencia entre nosotros de David para hacer la entrega de premios que como siempre ha consistido en manosear un poquito al cochino que tenemos por hucha antes de dedicarnos al noble arte de destriparlo (es más fácil de decir que de hacer). Aquí tenéis una foto donde sale Linares (anterior ganador), David nuestro CEO y fundador y Jose, flamante ganador con coleta y sudadera de Android.

El cerdo contenía 34€.

Estamos de Ranatón!!

En Morillo de Tou, un precioso pueblo pirenáico cerca de Aínsa y a los pies de Monte Perdido abandonado hace décadas y que ha sido rehabilitado para uso turístico. ¿Y qué demonios es un Ranatón, te preguntarás, lector?. Pues un maratón interno de programación organizado en Frogtek y donde pretendemos enfocarnos en ciertas funcionalidades que consideramos claves para el Sprint en el que nos encontramos. Hemos llegado hoy, lunes, a las 9 de la mañana…

y no nos iremos hasta el miércoles a las 8 de la tarde. Todo el Departamento de Tecnología (es decir, todos los de Huesca) más David, nuestro CEO que aprovecha que ha venido a España a pasar la Navidad para hacernos compañía en esta fría y soleada mañana de Diciembre. Van a ser tres días intensos que esperamos sirvan para:

  1. Darle un buen empujón a los últimos retoques de TiendaTek.
  2. Iniciar un nuevo producto clave para nuestra empresa.
  3. Hacer equipo y disfrutar de unos días previos a la Navidad con nuestra “otra familia”, esa con la que pasamos al final más tiempo todos los días.

Estamos en un antiguo aula que bien podría haber sido el colegio del pueblo años atrás, sentados a unos curiosos pupitres que tienen pinta de haber enseñado a leer a alguno de nuestros padres. Encima hemos colocado nuestros modernos TFTs de 21 pulgadas, macs y todo tipo cacharrería tecnológica, buena mezcla. Lo mejor que la WiFi funciona y además como no hay 3G las pruebas con GPRS son mucho más realistas!.

Os pongo alguna foto para que os hagáis una idea. En esta sala vamos a pasar muchas muchas horas estos tres días.

La comida nos la sirven en el restaurante del pueblo.

Y para cenar nos iremos al precioso pueblo de Ainsa con su espectacular Plaza Mayor y vistas a Monte Perdido, ¿qué más se puede pedir?.

El Pomodoro Síncrono ya está aquí

Ayer tuvimos una reunión de retrospectiva. Solemos hacer una al mes aproximadamente. Ésta fue particularmente interesante, especialmente por Jose, Linares y Pedro que habían acudido el fin de semana anterior al Agile Open Spain de Barcelona y se trajeron feed-back fresquito e interesantes ideas para aplicar en nuestro entorno de trabajo.

Esta semana presentamos… ¡el Pomodoro Síncrono! (lo que hay que oir). Se trata de buscar maneras de aumentar la productividad y se puede aplicar tanto a programadores como a cualquier otra persona que necesite cierta tranquilidad y concentración para llevar a cabo su trabajo. Básicamente la idea del Pomodoro consiste en reservar espacios de tiempo para aislarse del entorno y concentrarse un 200% en una tarea. Está claro, si apagas el teléfono, el chat, el twitter, el facebook, haces voto de silencio y te pones unos cascos tu productividad aumenta varios órdenes de magnitud. La duración de dichos espacios de tiempo es variable y personal, hay quien es capaz de aguantar en una especie de estado entre el trance y el nirvana durante varias horas seguidas, hay quien con media hora de aislamiento sensorial tiene más que suficiente. Resulta obvio que no es una técnica de la que se deba abusar pero también que, cada vez más y sobre todo en un trabajo como el de programador, si se quiere aumentar la productividad (esto es, ser más rápido, cometer menos errores y acabar más cosas) hay que ser capaces de abstraerse del ruido, principalmente spam cibernético, que nos rodea.

¿Y por qué Pomodoro?. Porque el tío que lo inventó usaba un reloj de cocina con forma de Tomate. ¿Y por qué Síncrono?. Porque si lo práctica toda la oficina a la vez es mucho más efectivo. Así que hemos decidido hacer Pomodoro Síncrono todos los días:

  • de 9:30 a 10:30
  • de 12:00 a 13:00
  • de 16:00 a 17:00

Desgraciadamente no hemos encontrado un reloj-tomate… así que siempre nos quedará el consuelo de decir: “Hoy he currado un huevo”.     😛

El curso de SCRUM en Walqa: ¿un éxito? no… dos!

Esto lleva un tiempo un poco parado, es cierto, pero no es que lo hayamos abandonado, es que tenemos mucho trabajo y a veces encontrar tiempo para ordenar las ideas y escribir un post resulta complicado. Hoy, sin embargo, me he decidido a romper este silencio por algo que pasó ayer.

Resulta que estábamos en pleno TPV, dando cuenta del menú de Walqa y viendo un video más gracioso que científico (bueno para gustos colores) cuando unas 20 personas irrumpieron en nuestra oficina porque querían ver nuestra tabla de Kanban. ¿Una manada de groupies de Frogtek?. No. ¿La gente del Agile Open Spain venían a flagelarnos porque tenemos más de un Product Owner?. Tampoco… menos mal. Mucho mejor, era la segunda tanda de gente del Curso de SCRUM que Teresa Oliver estaba dando en Walqa.

Da mucho gusto que te tomen como modelo para este tipo de cosas. Nosotros ni somos perfectamente ágiles según los estándares del “Agilismo puro”, ni pretendemos serlo, ni seguramente conseguiríamos serlo aunque lo intentáramos. Hemos avanzado muchísimo desde que empezamos y estamos encantados de contar lo que hemos aprendido por el camino, y de aprender muchas otras cosas más. Ójala pronto empecemos a ver alguna otra tabla más por Walqa, será señal de que estamos en el camino correcto.

También da mucho gusto saber que las iniciales dudas de si habría al menos 10 personas para hacer un curso de ese estilo en Walqa han sido ampliamente superadas con casi 4o personas… y eso que me consta de 3 ó 4 amiguetes que hubieran querido asistir y no han podido, lástima porque hubieran podido aportar cosas importantes ya que son gente que sabe mucho de tecnología y de proyectos. Bueno, al grano, parece que hay masa crítica así que pronto llegará el momento de mover más la cosa empezando por… ¿un curso de TDD?.

Y por cierto… aprovecho para arrojar el guante para que alguno de mis compañeros que estuvo en la Agile Open Spain 2010 se anime a contar lo que allí vimos, aprendimos y cómo nos dieron algún que otro revolcón… y voy a romper una lanza por Jose, Linares y Pedro que se atrevieron a hablar de Frogtek delante de gurús de la talla de Medinilla & company.

Antiguas entradas Recientes entradas