Close

¿En qué consiste la cultura de DevOps?

Cómo ayuda la cultura de DevOps a sincronizar las personas, los procesos y las herramientas hacia un enfoque en el cliente más unificado.

Foto de cara de Tom Hall
Tom Hall

Defensor y profesional de DevOps


Colaboración

DevOps es un enfoque ágil del cambio organizativo que busca cerrar las brechas tradicionales y los grupos aislados entre los equipos, además de establecer nuevos procesos que faciliten una mayor colaboración. DevOps es posible gracias a nuevas herramientas y a prácticas de ingeniería ágiles, pero con esto no basta para disfrutar de las ventajas de DevOps. Sin la mentalidad, los rituales y la cultura adecuados, es difícil beneficiarse por completo de DevOps.

Las personas y la cultura son las principales claves del éxito de la implementación de DevOps.
- Encuesta sobre tendencias de DevOps de 2020 realizada por Atlassian

¿En qué consiste la cultura de DevOps?


En esencia, la cultura de DevOps implica una colaboración más estrecha y una responsabilidad compartida entre los equipos de desarrollo y operaciones en cuanto a los productos que crean y mantienen. Esto ayuda a las empresas a coordinar a las personas, los procesos y las herramientas hacia un enfoque en el cliente más unificado.

Implica fomentar el desarrollo de equipos multidisciplinarios que se responsabilicen de todo el ciclo de vida de un producto. Los equipos de DevOps trabajan de forma autónoma y adoptan una cultura, un flujo de trabajo y un conjunto de herramientas de ingeniería de software que llevan los requisitos operativos al mismo nivel de importancia que la arquitectura, el diseño y el desarrollo. Ser consciente de que los desarrolladores que creen algo también deberán gestionarlo los acerca al usuario y les aporta una mayor comprensión de sus requisitos y necesidades. Además, como los equipos de operaciones están más involucrados en el proceso de desarrollo, pueden añadir requisitos de mantenimiento y necesidades de los clientes para obtener un producto aún mejor.

En el centro de la cultura de DevOps se encuentra el aumento de la transparencia, la comunicación y la colaboración entre equipos que tradicionalmente trabajaban aislados. Pero hay cambios culturales importantes que deben producirse para acercar a estos equipos. DevOps es un cambio de la cultura organizativa que hace hincapié en el aprendizaje y la mejora continuos, especialmente a través de la autonomía del equipo, el feedback rápido, el alto grado de empatía y confianza y la colaboración entre equipos.

Logotipo de pensamiento consciente
Material relacionado

Adopta una mentalidad centrada en el cliente

Logotipo de un trofeo
Material relacionado

Descubre las ventajas de DevOps

DevOps implica responsabilidades compartidas. Tanto el equipo de desarrollo como el de operaciones son los responsables del éxito o del fracaso de un producto. De los desarrolladores se espera que no se limiten a crear el producto y entregárselo al equipo de operaciones, sino que compartan la responsabilidad de supervisarlo durante toda su vida útil, adoptando la mentalidad "you build it, you run it" (tú lo creas, tú lo gestionas). En este sentido, los desarrolladores prueban y utilizan el software y colaboran más con el equipo de control de calidad y el de operaciones de TI. Al comprender los desafíos a los que se enfrenta el equipo de operaciones, es más probable que simplifiquen la implementación y el mantenimiento. Del mismo modo, si el equipo de operaciones es consciente de los objetivos empresariales del sistema, puede colaborar con los desarrolladores para definir las necesidades operativas de un sistema y adoptar herramientas de automatización.

Los equipos autónomos son otro aspecto importante de DevOps. Para que los equipos de desarrollo y operaciones colaboren eficazmente, necesitan poder tomar decisiones e implementar cambios sin pasar por un proceso de aprobación largo y engorroso. Esto implica confiar en los equipos y establecer un entorno en el que no haya miedo al fracaso. Estos equipos deben contar con los procesos y herramientas adecuados para tomar decisiones de forma más rápida y sencilla en cada nivel de riesgo para el cliente.

