Developing Frogtek

El blog del Departamento de Tecnología

Categoría: agile (página 1 de 4)

Trello y nuestro workflow de trabajo

Ya contamos en un post anterior parte del proceso de selección en el área de tecnología de Frogtek. Pero todavía podemos desvelar algún secreto más, y es que una de las primeras cosas que recibes al entrar el grupo de tecnología es una cuenta de Trello. Hasta ese momento podías conocer Trello o no; podías haberlo usado un poco para algunos proyectos, o tal vez para gestionar tus propias tareas. Pero ahora, con el acceso a los tableros de Frogtek… ya no hay vuelta atrás.

Fue una de las cosas que más me impactó: todo tiene una tarjeta de Trello. Y sí, lo admito, al principio es un poco overwhelming, tantos tableros, tantas notificaciones. Pero ahora ya está en el ADN, ya forma parte de uno mismo. Y si no está en Trello, seguramente, no ha pasado. De todas los procesos que tenemos trellificados me gustaría centrarme hoy en uno: las peticiones que se realizan a tecnología.
Seguir leyendo

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

Conferencia Agile Spain 2016

La Conferencia Agile Spain es uno de los dos eventos organizados a nivel nacional por la asociación Agile Spain. Desde Frogtek acudimos todos los años a aprender y compartir sobre metodologías ágiles. Este año nos ha tocado a Jorge y a ser los privilegiados que íbamos en representación de Frogtek.

Hacía ya un par de años que no podía acercarme y he vuelto con la cabeza llena de ideas y cosas para hacer. La verdad es que no recordaba lo que me cargan las pilas este tipo de eventos. Las charlas pueden gustarme más o menos según elija. Pero siempre me hacen pensar, de una forma otra. De hecho a mitad de muchas de ellas me sorprendo a mi mismo evadido de la charla y pensando en como aplicar el concepto que acaba de explicar el ponente en nuestra empresa. O cómo nos afecta o por qué deberíamos mejorar en ese area.

Vamos que nunca me deja indiferente un sitio tan lleno de gente con ideas tan buenas y con tantas ganas de compartirlas. Además este año la organización ha estado de diez. Así que muchas gracias desde aquí a todos los que han participado, ponentes, voluntarios, etc. Por ayudar a que podamos seguir mejorando.

FOSDEM y Config Management 2016

Acudir a diferentes charlas y eventos creo que es una parte imprescindible de la mejora continua de cualquier persona. Más importante todavía me parece cuando hablamos de personas que trabajan dentro del mundo de la tecnología, donde, siguiendo el tópico, todo avanza muy rápido. No es oro todo lo que reluce dentro de toda esas nuevas tecnologías, a veces tienen mucho de hype, pero lo cierto es que un año es mucho tiempo. Estar a la última en cuanto a tecnología a veces puede ser la diferencia entre un éxito y un fracaso estrepitoso.

Dentro de esa mejora continua Julio y Miky (el que escribe) tuvimos la suerte de poder ir a la FOSDEM y a la Config Management. Dos eventos que viven hermanados, pues son en días consecutivos en ciudades cercanas. Para mí ya es el cuarto año que acudo a la FOSDEM, pero el primero en el que acudo a la Conf Management. Primero explicar un poco de las charlas, pero luego, con permiso, entraré en detalles de lo que nos traemos en el zurrón de cada una de ellas.
Seguir leyendo

Seleccionando: un día de convivencia con un candidato con kata incluida

Kata en Frogtek

Si nos sigues un poquito seguro que te habrás enterado, buscamos candidatos, ingenieros de software. Detrás de un producto como Tiendatek hay muchas personas trabajando, un equipo que fluctúa y se adapta a las nuevas necesidades, algunos se han ido, otros hemos llegado, incluso algunos se van, aprenden y mejoran buscando nuevas aventuras, y vuelven con fuerzas renovadas. Nos sentimos orgullosos del equipo que formamos, y una parte importante para construir el equipo es el proceso de selección.

Si las personas sólo fuéramos recursos, números o conocimientos, la selección de personal sería muy fácil, seguramente sólo se necesitara una prueba que garantizara que en el CV no se ha mentido. Pero afortunadamente para todos, menos para RRHH, supongo, somos mucho más que números y conocimientos. Somos unos cacharros normalmente con brazos y piernas que tienen sentimientos, que tienen aficiones y afinidades. Y es que cinco personas bien avenidas garantizan mejor trabajo y durabilidad que cinco personas malavenidas.

