Team Topologies
Cómo influyen cuatro topologías fundamentales en una transformación al modelo DevOps.
Ian Buchanan
Ingeniero principal de soluciones
Contribución editorial: Shana Vu
Descubre qué ventajas tienen los equipos con flujos coordinados, cómo trabajan con los equipos de plataforma y los de subsistemas y cómo ayudan al resto de los equipos a ofrecer valor a los clientes.
Introducción a las topologías de equipo
Los equipos de ingeniería deben moverse más rápido que nunca para ofrecer valor a sus clientes. El auge de la nube, el software como servicio (SaaS) y los servicios ininterrumpidos implica que los clientes esperan nuevas funciones, menos errores y un tiempo de actividad del 99,99 % (o superior).
Para seguir el ritmo de esta demanda, las organizaciones adoptaron prácticas ágiles y, más recientemente, prácticas de DevOps, que prometen una comercialización y unos plazos más rápidos, mejoran la frecuencia de implementación, mejoran la cultura del equipo y aumentan la colaboración entre los equipos y departamentos.
Si bien adoptar prácticas de DevOps es más fácil decirlo que hacerlo, el libro Team Topologies ofrece algunas técnicas interesantes para que las organizaciones puedan incorporar la metodología DevOps a su empresa (por ejemplo, qué tipos de equipos podrían ser más efectivos). Este libro describe el punto de partida de Atlassian sobre cómo enfoca los equipos. En vez de reiterar sus conclusiones, queremos compartir nuestra propia perspectiva sobre los tipos de equipos.
El primer paso hacia una transformación al modelo DevOps es identificar la estructura organizativa que hay en la empresa. Ahora bien, hoy en día, las empresas tienen muchos tipos de equipos diferentes y, en algunos casos, equipos individuales que asumen múltiples funciones y responsabilidades. Esta expansión hace que a los responsables de equipo les cueste visualizar todo el organigrama y responder a preguntas como las siguientes:
Ver la solución
Herramientas DevOps para todo el equipo
Material relacionado
Crear una cultura de DevOps
- ¿Tenemos los equipos adecuados?
- ¿Nos faltan capacidades en algunas áreas que no está abordando ningún equipo?
- ¿Los equipos cuentan con el equilibrio necesario entre autonomía y apoyo con respecto a otros equipos?
Los responsables de los equipos de desarrollo y operaciones pueden hacerse una idea más clara de si están trabajando los equipos adecuados observando la organización a través del libro Team Topologies. Recomendamos reducir el número de variaciones en los equipos a cuatro topologías de equipo fundamentales que sean fáciles de "digerir" tanto para la dirección como para los propios miembros de los equipos:
- Equipo con flujos coordinados
- Equipo de plataforma
- Equipo de subsistemas complejos
- Equipo habilitador
Ten presente que estos tipos de equipos 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 un tipo de equipo o que un equipo se transforme en otro.
Equipo con flujos coordinados
Los equipos con flujos coordinados se centran en un único flujo de trabajo que sea efectivo. Puede ser un único producto o servicio, un solo conjunto de funciones, un único recorrido de usuario o un solo perfil de usuario. El equipo tiene la capacidad de crear y ofrecer valor al cliente o usuario de la forma más rápida, segura e independiente posible, sin tener que entregar parte de su trabajo a otros equipos.
Debido a que los equipos con flujos coordinados participan en el espectro completo de la entrega, tienen que estar necesariamente más cerca del cliente y, por lo general, ya suelen trabajar con una metodología ágil. Este tipo de equipo incorpora los comentarios de los clientes a los ciclos de desarrollo, a la vez que mantiene el software en producción.
Si bien los equipos con flujos coordinados son habituales en muchas empresas de software, otras organizaciones pueden estar más familiarizadas con las estructuras de equipo organizadas por función (p. ej., equipos divididos en ingeniería, diseño, control de calidad, etc.) que por flujo de entrega.
Dado que el tipo de equipo con flujos coordinados es el más habitual en las organizaciones, el papel que desempeñan el resto de equipos se define con respecto a los equipos con flujos coordinados. Este tipo de equipos debe comunicarse periódicamente con los siguientes equipos de soporte (habilitadores, de subsistemas complejos y de plataforma) para mejorar continuamente la velocidad de entrega y la calidad de sus productos y servicios.
Equipo de plataforma
Los equipos de plataforma permiten que los equipos con flujos coordinados entreguen trabajo con una gran autonomía. Los equipos con flujos coordinados asumen toda la responsabilidad de la compilación, ejecución y corrección de una aplicación en producción, mientras que los equipos de plataforma se encargan de proporcionarles los servicios internos que pueden utilizar.
Los equipos de plataforma crean funciones que se pueden utilizar por varios equipos con flujos coordinados con una sobrecarga mínima. Al optimizar un producto, los equipos de plataforma minimizan los recursos y las cargas cognitivas de los equipos con flujos coordinados. Esto también beneficia a los usuarios finales, ya que los equipos de plataforma pueden crear una experiencia coherente que abarque diferentes experiencias de usuario o productos.
En Atlassian, los equipos de plataforma crean servicios que se utilizan en todos nuestros productos (como la gestión de identidades) y se espera que ofrezcan documentación, soporte y asesoramiento a los equipos con flujos coordinados.
Equipo de subsistemas complejos
Es responsabilidad de un equipo de subsistemas complejos crear y mantener una parte del sistema que depende de habilidades y conocimientos específicos. La mayoría de los miembros de este equipo deben ser especialistas en un campo de conocimiento concreto para entender cómo funciona el subsistema y saber realizar cambios en él.
El objetivo de este equipo es reducir la carga de los equipos con flujos coordinados que trabajan en sistemas que, a su vez, incluyen o utilizan el subsistema. Gracias a la experiencia y los conocimientos del equipo de subsistemas complejos, los equipos con flujos coordinados no se ven en la necesidad de crear funciones para campos que son demasiado complejos para su trabajo diario. Los miembros de este equipo pueden ser especialistas en determinados microservicios (por ejemplo, un servicio de facturación), algoritmos o incluso inteligencia artificial.
Un error que se comete habitualmente es integrar estos especialistas en cada equipo con flujos coordinados que utiliza el subsistema. Aparentemente puede parecer una maniobra eficiente, pero a la larga no sale a cuenta y queda fuera del alcance de los equipos con flujos coordinados.
Equipo habilitador
Los equipos con flujos coordinados trabajan bajo presión constante para entregar y responder a los cambios rápidamente, lo que les impide encontrar momentos para investigar, aprender y practicar habilidades nuevas.
Un equipo habilitador compuesto por especialistas de un determinado campo técnico (o de producto) les ayuda a encontrar esos momentos. Este tipo de equipo se encarga de investigar y probar herramientas, ecosistemas y marcos de trabajo nuevos para luego poder dar sugerencias fundamentadas que afectan a la pila de herramientas.
Así, los equipos con flujos coordinados pueden adquirir y desarrollar nuevas habilidades sin dejar de dedicar tiempo a sus objetivos principales. Básicamente, el equipo habilitador se encarga de dar más autonomía a los equipos con flujos coordinados ampliando sus capacidades, poniendo el foco en los problemas más que en las soluciones.
Si un equipo habilitador hace bien su trabajo, el equipo al que asista dejará de necesitar ayuda al cabo de unas semanas. El equipo habilitador nunca debe trabajar en una dependencia permanente.
¿Tienes un equipo con flujos coordinados?
Para averiguar si tienes un equipo con flujos coordinados en tu empresa, responde a las siguientes preguntas:
¿Tu equipo se propone producir un flujo constante de funciones?
Los equipos maduros publican varias veces a la semana y, en algunos casos, varias veces al día. Para lograr este objetivo, los equipos maduros deben utilizar la integración continua y la entrega continua (CI/CD) para lanzar funciones con frecuencia.
¿Tu equipo cambia de rumbo rápidamente en función de los comentarios recibidos (del cliente o internos) respecto a los cambios más recientes?
A menudo lo mejor es utilizar un concepto experimental para hacer evolucionar el producto. Los procesos de DevOps maduros incluyen pruebas automatizadas para garantizar unos lanzamientos de código de calidad. Sin embargo, la experimentación va más allá de meras pruebas unitarias o de aceptación. Puedes asegurarse de que tus productos ofrezcan el máximo valor posible a los clientes utilizando marcas de función para automatizar las implantaciones en un subconjunto de usuarios, publicaciones alfa y beta para solicitar y medir los comentarios y el comportamiento de los usuarios, y comentarios cualitativos continuos a través de sugerencias, tickets de soporte, y foros de la comunidad.
¿Tu equipo minimiza las entregas de trabajo a otros equipos?
Debería ser así de dos formas. Por un lado, tu equipo debe ser autónomo y trabajar con sus compañeros inmediatos para garantizar una entrega rápida. Más allá del alcance del trabajo, las entregas mínimas también pueden adoptar la forma de procesos automatizados. La automatización del ciclo de desarrollo garantiza que el trabajo salga adelante de manera fluida, independientemente de si el siguiente paso es una acción (como una prueba automatizada o una fusión con la rama principal) o una persona.
Puntos de bonificación si...
¿Tu equipo tiene tiempo de abordar los cambios en la calidad del código (también conocida como "deuda tecnológica") para asegurarse de que sean seguros y fáciles de implementar?
Los equipos maduros utilizan el desarrollo basado en troncos y las prácticas de CI/CD para mantener su código base. La planificación de la capacidad debe tener en cuenta el tiempo que se destina a gestionar la deuda tecnológica. Además, los proyectos a gran escala que abordan problemas de infraestructura o plataforma subyacentes deben recibir la misma atención que el desarrollo de funciones.
¿Se evalúa a tu equipo con las métricas correctas?
Más allá de la rapidez con la que lanza tu equipo, entre sus métricas de éxito también se deberían incluir las relativas al estado del equipo y a la calidad técnica.
En cuanto a la última pregunta sobre la medición, tradicionalmente, los equipos de DevOps han incluido las cuatro métricas clave del programa DORA (DevOps Research and Assessment) en su definición de "éxito":
- Frecuencia de implementación: frecuencia con la que una organización publica correctamente a producción.
- Plazo para modificaciones: tiempo que tarda una confirmación en llegar a producción.
- Tasa de errores por modificaciones: porcentaje de implementaciones que provocan un error en la producción.
- Tiempo de restablecimiento del servicio: tiempo que tarda una organización en recuperarse de un error en la producción.
Además de estas métricas especificadas por DORA, Atlassian ha descubierto que los equipos de alto rendimiento con flujos coordinados también supervisan estos atributos:
- Equipo equilibrado: tu equipo cuenta con habilidades y perspectivas diferentes.
- Propietario a tiempo completo: un propietario a tiempo completo garantiza que el núcleo de tu equipo y los participantes interdisciplinares sepan a quién hacer preguntas y cómo tomar decisiones relacionadas con los proyectos que son propiedad del equipo.
- Percepción común: existe una percepción común de los requisitos, junto con la definición de los valores y métricas de éxito.
- Atención en el valor y las métricas: tu equipo se guía por unos criterios que le indican qué tareas debe abordar para hacer avanzar los proyectos hasta la fase de publicación.
- Prueba de concepto: tener un artefacto real con el que poder hacer comprobaciones y probar suposiciones ayuda al equipo a iterar y mejorar constantemente.
- Gestión de dependencias para mantener la velocidad: entender las dependencias gestionadas evita que surjan impedimentos y contribuye a mantener la velocidad.
En conclusión...
La metodología DevOps no es un destino, sino un viaje de mejora constante de herramientas, cultura de equipo y prácticas. Si es la primera vez que oyes hablar de DevOps, empieza por orientar tus objetivos para aportar valor a los clientes. A medida que tu empresa madure, incorpora la automatización a tus herramientas y procesos. Y, finalmente, cuando los miembros de tu equipo se conviertan en profesionales avanzados, incorpora la observabilidad para asegurarte de que estés supervisando, midiendo y mejorando los elementos adecuados.
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.
La comunidad de DevOps
Ruta de aprendizaje de DevOps
