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.

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

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.

Hace unos días Agile Delivery organizó un evento en formato Lean Coffee en el que estuvimos unas cuantas personas hablando sobre slicing de producto de software. Lo del slicing viene a ser simplemente ir haciendo rebanadas para organizar el trabajo desde problemas grandes a más pequeños para hacerlos más manejables.

Con la visión waterfalera lo habitual era hacer slicing con un enfoque horizontal descomponiendo por tipo de actividad, por ejemplo: hacer el análisis, diseñar la UI cubriendo todas las casuísticas reflejadas en el análisis, diseñar la base de datos, implementar el frontend de la UI diseñada, programar la lógica de negocio de lo que se definió, hacer pruebas para que todo funciona tal y como se indicó en el análisis… y acabar desplegando a modo big bang como último paso. Así que pueden pasar muchos meses o años para empezar a obtener feedback de que lo que hemos construido aporta valor o para empezar a recuperar la inversión.

La visión agilista cambia esta perspectiva a algo que parece mucho más razonable para crear mejores productos de software, construirlos de forma iterativa e incremental. Para ilustrarlo, y aunque suene un poco vetusto, estos son los principios del manifiesto ágil que se refieren a ello:

• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Working software is the primary measure of progress.
• Simplicity–the art of maximizing the amount of work not done–is essential.

Atención especial a ese art of maximizing the amount of work not done, principalmente desde el punto de vista de producto. Debemos intentar limitar al máximo el alcance de lo que construimos para que, con el mínimo esfuerzo posible, tratemos de conseguir el máximo valor o aprender lo máximo posible. Esto vendría a conseguirse a través de hacer slicing vertical para organizar el trabajo.

A día de hoy, aún con el boom de lo ágil que hay en el sector tech, es bastante habitual seguir viendo muchos vicios heredados del waterfall. Esto es porque aunque la teoría es simple, llevarlo a la práctica no lo suele ser. Requiere que las organizaciones y equipos tengan una mentalidad enfocada a producto y cierta capacidad técnica para llevarlo a cabo.

• La mentalidad de producto ayuda a plantear esos slices. Esto es hacer que se focalicen mucho más en los objetivos a conseguir o en las hipótesis que se pretendan validar y que busquen el camino más corto para hacerlo, evitando convertir a los equipos en meros feature factories de quienes se esperan que implementen a pies juntillas lo que alguien les dice.

• Ciertas capacidades técnicas son necesarias para que los equipos no se vean limitados o paralizados por esas cuestiones, además de para trabajar con más tranquilidad. Por ejemplo tener arquitecturas y diseños que absorban bien los cambios, confiar en los tests automáticos para comprobar que tanto lo nuevo como lo anterior sigue funcionando correctamente, poder entregar software de forma frecuente y con confianza…

En fin, os dejo el video de la conversación que tuvimos, a mi me resultó una sesión muy interesante y entretenida. Cerca del minuto 19 de la grabación es cuando se empieza a entrar en harina:

Salieron experiencias, consejos y referencias más que interesantes. Además pudimos enfrentar puntos de vista diferentes que creo que también aporta, ya que en eso del vertical slicing creo cada uno vamos explorando cosas diferentes que dependiendo de los contextos pueden funcionarnos mejor o peor.

Estoy releyendo el libro de The Nature of Software Development. Keep It Simple, Make It Valuable, Build It Piece by Piece de Ron Jeffries, uno de esos libros donde te encuentras condensadas ideas que merecen ser revisadas de vez en cuando.

Este libro habla de la forma natural de hacer software, the natural way lo llama Jeffries, que viene a ser algo tan simple como focalizarse en entregar valor pronto y a menudo. Simple, que no fácil.

Este no es un libro de recetas con trucos para hacerlo, si no de ideas sobre las que reflexionar y que anima a que explores por tu cuenta modos de hacerlo. Como muestra este es el capítulo resumen de la primera parte del libro llamada The circle of value.

Cerrando el círculo del valor:

• Valor es lo que queremos. Las funcionalidades entregan valor. Entregar funcionalidades pronto nos da valor antes.
• Gestionar observando el valor funciona mejor que gestionando fechas o artefactos que no entregan valor.
• Planificar funcionalidad es bastante fácil de hacer. Estima si debes hacerlo. Seleccionar el trabajo basado en el “tiempo que hizo ayer” funciona mejor.
• Construir por funcionalidades nos requiere construir un producto pequeño y completo cada pocas semanas. Ese producto debe funcionar siempre correctamente y debería estar siempre bien diseñado.
• Desarrollo debe entregar funcionalidades reales que funcionen. El producto debe estar bien testeado. La personas de negocio y las de desarrollo contribuyen al testing. El producto debe estar bien diseñado. Los desarrolladores mantienen el diseño vivo todo el tiempo.

Esto es todo al respecto. Muy simple. Un compromiso desde la cima del negocio, hasta los managers y desarrolladores individuales, es todo lo necesario. ¡Vamos! ¡Enséñame el software!