Developing Frogtek

El blog del Departamento de Tecnología

Categoría: eficiencia (página 1 de 3)

La comunicación y las nuevas herramientas: Slack

Siguiendo con el tema de la comunicación que ha iniciado Miky, me gustaría ahondar un poquito más en el tema.

El día 1 de abril, en Zaragoza, acudí al siguiente meetup donde Francho nos explicó cómo en su empresa, Spines, usan Slack y sus distintas integraciones. Siendo el centro de estas integraciones Hubot, un bot que permite realizar una serie de automatismos e integrar servicios y acciones fácilmente con Slack.

Como buen friki que soy tengo muchas ganas de montarme mi propio Hubot y ponerlo en nuestro Slack, pero eso no fue lo que más me llamó la atención de la charla. Lo que más me tocó fue el que ellos llevarán casi toda la comunicación a través de Slack. El email lo usaban lo mínimo. Según nos contó Francho en su cuenta de correo de la empresa sólo tenía 5 mails en los dos años y pico de empresa que llevan. Para poder llegar a esto, nos comentó que la clave residía en la separación correcta de las conversaciones en distintos canales, permitiendo así la selección de las conversaciones y facilitando la búsqueda y lectura de las mismas.

Como ya comentó Miky nosotros llevamos menos tiempo con Slack y nos ha reportado ya una serie de beneficios increíbles. No tengo claro que el objetivo deba ser abandonar el email del todo, pero sí que veo que para ciertos tipos de comunicación deberíamos tender más a Slack, sobre todo en torno a emails automáticos y alertas. Además creo que el tema de los canales por conversación tiene mucho sentido. Ahora mismo sufrimos, entiendo, uno de los primeros anti-patrones de uso de Slack, que es mezclar y tener muchas conversaciones en un mismo canal. No es que tengamos un único canal, ni mucho menos, pero igual deberíamos plantearnos dividir alguno más y acostumbrarnos a hacer un buen uso de los canales.

Al fin y al cabo es lo mismo que ocurre con el email. Con un buen uso de la herramienta se puede conseguir mejorar mucho la comunicación, sobre todo su calidad y facilidad de lectura. Aplicar una herramienta nueva lleva su tiempo y se necesitan distintas iteraciones hasta que se consigue dar en el clavo. Tenemos que trabajar en ello, así que ya tengo tema para la siguiente retrospectiva.

Comunicación: ajustando una máquina compleja (Work In Progress)

Comunicación: ajustando una máquina compleja (Work In Progress)

En Frogtek trabajamos personas desde diferentes sitios de la geografía mundial. Principalmente trabajamos desde varias ciudades de tres países: México, Colombia y España. Pero también tenemos que trabajar con gente en los EEUU y otros países. Y este aspecto en una empresa, sin duda alguna, es todo un reto.

Si ahora volvemos la vista atrás se podían ver varias máquinas (una por país) trabajando cada una con su entorno, dando lo mejor de ellas mismas, y de vez en cuando interactuando con las demás. Diferentes procedimientos, diferentes expectativas y prioridades, diferentes zonas horarias, diferentes culturas, … al final demasiadas diferencias que hacían que las interacciones entre las diferentes máquinas estuvieran lejos del óptimo.

Desde hace unos meses se ha realizado un esfuerzo notable y global en toda la empresa por homogeneizar la comunicación y los procesos. Un esfuerzo donde cada una de las máquinas debe entender la forma de trabajar del resto, buscando empatía en los diversos problemas que aparecen en otros engranajes, mejorando de forma proactiva todo lo que se puede.

Todavía hace falta mucho “3 en 1”, pero esas máquinas independientes que había antaño se han convertido en varios módulos que se relacionan de forma constante los unos con los otros. Parece que los primeros pasos se han dado y ahora la máquina evoluciona de forma autónoma. Las relaciones se estrechan y se agilizan, se minimizan las esperas. ¿Qué ha cambiado en este tiempo?
Seguir leyendo

El Día del Bedel

El último viernes día 6 estaba marcado en el calendario de nuestra oficina como Janitor’s Day. ¿En qué consiste este día? El día del Janitor, bedel en español, es un día de trabajo que se dedica a limpiar, pulir y dar esplendor a todo la suciedad, desorden o incidencia en nuestro software (aunque claro, también podría haberse llamado el Día del Apaleamiento).

