Práticas para Acelerar o Desenvolvimento de Software - SyncTech @ MercadoLivre
Nessa palestra você irá conhecer as mais recentes discussões sobre produtividade e performance na indústria do desenvolvimento de software, junto com um conjunto de boas práticas a nível individual e de equipe inspiradas em essas discussões.
É um processo subjetivo ◦ É um inventário invisível ◦ Design e entrega podem acontecer ao mesmo tempo • Tentativas: ◦ Linhas de código? Story points? Ocupação do time? ◦ Cuidado para não incentivar comportamentos indesejados!
of Lean Software and DevOps: Building and Scaling High Performing Technology • É baseado no maior e mais longo estudo de DevOps já conduzido (https://dora.dev/). ◦ O objetivo era encontrar uma forma de medir a performance de entrega de software, e o que a impacta. ◦ Utiliza uma grande quantidade de dados e análise estatística rigorosa. ◦ Foco em predição e correlação dos dados. • Reúne um conjunto de práticas que comprovadamente aumentam quantidade, qualidade e estabilidade das entregas de desenvolvimento de software de uma empresa.
de software de uma organização? Métricas-chave: 1. Delivery Lead Time: Tempo entre o código estar commitado e código executando com sucesso em produção. 2. Deployment Frequency: Frequência dos deploys em produção 3. Mean Time To Restore (MTTR): o quão rápido se conserta falhas em produção 4. Change Fail Percentage: % de mudanças em produção que falham (ie. rollbacks, fixes, outages…) Motivos: • Métricas globais • Medem velocidade e estabilidade • Valorizam resultados concretos, não ‘busywork’ • O estudo mostrou que empresas que tem bons valores nessas métricas também se saem bem em: • Performance financeira ◦ ex.: turnover e lucro • Performance não-financeira ◦ ex.: qualidade e satisfação do cliente
impacta a performance de uma empresa, tanto para resultados comerciais como não-comerciais. • Não é necessário escolher entre estabilidade e velocidade: Na realidade, velocidade depende de estabilidade. • Quando bem implementadas, muitas das práticas dos movimentos Agile, Lean e DevOps tem um impacto positivo na performance de entrega de software.
partir de empresas buscando maneiras de construir software que é seguro, resiliente e escalável. Era uma parceria entre as equipes de Dev e Ops de uma empresa. Valoriza: • Integração continua • Entrega continua • Métodos ágeis • Cultura colaborativa Não é apenas práticas e ferramentas, mas também uma cultura!
cultura da empresa. • Se os dados são utilizados como uma forma de controle, as pessoas passam a escondê-los. • Para melhorar a performance, é necessário melhorar a cultura. Modelo de Westrum para culturas organizacionais: • Patológico: baseado em poder • Burocrático: baseado em regras • Generativa: baseado em performance “Whenever there is fear, you get the wrong numbers”
um forte fluxo de informações, mas requer: ◦ Confiança ◦ Transparência ◦ Responsabilidade compartilhada ◦ Segurança para errar e aprender ◦ Encorajar novas ideias ◦ Alta colaboração entre as equipes • Como mudar a cultura? ◦ A maneira como as pessoas trabalham influencia a cultura. ◦ Ou seja, melhores práticas de trabalho podem melhorar a cultura. “the way to change culture is … to start by changing how people behave—what they do” “Accident investigations that stop at ‘human error’ are not just bad but dangerous. Human error should, instead, be the start of the investigation.”
facilitar a criação e melhoria de uma cultura de alta performance. ◦ Prover as ferramentas, coaching, objetivos e métricas para permitir que os times tenham autonomia. ◦ Apoiar um ambiente que permita mudanças incrementais de forma colaborativa • Encoraja a todos (inclusive a si mesmo) a desafiar suposições e tentar novos comportamentos, sempre aprendendo no processo. ◦ Os comportamentos que funcionam e recebem reforço se tornam hábitos, e hábitos mudam a cultura. • Times podem avançar de forma independente quando tem o conhecimento de porque eles estão fazendo o que estão fazendo, e como o sucesso vai ser medido. “Going fast is of no value if you don’t go in the right direction.”
Tanto para aplicação como para a infraestrutura 2. Deploy automático 3. Integração Contínua (CI) 4. Trunk-based development ◦ Ao invés de feature branches de longa duração 5. Testes automáticos ◦ Testes confiáveis e frequentes 6. Gestão de dados de teste 7. Shift left on security 8. Continuous Delivery (CD) Princípios: 1. Construir já com qualidade 2. Trabalhar em batches pequenos 3. Automatizar trabalho repetitivo 4. Melhoria constante 5. Responsabilidade compartilhada Objetivo: Criar um ambiente que permita entrega contínua de software que é valioso para os clientes, em iterações pequenas e rápidas, de forma segura e sustentável.
◦ Remover dependência tanto a nível de sistemas como de times ◦ Não foque em ferramentas e tecnologias, mas em deployability e testability ◦ Modularidade 10. Times empoderados ◦ Time autônomos com autoridade para tomar decisões ◦ Balanço entre padronização e times escolherem as ferramentas “High performance is possible with all kinds of systems, provided that systems — and the teams that build and maintain them — are loosely coupled” Deployability • Capacidade de deployar uma aplicação de forma independente, em múltiplos ambientes. • De preferência, a nível de componente, e sendo capaz de detectar e tolerar falhas. Testability • Capacidade de testar uma aplicação de forma independente, sem requerer um ambiente integrado. “Following standard processes saves time and energy — but will prevent generative culture if the business doesn’t regularly re-evaluate it and improve it by empowering interested and skilled individuals to come together and be empowered to make the change from all levels.”
◦ Buscar feedback dos clientes de forma ativa e incorporá-lo no design dos produtos. 12. Value stream ◦ Entender e ter visibilidade do fluxo ponta-a-ponta entre o negócio e o cliente. 13. Trabalhar em batches pequenos ◦ Tanto a nível de código, como de entregas, e de produto (ex.: MVPs) 14. Team experimentation ◦ Times terem liberdade para experimentar novas ideias ◦ Ter autoridade para fazer mudanças sem aprovação externa Objetivo: Iterar sobre o ciclo de vida do produto de forma rápida e com visibilidade. O objetivo da experimentação é poder fazer decisões informadas em dados, através de feedback dos clientes e performance do software, e assim permitir um processo rápido de testes e validação.
aprovação leves ◦ ex.: revisões por pares ou da própria equipe 16. Monitoramento do sistema 17. Notificações pró-ativas 18. Limites de WIP ◦ Não deve ser um limite fixo, mas um processo de melhoria 19. Visualizar o trabalho ◦ Tarefas, métricas… ◦ Deve ser de fácil acesso
aprendizado ◦ Ideias: ser seguro falhar, ter um budget, espaços para compartilhar conhecimento 22. Forte colaboração entre times ◦ Uma relação de confiança: manter palavra, previsibilidade, comunicação aberta ◦ Encorajar e incentivar trabalhos que facilitem a cooperação 23. Satisfação com o trabalho ◦ Trabalho desafiador e com significado ◦ Ter autonomia para exercer suas habilidades e conhecimento ◦ Ter as ferramentas e recursos necessários 24. Liderança transformadora • Caracteristicas: ◦ Visão ◦ Comunicação inspiradora ◦ Estimula intelectualmente ◦ Se importa ◦ Reconhecimento pessoal ◦ Dá o exemplo
de alta performance: ◦ Desenvolver e manter um mindset de aprendizado compartilhado ◦ Não copie modelos. ▪ Adapte o que os outros fazem para o seu contexto. ◦ Você precisa mudar junto com o negócio ◦ Praticar disciplina ◦ Praticar paciência ◦ Aprenda na prática ▪ fazendo, repetindo, e incrementalmente evoluindo baseado no que você aprende “High-performance culture… is the development, through experimentation and learning guided by evidence, of a new way of working together that is situationally and culturally appropriate to each organization.”
de deployment’ ◦ Líderes focados em remover impedimentos, não em comando-e-controle ◦ Investimento em DevOps ◦ Práticas de Gestão Lean e Entrega Contínua “The technical practices that improve our ability to deliver software with both speed and stability also reduce the stress and anxiety associated with pushing code to production”
e código. • É importante decompor uma entrega em features, e decompor a feature em PRs pequenos. Vantagens: • Reduz o cycle time e a variabilidade • Permite obter resultados em produção e iterar sobre isso • Reduz risco e overhead • Reuso de código • Evita retrabalho com conflito de código • Permite revisões de código mais rápidas
jpbonson
kidooonn
msato
eventhub
tsumita
negi111111
ysknsid25
stajima
syntasso
fumiyasac0921
tacck
salaboy
nikkei_engineer_recruiting
orderedlist
mza
marcduiker
marcelosomers
jacobian
lauravandoore
hatefulcrawdad
eileencodes
colly
ddemaree
cromwellryan
tammyeverts
