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!

Llevamos ya unos años en los que se habla de DevOps, un término que originalmente se acuñó para referirse a transformar el modo en el que se entrega software en las organizaciones basándose en ideas de Lean Manufacturing.

Pero en los últimos tiempos, al explotar su popularidad, parece haberse asumido por gran parte del sector como la forma de llamar a los equipos o ingenieros de plataforma, o en otros sitios simplemente como la forma moderna de llamar a los administradores de sistemas; ya que se asocia principal, y a veces únicamente, con despliegues automatizados o con montar infraestructura como código.

Personalmente, es algo que de vez en cuando he hablado con algunos compañeros de profesión, y aunque no es algo que me quite el sueño, sí me apena un poco el hecho de que con ello se pierda la parte más importante del mensaje: romper silos organizativos para centrarse en entregar valor.

Los Three Ways, que son mencionados en libros como The Phoenix Project o en The DevOps Handbook, vienen a ser los principios de los que derivan los comportamientos y patrones que nos ayudarán a romper esos silos y a poner foco en la entrega de valor:

• The First Way: aumentar el flujo de entrega al cliente previniendo defectos.

• The Second Way: amplificar los ciclos de feedback para prevenir problemas y mejorar la calidad en origen.

• The Third Way: crear y fomentar una cultura de experimentación y aprendizaje continuos.

The First Way: aumentar el flujo de entrega

Hasta que algo no se está usando en producción por los usuarios y/o clientes no se está creando valor, así que deberíamos buscar desplegar de forma temprana y frecuente en producción incrementando la fiabilidad y calidad de lo entregado.

Sus principios son:

• Hacer el trabajo visible. Típicamente con algún tipo de tablero (tipo kanban, sprint backlog…) donde tener el inventario de trabajo a realizar y su flujo entre “work centers”, permitiendo así detectar cuellos de botella entre ellos.
• Limitar el WIP. Básicamente tener más foco para acabar antes y pasar el trabajo al siguiente “work center”.
• Reducir el tamaño de de los paquetes de trabajo: Entregar menos funcionalidades pero con mayor frecuencia.
• Reducir el número de traspasos: Reducir pasos donde se encole el trabajo y que alargue el tiempo de entrega.
• Identificar y resolver continuamente los “constraints”: Para reducir tiempos de entrega necesitamos estar continuamente identificando el “constraint” del sistema y mejorar su capacidad de trabajo.

  In any value stream, there is always a direction of flow, and there is always one and only one constraint; any improvement not made at that constraint is an illusion. (Eliyahu M. Goldratt)

• Eliminar las dificultades y desperdicios del flujo de valor: Cualquier cosa que cause retrasos de cara a la entrega al cliente o actividades que puedan evitarse sin afectar al resultado. En Implementing Lean Software Development categorizan los desperdicios en: Trabajo parcialmente hecho, procesos extra, funcionalidades extra, cambios de tareas, esperas, motion o esfuerzo de transporte/comunicación entre “work centers”, defectos, trabajo manual o no estándar y heroicidades.

The Second Way: amplificar los ciclos de feedback

Una vez entregado, necesitamos feedback rápido y constante, la meta es conseguir un sistema de trabajo cada vez más seguro y resiliente, detectando y resolviendo los problemas cuando son más pequeños y más fáciles de resolver. Pero los fallos son inevitables en sistemas complejos, cuando ocurren se deben asumir como oportunidades de aprendizaje frente a buscar o castigar culpables.

Sus principios son:

• Ver los problemas en cuanto ocurren: Tener telemetría que muestre cómo se comportan los componentes del sistema en producción para detectar cuando no lo hacen como se espera.
• Resolver los problemas para construir nuevo conocimiento: Una vez que un problema ocurre debemos resolverlo como un enjambre, movilizando a quienes haga falta para arreglarlo. Llegando a parar todo lo necesario del mismo modo que en el mundo de manufactura se utiliza una cuerda andon.
• Empujar la calidad cerca del origen: Debemos encontrar y arreglar los problemas en cada área de control, las responsabilidades y toma de decisiones deben ocurrir donde se hace el trabajo.
• Facilitar la optimización de los “work centers” posteriores: Diseñando para facilidad operacional, donde los atributos de calidad (rendimiento, configurabilidad, testabilidad…) tienen la misma importancia que las funcionalidades.

The Third Way: experimentación y aprendizaje continuos

El objetivo es crear un entorno de alta confianza, reforzando la idea de que estamos aprendiendo de por vida. Aplicando una aproximación científica, tanto para el desarrollo de producto como mejora de proceso, aprendiendo de aciertos y fallos. Además, transformando los aprendizajes locales en mejoras globales para toda la organización.

Sus principios son:

• Facilitar el aprendizaje organizacional y una cultura de seguridad psicológica: Frente a buscar el error humano, buscar modos en la que se pueda rediseñar el sistema para que no vuelva a ocurrir este accidente.

  By removing blame, you remove fear; by removing fear, you enable honesty; honesty enables prevention. (Bethany Macri)

• Institucionalizar la mejora del trabajo diario: Reservar tiempo explícito para pagar deuda técnica, arreglar defectos y áreas problemáticas.
• Transformar descubrimientos locales en mejoras globales: Tratar de convertir la experiencia que obtienen equipos o individuos en conocimiento explícito para la organización para que sea fácil de utilizar (librerías, configuraciones, código…).
• Inyectar patrones de resiliencia en el trabajo diario: Mejorando las operaciones diarias introduciendo tensión de forma intencionada buscando mejorar (chaos engineering, organizar game days).
• Los líderes refuerzan la cultura de aprendizaje: Establecer objetivos que enmarquen los experimentos haciendo explícito el problema a resolver, la hipótesis, el método de testearla, la interpretación de los resultados y usar los aprendizajes en las siguientes iteraciones.

Junto la aplicación de las prácticas técnicas (pipelines de despliegue, testing automático, añadir telemetría y alertado, chaos engineering…) y mejorar en ellas; estos principios DevOps nos ayudarán a tener organizaciones donde al entregar valor de negocio antes, se hagan más predictibles y se reduzcan riesgos.

Lo que, en consecuencia, ayudará a reducir estrés en los equipos de tecnología y a que esas organizaciones sean lugares más habitables.