Close

La importancia de la estructura del equipo en la metodología DevOps

Cada equipo requiere una estructura diferente según el contexto general de la empresa.

Shana Vu

Marketing de Producto, DevOps


Cuando un equipo de software está en proceso de adoptar la metodología DevOps, es importante tener en cuenta que cada equipo deberá estructurarse de una forma distinta según el contexto general de la empresa y sus ganas de cambio.

El auge de los equipos de DevOps

¿Tienes un equipo de DevOps en tu empresa? Es muy posible que sí. En nuestra encuesta sobre tendencias de DevOps, más de dos tercios de las organizaciones encuestadas afirmaron tener un equipo o una persona con la palabra "DevOps" en alguna de sus funciones.

A medida que DevOps se va generalizando, a menudo oímos que los equipos de software ahora son equipos de DevOps. Sin embargo, el hecho de incorporar herramientas nuevas o llamar a un equipo "de DevOps" no es suficiente para empezar a disfrutar de todos los beneficios que ofrece DevOps.

Sin una comprensión clara del modelo DevOps y cómo implementarlo correctamente, una transformación a este modelo normalmente se limitará a una reorganización o a la incorporación de las últimas herramientas del mercado. La correcta adopción del modelo DevOps pasa por un cambio cultural, que consiste en reestructurar los equipos, regirse por nuevos principios de gestión e incorporar determinadas herramientas tecnológicas.

Tipos de estructuras de equipo en DevOps

Antes de decidir qué estructura de equipo de DevOps conviene implementar, es necesario tener en cuenta varios factores, como el número de productos en los que trabaja una organización, los puestos de liderazgo técnicos y si los equipos de desarrollo y operaciones tienen la capacidad de sincronizar sus procesos.

Ver la solución

Herramientas DevOps para todo el equipo

Material relacionado

Descubre las ventajas de DevOps

Es importante entender que no todos los equipos tienen los mismos objetivos ni utilizarán las mismas prácticas y herramientas. Incluso la forma en la que se estructura un equipo no debería estandarizarse. Cada equipo requiere una estructura diferente según el contexto general de la empresa y sus ganas de cambio. Un equipo de DevOps de dos empresas diferentes puede significar dos cosas completamente distintas.

Para aprovechar todas las ventajas (como una comercialización más rápida, una frecuencia de implementación mejorada, una mejor cultura de equipo y una mayor colaboración entre equipos y departamentos), es importante entender el papel que desempeña cada equipo. Aun así, en muchas organizaciones hay equipos con varios nombres que asumen múltiples cargos (por ejemplo, un equipo de infraestructura actúa como selector y encargado de mantener las herramientas). Esta expansión hace que a los responsables de equipo les cueste visualizar todo el organigrama y responder a preguntas importantes como las siguientes: ¿Tenemos los equipos adecuados?, ¿Nos faltan capacidades en algunas áreas que no está abordando ningún equipo? ¿Parece que los equipos cuentan con el equilibrio necesario entre autonomía y apoyo con respecto a otros equipos?

El gran trabajo que ha hecho el equipo de Team Topologies ha servido como punto de partida para Atlassian en cuanto a su forma de entender los diferentes enfoques de equipo de DevOps. Ten presente que las estructuras de equipo que se indican a continuación pueden adoptar diferentes formas según el tamaño y la madurez de cada empresa. En realidad, el enfoque ideal sería combinar más de una estructura o que una estructura se transforme en otra.

Colaboración entre los equipos de desarrollo y operaciones

Muchas personas creen que la metodología DevOps consiste en hacer que los equipos de desarrollo y operaciones trabajen y colaboren de forma coordinada. Esta es, sin duda, la base de esta metodología y tiene unas ventajas claras, como dotar a los equipos de software de la capacidad de crear, probar y lanzar de forma más rápida y fiable.

La clave del éxito de esta estructura de equipo es que los desarrolladores toman consciencia de la presión que a la que están sometidos los equipos de operaciones para mantener el tiempo de actividad y minimizar las resoluciones. Igual de importante es que los equipos de operaciones comprendan el deseo de los equipos de desarrollo de reducir el tiempo de implementación y comercialización.

Desarrollo y operaciones, juntos

En esta estructura de equipo, se asume que el desarrollo y las operaciones van de la mano y trabajan en un mismo equipo, actuando como un frente único con objetivos compartidos. A veces, este tipo de estructura recibe el nombre de "NoOps", sobre todo en grandes empresas tecnológicas que tienen un solo producto digital principal, como Facebook o Netflix. Esta situación puede incluso dar lugar a que las mismas personas tengan que desarrollar y operar las aplicaciones al estilo "tú lo creas, tú lo gestionas".

DevOps/SRE

Esta estructura de equipo, popularizada por Google, consiste en que un equipo de desarrollo entrega un producto al equipo de ingeniería de fiabilidad del sitio (SRE), que es quien realmente ejecuta el software. En este modelo, los equipos de desarrollo proporcionan registros y otros artefactos al equipo de SRE para demostrar que su software cumple unos estándares suficientes para que el equipo de SRE le dé el visto bueno. Los equipos de desarrollo y SRE colaboran siguiendo unos criterios operativos. Los equipos de SRE tienen la capacidad de pedir a los desarrolladores que mejoren el código antes de enviarlo a producción.

