El polémico perfil del Ingeniero DevOps

El polémico perfil del Ingeniero DevOps

Ayer estuve participando del Meetup de Infrastructure as Code. Hubo un par de presentaciones y luego un panel de debate con los disertantes. En ese contexto un participante planteó una consulta sobre la formación de perfiles DevOps. Yo di una respuesta que me parece resultó polémica para algunos: no creo en un perfil DevOps.

A esta altura claro está que DevOps es un mindset que busca remover las fricciones típicas entre las áreas de Desarrollo y Operaciones a partir de un trabajo colaborativo y la implementación de ciertas prácticas. No creo que esto implique un nuevo perfil ya que me parece que no hay nuevas responsabilidades ni tareas. Es cierto que entre las prácticas “novedosas”que propone DevOps está el manejo de infraestructura como código, pero no creo que amerite un nuevo perfil, pues la infraestructura ya era una cuestión que teníamos que administrar, la novedad está en todo caso en la forma en que lo haremos: ahora quienes esten a cargo de la administración de la infraestructura deben escribir código ¿vamos a contratar nuevos perfiles para eso o vamos a pedir a los sysAdmins o developers que se encarguen? Yo voto por esto último.

Por otro, si uno mira las búsquedas de perfiles DevOps, en general se encuentra con una extensa lista de conocimientos técnicos y de herramientas, pero casi nada sobre “soft-skills”, o sea: DevOps tiene que ver con colaboración, supongamos por un momento que generamos un nuevo perfil (Ingeniero DevOps) para que facilite que la organización pueda trabajar de en una cultura DevOps ¿no debería entonces ese perfil de Ingeniero DevOps tener ciertas habilidades de facilitación, generación de acuerdos, vocación de servicio, etc? Pues para varios parece que no, pues estas cuestiones son muchas veces omitidas en las búsquedas de DevOps.

Continuará…

Review of my DevOps Tutorial @ Profes 2019

I delivery this tutorial yesterday morning. Seven people participated on it: 2 from Austria, 2 from Spain, 2 from Finland and 1 from Germany.

The tutorial flowed as expected but I would have like to have 30 extra minutes to cover the Continuous Delivery part with a hands-on exercise.

Participants evaluated the tutorial with 5 points out of 5 🙂

Here is the formal summary of the tutorial.

Prácticas DevOps para todos y todas

Este fue el título de la charla que estuve dando el lunes pasado en el meetup de Software Crafters Barcelona. La charla estuvo basada en el material de mi charla “No contrates Ingenieros DevOps”, pero decidí darle una dinámica distinta. Inicialmente hice una introducción al mindset DevOps y luego debatimos sobre el rol del Ingeniero DevOps usando una dinámica de Fishbowl. Finalmente cerramos revisando algunas prácticas para intentar acercar y mejorar el flujo de la gente de Dev y gente de Ops.

Me gustó mucho la forma en que fluyó la actividad. Luego de la charla nos quedamos compartiendo unos tragos con los participantes. Agradezco a la comunidad de Crafters, a la gente de Voxel Group y a Adrián Perreau porque hicieron posible el meetup.

Comparto aquí algunos recursos que mencioné durante la charla:

DevOps Tutorial at Profes 2019

Next week I will deliver my DevOps Tutorial at the International Conference on Product-Focused Software Process Improvement, Profes 2019. This will be my second time delivering this tutorial in Europe, but this time I have updated the tutorial to include Kubernetes-related content and of course I had to remove some other content that was not so relevant.

The conference will be held in the North Campus of the Technical University of Barcelona. The tutorial is scheduled for November 27 morning.

For those that plan to participate ensure to install the following software on your notebooks: an Ssh client, Git and Docker Desktop (or docker-engine for those running on Linux).

Estructura de equipo para desarrollo de producto

Desde hace un tiempo estoy trabajando un equipo de producto de más de 20 personas y estamos organizados en una estructura que es nueva para mi pero que al mismo tiempo me parece viene resultando efectiva. La siguiente figura resume esta estructura.

Si bien todo el equipo de producto son más de 20 personas, en el día a día estamos divididos en 4 equipos: 3 feature teams y 1 equipo de toolsmiths (este nombre lo tomé del enfoque FDD, pero no es el nombre real del equipo)

Los 3 feature teams trabajan en funcionalidades del producto y están en el día a día con gente de negocio.

El equipo de toolsmiths es donde yo trabajo. Actuamos como proveedores/facilitadores de los features teams y nos encargamos de mantener/optimizar la infraestructura de desarrollo: repositorios, build server, ambientes, etc. Incluso en ocasiones agregamos código al producto, pero obviamente relacionado a cuestiones de soporte/infra como feature flags, health endpoints, etc. Como parte de nuestro trabajo tenemos que interactuar con otros grupos de soporte organizacional que se encargan de infraestructura de base y regulaciones (seguridad, red, etc). En el equipo somos 3 personas con skills mixtos: podemos codear, agregar tests, configurar servers, scriptear infraestructura pero sobre todo podemos hablar con otros grupos y generar concenso. Alguien podría tentarse de decir que somos DevOps, pero no lo vemos así, porque de entrada no creemos que DevOps sea ni un rol ni un área, sino un mindset con un conjunto de prácticas.

No se si este es el mejor enfoque para la estructura de un equipo de producto, pero consideramos que nos viene resultando bien: el negocio está contento, los distintos equipos están contentos, el producto está estable y tenemos la capacidad de ir a producción bajo demanda y de forma altamente automatizada.

Nueva edición del taller de Prácticas DevOps y Continuous Delivery

Los días 28 y 30 de mayo estaré dictando estos dos taller junto a la gente de 10 Pines. Como siempre hice algunos ajustes en el contenido:

  • Agregué un ejercicio de Kubernetes puro, que complementa el ejercicio de OpenShift que ya tenía
  • Actualicé el setup de los ejercicios de Jenkins para usar Docker como builder
  • Actualicé el material de teoríco incluyendo algunos slides con cuestiones que leí en el workbook de SRE.

Los interesados pueden encontrar más detalles en la página de 10 Pines University:

Sobre el State of Agile Report 2019

Hace un par de dias se publicó este reporte surgido de la encuesta que realiza anualmente la empresa Version One. Los resultados no me soprendieron, al contrario, me resultaron muy familiares respecto de lo que veo en mi día a día.

En el resumen ejecutivo se destacan tres puntos.

1. Scrum (y SAFE) sigue siendo el enfoque agile más popular

No me sorprende y en un punto me parece esperable ya que más allá de las bondades de Scrum, es el enfoque ágil con mayor marketing: Scrum Alliance, Scrum.Org, Certified Scrum zaraza, etc

2. La cultura organizacional es el mayor impedimento para adopción y escalamiento de agile

Me parece esperable considerando que agile es un mindset, una forma de hacer las cosas e incluso un forma de pararse frente a los problemas y desafios

3. DevOps es cada vez más relevante

Tengo la sospecha que esto se debe a que mucha de la gente que trabaja con Scrum, hace en realidad un Flaccid Scrum, o sea, solo aplican la parte de gestión de Agile. Pero en un punto toman conciencia que sin prácticas técnicas varias “promesas de Agile” no son posibles. Pero como ya se gastaron todo el presupuesto de Agile en tomar los curso de “Certified Scrum/Agile XXXX” ahora necesitan otro buzzword para conseguir presupuesto y ahí está DevOps al alcance de la mano.