Dimensionamento da equipe de TI na era do DevOps - como e quando uma equipe de DevOps aumentaria?

Como o DevOps permite que a equipe de TI reduza a escala e faça mais com toda a automação, quais são os limites para isso?

Ou seja, quais são as regras práticas - se houver - onde você saberia que precisa de mais pessoas, apesar das taxas de automação e introdução rápidas do RPA ( Robotic Process Automation )?

Nota: trata-se do tamanho da equipe de todos os departamentos de TI totalmente relacionados ao tamanho, estrutura e função do seu negócio (o tamanho de uma única equipe é bem definido pelo conceito de equipe de duas pizzas ).

IMHO não é uma boa idéia para aplicar diretamente e imediatamente ganhos de uma equipe de sua transformação DevOps para escalar a equipe para baixo . Na melhor das hipóteses, você perderá apenas a motivação da equipe para fazer essa melhoria no futuro. Mas é mais provável que você perca quase todo o talento dessa equipe.

Em vez de:

• permita que a equipe aprecie os benefícios da difícil transformação pela qual passou, para que eles espalhem a palavra para as outras equipes que terão que passar (ou já estão lutando com) pela transformação
• concentre-se em fornecer produtos / serviços de melhor qualidade, mais rapidamente - com a mesma equipe - agora isso é possível devido à transformação.
• em muitos casos, sua empresa ganhará velocidade por causa da transformação - em breve você provavelmente precisará contratar pessoas - IMHO é melhor usar a experiência daqueles que você já possui, em vez de educar novos contratados
• permita que o atrito voluntário trabalhe para você e obtenha uma redução eficaz no caminho.

Mas geralmente as transformações do DevOps tendem a não acontecer com rapidez suficiente para permitir as opções acima :)

Agora, para aumentar / diminuir a escala .

Idealmente, a transformação do DevOps deveria ter aumentado bastante a previsibilidade do seu processo de desenvolvimento e entrega de sw. Você deve poder dizer com grande precisão a capacidade da equipe existente: quanto sw / serviços de uma determinada qualidade a equipe atual pode executar em um determinado período de tempo.

Quando você precisar fazer mais coisas ou executar melhor / mais rapidamente do que a capacidade da equipe atual, precisará aumentar / diminuir a equipe. Os detalhes exatos vêm de qualquer processo / metodologia que você usa para suas atividades diárias, provavelmente alguma variante ágil (consulte também Minha organização precisa adotar o Agile Soft. Dev. Antes de adotar DevOps? )

Como - aparentemente fácil: contrate mais pessoas para lidar com as atividades transbordantes. Se você está preocupado com a rapidez com que pode colocá-los a bordo e realmente lidar com esse trabalho excedente nas taxas esperadas: comece a contratar mais cedo, com base em projeções.

A realidade pode, no entanto, um pouco mais difícil do que isso. Escalar um produto / serviço de software ou o processo de desenvolvimento e as ferramentas que o suportam não é necessariamente direto, mesmo para uma organização habilitada para DevOps.

Um dos meus exemplos favoritos é o link mais fraco do DevOps quando se trata de escalabilidade : integração contínua. Se a construção do IC falhar, não haverá Entrega / Implantação (meio que minando o termo "contínuo" no contexto do CD).

Só porque uma determinada equipe está felizmente usando o IC com resultados decentes, não significa que o mesmo acontecerá se o tamanho da equipe dobrar. Não, os resultados podem ser devastadores - o processo de entrega pode ser interrompido (em casos extremos). Estou tentando explicar isso em Congestionamento nos sistemas tradicionais de IC ( exoneração de responsabilidade: sou o fundador da empresa que possui a página referenciada e oferece uma solução para esse problema).

Outro exemplo pode ser, por exemplo, o sistema de controle de versão (VCS) que está sendo usado: à medida que o software armazenado em um repositório evolui, o mesmo ocorre com o histórico de alterações, aumentando os limites do sistema VCS, às vezes além dos níveis de desempenho aceitáveis. Mudar para um sistema VCS mais escalável ou dividir a base de código em vários repositórios pode ser uma abordagem para resolver o problema.

Mas evoluir os processos de desenvolvimento e as ferramentas que os suportam, juntamente com a evolução dos produtos / serviços de software que estão sendo entregues, são basicamente o que uma equipe madura de DevOps faz. Eles também precisam ser levados em consideração na estratégia de expansão / retirada da equipe.

Com isso em mente, o como pode, de fato, ser reduzido a apenas aumentar o tamanho da equipe para cobrir a quantidade adicional de trabalho necessária para a execução da estratégia mencionada acima.