Documental sobre Squads

Squads es un documental de Invision sobre el popularizado término squads, en el que se explica su origen y se muestran unas pinceladas de cómo trabajan algunos equipos que crean productos de digitales.

Mi resumen sobre el término sería algo como tener equipos multidisciplinares donde se mezclan personas con habilidades complementarias que estén alineadas para alcanzar un objetivo común, o como mínimo aspirar a ello.

El documental se centra principalmente en la parte de descubrimiento y diseño de producto (siendo Invision una compañía de diseño tampoco sorprende :)). Aparecen personas de compañías conocidas mundialmente como Atlassian, Airbnb, Youtube… y algunas startups de menor tamaño. Además de Jeff Sutherland, uno de los creadores de Scrum; y Henrik Kniberg, el de los famosos vídeos de Spotify Engineering Culture que tanto se viralizaron y terminaron en el boom del “modelo spotify” que se ha intentado replicar tantas veces, al parecer sin demasiado éxito.

Creo que es un documental interesante para cualquiera que trabaje en el mundo de producto digital, sea cual sea su perfil. Aunque también creo que idealiza y simplifica el conseguir trabajar de ese modo.

Digo esto porque, aunque creo que tener equipos multidisciplinares es la mejor estrategia para construir producto (que los llamen squads, células, scrum teams… es irrelevante), no es algo que ocurra diciéndole a un grupo de personas que tienen que trabajar en lo mismo y eso haga que se alineen mágicamente. Hay que trabajarlo e iterarlo, y aún así puede que nunca se consiga convertir a un grupo de personas en un equipo.

Píldora. Acceder a variables de entorno desde plantillas Thymeleaf

Es una buena práctica depender de variables de entorno para las configuraciones, tanto secretos como cualquier otra configuración que puede cambiar entre los entornos de despliegue de nuestro software. De ese modo tenemos control granular de cada configuración en cada despliegue que hagamos, y en caso de tener que cambiar alguna configuración no es necesario hacer ningún commit en nuestro repositorio.

A veces es algo que hay que montar un poco más a mano, pero trabajando con Spring Boot es algo que ya está resuelto y da flexibilidad al respecto. A nivel del código de infraestructura en código dependiente de Spring simplemente usando la anotación @Value ya nos inyectará el valor que haya en el application context.

Lo que hasta hace poco no había tenido que resolver es acceder a esas variables de entorno directamente desde plantillas de Thymeleaf, en este caso para evitar tener hardcoded la configuración de Firebase Authentication.

Buscando información encontré que, como parte de la integración con Spring, es posible acceder a los beans del application context utilizando @ en las plantillas.

Así que podemos acceder al bean que representa el Environment, por ejemplo:

${@environment.getProperty("FIREBASE_API_KEY")}

Un año ayudando a equipos

Hace poco más de un año hice público que empezaba a dar servicios de consultoría para ayudar equipos, sin mucha más pretensión que por un lado ordenar mis ideas sobre los servicios que quería empezar a dar y por otro que la gente que conozco supiera de ello.

Al publicar el post tuvo muy buena acogida, infinitamente mejor de lo que hubiera imaginado nunca. Me surgieron bastantes leads de ahí, incluso un par de tentadoras ofertas para incorporarme a startups muy prometedoras que preferí declinar en ese momento.

Como es normal, de esos leads muchos no se concretaron. Ya fuera por mi parte, por la de las compañías interesadas o por ambas; no terminamos de encontrar encaje. Pero ese post sirvió perfectamente para el propósito de que gran parte de la gente que conozco me tuviera en mente.

Tipos de clientes

Durante este año he podido trabajar con algo más de una decena de empresas de distintos tamaños, que podrían agruparse en estos sectores:

  • Impresión industrial
  • Logística
  • Consultoría tecnológica
  • Alquiler de vehículos
  • Moda
  • Certificación de autenticidad
  • Medios digitales

Con contextos de lo más variopintos, desde fundadores de startups a la búsqueda de su market fit aún sin equipo técnico, hasta equipos dentro de multinacionales involucrados en grandes cambios tecnológicos y organizativos.

Formatos de las colaboraciones

En este año en algunas ocasiones aunque a veces pudiera haber buen feeling inicial sobre posibles colaboraciones, no encontraba un formato de colaboración más allá de incrustarme en los equipos unos meses. Cosa que no podía hacer tras incorporarme en Sigma Rail actuando como tech lead la mayor parte de mi tiempo.

Descartada la opción de incrustarme en equipos, tenía pensados dos formatos: Mentorías y formaciones a equipos, son dos tipos de colaboraciones que ya había hecho en el pasado varias ocasiones y con las que me sentía cómodo. A ese tipo de colaboraciones se le unió pronto el hacer asesorías, que a diferencia de las mentorías los objetivos tienden a tener un impacto más cercano al nivel organizacional, normalmente para apoyar a roles con respondabilidades de gestión.

Las formaciones no tienen mucho misterio. Procuro que sean de no más de 2 o 3 días y que no duren mucho más de media jornada, la gente tiene otras cosas que hacer aparte de estar en tus sesiones. También lo que hago es adaptar cada formación a la realidad de cada cliente, incluso las diseño de cero si es necesario. Si es para un equipo que trabaja conjuntamente procuro que buena parte del trabajo sea sobre su propio código, para facilitar llevar a su día a día lo que hayamos estado tratando.

