Dimensionamiento del personal de TI en la era de DevOps: ¿cómo y cuándo se ampliaría un equipo de DevOps?

Dado que DevOps permite al personal de TI reducir y hacer más a través de toda la automatización, ¿cuáles son los límites para eso?

Es decir, ¿cuáles son las reglas generales, si las hay, en las que sabría que necesita más personas a pesar de las tasas de automatización que avanzan rápidamente y la introducción de RPA ( Automatización robótica de procesos )?

Nota: se trata del tamaño del personal de todos los departamentos de TI en conjunto con el tamaño, la estructura y la función de su negocio (el tamaño de un solo equipo está bien definido por el concepto de equipo de dos pizzas ).

En mi humilde opinión no es una buena idea para aplicar directa e inmediatamente las ganancias de un equipo de su transformación DevOps en escalar el equipo hacia abajo . En el mejor de los casos, perderá solo la motivación del equipo para hacer tal mejora en el futuro. Pero lo más probable es que pierdas la mayoría / todo el talento en ese equipo.

En lugar:

• permita que el equipo aprecie los beneficios de la difícil transformación por la que pasaron, para que corran la voz a sus otros equipos que tendrán que pasar (o ya están luchando) con la transformación
• enfóquese en ofrecer productos / servicios de mejor calidad, más rápido, con el mismo equipo, esto ahora es posible debido a la transformación.
• en muchos casos, su negocio se acelerará debido a la transformación (pronto tendrá más probabilidades de contratar personas). En mi humilde opinión, es mejor utilizar la experiencia de los que ya tiene en lugar de educar a nuevos empleados
• permita que la deserción voluntaria trabaje para usted y obtenga la reducción efectiva en el futuro.

Pero, en general, las transformaciones de DevOps tienden a no suceder lo suficientemente rápido como para permitir las opciones anteriores :)

Ahora en escalar hacia arriba / afuera .

Idealmente, la transformación DevOps debería haber aumentado considerablemente la previsibilidad de su proceso de desarrollo y entrega de software. Debería poder determinar con gran precisión la capacidad de su equipo existente: la cantidad de servicios / servicios de cierta calidad que su equipo actual puede realizar en un determinado período de tiempo.

Cuando necesita hacer más cosas, o hacerlo mejor / más rápido que la capacidad del equipo actual, necesita escalar el equipo hacia arriba / afuera. Los detalles exactos provienen de cualquier proceso / metodología que utilice para sus actividades diarias, probablemente alguna variante ágil (consulte también ¿Mi organización necesita adoptar Agile Soft. Dev. Antes de adoptar DevOps? )

Cómo , aparentemente fácil: contratar a más personas para manejar las actividades desbordantes. Si le preocupa qué tan rápido puede llevarlos a bordo y realmente manejar ese trabajo de desbordamiento a las tasas esperadas: comience a contratar antes, según las proyecciones.

Sin embargo, la realidad puede ser un poco más difícil que eso. Escalar un producto / servicio de software o el proceso de desarrollo y las herramientas que lo respaldan no es necesariamente sencillo, incluso para una organización con poder DevOps.

Uno de mis ejemplos favoritos es el enlace más débil de DevOps cuando se trata de escalabilidad : Integración continua. Si la compilación de CI falla, no puede haber entrega / implementación (lo que socava el término "continuo" en el contexto del CD).

El hecho de que cierto equipo esté usando CI con buenos resultados, no significa que sucederá lo mismo si el tamaño del equipo se duplica. No, los resultados podrían ser devastadores: el proceso de entrega puede detenerse (en casos extremos). Estoy tratando de explicar esto en Congestion in Traditional CI Systems ( descargo de responsabilidad: soy el fundador de la empresa propietaria de la página referenciada y que ofrece una solución a este problema).

Otro ejemplo podría ser, por ejemplo, el sistema de control de versiones (VCS) que se utiliza: a medida que el software que se almacena en un repositorio evoluciona, también lo hace su historial de cambios, superando los límites del sistema VCS, a veces más allá de los niveles de rendimiento aceptables. Cambiar a un sistema VCS más escalable o dividir la base de código en múltiples repositorios podría ser un enfoque para abordar el problema.

Pero la evolución de los procesos de desarrollo y las herramientas que los respaldan junto con la evolución de los productos / servicios de software que se entregan son fundamentalmente lo que hace un equipo maduro de DevOps. Solo deben tenerse en cuenta cuando se está en la estrategia de ampliación / escalado del equipo.

Con eso en mente, el cómo puede, de hecho, reducirse a solo aumentar el tamaño del equipo para cubrir la cantidad de trabajo adicional necesaria para la ejecución de la estrategia mencionada anteriormente.