Allá por el año 2000, cuando estaba intentando terminar la carrera, me topé con una asignatura cuyo contenido me parecía críptico y sin ninguna conexión con la realidad o mis conocimientos. Aunque pensarás que esto no es tan raro 😂, “Informática y Sociedad” se centraba, entre otras muchas cosas, en el estudio del ensayo El taller y el cronómetro de Benjamin Coriat. 

Tranquilo, que no voy a entrar a comentar aspectos como la producción en masa o Lean Manufactoring, pero está claro que todos esos conceptos han calado de forma muy profunda en la parte más Crafter de la industria que busca como objetivo la calidad y la reducción de desperdicios.

Del análisis de aquel ensayo, me ha quedado muy vivo el concepto de Lead Time como medida general del tiempo transcurrido entre que algo entra en nuestro sistema productivo y que acaba en manos del usuario final.

 
¿Qué frena la entrega continua de valor?

Para poder responder a esta pregunta, el primer paso como siempre es poder medir. ¿Cuál es el Lead Time de nuestro proceso de construcción y entrega de valor? ¿Cuánto tarda el usuario en disfrutar en producción del valor que aporta un cambio o una nueva funcionalidad?

Medir el Lead Time puede ser complejo, ya que el proceso pasa en cada caso por muchas manos, entornos y herramientas antes de que la entrega de valor se haga efectiva. Todo este proceso viene condicionado por las prácticas que hemos adoptado, la manera que tenemos de aplicarlas y, sobretodo, de los conocimientos que tenemos para ser efectivos al hacerlo. Es imposible generalizar. El contexto es, pues, fundamental. Es interesante observar que, a la hora de hablar de entrega continua, existe la tendencia a centrarse únicamente en la definición de pipelines automáticas que permitan gestionar la construcción, prueba y despliegue de nuestro código.

Esta visión de la entrega continua está orientada a llevar cada commit a producción lo antes posible, pero hay una diferencia notable entre propagar rápidamente un cambio a producción y reducir el tiempo en el proceso de entrega de valor. En este artículo me centraré en el valor entregado, ya que el software no aporta valor hasta que está en manos de los usuarios.

Con este contexto, abre tu visión del proceso para poder identificar donde pueden estar algunos de los frenos que provocan el aumento del Lead Time en cuanto a la entrega de valor se refiere, y qué cambios organizativos, técnicos o de flujo pueden ayudar a eliminarlos. Como no son pocos, en este caso nos centraremos en la confianza en la base de código.

Confianza en la base de código

En un enfoque muy centrado en producto, el flujo de entrega continua tendrá como objetivo la definición de historias de usuario que sean pequeñas, independientes y que no tengan incertidumbre (SMART o INVEST son unas buenas guías en este caso). Esto te permite reducir el "Waste" que se puede producir en el proceso, pero no garantiza que el código entregado funcione o sea de la calidad esperada. De hecho, si aceleras el ritmo de entrega, es muy probable que comiences a tener problemas de calidad si no estás bien preparado.

Aquí es donde eXtreme Programming o XP marca la diferencia. El conjunto de las prácticas técnicas que propone nos permite ir ganando de forma progresiva esa confianza que necesitamos tener en nuestro código. Pero, ¿contra qué situaciones mitiga XP? Algunas de las que tienen mayor impacto en mi opinión son:

• 💰 Hay mucha deuda técnica.
• ⚙️ El código no tiene tests.
• ♻️ No hay integración continua.
• 😅 El código es difícil de entender y, por consiguiente, difícil de modificar.

En cualquier caso, existen otros muchos aspectos que te lastrarán en el proceso de cambio y que es muy complicado ignorar:

• No hay un proceso automatizado de construcción y despliegue (pipeline).
• El flujo de trabajo con el repositorio es complejo.
• El sistema no es observable o no tiene un sistema de agregación de logs adecuado.
• No podemos hacer rollback de las versiones desplegadas en producción.
• No podemos activar o desactivar funcionalidades (Feature Toggles).
• No podemos aplicar versiones a unos pocos clientes para realizar pruebas (Rollup Upgrades + Canary Deployments).

Y por suerte o por desgracia la lista continúa. Cuantos más aspectos puedas cubrir, más confianza tendrás en que tu código se entregue a producción tantas veces como sea necesario. ¡¡Incluso en viernes!! 🤣

Conclusiones

A modo de TL;DR y si quieres comenzar a entregar más rápido y de forma más confiable, algunos puntos que no puedes dejar de revisar son:

• El proceso de definición y gestión de las historias de usuario a nivel de producto.

• Las prácticas técnicas que utiliza tu equipo de desarrollo: Testing, refactoring, pair programming, clean code, etcétera.

• La gestión de la deuda técnica, adoptando un proceso consciente e integrado en el propio proceso de desarrollo.

Es un camino largo, como puedes ver en los módulos que componen la formación de la que voy a hablarte, pero cada paso cuenta. Si estás buscando dar un salto en tu carrera de liderazgo técnico puede interesarte el Bootcamp Online Tech Management & Leadership de GeeksHubs Academy. 

En mi caso imparto el módulo de Testing, pero se trata de una formación intensiva muy completa formada por profesionales referentes en cada área — Chaume Sánchez, CEO de GeeksHubs; Maribel Vilaplana, consultora y formadora en comunicación de alto impacto; Álvaro Núñez, Security Researcher en el equipo de Ideas Locas de Chema Alonso; Olga Cebrián, co-fundadora en Aoimm.t; Pablo González, Technical Manager & Security en Telefónica Digital España… — que te impulsan si lo que quieres es dar un paso más hacia el rol de CTO, Tech Lead, Manager IT, etcétera.

Let’s ship!! 🚀