En cuanto a las mentorías normalmente tendemos a cerrar una bolsa de sesiones inicial que puede ir renovándose si estamos todos a gusto con ello. Combinamos hacer revisiones de arquitectura y de código con programar en pair/mob. Las primeras sesiones suelen ser muy de aterrizaje por mi parte, tienden a ser revisiones de arquitectura de alguna aplicación sobre la que vayamos a trabajar en las que busco detectar de dónde vienen los principales dolores del equipo. En esas sesiones bombardeo a preguntas para conocer qué componentes tiene y cómo interactúan entre ellos, suelo hacer mucho foco en conocer los porqués de las decisiones que se tomaron en el pasado, ya que me ayuda a entender mucho mejor la situación actual. Lo malo es que a veces ya no queda nadie en el equipo que formó parte de esas decisiones y toca tirar de hipótesis.

Respecto a las asesorías técnicas, más allá de también resevar bolsas de sesiones o de horas bastante más reducidas, no tengo un formato establecido. Cada colaboración me ha resultado una situación totalmente diferente a la otra. Las que he hecho es a gente que ha llegado a mi porque ya me conocen o alguien que se fía de mi les ha pasado mi contacto, así que empezamos con un escenario de cierta confianza inicial.

Temáticas de las colaboraciones

En las formaciones, adaptando contenidos a las necesidades de cada cliente, los temas centrales a trabajar han sido en esencia tres: Testing automático, diseño de software y DevOps, pero también me pidieron una específica de Python usando buenas prácticas. En otras de esas formaciones utilizamos Java y C#, ya que el lenguaje es parte de la adaptación.

Las formaciones relacionadas con DevOps no era algo que tuviera en mente, pero llegaron un par de peticiones de empresas interesadas, así que le propuse a Néstor hacerlo conjuntamente porque creo que lo complementamos muy bien. De ahí diseñamos una formación de tres días sobre Principios y Prácticas Devops, donde nos focalizamos en los fundamentos entrando en algunas herramientas para ilustrar algunas de las prácticas, bastante cañera en mi humilde opinión ;).

De momento se me ha quedado fuera el hacer formaciones de Specification by Example (aka BDD) y de Clean Architecture, que eran temas que me apetecían pero de momento no ha surgido la posibilidad de hacerlo. En cambio, aunque fuera sólo en formato charla, sí tuve oportuniad de hablar sobre las partes exploratoria y estratégica de Domain-Driven Design.

En cuanto a mentorías básicamente hice tres. Acompañé a un equipo en el desarrollo de una aplicación móvil desde cero, colaboré en pequeñas evoluciones de un MVP aún en la búsqueda de su market fit y ayudé en poner al día componentes que a nivel técnico se habían quedado algo estancados en un ecosistema de microservicios; en esto último aún seguimos colaborando. En estos casos fui intentando aportar en temas de testing, arquitectura, pipelines de integración y entrega continua… vamos, temas habituales. Respecto a lenguajes Kotlin (que no había tenido oportunidad de usar medianamente en serio y me ha despertado aún más curiosidad), Javascript/Node y Java respectivamente.

Dentro del cajón de las asesorías como decía he hecho cosas bastante variadas, e incluso inesperadas para mi. Algunas cosas más o menos normales; como apoyar en temas de product owning, hacer auditorías o dar feedback sobre código/arquitectura de software. Pero no esperaba hacer cosas como evaluar para contratar (o no) proveedores y servicios o hacer poco más que de patito de goma para ayudar a tomar decisiones, son cosas que no me hubiera contratado nadie sin un escenario confianza previo.

¿Y ahora qué?

Cuando arranqué el año pasado no tenía muy claro qué tal iba a funcionar, tenía dudas de si iba a encontrar un interés suficiente en el tipo de servicios que quería ofrecer para hacerlo sostenible. Pero a los meses me vi en un momento en el que tuve que pisar un poco el freno y quitarme algo de trabajo para equilibrar.

De momento hay un par de clientes con los que vengo trabajando desde hace unos meses con los que vamos a seguir haciéndolo, uno en formato mentoría y otro en asesoría.

Cuento con que prácticamente hasta el último trimestre del año no voy a arrancar ninguna nueva colaboración. Hay alguna posibilidad de colaboración a modo de asesoría que quedó pendiente de concretar tras las vacaciones de verano que debería confirmarse (o no) en cosa de un par de semanas. Y sin haber nada cerrado, quizá de cara a final del año hagamos alguna formación. Más allá de eso, una incógnita.

En fin, que como es de suponer, por mi encantado de explorar posibles nuevas colaboraciones. Así que sea para eso o para cualquier duda o tipo de cuestión vía mi email estoy disponible :). Que aunque luego no cuajen siempre me resulta muy interesante conocer equipos y contextos nuevos.

Píldora. Deshabilitar la comprobación del certificado SSL en Maven

Hace cosa de un par de semanas que he empecé a colaborar con un nuevo equipo de uno de mis clientes. En su caso trabajan en un entorno Java y utilizan Maven para construir sus proyectos. Como tienen librerías internas publicadas en un Nexus, tuve que configurar mi setting.xml para poder tener acceso a ello, hasta ahí todo normal.

Pero vez lanzando el primer mvn install me dio un error con el certificado SSL, por ser un certificado autofirmado. Así que tras buscar un poco por ahí, encontré que gracias al subproyecto Maven Wagon podemos decirle que ignore esas comprobaciones porque confiamos en el repository manager configurado:

mvn install -Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true -Dmaven.wagon.http.ssl.ignore.validity.dates=true

Píldora. Migrando de Travis a GitHub Actions

Hace un tiempo que me está volviendo a llamar la atención grabar de vez en cuando algún screencast sobre temas de desarrollo de software, a modo de píldoras sobre algún tema muy concreto. En el pasado ya experimenté un poco con ello pero lo dejé olvidado.

En esta ocasión, aprovechando que he migrado hace poco un pipeline de integración continua de un proyecto personal de Travis a GitHub Actions aproveché para hacer un repaso y grabarlo.

Aquí os dejo el vídeo:

También hay una pull request donde pueden verse esos cambios con más detenimiento.