menu_superior

Algunos mitos con el tema de DevOps

Desde que modifiqué mi perfil de LinkedIn para incluir mis conocimientos/responsabilidades en DevOps recibo varias ofertas semanales para incorporar mi candidatura a procesos de selección de perfiles DevOps. Me acaba de volver a pasar y quiero aprovechar la oportunidad para escribir un post breve sobre algunos de los mitos que el tema DevOps encierra. Esta es mi lista personal, seguramente incompleta y totalmente transferible, como siempre, si alguien tiene otros los comentarios están a su disposición:

  1. DevOps como rol. Este el que motiva el post y por tanto le concedo el honor de ir el primero. No seamos fundamentalistas, podemos aceptar que DevOps sea un modelo, un paradigma, una visión, un framework o un conjunto de prácticas, con lo que no podemos estar de acuerdo es con que DevOps sea un rol. Para mi es el mismo sinsentido que si dijéramos “busco un Calidad”  si necesitamos gestionar la calidad del software. El error me parece de base porque precisamente DevOps es lo contrario de concentrar la responsabilidad en una sola persona, DevOps es cooperación entre equipos (Desarrollo y Operaciones), creación de dinámicas que permitan colaborar a equipos con responsabilidades diferentes. Puedo entender que haya un encargado de gestionar la entrega del software de desarrollo a producción, que haga de intermediario, pero eso no es DevOps, eso es gestionar la barrera, no eliminarla.
  2. DevOps como departamento. Por lo mismo de lo anterior. No es un rol ni puede ser un departamento, es… otra cosa. Si es un departamento o una persona que gestione los pases de desarrollo a producción eso implica que sigue habiendo una diferencia, un salto. Desarrollo sigue sin saber como se comporta el software en producción. Producción sigue sin saber como está estructurado el software. Equipos en silos. Dicho de otro modo, aceptar un departamento o un rol DevOps implica necesariamente aceptar el statu quo de la separación de equipos, aceptar que cada uno se ciña a una parcela y se olvide de las demás.
  3. DevOps como plataforma tecnológica. Pues tampoco, no? Si no es una persona ni un departamento, tampoco debería ser una plataforma tecnológica o un conjunto de herramientas. Necesitamos herramientas igual que necesitamos personas, pero ambas deben ser transversales, es decir, operadas por personas que tienen un mismo objetivo: poner el software en producción de manera rápida e indolora. Desarrollo trabaja en estructuras conocidas por producción, ambos van a un ritmo sincronizado y ambos tienen visibilidad sobre el rendimiento de dicho software y sobre el feedback del cliente. En otras palabras: NO HAY DOS EQUIPOS, hay un equipo que trabaja de acuerdo a las prioridades del negocio, que captura información de producción y que resuelve los incidentes que pudieran surgir de manera coordinada y transparente.

Si no es todo lo anterior, ¿qué debería ser DevOps?

No se me ocurre una sola palabra, o una definición precisa. Digamos que es colaboración entre equipos, comunicación positiva (transparencia, feedback, honestidad), ritmo sostenible, responsabilidad compartida. En mi opinión para entender qué es deberíamos alejarnos de todo lo relacionado con productividad (planificación, fases, horas, actividades, tareas, costes) y de todo lo relacionado con tecnología (herramientas, contenedores, automatización, entornos, etc.) y acercarnos a los aspectos esenciales y relacionados con la mentalidad (mindset) y los valores.

,

Comments are closed.