Por eso nos gusta ofrecer a los candidatos que entrevistamos, y vemos que pueden encajar en el puesto, un día de convivencia en la oficina de Frogtek. Es un día especial. Ahora ya he vivido esa experiencia desde los dos bandos, y desde ambos dos se ve muy enriquecedora. Desde uno de los lados se ve con bastantes nervios e inquietud; acabas con la cabeza llena de demasiada información y, en mi caso, vuelves a casa con un buen dolor de cabeza. Desde el otro lado lo esperas con impaciencia, intentas enseñar y hacer que la otra persona se sienta cómoda, y al final siempre aprendes algo nuevo de la persona que ha venido.
Seguir leyendo

Continuous learning, un ‘must’ para todos

El pasado 4 de diciembre dentro de la Conferencia Agile Spain 2015 tuve la oportunidad de asistir a una charla de Miguel Grazziotin. La charla fue justo después del descanso para comer, apenas éramos un poco más de diez personas en la sala, no entendíamos muy bien el título de la misma, pero al final, resultó ser, personalmente, una de las charlas más inspiradoras.

La charla tenía el título de “Jacket on, jacket off – Stop working and start training!”, no demasiado amigable, pero el contenido era sencillo. ¿Qué es entrenar/aprender? ¿Por qué entrenar/aprender? ¿Qué entrenar/aprender? Al final de la charla tenía un revuelo de mis propias creencias sumadas a lo que acababa de escuchar en una buena charla (aunque tal vez un poco aséptica). Nada mejor que escribir para poner orden, compartir, discutir y mejorar.

Como individuo: el aprendizaje como elemento clave

¿En el trabajo también? Desde hace ya algunos años he visto el trabajo como una oportunidad única. Entre otras cosas, trabajar es la oportunidad de aprender y vivir en un entorno positivo y exigente; una oportunidad por la que además te van a recompensar con dinero (principalmente) que te va a servir para invertirlo en más aprendizaje y vivencias. Un puesto de trabajo debe aportar de forma activa a nuestra mejoría como persona.
Seguir leyendo

La regla del boy Scout

Desde mi último cambio de trabajo le he estado dando vueltas a un tema que me parece interesante.

Por un lado en el traspaso de conocimiento que hice antes de irme de Zentyal, la persona que se incorporaba llegó con energía, cuestionándose las cosas y mejorando en general todos los sistemas que yo le estaba traspasando. Había cosas que él proponía que me costaba aceptar. Seguramente porque no quería reconocer que me había acomodado, ya no buscaba las mejoras con el mismo ímpetu y ganas; y había dejado que ciertas áreas se estancaran bastante.

Al entrar de nuevo en Frogtek sí que fui yo el que se puso a buscar dónde aplicar todo lo aprendido desde mi última vez por aquí, planteando mejoras y buscando sitios donde aplicar mis conocimientos para el provecho del equipo. Ahora voy con mucha energía y ganas, pero me da miedo que dentro de un tiempo vuelva a acomodarme otra vez y me cueste buscar mejoras y realizarlas.

Creo que el problema tiene mucho que ver con la teoría de las ventanas rotas. Al principio, al llegar, quiero mejorarlo todo porque creo que el edificio esta nuevecito, para mí obviamente lo está. Pero conforme pasa el tiempo y voy conociendo más los entresijos de la empresa, el equipo, el código… se me van rompiendo las ventanas y me va dando más pereza intentar arreglarlas. Porque me parece el estado normal, total una ventana más o menos qué más da,  ¿no? ¿ Qué importa un archivo sin usar en el repositorio, una librería desactualizada, un proceso mejorable o unos tests de más o menos?

¡¡Mucho!! Por eso creo que es muy importante La regla del boy Scout, pero no sólo aplicada al código, sino a todo. Cada vez que toquemos un archivo del repo, cambiemos una configuración de Jenkins o simplemente asistamos a una reunión del proceso. Hay que estar atentos para buscar esos pequeños cambios o mejoras que nos van a permitir poco a poco llevar nuestro trabajo, y el del todo el equipo, a otro nivel.

