A partir de un pedido de un cliente he empezado trabajar en un nuevo módulo para la versión 5 del taller. Este módulo estará enfocado en el ecosistema Docker (particularmente Swarm, Compose y Kubernetes) y en cuestiones de monitoreo y logging. Estimo que esto podría llegar a extender la duración del taller unas 3 o 4 horas adicionales.

Esta semana debería terminar de completar el contenido conceptual (diapositivas) y la semana próxima debería comenzar a trabajar en el diseño de los ejercicios. Una vez tenga estos ejercicios completos será hora poner fecha para el estreno de esta versión, lo cual con viento a favor será hacia fines de agosto.

Recientemente me he encontrado hablando con varios colegas sobre posibles estrategias para «adoptar» DevOps y eso me llevó a poner por escrito lo que viene siendo mi estrategia preferida cuando me toca participar.

De cara  lograr una adopción efectiva de una estrategia DevOps y considerando las experiencias en organizaciones de distinta índole en las que he estado involucrado mi propuesta consiste en 3 fases:

Fase 1: assessment
Me gusta comenzar realizando una primer reunión con quien será el sponsor de esta iniciativa de cara a  asegurar la intención/motivación de todos los sectores involucrados: negocio + desarrollo + operaciones.
Luego suelo pedir al sponsor que encuentre dos equipo de desarrollo que quieran recorrer este camino y que actualmente sea conscientes de algunas limitaciones/situaciones que quieran resolver/mejorar a partir de una iniciativa DevOps. Como siguiente paso propongo realizar un par de entrevistas (~30 minutos) con los equipos identificados y también con gente de las otras área (negocio y operaciones)
Esta fase cierra con un informe y una propuesta de plan a corto plazo y una visión a largo plazo. Para este trabajo estimo un esfuerzo de unas 10 horas máximo y debería poder ejecutarse en 1 semana (o eventualmente 2 semanas si se complica agendar las reuniones). Más allá de las particularidades del caso, la propuesta es trabajar bottom-up, generando consenso desde la gente que realiza el trabajo en el día a día. Esto difiere de otras estrategias muy comunes, generalmente de tipo top-down: los jefes/gerentes/directivos definen como los developers deben trabajar.

Fase 2: exploración
Partiendo de lo realizado en la fase anterior, empiezo a trabajar con 1 de los equipos identificados durante 3 iteraciones (asumiendo que el equipo trabaja en forma iterativa). Yo me sumo al equipo en forma part-time para ayudar en la mejora actuando de coach tanto en lo técnico como en la gestión y coordinación con las otras areas.
Durante la primer iteración relevo el proceso y los impedimentos, y establecemos métricas que nos permitan medir objetivamente el estado actual y la potencial mejora.
Al cabo de dos iteraciones más, debería empezar a notarse alguna mejora en las métricas. En este punto hacemos un checkpoint y vemos si mi participación ha generado alguna mejora razonable y en base a ello decidimos mi continuidad o no.
Aproximadamente en la sexta iteración el equipo ya debería tener una mejora visible y podríamos empezar a replicar el proceso con un segundo equipo.
Habiendo recorrido este camino de mejora con al menos 2 equipos, estamos en condiciones de refinar la visión y definir un plan de implementación a mediano plazo.

Fase 3: expansión
En esta fase trabajamos en implementar el plan de mediano plazo y deberíamos poder generar líderes internos que serán los encargado de materializar el plan de largo plazo. Es aquí donde comenzar a intentar formalizar acuerdos y convención sumando iterativamente más gente a la iniciativa.