De esta forma, durante un día el equipo se dedica en exclusiva a realizar mejoras y modificaciones en el código que de otra manera se hubieran postergado y abandonado en el olvido.

El janitor de Scrubs, hombre 10

Para organizar el evento, creamos una hoja de cálculo con una amalgama de tareas que realizar. La idea era que voluntariamente, cada uno tomáramos una de esas tareas y nos encargáramos de solucionarla. Las tareas podían ser tan variopintas como arreglar una tanda de tests, refactorizar una clase o traducir al inglés las cadenas que quedan en español en la aplicación.

En definitiva: todos los que trabajamos en software nos damos cuenta de que en ocasiones, algunas tareas se postponen o se descartan porque se descubren a mitad de otra tarea, y el miedo al cambio de contexto impide su realización. Es por ello que realizar un Janitor’s Day cada cierto tiempo es una tarea que recomendamos encarecidamente, ya que las ventajas son incontables:

  • Permite coordinar al equipo en un mismo objetivo
  • Aumenta el control del código por parte del equipo.
  • Permite e incluso potencia el pair programming
  • Da cabida a tareas que de otra forma jamás se realizarían (desidia, desconocimiento del problema por parte del C-level, …)

Cómo evitar abrir más de una Activity desde un botón

  • ¿Harto de que se pueda pulsar un botón de tu aplicación repetidas veces antes de que se cree la nueva Activity?
  • ¿Harto de tratar de evitar este comportamiento deshabilitando el botón nada más ser pulsado, y que aun así se lancen Activity sin talento?
  • ¿Harto de consultar StackOverflow y la Internet entera para no encontrar una solución que funcione de verdad?

Nosotros también lo estábamos. Concretamente, habíamos estado experimentando este problema durante años. Ahora tenemos la solución.

Como nunca hemos sido unos expertos programadores, y teníamos muchas prisas por sacar mucho trabajo adelante, nos fiábamos del “método Google” para iniciar una nueva Activity:

Intent intent = new Intent(this, NuevaActivity.class);
this.startActivity(intent);

Y aun así… daba igual que la nueva, como la vieja Activity procesaran mucha información, o poca, que marcásemos la nueva Activity como singleTop, que invocásemos al setEnabled(false); del objeto View que llamaba al startActivity(). También hemos de decir que nuestros usuarios son expertos en pulsar varios botones al mismo tiempo, o que les tiemble el dedo y hagan varias pulsaciones muy rápidas sobre el mismo botón, o que debido a la lentitud del hardware chino se desesperen a la hora de completar una tarea y sigan pulsando el mismo botón hasta el infinito y más allá.
Abrir dos o más instancias de una Activity en nuestra aplicación era muy sencillo, hasta que se nos ocurrió convertir la variable de tipo Intent en un field de nuestra clase de tipo Activity padre. Y cada vez que queremos invocar al startActivity(intent);, lo hacemos sólo si el field intent es == null.
Hay que tener cuidado si la Activity padre es una pantalla principal desde la que se pueden iniciar distintas Activity, por que si todos los new Intent() los asociamos con el field que comentaba antes, al querer iniciar la segunda vez la Activity, como intent != null, la aplicación no haría nada. Es decisión del lector de esta entrada saber cuándo hacer que el field intent sea igual a null de nuevo. ¿Quizás en el onResume()? ¿O mejor en el onActivityResult()? ¿Qué tal crear una clase de tipo Activity con este truco y que todas las actividades de la aplicación hereden de esta clase?

A nosotros nos funciona a la perfección, ¿y a ti?

Cualquier mejora a este truco, queja, grito, etc. es más que bienvenida.

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

actionbarsherlock para Android

Hace poco nos vimos en la tesitura de querer añadir una actionBar a nuestra aplicación. Investigando sobre cómo hacerlo, nos dimos cuenta de que la compatibilidad hacía atrás era un poco “laboriosa“.

Mientras dudábamos sobre cómo afrontar la creación de la nueva actionBar, nuestro querido compañero Francho nos informó de la existencia de ActionBarSherlock.

ActionBarSherlock es una librería que facilita el uso de la librería de compatibilidad de Android y además incorpora la creación de la barra de acciones que por defecto no está soportada. Su funcionamiento es impecable y simplifica mucho el uso de todos los elementos no soportados en versiones pre-HoneyComb.