Hay que tener paciencia y no desesperar, no sólo los grandes refactors pueden ayudarte a saber vivir con tu deuda técnica, pequeño paso a pequeño paso se puede llegar muy lejos. A ver si soy capaz de tener paciencia y aplicarme esta última frase.

Charla de Ángel Medinilla en Walqa: el biopic

El pasado lunes día 12 de noviembre tuvimos el honor de recibir a Ángel Medinilla (@angel_m) en el parque tecnológico Walqa (aprovechando su décimo aniversario) para que diera una charla sobre Agile en la empresa. Para el que no lo conozca, Ángel es un coach y consultor agile que lleva ya un tiempo recorriéndose el mundo asesorando a empresas sobre agilismo y contando su experiencia al respecto.

Como no me gustan mucho las notas de prensa en las que se fusila todo lo que dice el conferenciante, voy a escribir acerca de qué reflexiones he inferido tras asistir a su charla. Lo cual nos lleva al siguiente disclaimer…

DISCLAIMER: los siguientes puntos no están firmados por el propio Medinilla, son solo reflexiones obtenidas por mi parte. Al igual que con los biopics (películas basadas en la vida de alguien famoso), cualquier parecido con la realidad puede no ser cierto 😀

  • Las empresas de hoy en día son hijas de las cadenas de montaje y nietas del ejército de Roma. Estamos trabajando en compañías herederas de las ideas de Taylor y Ford (muchas de ellas incluso tienen residuos de las primeras grandes empresas: los ejércitos) y con ello, arrastrando conceptos empresariales basados en paradigmas del pasado, que pueden funcionar para una cadena de montaje, pero no para compañías basadas en el conocimiento. Suele circular por internet una anécdota graciosa: “¿Por qué los reactores de los cohetes de la NASA tienen la anchura de dos culos de caballo?… Pues bien, todo se debe a que los reactores han de ser trasladados hasta Cabo Cañaveral por tren, el ancho de las vías del tren se tomó en función del tamaño de los coches, y el coche en función del tamaño de la carretera, que es un legado del imperio romano, el cual quiso que la carretera tuviese el tamaño de dos caballos, para así permitir la circulación de carros.” Basándonos en esta anécdota, se me ocurre un paralelismo igual de gracioso: ¿Por qué algunos desarrolladores de software van a trabajar con traje y fichan nada más entrar?
  • No hay que ser esclavos de los estándares. Principalmente porque los estándares deberían revisarse continuamente. Siguiendo la filosofía lean, deberíamos usar estándares para asegurarnos de que todos estamos haciendo lo mismo. Intentar algo más complejo que eso solo va a conseguir que tengamos un sistema anquilosado difícil de renovar.
  • Muchos managers son sargentos chusqueros y deberían ser entrenadores. Donde las empresas basadas en los paradigmas de Taylor y Ford necesitaban de un supervisor que controlara la productividad de sus trabajadores, las empresas del conocimiento de hoy en día necesitan de líderes que sepan motivar y potenciar las capacidades de un equipo. Lo que llamaríamos en inglés un enabler, alguien que pueda conseguir que su equipo dé lo mejor de sí mismo.
  • Mejor que intentar ser agile es entender por qué queremos ser agile. Al igual que en el ejemplo del cargo cult, el hecho de poner post-its en la oficina para indicar las tareas (al estilo de las oficinas con sala de relax con el guitar hero porque Google la tiene) no va a hacer que nuestra empresa mejore. Tenemos que entender qué motivaciones tiene agile para poder comprender por qué queremos usar agile (¡o incluso si realmente queremos usarlo!)
  • Agile no es un paracaídas ni la pluma de Dumbo. No nos engañemos: la mera implantación de Agile no va a conseguir que hagamos software de calidad, ni que ingresemos más dinero, o que nuestros competidores vayan a la ruina. Es simplemente una metodología de desarrollo de proyectos mucho más orientada al cambio y a la mejora continua. Podemos migrar una empresa a agile, pero esto no va a  otorgarnos capacidad de mejora, entrega o adaptación. Estas capacidades son los requisitos para el camino Agile, no las recompensas.
  • Tenemos que ser escépticos respecto a Agile. Las metodologías ágiles representan un camino, una serie de filosofías que pueden ser de utilidad para las empresas. Pero no tiene por qué ser buenas para TU empresa. Como decía Henrik Kniberg, Scrum es una herramienta, puedes usarla como te plazca. Cada empresa es un mundo y como tal, es muy difícil que Agile te dé una solución personalizada. Eso sí, si modificas Scrum a tu antojo, luego no vayas diciendo por ahí que Scrum no te ha funcionado 😀

