Como dice Jim Benson en The Collaboration Equation, “las personas que forman parte de un equipo crean valor”, la combinación de las habilidades individuales con la colaboración es lo que permite que sucedan grandes cosas.
Los equipos que no rinden lo suficiente se producen cuando no se tiene en cuenta la necesidad de que las personas trabajen juntas para liberar sus talentos únicos.
Desde que DevOps se convirtió en la palabra de moda en la industria, surgieron muchos ejemplos de antipatrones. Sin embargo, los patrones y los antipatrones no significan nada cuando se reúne a personas en una sala y se les pide que resuelvan un problema o brinden valor.
En lugar de una única forma verdadera de organizar los equipos, es necesario prestar atención a lo siguiente:
- Cultura y contexto
- Las habilidades de cada individuo
- ¿Qué problemas sistémicos podrían estar sofocando la colaboración?
No es necesario empezar desde cero. Analice las estructuras de equipos de DevOps existentes que utilizan otras organizaciones en determinadas circunstancias.
Los modelos de interacción pueden ayudarlo a comprender la naturaleza de las dependencias entre equipos.
DevOps
La idea original de DevOps no era cambiar las estructuras de los equipos en absoluto. Se trataba de que los equipos de desarrollo y operaciones trabajaran más de cerca para entregar software.
Para que esto sucediera, había que eliminar los objetivos conflictivos. Después de identificar y corregir los comportamientos sistémicos que dañaban el valor, la colaboración se hace posible.
Muchas organizaciones ya estaban familiarizadas con los equipos multifuncionales. No es de sorprender que el personal de operaciones comenzara a incorporarse a los equipos de entrega de software existentes para trabajar con otras disciplinas, como desarrolladores de software, evaluadores y gerentes de productos. Tener un solo equipo hace que sea mucho más difícil encontrar objetivos conflictivos.
Otras organizaciones formaron un equipo entre el equipo de desarrollo y el de operaciones, a menudo denominado “equipo DevOps”. En general, esto es un antipatrón, pero si da como resultado una mayor colaboración y una comprensión compartida, es un paso hacia mejores resultados.
Es probable que tenga éxito si el equipo cuenta con miembros de ambos equipos existentes y es un trampolín hacia equipos multifuncionales.
DevSecOps, BizOps y otros
Es posible que el principal límite de su organización no sea el de desarrollo y operaciones. Muchas organizaciones utilizaron variaciones de DevOps como una campaña interna para aumentar la colaboración.
Aquí es donde DevSecOps y BizOps alentaron a los especialistas a trabajar más juntos.
Puede utilizar BizOps para destacar una desconexión entre la empresa y los equipos que proporcionan sus herramientas. Para que esto funcione, debe repetir el proceso de DevOps para encontrar objetivos conflictivos y otras barreras que impidan que los equipos trabajen juntos.
El nombre por sí solo no cambiará nada.
Puedes ampliar la idea allí donde encuentres silos que separen a las personas que necesitan trabajar juntas. Si tienes muchos silos, debes abordar los problemas culturales centrales que causan estas barreras defensivas. La sección sobre topologías de equipo puede ayudarte a rediseñar tus equipos y tus interacciones.
Mida todas las iniciativas de DevOps en función de los resultados organizacionales en lugar de las medidas locales.
En todos los casos, la investigación y el modelado de DevOps abarcan el liderazgo, la cultura y las prácticas técnicas. DevOps funciona en colaboración y muchos optan por equipos autónomos y multifuncionales. Estos otros nombres reflejan preocupaciones urgentes para organizaciones específicas.
RUTAS DE DEVOPS
Hay dos errores comunes en el diseño del equipo de DevOps:
- Contratar a una persona para cada habilidad, lo que crea silos de uno
- Cargar a una sola persona con demasiadas habilidades y provocar una sobrecarga cognitiva
Solo se pueden evitar estos dos extremos adoptando una posición intermedia. Hay que encontrar una combinación de personas que aporten distintas combinaciones de habilidades al equipo. Es una tarea compleja, ya que cada persona que se incorpora cambia lo que se necesita de la siguiente.
Para ayudarle a diseñar sus equipos, puede utilizar DevOps PATHS.
PATHS significa:
- Proceso (Lean, Agile, Kanban, DevOps, Entrega continua, Programación extrema)
- Automatización (scripting, herramientas)
- Técnico (Programación, arquitectura, nube)
- Humano (comunicación, cultura, empatía)
- Especialista (desarrollo, operaciones, seguridad, pruebas)
El uso de PATHS puede ayudarle a equilibrar los silos individuales y la sobrecarga cognitiva.
Puede utilizar DevOps PATHS para detectar estructuras de equipo accidentales comunes para solucionar y evitar problemas a largo plazo.
Equipos de héroes
Los equipos compuestos por especialistas, como los desarrolladores de software, son “equipos heroicos”. Un miembro del equipo altamente capacitado administra las compilaciones, las implementaciones y la respuesta a las interrupciones del servicio.
En algunos casos, el héroe obtiene un rol como el de ingeniero de DevOps. A menudo, simplemente les apasiona el proceso de entrega de software en general y quieren mejorarlo.
A largo plazo, la carga que soporta este miembro del equipo puede provocar agotamiento. No es bueno para la persona y es una mala noticia para la organización cuando su rendimiento disminuye o se va.
Utilice DevOps PATHS para detectar grupos densos de habilidades y alentar a los miembros del equipo a explorar otras áreas que les interesen. Le ayuda a distribuir el conocimiento y la carga de manera más uniforme.
Anteojeras
Un equipo con anteojeras tiene un buen desempeño en muchas de las habilidades de PATHS, pero tiene puntos ciegos importantes. Puede que esté entregando un gran producto, pero con poca automatización.
La falta de automatización no es evidente durante la operación normal, pero lleva mucho tiempo implementar una solución cuando se descubre un problema crítico de producción.
A largo plazo, comienzan a aparecer grietas que se extienden desde los puntos ciegos hacia áreas en las que el equipo inicialmente tuvo un buen desempeño. Muchos equipos de bajo rendimiento eran equipos que antes tenían una visión limitada y que estaban teniendo un buen desempeño.
Utilice DevOps PATHS para detectar áreas de habilidades con poca o ninguna cobertura y busque líderes en el equipo que puedan crecer en esas materias.
Uso de DevOps PATHS
Además de estos ejemplos, muchos otros diseños resultan problemáticos a largo plazo. DevOps PATHS ofrece una forma de abordar la sobrecarga de miembros del equipo y las carencias de habilidades.
Al crear comunidades de práctica en torno a cada una de las cinco áreas de habilidades, puede:
- Fomentar el intercambio de conocimientos
- Resalte las habilidades críticas que necesita en el equipo
- Difundir ideas más allá de los límites del equipo
Puede utilizar su mapa de habilidades cuando los miembros del equipo estén buscando oportunidades de crecimiento o durante el proceso de contratación.
El tamaño y la composición del equipo forman parte del diseño más amplio del sistema de gestión. A medida que los equipos crecen, la productividad individual disminuye, pero se es más resistente a las bajas por enfermedad, las vacaciones y el paso de miembros del equipo a nuevos puestos.
Es fácil crear un equipo con todas las habilidades necesarias contratando a muchas personas, pero el equipo no tendrá resiliencia ya que cada miembro se encarga de un área pequeña y aislada.
El trabajo de un gerente profesional es formar un equipo con una combinación sólida de habilidades que se superpongan y mantener el equipo lo más pequeño posible.
Topologías de equipo
Puede revisar su comprensión de estas estructuras de equipo de DevOps utilizando Topologías de equipo. Este modelo reconoce que la comunicación dentro de un equipo requiere un gran ancho de banda.
La alineación de dos equipos puede afectar la velocidad con la que se transmite la información entre ellos. En algunos casos, la información fluye muy lentamente.
Puedes tener esto en cuenta cuando diseñes equipos. Esto no significa juntar a personas si van a compartir información regularmente. También debes resolver problemas que provoquen una comunicación innecesaria.
Por ejemplo, si todos necesitan hablar con un equipo que está desarrollando una API, es posible que la API:
- No está bien diseñado
- Tiene muchos problemas
- No es autodocumentarse
También puede utilizar las cuatro topologías de equipo fundamentales para comprender el rol, las responsabilidades y el modo de interacción de un equipo. Las cuatro topologías de equipo son:
- Alineado con la corriente
- Subsistema complicado
- Habilitando
- Plataforma
No es necesario que haya un equipo de cada tipo, pero cualquier equipo debe parecerse a uno de los cuatro tipos. Los autores describen esto como una serie de polos magnéticos, en los que cada equipo se siente atraído por un tipo.
Equipos alineados con el flujo de trabajo
Los equipos alineados con el flujo de trabajo trabajan en un único flujo de trabajo valioso, generalmente alineado con un dominio empresarial. Pueden centrarse en una función o un grupo de funciones específicos, trabajar solo en un recorrido de usuario o alinearse con una personalidad en particular.
Un equipo alineado con el flujo de trabajo trabaja en todo lo necesario para la entrega. Por ejemplo, el equipo descubriría los problemas de los usuarios y operaría y supervisaría el sistema en producción.
Cuando se observa a un equipo alineado con el flujo de trabajo, no tiene dependencias críticas de ningún otro equipo. Tiene todas las habilidades necesarias para brindar valor.
Encontrar la combinación adecuada de personas para crear un equipo pequeño con las habilidades necesarias es un desafío. Aun así, los resultados son un flujo de información de gran ancho de banda y una colaboración cada vez más brillante.
Equipos de subsistemas complicados
Si una parte de su sistema está altamente especializada, puede utilizar un equipo de subsistemas complejo para gestionarla. No debería crear este equipo a menos que las circunstancias lo obliguen. Por ejemplo, si las habilidades necesarias son tan especializadas, debe agruparlas.
Siempre que sea posible, utilice equipos alineados con el flujo de trabajo. Si tiene que crear un motor de renderizado 3D innovador, es posible que necesite un equipo de subsistemas complicado para afrontar los desafíos.
Habilitando equipos
Un equipo habilitador adopta una visión a largo plazo de la tecnología para aportar una ventaja competitiva a las organizaciones.
Investigan posibles novedades:
- Herramientas
- Capacidades
- Prácticas
- Otras tecnologías
Protegen la autonomía de los equipos alineados con el flujo de trabajo al ayudarlos a aumentar las habilidades e instalar nuevas tecnologías. Como equipo facilitador, el objetivo es brindarles el conocimiento a los equipos, no dictarles qué hacer con él.
Los equipos de apoyo son útiles como parte de una estrategia de escalamiento, ya que los equipos alineados con el flujo de trabajo suelen estar demasiado ocupados para investigar y crear prototipos de nuevas herramientas y tecnologías.
El equipo de apoyo puede explorar el nuevo territorio y empaquetar el conocimiento para su uso general dentro de la organización.
Equipos de plataforma
Un equipo de plataforma actúa como un equipo facilitador que reúne el conocimiento en una oferta de autoservicio. Los equipos alineados con la corriente pueden usar los productos creados por los equipos de plataforma para simplificar y acelerar su trabajo.
Los equipos de plataforma promueven buenas prácticas técnicas al facilitar el acceso a buenas decisiones y ayudan a los equipos alineados con el flujo de trabajo a lograr más.
Modos de interacción
Aún más útiles que los tipos de equipo son los modos de interacción. La interacción entre dos equipos debe ser uno de los tres tipos de interacción:
- Colaborando
- Facilitando
- Proporcionar un servicio
Clasificar cada interacción puede ayudarle a comprender la naturaleza de la dependencia y el nivel de servicio ofrecido. Es probable que interactúe con los equipos de manera diferente, pero cada relación debería poder identificarse como uno de estos modos.
Ingeniería de plataformas
La ingeniería de plataformas suele encontrarse junto con DevOps y tiene un fuerte vínculo con el rendimiento de la entrega de software. Se relaciona con las topologías de equipo, ya que los equipos de plataformas tienen muchas interacciones “como servicio” con los otros tipos de equipos.
Los equipos de la plataforma trabajan con los equipos de desarrollo para crear una o más rutas de trabajo . Estas rutas no impiden que los equipos utilicen algo más, pero ofrecen productos de autoservicio compatibles que ayudan a los equipos a mejorar la capacidad de entrega. Las rutas fomentan la alineación sin eliminar la autonomía del equipo.
El informe Accelerate State of DevOps muestra que es común encontrar equipos de ingeniería de plataformas en organizaciones de alto rendimiento.
| Categoría | % con Ingeniería de Plataforma |
|---|---|
| Bajo | 8% |
| Medio | 25% |
| Alto | 48% |
Si está ampliando la cantidad de equipos que entregan software, la ingeniería de plataformas ofrece coherencia sin limitar la elección del equipo. Como sus equipos no tienen que usar la plataforma, se beneficia de la competencia con otras vías de entrega de software.
Ingeniería de confiabilidad del sitio
La ingeniería de confiabilidad del sitio (SRE) resuelve las operaciones como si se tratara de un problema de software. El equipo de SRE se centra en el rendimiento, la capacidad, la disponibilidad y la latencia de los productos que operan a gran escala. Google fue pionero en este enfoque para gestionar la capacidad de servicio a nivel continental .
Si bien el rol de SRE es impactar la confiabilidad, muchos aspectos de la ingeniería de confiabilidad del sitio se alinean con los conceptos de DevOps.
- Colaboración interfuncional
- Amplia automatización
- Aprendizaje empírico
- El uso de técnicas de medición
Las prácticas de SRE son comunes en los equipos de DevOps, independientemente de si las adoptan formalmente.
La investigación de DORA ha descubierto que la confiabilidad libera el efecto del rendimiento de la entrega de software en los resultados organizacionales.
Resumen
No se debe juzgar el diseño de un equipo desde una perspectiva externa. Todas las organizaciones están en un proceso de mejora continua. Solo se puede evaluar su estado actual en relación con cómo eran las cosas antes.
El objetivo es una mayor colaboración y una mejora continua. Si una organización logra estos objetivos, es irrelevante que parezca un antipatrón desde el exterior.
Los diseños de equipos problemáticos (como equipos heroicos o equipos DevOps dedicados) son necesarios para lograr soluciones estables a largo plazo.
Puede utilizar DevOps PATHS y Team Topologies para fundamentar el diseño de su equipo. Inspírese en la ingeniería de plataformas y la ingeniería de confiabilidad del sitio cuando necesite escalar.
Las condiciones necesarias para el éxito son:
- Una cultura de alta confianza y baja culpa
- Liderazgo transformacional
- Gestión lean.
Las capacidades técnicas tendrán menos efecto en sus resultados sin estos requisitos previos.