Echadle un vistazo si estáis pensando dar soporte a versiones antiguas, sin perder la potencia de los elementos y herramientas de lo más nuevo de Android.

 

Visualizar el servidor de integración continua

Monitor de monitorizaciónOs presento la última “frikada” que hemos añadido a nuestra colección de gadgets de oficina.

Con el viejo servidor, actualmente en desuso, una pantalla vieja y el plugin de Jenkins  eXtreme Feedback Panel Plugin. Hemos montado un visualizador del estado de nuestro servidor de integración continua (Jenkins).

El objetivo esta claro. Conseguir estar enterados en todo momento de la salud de nuestras construcciones. Ya no vale eso de “no vi el email”.

Además informa del culpable de la rotura si la hay. Y muestra el número de tests añadidos en la última construcción, entre otras virguerías.

 

 

 

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.

Drive, de Daniel H. Pink

Drive book

Increíble libro que ahonda en el “sistema operativo” que nos conduce. Planteando lo anticuado que se está quedando el sistema tradicional de motivación del “palo y las zanahorias” del Siglo XX con respecto al nuevo sistema del Siglo XXI, donde la motivación se basa en factores no tan extrínsecos y más intrínsecos como la autonomía, el propósito y la maestría.

Conforme iba leyendo me ha encantado ver que en nuestra empresa mucho de estos conceptos ya se están aplicando en mayor o menor medida. Y me encanta poder disfrutar de un ambiente tan positivo para crecer como persona y profesional.

Mucho de lo explicado en el libro me sonaba ya. O lo había comentado de una forma u otra con los amigos… Pero no es lo mismo hablarlo, o intuir un concepto que leer las teorías, las explicaciones, todo. He salido con muchas ideas nuevas para auto motivarme. Un libro que vale la pena mucho leerse, desde mi punto de vista.

Para aquellos más vagos, os dejo un vídeo que resume parte de sus teorías de una forma graciosa e interesante. Además también esta disponible la Ted Talk que dio Daniel Pink en 2009.

 

Android y sus Layouts

Imaginad que al realizar una aplicación web compleja, en vez de hacerla para que se vea bien en todos los navegadores, la hacéis solo para una resolución de pantalla concreta y un navegador específico. Sería un infierno tener que repasarla entera, una vez acabada, para que se adapte a cualquier navegador y resolución, ¿verdad?.

Android Layout

Pues algo así nos pasó a nosotros, pero en Android. Parte de culpa tuvimos, he de reconocer, por no ser previsores y tirarnos por el camino fácil. Aunque diré en nuestra defensa que cuando se empezó nuestro producto Android estaba en pañales y no existía tanta tablet y teléfono en el cual ejecutar tu aplicación.

Aquí van pues una serie de recomendaciones. Para que no cometáis los mismos errores que nosotros.

  • Entended cómo funciona el tema de las pantallas en Android, no es lo mismo una densidad que otra, el tamaño de pantalla, etc.
  • No uséis la unidad de medida px. Mejor dp, o sp si son tamaños de texto.
  • Tened claro como elige Android los recursos que ponéis a su disponibilidad.
  • Evitad en toda medida posible usar layouts con medidas absolutas, hacedlos adaptables (fill_parent, wrap_content). Os ahorrareis muchos quebraderos de cabeza.
  • Si no podéis evitarlo y tenéis que usar valores en vuestros layouts. Extraedlos a un xml y definidlos como Dimensions. Así os será más fácil adaptar la aplicación a las distintas configuraciones que queráis soportar, pues con definir el archivo de dimensiones para cada modalidad de recursos os valdrá.
  • Usad el atributo android:drawableTop, android:drawableLeft…, para introducir imágenes en botones. No os pase como a nosotros que o pedíamos el fondo ya con la imagen o introducíamos un elemento adicional, recargando el layout.
  • No os dejéis enamorar por las bondades de los RelativeLayout. No son malos. Pero a veces un LinearLayout con sus pesos puede ser más fácilmente adaptado a varias pantallas.

Y nada más. Si se os ocurre alguna más que nosotros no hemos nombrado, compartidlo con todos!

 

Antiguas entradas