Slides de la charla en http://www.slideshare.net/proyectalis/agilidad-empresarial

¿Para qué sirve ser ágil en una start-up?

Mucho agile, mucho agile… pero si te descuidas puedes acabar en una empresa en la que lo único agile es el motor y para de contar, más cuando el equipo de producción, como en nuestro caso, está aislado del resto o directamente, como pasa en las consultoras, no hay resto. Ésta es un poco la conclusión que he obtenido tras leer los libros “Lean Start-up Method” de Eric Ries, “The four steps to the epiphany” de Steve Blank y después de conocer un poco el mundillo éste del agilismo en España… y por experiencia propia, por qué no decirlo.

Supongo que en parte es porque el mundo del software ibérico está principalmente orientado a programar para terceros y en ese caso ser ágil es “tan fácil” (y tan difícil) como pegarte unos años hasta que haces scrum, tdd y demás como Dios manda y conseguir que el cliente acuda a las reuniones y se involucre en el proceso de cada sprint. Pero la realidad es que detrás de los métodos ágiles hay mucho más y es algo de lo que no se oye hablar demasiado. Hace mucho que no acudo a ninguna AOS, ni CAS (siempre me coinciden con algo que no puedo dejar para otro momento), pero la primera CAS a la que acudí (2010) me encantó, sabíamos tan poco de métodos ágiles que cada charla era un nuevo mundo de conocimientos y posibilidades. Desde entonces si no yo, siempre alguien de Frogtek ha acudido a estos eventos y trasladado lo que allí ha aprendido. Últimamente, sin embargo, me empezó a sorprender que si bien toda la comunidad está muy interesada en ser técnicamente ágiles, no parece haber tanta ebullición, o al menos yo no la he detectado, una capa por encima de eso. Está bien tener un método de producción iterativo-incremental, está bien ofrecer al cliente (que muchas veces no es el usuario final, desgraciadamente) un proceso súper adaptable a sus cambios de humor y requisitos… pero estaría mejor dotarnos de los procesos, que tiene que haberlos, para utilizar este gran método para crear el producto que el usuario final necesita. Para ello no basta con que el equipo de desarrollo sea ágil, hay que aprovechar esa agilidad para que los equipos de marketing y ventas (o el product owner, o los encargados de desarrollo de cliente, o quien sea) puedan, a su vez, realizar sus propios experimentos, implementar sus propias métricas y tener sus propios objetivos iterativos e incrementales que nada tengan que ver con el desarrollo y sí con el negocio. Por eso, echo de menos, conceptos que Ries maneja en su libro como “indicadores vanidosos”, “indicadores accionables”, “análisis de cohortes”, “contabilidad de la innovación“… conceptos sin los que scrum, tdd, los sprints y todo lo demás no sirven más que para tener un proceso de desarrollo flexible y adaptable… lo cual no tiene porqué evitar que se acabe construyendo de forma eficiente y completamente flexiblemente un producto totalmente inútil. Supongo que, en España, el principal problema es precisamente que no existen muchas start-ups y hay, sin embargo, demasiadas factorías de software… y en una factoría de software es difícil vislumbrar nada más allá de lo técnico (por no hablar ya de meter baza) y suficiente se tiene con lidiar con el cliente.

