Developing Frogtek

El blog del Departamento de Tecnología

Etiqueta: equipo (página 1 de 3)

Somos ágiles, hacemos stand-ups

Como crítica constructiva o destructiva, la frase se utiliza muchas veces. Uno lee artículos, escucha podcasts, ve charlas, … Stand-up para arriba, stand-up para abajo. Uno ya no sabe que pensar, casi mejor me quedo en la cama un rato más, que ahora en invierno se está muy “agustico”. ¡No! analicemos nuestros stand-up.

PRIMERO UN POCO DE REALIDAD

La realidad es que desde el teletrabajo los stand-ups solemos hacerlos sentados. Pero conservan el nombre. Y sí, a veces se alargan. En lugar de ver un círculo de gente rodeada de post-its y tareas en los cristales, veo los caretos de todos mis compañeros en primer plano (un porcentaje muy alto no nos hemos peinado, pero los auriculares lo disimulan). Eso sí, en lugar de post-its tengo mi libreta y un tablero de Trello con lo que he hecho, las siguientes tareas y lo que quiero comentar.

Empieza el stand-up, suele empezar el que ha compartido el enlace, tradición (todavía no es automático, ¡por el amor del MEV!).
Lo normal:
– Sujeto 1: Ayer hice esto y aquello, me queda pendiente esto que lo hago ahora por la mañana. Luego me pongo con aquello. Hoy trabajaré a partir de las 11:00 que me voy al médico.

Normalmente la cosa acaba aquí. Pero hay diferentes casuísticas interesantes.
Seguir leyendo

Sobre código, revisiones y despliegues

Lo sé. Lo admito. Me encanta la sensación de acabar de programar algo a las 5 de la mañana. Satisfecho. Orgulloso. Tal vez con un exceso de cafeína. Mergeas, despliegas y a dormir con una sonrisa. En tus sueños un cowboy se monta en su caballo, llega al pueblo y desmonta bajo la mirada de los pueblerinos. Captura a los malos, se sacude el polvo y se va triunfal con los suspiros de aquellos y aquellas a sus espaldas. Sí, ese desarrollador cowboy que es capaz de hacerlo todo, sin hablar con nadie, sin consensuar nada.

Te levantas con la sonrisa todavía en la boca (dejemos de lado babas y otros sucesos paranormales). Vas al ordenador y ¡boom!, algo ha ido mal. La explosión despierta hasta al cowboy de tus sueños, que se tapa con una piel y se acurruca junto a la hoguera, ahora hay miedo en ojos del valiente cowboy. Creo que esta historia nos suena a muchos y a muchas. Y sí, los sueños y las sonrisas, e incluso las risas molan; pero mejor dejar las explosiones para nuestros proyectos locos y no para los serios, o para el trabajo.

Historias de usuario públicas. Ramas. Revisión de código. Pruebas manuales. Pruebas automáticas. Despliegues. El cowboy puede hacer lo que quiera, que vamos a hacer que esto no explote (o mejor dicho, que explote cuanto menos, mejor).
Seguir leyendo

Global Day of Code Retreat en Aragón

Tenemos el placer de anunciar que, junto con Teresa Oliver (más conocida en twitter como @tolivern) y el Parque Tecnológico Walqa, Frogtek va a organizar el Global Day of Code Retreat en Aragón.

¿Qué es el Global Day of Code Retreat?. Corey Haines lo explica mucho mejor que yo, pero en pocas palabras se podría decir que es un día para celebrar la pasión por el software y por el craftmanship, palabro que se refiere a la calidad personal que un artesano pone en su trabajo y que muchos programadores se esfuerzan por poner en el suyo.

¿Cómo lo vamos a celebrar?. Con una especie de gran Coding Dojo de un día entero de duración que llevaremos a cabo simultáneamente con decenas de ciudades en otras partes del mundo. En Aragón, los programadores que estén por la zona y quieran pasar un día de práctica intensiva de diseño y programación están invitados a unirse a nosotros en el edificio de servicios generales (el de la cafetería) del Parque Tecnológico Walqa en Huesca. Será el próximo 3 de Diciembre y contaremos con un facilitador de lujo, Sebastián Hermida. Sebastian posee el acento raro de los vídeos de http://holatdd.com. Le gusta el fresco aroma del verde de los tests y la programacion por pares. Intenta hacer que escribir tests sea divertido con http://happyprog.com. Quiere que te lo pases en grande hablando y programando en ingles con http://elkataingles.comDespués de 10 años fuera del pais, vuelve a disfrutar de España empezando una nueva aventura con http://path11.com, de la que es co-fundador junto con, entre otras personas, otro de los grandes, Enrique Comba. No te lo pierdas y ven a conocer gente interesante a Walqa.

Algunos temas logísticos:

  • Horario: de 10:00 a 18:00
  • Lugar: Edificio de Servicios Generales del Parque Tecnológico Walqa
  • Precio: Gratuito
  • Inscripciones: mandando un correo con título “Inscripción Code Retreat” y con tu nombre a walqa@ptwalqa.com
  • Número de plazas: mínimo 12, máximo 30
  • Comida: Walqa nos pone café y galletas a discrección, para la comida hemos negociado un menú de 9€ en la cafetería
  • Trae tu propio ordenador!

Un saludo y os esperamos a todos en Walqa. ¡Con todo esto y otras sorpresas!.

Actualización: además de la inscripción oficial vía mail puedes unirte al evento en la web de Code Retreat donde puedes ver parte de la gente que va a acudir y mandar comentarios y propuestas.

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.

 

Desk-Surfing

La semana pasada tuvimos a @francho_lab en la oficina, no voy a entrar en detalles de lo interesante que fue su visita porque soy el menos indicado para hacerlo y porque cualquiera de los programadores lo hará mucho mejor que yo. Pero sí que me gustaría ensalzar las virtudes de este tipo de intercambios informales y de la web que se montó con ese objetivo, Desk-Surfing.Org, después de la última Agile Open Spain 2011 de Pamplona.

Para nosotros éste ha sido el cuarto intercambio/visita. Anteriormente hemos tenido el honor de tener a @carlosble, @hell03610 (Emma) y a @rubenbpv. Además Pedro estuvo tres días en Biko2 y Julio ha estado 2 en PocketWidget. Todas y cada una de las visitas han sido fuente de innumerables mejoras. El mero hecho de salir y ver un entorno diferente o recibir a una persona de otra empresa hace que te replantees la forma de trabajar, aprendas nuevas técnicas o procesos.

Son estas cosas, junto con la asistencias a eventos como las AOS o la CAS, las que nos dan los empujones necesarios para seguir mejorando continuamente. Por eso Frogtek se registro en la web Desk-Surfing.Org y por eso continuaremos acogiendo y enviando ingenieros en el futuro. ¡Os animamos a todos a probar la experiencia!.

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?

Detalles para el Coding Dojo

Rubén ha publicado en su blog los detalles de la kata que haremos el próximo día 8 de abril. Se trata de la conocida String Calculator: conéctate a su página para conocer los detalles del enunciado y los consejos de Rubén para iniciarte en el TDD.

Aún tenemos huecos para el Dojo, ¡nos vemos en menos de dos semanas!.

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.


Antiguas entradas