DevOps! Que tal conversarmos mais sobre as responsabilidades de operação e desenvolvimento ? por: Filipe Cifali

1. Dev/Ops
Oops?!

2. #whoami
icmp reply: 200 bits from
shogoki
● Nome: Filipe Cifali
● Ocupação: Líder de time
na Avidity SE
● Horas pagas:
Consultoria Devops
● Horas vagas: Responder
pessoas nos chats de
Python do Telegram

3. Um pouco sobre minha experiência até agora
● Trabalhei em times focados
em um domínio
● Trabalhei em times
“flutuantes” onde pessoas
eram alocadas e deslocadas
conforme as necessidades
● Trabalhei em times de
produtos
Meu favorito: times de produtos
<insira grande stack de
tecnologias aqui para tentar
impressionar a platéia>
Cada projeto é único e por isso
merece atenção e cuidado ao
escolher tecnologias, não sigam
o hype, sigam os dados!

4. Na Ciência da Computação o DevOps
(contração de development e
operations), é uma cultura na
engenharia de software que aproxima
os desenvolvedores de software (Dev) e
os operadores do software /
administradores do sistema (Ops)
(https://pt.wikipedia.org/wiki/DevOps)

5. DevOps… de verdade (fonte: DataEu)

6. Dev
Parte 1
● Desenvolvimento né?
● Desenvolvimento de
software
● Garantia de Qualidade
● Automação de testes
● Um universo próprio

7. Ops
Parte 2 - o retorno
● Operação talvez?
● Infraestrutura
● Suporte
● Administração de
Sistemas
● Administração de Redes
● Engenharia de
Confiabilidade de
sítios
● Outros múltiplos
universos

8. Pessoas
Parte 3 - As pessoas
contra-atacam
Achei que eram só dois filmes
● Cultura
● Forma de trabalho
● Forma de lidar com o
trabalho
● Forma de produzir

9. Independência e Responsabilidade

10. DevOps na prática
● Pense em times, não em pessoas
● Títulos de linkedin não resolvem problemas reais
● Responsabilidade de ponta a ponta
● Independência entre times
● Ciclo ágil de vida de software

11. Desenvolvimento Ágil
● AGILE não é só “desenvolvimento” de software em termos de
código
● DevOps tem o propósito de melhorar o ciclo de
desenvolvimento desde o protótipo a produção
● Criam-se times compostos por pessoas com múltiplas
capacidades e conhecimentos

12. Hora das ilustrações

14. Caso 1
Desenvolvimento de
produtos em times com
domínio próprio
● Falta de inovação entre
tecnologias de produtos
● Baixa visibilidade
entre a saúde do
sistema e da aplicação
● Concentração de
controle entre
lançamento e ambiente
● Necessidade de alta
comunicação entre times
diferentes

17. Caso 2
Desenvolvimento de
produtos na forma “DevOps”
● Maior velocidade de
lançamento de novas
versões
● Menor esforço e custo
de comunicação em
diferentes
responsabilidades
● Ciclo de opinião do
cliente final mais
rápido

19. Isso parece mais trabalho…

20. Bem, não tem uma forma fácil de dizer isso
● A realidade é que é mais trabalhoso, porém trabalhar
dentro da cultura DevOps é mais saudável
● Elimina-se o maior desgaste de comunicação que existe,
lideranças de times lidando com múltiplas datas-limite
● Empoderam-se as pessoas responsáveis por criar o software
e permitem que elas mostrem seus resultados de maneira
muito mais visível

21. Dev criando software vivo?
● Trabalho Ágil envolve ciclos curtos repetidos de
planejamento/desenvolvimento/lançamento/análise de
resultado
● Você lida mais com pessoas e menos com código
● Tem maiores chances de alinhar expectativas e resultados

22. E tá tudo bem, mas o que isso tem a ver com OpsDev? Oops?!
● Responsabilidade compartilhada permite que o time esteja
envolvido nas soluções finais sem gargalos entre pessoas
dentro do time
● Enriquece o conhecimento sobre o que é o produto final e
transforma a forma de lidar com o mesmo

23. Custo em Tempo
Cada teste rodado, um
cafézinho?
● Se sua bateria de
testes demora 30
minutos e você tem 3
devs, quanto tempo você
gasta por semana
esperando testes para
lançar atualizações?

24. Custo em Tempo
2, A Hora do Rush
Mais uma sequência de
filmes?
● A falta de
independência entre
times com domínios
fixos gera atrito e
desacelera a resolução
de problemas
● A comunicação entre
times se torna um
gargalo grande e a
falta de posse sobre o
produto

25. Custo em tempo 3
Usem tempo para Pesquisa e
Desenvolvimento
● Trabalhando na cultura
DevOps e ágil não
significa “entregar o
tempo todo”
● Aloque no orçamento e
use tempo para
pesquisar soluções de
maneira sólida, não
siga tendências sem
apoio de dados

26. Como eu vim parar aqui meu deus eu só tenho 6
anos

27. Pausa para o café
Às vezes uma bebida quente
e 15 minutos conversando
com colegas ajudam mais do
que 1 hora de “foco”
● Refletir sobre como
você trabalha hoje é
essencial para mudar
● Converse com colegas
sobre como as coisas
são e como podem ser
● Não pense que culturas
são estáticas, assim
como pessoas, culturas
mudam

28. Produtos
Não são feitos sozinhos
● Tomar responsabilidade
sobre algo pode parecer
assustador, e é, mas
você não estará sozinho
● Conversar com pessoas
com diferentes
experiências vai te
ensinar muito mais do
que você imagina

29. Improvise, Adapte
e Supere
Melhorias contínuas
● Elas não são só sobre
software
● Cerimônias, reflitam
sobre elas, usem o que
serve e descartem o que
não serve
● Não sigam regras sem
entender as regras

30. Trabalhe como
um time
Times são pessoas com
objetivos conjuntos
● Colaboração é essencial
para ambientes
saudáveis
● Colaborar não significa
“fazer tudo que os
outros mandam”
● Colaborar significa
ouvir e falar,
significa trocar

31. O que eu projeto como um time ideal
● Capaz de receber demandas para novos produtos e trabalhar
desde a concepção até o lançamento e manutenção do mesmo
ao longo da vida útil do produto
● Independente a ponto de não precisar “esperar” por outros
times / recursos internos
● Sábio e inteligente para tomar as decisões necessárias
para o produto funcionar

32. Casos de estudo

33. O que vocês pensam sobre isso?

34. Dê tempo ao tempo, permitam-se
refletir sobre o que vocês consomem,
não sejam empurrados pelo ágil, usem
ele, adaptem ele, mas lembrem-se,
software é feito por pessoas, para
pessoas. Pessoas > Tecnologia.
Espero que tenham gostado J