Por ejemplo, un flujo de trabajo de desarrollo típico puede requerir la participación de varios colaboradores de distintos equipos para implementar cambios en el código. El desarrollador hace un cambio de código y lo envía a un repositorio de control de código fuente, un ingeniero de compilación compila e implementa el código en un entorno de prueba, el propietario del producto actualiza el estado del trabajo en una herramienta de seguimiento de incidencias, etc. Un equipo autónomo aprovechará las herramientas que automatizan estos procesos, de modo que el envío de código nuevo desencadene la creación e implementación de una nueva función en un entorno de prueba y la herramienta de seguimiento de incidencias se actualice automáticamente.

Por ejemplo, un equipo se ve obstaculizado por requisitos como tener que abrir un ticket con un equipo de operaciones distinto si quiere hacer un cambio insignificante en la infraestructura, como una nueva entrada de DNS. Para una tarea que debería llevar unos segundos, al final se tardan días o semanas. Un equipo autónomo tiene la capacidad de implementar estos cambios por sí mismo, ya sea mediante una persona del equipo que tenga las habilidades y la experiencia adecuadas, o bien mediante el acceso a herramientas de autoservicio.

La cultura de equipo de DevOps valora el feedback rápido que pueda ayudar a la mejora continua de un equipo de desarrollo y operaciones unificado. En un entorno en el que los equipos de desarrollo y operaciones trabajan en grupos aislados, el feedback sobre el rendimiento y la estabilidad del software de aplicaciones en producción suele tardar en llegar al equipo de desarrollo (si es que consigue llegar). DevOps garantiza que los desarrolladores obtengan el feedback rápido que necesitan para iterar y mejorar rápidamente el código de las aplicaciones, ya que requiere la participación del equipo de operaciones en el diseño e implementación de estrategias de supervisión y generación de informes sobre las aplicaciones. Por ejemplo, cualquier herramienta de integración continua suficientemente potente permitirá la compilación y las pruebas automatizadas de los nuevos envíos de código y proporcionará al desarrollador feedback inmediato sobre la calidad del código.

La automatización es esencial en la cultura de DevOps, ya que permite un gran nivel de colaboración y libera recursos. La automatización e integración de los procesos entre los equipos de desarrollo de software y los equipos de TI les ayuda a compilar, probar y publicar software de forma más rápida y fiable.

¿Cuáles son las ventajas de la cultura de DevOps?


La ventaja más obvia y notable de adoptar una cultura de DevOps es que las publicaciones de software son más sencillas, frecuentes y de alta calidad. Esto no solo aumenta el rendimiento de la empresa, sino también la satisfacción de los empleados.

Según el libro "Accelerate: Building and Scaling High Performing Technology Organizations", una cultura de DevOps fomenta un alto grado de confianza y colaboración, da como resultado una toma de decisiones de mayor calidad e incluso mayores niveles de satisfacción en el trabajo.

Adoptar una cultura de DevOps es fundamental para crear un equipo de ingeniería de alto rendimiento sin sacrificar la satisfacción de los empleados. Así, todo el mundo sale ganando. Para un ingeniero no hay nada como la sensación de implementar y ejecutar con frecuencia y facilidad un software estable y de alto rendimiento que haga felices a los usuarios, mientras que para los ejecutivos la mejora de los resultados empresariales es todo un éxito.

¿Cuáles son los retos?


Adoptar por completo la cultura de DevOps suele requerir que las personas y los equipos hagan cambios significativos en su forma de trabajar, por lo que es necesario contar con la aceptación de las esferas más altas de la organización.

Empezar por los empleados y equipos de base puede ser, y a menudo es, un punto de partida importante para conseguir que los gerentes y ejecutivos acepten la transformación a DevOps. A menudo, el argumento más convincente a favor de una adopción más amplia de DevOps es que se vean los frutos después de que algunas personas o equipos pequeños lo hayan puesto en práctica.

Los altos niveles de autonomía y confianza habituales de una cultura de DevOps pueden ser difíciles de alcanzar si existe un historial de conflicto entre cualquiera de las personas o equipos involucrados. Cuanto más aislados estuvieran los equipos antes de intentar adoptar el enfoque de DevOps, más difícil será crear conexiones.

