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.