A ideia de que existe uma única forma da cultura DevOps é uma mal interpretação do que significa DevOps. Em algumas organizações o DevOps surge apoiado na própria cultura já existente na empresa dando como resultado uma implementação única. Mas na diversidade de culturas, existem alguns padrões em que a maioria das empresas se organizam. Pelo menos três deles são bastante comuns. -Infraestrutura como serviço -Responsabilidade totalmente compartilhada -Equipe "temporária" DevOps. Por último, cada implementação (ou sabor) de DevOps precisa estar fundamentada em valores, liderança, time, química do time, repasse de conhecimento (mentor) e comunicação.

1. Como a forma e
organização dos times afeta
a implementação de
DevOps
Pablo D. Pagues Ernst
br.linkedin.com/in/pablopagues/
pablo.pagues@gmail.com
pablopagues.wordpress.com

2. DevOps
O termo em se já mostra a tensão e até oposição
que sempre existiu entre eles.
TI: "Funciona? fica bem longe desse treco!“
Devs: “Quero inovar, quero mudanças, quero coisa
nova!”

3. PESOAS >>> PROCESSOS >> FERRAMENTAS
• Por que implementar DevOps? DevOps vem para dinamizar um
relacionamento que é estático e frio.
• Organizações estão cheias de problemas de rivalidades entre times Devs vs
Ops.
As questões políticas e a liderança pobre levam a desatar um pequeno caos
que já dificulta as coisas em épocas de calmaria e se torna o apocalipse em
casos de eventos catastróficos.

4. Cenário
• Qual o cenário destes times nas empresas?
• Cada um tentando puxar a sardinha para o seu lado, cada uma tentando
demonstrar para a empresa a sua indispensabilidade.
• Muito comum é ver estas partes lutando por verbas.

5. Cenário
• A falta de comunicação fluida transforma qualquer necessidade da empresa
em difíceis processos burocráticos.
• Abriu Helpdesk?
• A falta de comunicação é suprida com regras.

6. Cenário
• Em lugar de times compartilhando informação temos pessoas com
conhecimento compartimentado e inacessível.
• Precisa fazer uma publicação? Só fulano faz. E cadê o fulano? Ele não vem
trabalhar hoje. Só amanhã...
• Integração continua? Esquece...

7. Fator Assassino da Colaboração e da
Comunicação
• Pessoas tendem ainda a pensar como no século passado e buscam se tornar
indispensáveis.
• Não podemos julgar isto, na escola nos ensinam a ser individualistas.

8. Cenário
• As empresas com maior visão estão tentando mudar este estado de coisas
visando melhorar a performance e o valor entregue ao cliente, mas
frequentemente se deparam com dificuldades e conflitos de interesses.
• Para estas empresas, a menos que tenham uma vontade que se sobreponha
ou uma liderança forte de cima para baixo, a saída é adotar uma topologia
de times para implementar DevOps que se adapte ao cenário cultural e
motivacional já existente.

9. Como Mudo este Cenário?
Liderança!
Conhecem a historia do crachá?

10. DevOps
-Não focado em tecnologia (que muda toda hora), focado
em cultura e times.
-Pessoas, ideias e tecnologia
-Comunicação, integração, menos desperdício
-Melhorar a frequência das entregas o que sempre é
estratégico para o cliente

11. Implementando DevOps
A ideia de que existe uma única forma da cultura DevOps é uma
mal interpretação do que significa DevOps.
Em algumas organizações o DevOps surge apoiado na própria
cultura já existente na empresa dando como resultado uma
implementação única.

12. Implementando DevOps
Por último, cada implementação (ou sabor) de DevOps precisa
estar fundamentada em valores, liderança, time, química do time,
fator mentor e comunicação.
O que funciona numa empresa pode não funcionar em outra
devido a diferenças na conformação dos times, no set de
habilidades, motivações, tecnologias disponíveis ou inclusive
personalidades.

13. Implementando DevOps
Mas na diversidade de culturas, existem alguns padrões em que a
maioria das empresas se organizam. Pelo menos três deles são
bastante comuns.
-Infraestrutura como serviço
-Responsabilidade compartilhada
-Equipe "temporária" DevOps.

14. Infraestrutura como serviço
Caso: Empresas com vários produtos e serviços com uma equipe operacional
tradicional ou estrutura de infra na nuvem ou em outro local físico.
É o caso em que o ambiente, as ferramentas e o tipo de projeto requere que os
desenvolvedores se "sirvam" da parte operacional como serviço porém mantendo
uma comunicação limitada.
Neste tipo de cenário é desejável certo tipo de interação, pelo menos compartilhar
um almoço e algum tipo de evento para facilitar o intercambio de pontos de vista.
No dia a dia a interação é bem reduzida mantendo apenas o compartilhamento de
informação entre os times.

15. Infraestrutura como serviço

16. Responsabilidade compartilhada
Caso: Empresas que tem apenas um produto ou serviço.
Neste caso todos trabalham na mesma sala sobre um mesmo produto e geralmente a
infra esta no mesmo local.Tanto desenvolvedores como a operação são donos e tem
controle sobre todo o processo e trabalham em plena colaboração.
Pessoas com diferentes habilidades trabalham juntos e se apoiam mutuamente para
resolver os diferentes aspectos das entregas e da operação. Este tipo de times atua
isolado de outros times que trabalham em outros produtos ou serviços.
O ambiente esta disposto de maneira que a quantidade de burocracia para a
colaboração e comunicação é mínima.

17. Responsabilidade compartilhada

18. Equipe "temporária" DevOps
Caso: Usado como precursor das topologias anteriores. Para empresas com dificuldade em
implementar a cultura DevOps.
Quando a empresa quer implementar DevOps mas se chega a conclusão de que a distância
entre os dois times é muito grande como para começar a colaborar de forma imediata a
solução pode ser criar um time temporário DevOps por um tempo especifico para encorajar a
cultura da colaboração.
O problema? Um time "temporário para sempre" pode se converter num obstáculo a
comunicação entre Dev e Ops.
Em empresas onde sysadmins relutam em adotar certas práticas e desenvolvedores se negam
a aplicar monitoramento e métricas para otimizar apps as diferenças de critério são muito
grandes. Neste caso é necessário criar um ponto de união, um catalizador.Aqui é onde um
time criado especialmente para implementar DevOps pode ajudar.

19. Equipe "temporária" DevOps

20. Para Finalizar Uma Boa Estratégia
Escolher uma topologia de time que se adapte a cultura e
necessidades da empresa é ser realista e efetivo.
Assim tanto a cultura de colaboração que vai surgindo quanto a
topologia do time devem ser vistos como algo que deve evoluir e
melhorar com o tempo na medida que novas habilidades são
conquistadas, novas tecnologias aplicadas e as necessidades do
negocio vão mudando.

21. Obrigado pela paciência!
Perguntas?