Operaciones como plataforma

En esta estructura de equipo, un equipo dentro del equipo de desarrollo actúa como fuente de conocimientos en todas las operaciones y trabaja en la mayor parte de la interfaz con el equipo de infraestructura como servicio (IaaS). Esta estructura de equipo depende de las aplicaciones que se ejecutan en una nube pública, ya que el equipo de IaaS crea servicios virtuales escalables que utiliza el equipo de desarrollo.

DevOps como parte externa

Hay empresas que utilizan la metodología DevOps a través de un consultor o un equipo de DevOps externo durante un periodo concreto para ayudar a sus equipos de desarrollo y operaciones a avanzar hacia las dos primeras estructuras de equipo mencionadas (es decir, colaboración entre los equipos de desarrollo y operaciones, y desarrollo y operaciones, juntos).

Si bien hay varias formas de adoptar la metodología DevOps, también hay muchas formas de no hacerlo. Los equipos y responsables de DevOps deben tener cuidado con los antipatrones, que se caracterizan por la división de equipos, la falta de comunicación y una priorización errónea de las herramientas por encima de la comunicación.


Funciones y responsabilidades de los equipos de DevOps

Independientemente de la estructura que tenga tu equipo, todos los equipos de alto rendimiento que utilizan la metodología DevOps comparten regularmente sus conocimientos y experiencias de desarrollo y operaciones, ya sea en reuniones periódicas, poniendo varias personas a trabajar en ambos equipos o haciendo que los miembros del equipo desempeñen ambas funciones. Un equipo de alto rendimiento se caracteriza por las ventajas que ofrece la metodología DevOps, es decir, una comercialización más rápida, unos plazos mejorados, una mayor frecuencia de implementación, unas entregas de mejor calidad, una mejor cultura de equipo y una mayor colaboración entre equipos y departamentos.

Los equipos de DevOps suelen estar compuestos por personas con habilidades tanto de desarrollo como de operaciones. A algunos miembros se les dará mejor la programación y a otros, la operación y administración de infraestructuras. Sin embargo, en las grandes empresas, cada aspecto de la metodología DevOps (desde la CI/CD hasta la IaaS y la automatización) puede materializarse en una función. Por ejemplo, un gestor de publicaciones que coordine y administre aplicaciones desde la fase de desarrollo hasta la de producción, arquitectos de automatización que mantengan y automaticen la canalización de CI/CD del equipo, etc.

Así pues, ¿qué se necesita para unirse a un equipo de DevOps? Los requisitos laborales para unirse a un equipo de DevOps evolucionan debido a las nuevas tecnologías y técnicas, pero las cualidades de un buen equipo de DevOps son siempre las mismas: tener unas habilidades técnicas sólidas, buenas dotes de comunicación, una mentalidad de trabajo en equipo y la capacidad de adaptarse. Estas solo son algunas de las características principales de un profesional de DevOps consumado. Contar con una combinación de estas aptitudes es probablemente más importante que tener un conocimiento enciclopédico de Kubernetes o Git. Ahora bien, si se tienen las dos cosas, ¡mejor que mejor!

Otro ingrediente para el éxito es contar con un líder dispuesto a evangelizar la metodología DevOps en un equipo, los equipos colaborativos y toda la organización en general. No tiene por qué ser alguien con la palabra "gerente" en su cargo, pero sí alguien dispuesto a convencer a los miembros escépticos de los equipos para empezar a acortar distancias entre su equipo y los demás, ya sean de desarrollo, operaciones o plataforma.


Software para reforzar tu equipo

Al final, el trabajo que hace un equipo a diario es el que determina qué cadena de herramientas de DevOps necesita. Aun así, necesitarás contar con algún tipo de software que conecte y coordine el trabajo entre tu equipo y el resto de la organización. Jira es una potente herramienta que planifica, supervisa y gestiona proyectos de desarrollo de software, manteniendo a tus compañeros de equipo más cercanos y al resto de la organización al tanto del estado de tu trabajo.

Aplicaciones como Zoom, Slack y Microsoft Teams también son necesarias para una comunicación rápida y eficiente entre equipos, especialmente en un mundo que da prioridad al trabajo en remoto. Antes, un desarrollador podía ir al equipo de operaciones para preguntarle acerca del estado de un incidente. Sin embargo, ahora las aplicaciones de comunicación virtual proporcionan esa misma comunicación instantánea.

Pero recuerda: el software para permitir que tus equipos trabajen juntos es un medio, no un fin. Si tu organización quiere aprovechar todo el potencial de la metodología DevOps (transparencia, confianza y autonomía), se necesitan equipos (no solo herramientas) para lograrlo.

Shana Vu
Shana Vu

Shana is a product marketer passionate about DevOps and what it means for teams of all shapes and sizes. She loves understanding the challenges software teams face, and building content solutions that help address those challenges. If she's not at work, she's likely wandering the aisles of her local Trader Joes, strolling around Golden Gate, or grabbing a beer with friends.


Compartir este artículo
Tema siguiente

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