Hacer este cambio no es sencillo. Si sus ventajas no se transmiten y comprenden claramente, puede ser difícil impulsar la aceptación y la voluntad de llevarlo a cabo, incluso en entornos en los que las personas y los equipos existentes trabajan en armonía.

Es comprensible que las organizaciones muy centradas en la ingeniería recurran de inmediato a herramientas y tecnologías para resolver los retos empresariales. Es cierto que existen herramientas y tecnologías que pueden ayudar a que tu organización adopte el enfoque de DevOps. Pero cambiar las herramientas y tecnologías sin cambiar la cultura a menudo se denomina "DevOps de culto cargo", ya que se modifica la fachada sin abordar la debilidad de los cimientos.

Aspectos que se deben tener en cuenta para la transición a la cultura de DevOps


Comunicación abierta

Uno de los principales objetivos de DevOps es acabar con el aislamiento del conocimiento, la experiencia y el trabajo en diferentes unidades organizativas. Si los programadores que escriben código y los administradores de sistemas que lo implementan y mantienen no se comunican, es probable que haya ineficiencias.

Posibilidad de cometer errores

Muchos equipos, personas y organizaciones se presionan y presionan a los demás para no cometer errores. El problema es que, si equivocarse no es una opción, hay menos probabilidades de que una persona o un equipo intente un enfoque nuevo para resolver un problema o desarrollar funciones innovadoras.

Esta mentalidad se refleja en la obsesión del pasado por medir el "tiempo medio entre fallos" (MTBF) más que el "tiempo medio de recuperación" (MTTR). Para el tiempo medio entre fallos, se utilizan herramientas como el "análisis del origen del problema" para identificar el origen de los fallos e intentar evitar que vuelvan a producirse. El tiempo medio de recuperación refleja una visión de las aplicaciones de software como sistemas complejos que pueden fallar de manera impredecible y se centra en la recuperación rápida cuando esto ocurre.

La "retrospectiva sin culpables" es un aspecto habitual de la cultura de DevOps. Y es que pueden obtenerse mejores resultados si un equipo se reúne al final de un sprint o proyecto para comentar qué ha salido bien y qué podría hacerse mejor en un entorno abierto y seguro.

El éxito del método de no buscar culpables cuando algo sale mal se debe, en parte, a que se basa en una mentalidad de crecimiento en la que se admite que puede haber errores y que da por sentado que tanto las personas como las organizaciones pueden aprender, crecer y mejorar.
- "Effective DevOps", de Jennifer Davis y Katherine Daniels

Un nuevo conjunto de procesos

Crear una cultura de DevOps requiere desarrollar nuevos enfoques para problemas antiguos. DevOps implica cambiar el proceso en el que los programadores escriben código de aplicaciones de forma aislada y pasan la pelota al equipo de operaciones para que implemente y ponga en funcionamiento la aplicación. DevOps supone establecer una colaboración entre los equipos de desarrollo y operaciones durante todo el ciclo de vida de un proyecto.

La integración y entrega continuas (CI/CD) suelen considerarse requisitos indispensables para una cultura de DevOps. Hay un tercer proceso, la implementación continua, que normalmente adoptan y promueven grandes organizaciones como Netflix, aunque no suele ponerse en práctica (o no se necesita) en la mayoría de las empresas más pequeñas. Esto se debe a que la implementación continua de nuevas funciones en un entorno de producción requiere un alto grado de confianza en que el código nuevo se ha probado de forma exhaustiva y puede implementarse con seguridad (por ejemplo, con un conmutador de función). Por lo tanto, a menos que en tu organización se hagan implementaciones muchas veces al día, puede que no valga la pena invertir en este tercer proceso.

En la mayoría de los casos, una pequeña variación del "desarrollo basado en troncos" puede simplificar enormemente tus esfuerzos de CI/CD. En este modelo, el equipo ha eliminado las ramas de función de larga duración y envía confirmaciones frecuentes a la rama del tronco del código.

Un componente importante del desarrollo basado en troncos son las pruebas automatizadas exhaustivas de unidad, integración y regresión. Esto ayuda a garantizar que todas las confirmaciones nuevas que se envíen a la rama del tronco se han examinado a fondo al enviarlas al repositorio.

