Equipos DevOps
La creación de equipos dedicados de DevOps es una práctica cada vez más común en organizaciones que buscan mejorar la colaboración entre los equipos de desarrollo y operaciones, así como optimizar el ciclo de vida del desarrollo de software. Estos equipos están formados por profesionales que tienen habilidades tanto en desarrollo como en operaciones de TI, lo que les permite abordar de manera integral los desafíos relacionados con la entrega continua, la automatización, la infraestructura como código y la gestión de la configuración.
DevOps requiere la creación de equipos multifuncionales para cada producto o servicio a fin de que las personas sean responsables de las consecuencias de sus acciones.
Un Equipo multifuncional es un equipo de desarrollo de producto autodirigido. Puede tener un Scrum Master local (s) y (o) un Product Owner local (s). Un Equipo multifuncional puede tener funciones adicionales distintas de las funciones estándar de Scrum, tales como:
- Chief Scrum Master (Scrum de Scrums Master): Dirige o ayuda a que todo el proyecto siga el marco en colaboración con los Scrum Masters locales. Una persona puede ser el Scrum Master local para varios equipos. No es necesariamente un trabajo a tiempo completo.
- Chief Product Owner: se encarga del Backlog de productos en colaboración con los Product Owners locales para cumplir con las responsabilidades de Propiedad del producto. Algunas personas en el lugar de trabajo suelen estar en contra del concepto de tener varios Product Owner. Sin embargo, en ciertas situaciones, puede ser imposible o poco realista para un Product Owner colaborar con un gran número de personas o miembros del equipo, especialmente en el caso de un gran equipo de cientos de desarrolladores. Considere un ejemplo de hacer Historias de Usuario claras y concisas.
Evite crear un equipo insertando una capa de indirección entre los Equipos de desarrollo y operaciones. Nombrar a un equipo de este tipo como equipo DevOps en lugar de crear un equipo multifuncional a partir de los equipos de desarrollo y operaciones existentes no funcionará. Llevará a la creación de otro silo o equipo orientado a tareas.
Una organización tiene diferentes tipos de perfiles, como I-shape, Dash-shape y T-shape. DevOps anima a tener Perfiles en forma de T a la hora de formar equipos.
Reflexionar sobre la pregunta: “¿Dónde está el Ingeniero DevOps?”. Plantéate qué entiendes por la función de un ingeniero DevOps y cómo encaja esta función en el equipo DevOps.
DevOps Total.
El término «DevOps Total» es una extensión del concepto de DevOps que busca integrar aún más los equipos de desarrollo, operaciones y seguridad dentro de una organización. Esta idea se basa en la noción de que la colaboración entre estos equipos no solo debe abordar la entrega rápida y confiable de software, sino también la seguridad y el cumplimiento de las normativas.
En el mundo de DevOps, el ingeniero DevOps sirve como conector crucial, tendiendo puentes entre varios departamentos al tiempo que fomenta el intercambio de conocimientos y la colaboración mediante la aplicación de los principios DevOps. Esta función resulta esencial para superar las diferencias culturales y fomentar un sentido de propósito compartido entre equipos diversos. Las dos responsabilidades principales que defienden son fomentar la conciencia compartida y promover la responsabilidad colectiva. Analicemos estos dos elementos.
1. Hacer que la gente sea consciente de las consecuencias de sus actos. El primer paso clave es cultivar una conciencia compartida de las consecuencias de nuestras acciones. Esto implica crear un entendimiento común, una percepción mutua de las repercusiones del trabajo de cada miembro del equipo. Las estrategias para facilitarlo podrían incluir la rotación de los desarrolladores en los equipos de operaciones, invitar al personal de operaciones a las presentaciones de los desarrolladores e iniciar sesiones de “almuerzo y aprendizaje”. Animar a la gente a que cuente sus experiencias en un blog o a que comparta una comida con colegas de diferentes silos también puede reforzar este sentimiento de conciencia compartida.
2. Responsabilizar a las personas de las consecuencias de sus actos. El segundo elemento importante es fomentar un sentido compartido de la responsabilidad por las consecuencias de las acciones. Para ello hay que responsabilizar a cada miembro, asegurándose de que no sólo entienden su papel, sino que también se sienten responsables de sus resultados. Esto puede lograrse haciendo que los desarrolladores carguen con el peso de los aspectos operativos de sus proyectos, como llevar localizadores o responsabilizarse de los acuerdos de nivel de servicio (SLA) de los productos y Servicios que crean. Por ejemplo, responsabilizar al equipo de desarrollo del tiempo de actividad de un servicio como soporte de nivel 3 (L3) infunde un sentimiento de propiedad compartida.
La transición a esta responsabilidad compartida suele toparse con obstáculos en las grandes organizaciones tradicionales. Estas entidades tienden a ejecutar sus esfuerzos de desarrollo de software como proyectos de ingeniería civil. Una vez terminado, el sistema se entrega al equipo de operaciones para su mantenimiento, y el equipo del proyecto se reasigna a nuevas tareas. Este enfoque es fundamentalmente erróneo para el desarrollo de software. En su lugar, el desarrollo de software debería tratarse como un desarrollo de producto continuo, fomentando un sentido compartido de propiedad y responsabilidad a largo plazo. Este cambio garantiza que las responsabilidades no se “tiren por la borda”, sino que sean compartidas y comprendidas por todos los implicados, promoviendo una verdadera cultura DevOps.
Lecturas complementarias:
Fuente: https://dzone.com/articles/there%E2%80%99s-no-such-thing-%E2%80%9Cdevops