Frogtek no es una software factory pero también hemos sufrido en parte ese problema. Tras varios años de trabajo teníamos un equipo de tecnología muy “agile” y muy “kaizen” que implementaba las “ocurrencias” de la empresa de manera eficiente y puntual. Ocurrencias, dicho en el mejor de los sentidos y con todo el cariño, que trataban de ser lo más meditadas posible y que suponíamos beneficiosas para los tenderos y que, lo fueran o no permanecían en el producto sine die. El problema de esta aproximación es que no es todo lo científica que debería ya se basa en asunciones que habría que comprobar, pero que rara vez se comprueban, por falta de tiempo y de proceso principalmente. No basta con implementar User Stories por muy bien definidas que estén, el cementerio está lleno de productos técnicamente impecables. Para solucionar esto en Frogtek vamos a utilizar una capa más de abstracción, basada en Épicas, que iría sobre los sprints de User Stories. Una Épica no es más que un objetivo del product owner para un sprint determinado. Algo así como el objetivo estratégico de alto nivel de mejorar el indicador X de la empresa en un x% (p.e. “hay que conseguir que el 80% de los tenderos levanten su inventario en menos de 2 horas”). Muchas veces, este tipo de mejoras no es cuestión de una sola User Story es, más bien y por limitarlo al producto, un conjunto de historias (“el producto debe adivinar los precios”, “el producto debe adivinar los costes”, “el producto debe proponer los productos más comunes”, “el interfaz debe cambiar así o asá”…) que se pueden desarrollar durante un sprint (de forma ágil, claro), la diferencia con nuestra aproximación pasada es que terminado el sprint el trabajo del product owner no ha hecho más que empezar y a la vez que se empieza a pensar en el sprint siguiente, tiene que echarle un ojo al indicador asociado a la Épica del sprint pasado con el objeto de aprender si los cambios en el producto están teniendo el efecto deseado en el comportamiento real de los usuarios o, por el contrario, no han servido para nada y se necesitan más cambios (volver a iterar).

 

El trabajo del product owner se complica, ya que como se ve en el dibujo el contenido del sprint N empieza a analizar incluso antes de que empiece el sprint N-1.  La secuencia es la siguiente:

  1. Recoger indicadores.
  2. Analizar indicadores y Épicas en evaluación para decidir los objetivos (creando nuevas o modificando Épicas).
  3. Desglosar las Épicas en historias de usuario.
  4. Preparar la historias de usuario (mock-ups, pruebas de usabilidad con clientes, más mock-ups…).
  5. Estimar historias de usuario.
  6. Ejecutar el sprint (incluyendo pruebas, instalación en friendly users, etc).
  7. Instalar nueva versión en usuarios.
  8. Vuelta a 1.

Normalmente los indicadores a recoger y analizar necesitan un tiempo hasta que se generan, al menos en nuestro caso, así que no será extraño que las Épicas que se evalúen en un momento dado se hayan implementado hace dos, tres o más sprints. Por lo tanto el PO, no sólo tiene que estar pendiente del sprint actual sino que tiene que pensar en las Épicas (objetivos estratégicos del producto) que querrá definir para el sprint siguiente, mientras que monitoriza meticulosamente los indicadores asociados a las Épicas que están ahora mismo en evaluación y que pueden seguir así por uno o varios sprints. Porque una Épica, como una User Story, tiene un ciclo de vida ¡e incluso su propia tabla! (se proponen, se discuten, se diseñan, se implementan, se evalúan y si están bien se archivan, muy propio para una tabla de kanban) pero a diferencia de una User Story la evaluación no depende de factores meramente técnicos, si no que es función del valor que aporte al usuario final (si está bien definida y si se monitoriza usando datos reales). El paralelismo con las User Stories también tiene otras ventajas, se puede medir el throughput en Épicas de un equipo, es decir, la velocidad de la empresa para poner hipótesis a prueba y aprender de la realidad, concepto directamente relacionado con las posibilidades de la empresa de sobrevivir.

Al final como en muchos aspectos de la vida, se pueden extraer unas cuantas enseñanzas muy interesantes: No llega más lejos la empresa que hace más User Stories, sino la que hace User Stories como consecuencia del aprendizaje validado de otras User Stories. Es importante tener un framework de gestión del trabajo ágil, pero más importante es integrar en el proceso de producción herramientas de medida como Google Analytics o Flurry que permitan obtener información sobre la utilización de las distintas funciones y que permitan discriminar entre distintos grupos de usuarios con distintas versiones para poder relacionar causas y efectos usando el análisis de cohortes (¿a los usuarios de la versión x+1 les ha ido mejor que los de la version x?). Así que ahí estamos en Frogtek, peleándonos, como buenos novatos, con Analytics y con nuestras propias métricas, discutiendo las métricas que debemos aplicar a las Épicas y tratando de encajar su ciclo de vida con el de definición e implementación de los sprints. Este post, más que una realidad, es una declaración de intenciones acerca de lo que queremos hacer para conseguir ser una “agile data-driven company” para lo cual es necesario ser ágil pero, visto lo visto, no suficiente.

Antiguas entradas