La integración continua (CI) es la práctica de automatizar la integración de los cambios de código de varios contribuidores en un proyecto de software. Esto va más allá de los equipos de desarrollo e incumbe a toda la organización. Por ejemplo, los equipos de producto coordinan cuándo lanzar funciones y soluciones secuencialmente, y qué miembros del equipo serán los responsables.

La entrega continua (CD) es una metodología organizativa que reúne a los equipos de ingeniería y a los que no son de ingeniería, como los de diseño, producto y marketing, para entregar un producto. Los entornos que no son de CD pueden hacer que los desarrolladores acaben centrándose en complacer al equipo de control de calidad. Esto supone que la rama del tronco del repositorio siempre esté en estado "implementable".

La implementación continua permite que los cambios de código se apliquen automáticamente en producción en cuanto se realizan, ya sea ocultos tras una marca de función o implementados para un pequeño porcentaje de clientes, de este modo pueden revertirse fácilmente. Esto proporciona a los equipos mayor flexibilidad para responder a los cambios del mercado y a las demandas de los clientes, ya que pueden reaccionar al feedback e implementar y validar rápidamente nuevas funciones. También permite revertir funciones fácilmente, lo que evita los obstáculos que supone para los equipos que se rompa la compilación.

Las marcas de función, los conmutadores de función o la implementación oscura son métodos habituales para que los usuarios no puedan ver ni utilizar las funciones nuevas de las aplicaciones al implementarlas en el entorno de producción, aunque después pueden activarse con el mínimo esfuerzo. Esta estrategia permite una implementación continua porque hay muy poco riesgo de que los usuarios se vean afectados negativamente. También es habitual restringir las funciones a un subconjunto de la base de usuarios segmentándolos por zona geográfica o ejecutando instancias de servidor independientes y publicando funciones en un solo servidor al que los usuarios puedan acceder.

Una cadena de herramientas actualizada

La mayoría de los equipos de desarrollo de software utilizan al menos algún tipo de herramientas de control de versiones, seguimiento de incidencias y supervisión de aplicaciones. Todas ellas tienen un papel destacado en la cultura de DevOps, pero puede que el complemento más importante al conjunto de herramientas tradicional sea un software que posibilite la CI/CD. Tener un flujo de trabajo automatizado que, al realizar una confirmación, lleve a cabo las pruebas y las implementaciones correspondientes es la única forma de obtener el feedback rápido que requiere la cultura de DevOps.

DevOps: un cambio cultural que da resultados


Los desarrolladores siempre han soñado con poder entregar software más a menudo, con menos esfuerzo y menos errores. Pues bien, las herramientas y las prácticas para que ese sueño se haga realidad ya están aquí.

En Atlassian hemos constatado que las organizaciones que aplican el enfoque de DevOps declaran que lanzan productos de mayor calidad (61 %), con una mayor frecuencia de implementación y un tiempo de comercialización más rápido (49 %). Y no son solo las organizaciones las que obtienen ventajas: los profesionales afirman que han adquirido nuevas habilidades (78 %) y han generado un aumento (48 %).

Crear una cultura de DevOps puede ser todo un reto, pero la recompensa que supone un aumento de la satisfacción de desarrolladores, gerentes y clientes merece la pena.

¿Quieres mejorar tu cultura de DevOps? Empieza con el Monitor de estado del equipo de servicios y practica la comunicación, la colaboración y la lluvia de ideas con tus compañeros con las 4 estrategias más importantes para crear una cultura de DevOps.

Tom Hall
Tom Hall

Tom Hall es usuario y entusiasta de DevOps, lector voraz y pianista aficionado.
En los últimos 20 años ha conseguido, entre otros logros, certificaciones de Novell, EMC, VMware y AWS. Ayudó a organizar las jornadas DevOpsDays en Atlanta en 2016 y en Austin (Texas) en años posteriores.


Compartir este artículo

Lecturas recomendadas

Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.

Ilustración de Devops

La comunidad de DevOps

Ilustración de Devops

Taller de simulación

Ilustración de un mapa

Pruébalo gratis

Suscríbete para recibir el boletín de DevOps

Thank you for signing up