Você, desenvolvedor de software, já teve a sensação de que gasta uma parte importante da sua memória (não, não do seu PC ou celular! do seu cérebro mesmo) só pra "armazenar" os que são os nomes e siglas das linguagens, frameworks, libs, patterns, ferramentas e etc? Quem dirá dominar cada uma dessas "coisas", né!?
Depois de alguns anos de estrada passando por diferentes ambientes, em todos os sentidos da palavra, não importa mais se vai ser Java, Ruby ou Python...se BDD, DDD ou TDD... se SQL, noSQL ou newSQL...Depois de passar por vários paradigmas, tudo fica mais fácil e é possível se adaptar rapidamente a qualquer cenário. Afinal, eles não são tão diferentes assim.
Isso vale para as práticas de gestão também! DevOps, Kanban, Scrum, Lean, BPM e etc são escolas complementares que bebem da mesmas fonte.
Quando se fala em DevOps, ouvimos mais a parte técnica, principalmente ferramentas. Desenvolvedores gostam de colocar a mão na massa e sair usando todas elas, se possível todas de uma só vez. As práticas acabam sendo adotadas como consequência do uso de ferramentas e não o inverso, que seria o natural.
Qual o problema disso? Nem sempre os sponsors topam práticas que à primeira vista parecem caras. Clientes resistem a qualquer atualização de versão, quem dirá "10 deploys por dia"!?
É para ajudar nisso que na palestra "Cultura DevOps: além das inúmeras ferramentas", Silvio Neto vai abordar um pouco da teoria que fundamenta as práticas e princípios que ficam embaixo deste grande guarda-chuva que ficou conhecido com "Agile"!
Essa será uma conversa introdutória abrindo as palestras seguintes que abordarão aspectos mais técnicos e práticos de ferramentas e abordagens alinhadas com a cultura DevOps.
5. Agile > DevOps
• “In DevOps, we typically define our technology
value stream as the process required to
convert a business hypothesis into a
technology enabled service that delivers value
to the customer” (The DevOps Handbook)
• “Our highest priority is to satisfy the customer
through early and continuous delivery of
valuable software” (Manifesto Ágil)
9. The First Way: Flow
• Fluidez de Dev para Ops para entregar valor aos
consumidores rapidamente
• Otimizar para este o objetivo global: da
requisição a mudança confiável em produção
(lead time)
• Reduzir tamanho dos lotes de trabalho
• Tornar o trabalho visível (kanban board)
• Limitar WIP
• Reduzir handoffs
• Reduzir gargalos (constraints)
10. Desperdícios e Dificuldades
• Trabalho parcialmente completado
• Processos extra
• Funcionalidades extra
• Troca de tarefas
• Espera
• Movimentação
• Defeitos
• Trabalho não padronizado ou manual
• Heroísmo
11. The Second Way: Feedback
• Criar um sistema de trabalho cada vez mais
seguro e resiliente
• Integração contínua
• Teste automático e contínuo
• Deploy/Entrega contínua
• Swarming (andon cord)
• Monitoramento
12.
13. The Third Way: Continual Learning and
Experimentation
• Criar cultura de confiança mútua, reforçando
que somos eternos aprendizes que precisam
assumir riscos em nosso trabalho diário
• Reservar tempo para melhorias diárias
• Pagar dívida técnica
• Estressar sistemas para forçar melhoria
contínua
• Blameless post-mortem
14. Technical Debt
“It comes from taking shortcuts, which may
make sense in the short-term. But like financial
debt, the compounding interest cost grow over
time. If an organization doesn’t pay down its
technical debt, every calorie in the organization
cab be spent just paying interest, in form of
unplanned work” (The Phoenix Project)