9 práticas para tornar a sua equipe DevOps

A equipe DevOps não é uma equipe de projeto temporário. Pelo contrário, ela é formada a longo prazo, pois uma vez que ela ganha maturidade, é possível se trabalhar em cima de um modelo mais evolutivo, um trabalho mais colaborativo e uma maior autoridade. Além disso, geralmente a vida útil da equipe não é determinada com antecedência e não é fixa. A equipe trabalha em sua área de responsabilidade, desde que a sua área permaneça relevante. Se a trajetória for alterada, a equipe “gira” junto com a área de responsabilidade. Se essa área for abandonada, a equipe muda para outra área.

A equipe DevOps é uma incrível unidade de combate. É responsável por uma pequena, mas claramente definida parte de um sistema de TI ou infraestrutura de TI. Tendo esse foco, os membros da equipe gradualmente e inevitavelmente tornam-se especialistas na área do assunto, mantendo-se totalmente responsáveis por isso. Isso acaba levando mais qualidade ao serviço final oferecido pela organização e maior fidelidade e identificação por parte dos membros.

Os membros da equipe trabalham na equipe por 100% do seu tempo de trabalho. Sem mais compartilhamento de recursos, combinando deveres aqui e ali, cobrindo para um funcionário doente de outro departamento e afins. O comprometimento total de cada membro da equipe simplifica a coordenação do trabalho, remove dependências de fatores externos e exclui a oportunidade de encontrar desculpas em outra carga de trabalho.

Equipes DevOps são multifuncionais. Isso significa que uma equipe deve ser capaz de realizar plenamente todo o trabalho no fluxo de valor de sua área de responsabilidade. Esta é a única maneira de viabilizar uma compreensão comum e precisa da definição de done, usuários utilizando a solução. Só assim pode garantir que todas as tarefas sejam concluídas, e o trabalho inacabado seja totalmente eliminado.

O tamanho da equipe é importante. Por um lado, não pode ser muito pequena pois ela pode não se tornar multifuncional como descrito acima. Por outro lado, equipes de vinte ou mais pessoas são difíceis de coordenar e exigirão a formação de níveis de gestão, ou tentem a desmoronar em subtemas. Além disso, grandes equipes incorrem em custos adicionais de comunicação e a inevitável perda de informações entre os membros. Tudo isso afeta a velocidade do trabalho.

Os membros da equipe DevOps devem ser os mais versáteis possíveis. A equipe DevOps requer que os limites sejam apagados (ou seja, programador, testador, etc). Idealmente, todos devem ser capazes de fazer o trabalho de todos. Isso não significa que todos se tornarão desenvolvedores ou administradores de banco de dados por exemplo. É evidente que a expertise dos colaboradores em determinadas áreas pode e deve ser profunda.

Não há nenhum líder formal, nenhum coordenador ou supervisor entre um pequeno número de membros da equipe DevOps. A equipe deve ser capaz de resolver independentemente todos os problemas de gestão emergentes e buscar apoio de especialistas ou mentores em casos difíceis. Em outras palavras, este deve ser um time autogerenciável, que é bastante alcançável para equipe de tamanho pequeno.

É importante que todos os membros da equipe estejam fisicamente co-alocados. É necessário um contato presencialmente constante, e-comunicações remotas não são suficientes. A localização de toda a equipe na mesma sala torna inevitável o contato diário com todos. Um e-mail na caixa de entrada pode ser ignorado por semanas. As chamadas telefônicas podem simplesmente não ser aceitas, referindo-se a alta carga de trabalho, reuniões e assim por diante. E as perguntas de um colega que está ali podem ser respondidas imediatamente. Este é o conceito do Obeja em Lean, que permite um maior contexto entre os membros e uma melhor qualidade e rapidez na toma de decisões, que tem foco coletivo.

A equipe DevOps é responsável pelas ferramentas que usa. Como construir um pipeline, que tecnologias ou versões de tecnologias usarem, tudo isto está na área de responsabilidade da equipe. A equipe deve ser capaz de avaliar as consequências de quaisquer mudanças que estão sendo feitas. Essas declarações não revogam a necessidade de seguir padrões corporativos, incluindo os das áreas de arquitetura, segurança da informação e auditoria. Veja que é bem diferente do modelo tradicional, onde a organização escolhe uma tecnologia global que é imposta de maneira autoritária muitas vezes por conta de acordos comerciais e no fim acabam não solucionando as dores da área.