Lições Aprendidas das 4 Key Metrics (DORA Metrics)

Slide 1

Slide 1 text

Insights sobre 4 Key Metrics

Slide 2

Slide 2 text

Fernando Ike // linkedin.com/in/fernandoike // twitter.com/fernandoike // pontocafe.fernandoike.com

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

4 Keys Metrics https://unsplash.com/photos/C1P4wHhQbjM

Slide 5

Slide 5 text

Deploy Frequency For the primary application or service you work on, how often does your organization deploy code to production or release it to end users? https://pixabay.com/photos/moto-motorcycling-sport-motorcycles-3406328/

Slide 6

Slide 6 text

Lead time for changes For the primary application or service you work on, what is your lead time for changes (in production) https://pixabay.com/photos/motocycle-racing-race-track-moto-2101565/

Slide 7

Slide 7 text

Time to restore service For the primary application or service you work on, how long does it generally take to restore service when a service incident or a defect that impacts users occurs (unplanned outage) https://pixabay.com/photos/running-marathon-people-sports-6660186/

Slide 8

Slide 8 text

Change failure rate For the primary application or service you work on, what percentage of changes to production or released to users result in degraded service and subsequently require remediation? https://pixabay.com/photos/marathon-competition-sports-running-7111384/

Slide 9

Slide 9 text

DevOps - 4 Key Metrics Throughput ● Deployment frequency ● Lead time for changes https://pixabay.com/photos/cheetah-animal-wildlife-leopard-2560006/

Slide 10

Slide 10 text

DevOps - 4 Key Metrics Stability ● Time to restore service ● Change failure rate https://pixabay.com/photos/turtle-reptile-walk-walking-shell-1850190/

Slide 11

Slide 11 text

Quando a organização não é de Elite Performance?

Slide 12

Slide 12 text

DORA Metrics - Exemplo 1 Normal Incidente 1 Deploy Frequency 3 dias 3/dia Lead Time for Changes 2 dias 90 minutos Time to Restore Service 12 horas 1,5 dia Change Failure Rate 60% 83%

Slide 13

Slide 13 text

DORA Metrics - Exemplo 2 Backend Release Train Deploy Frequency 1,2/dia 1/semana Lead Time for Changes 78 minutos 8 horas Time to Restore Service 122 minutos 52 minutos Change Failure Rate 19% 12%

Slide 14

Slide 14 text

https://pixabay.com/pt/photos/puzzle-quebra-cabe%c3%a7a-textura-2204615/ O que as 4 Keys Metrics não são…

Slide 15

Slide 15 text

O que não são as 4 Keys Metrics Não são um objetivo em si Não são as únicas métricas a serem utilizadas Só implementar Kubernetes Só implementar Jenkins como CI/CD

Slide 16

Slide 16 text

O desaﬁo para coletar as 4 Key Metrics https://pixabay.com/pt/photos/corredor-obst%c3%a1culo-corre-esporte-555074/

Slide 17

Slide 17 text

Os desaﬁos para obter as 4 key metrics Visibilidade do Value Stream das equipes e/ou da organização Padrão mínimo Ciclo de Desenvolvimento de Software (Systems Development Life Cycle) Padrão mínimo de Infraestrutura (Ops)

Slide 18

Slide 18 text

Os desaﬁos para obter as 4 keys metrics Padrão mínimo de arquitetura de software ou componentes* Não há incentivo pela liderança de tecnologia em olhar indicadores e métricas de engenharia de software Baixa autonomia para coletar as dados para 4 Keys Metrics

Slide 19

Slide 19 text

Casos

Slide 20

Slide 20 text

AI Company - Contexto 100% dos deploys falhavam 90 horas MTTR Deploy a cada 15 dias 102 dias para o primeiro release para um cliente Alto acoplamento entre os serviços Sobrecarga de trabalho em parte da equipe

Slide 21

Slide 21 text

AI Company Critérios de aceitação para cada tarefa Testes automatizado para nova funcionalidade Implementação de CI/CD automatizado Roadmap de desenvolvimento dos componentes da plataforma “Framework” Migrations Implementação de observabilidade (Distributed Tracing)

Slide 22

Slide 22 text

AI Company Arquitetura de software baseada em Domain-Driven Design Trunk-Based Development Gerenciamento visual (Kanban) Redistribuição da carga de trabalho para toda equipe Postmortem Premissas ○ Tornar o onboading mais rápido de novos clientes ○ Diminuir o Lead Time de novas funcionalidades ○ Visibilidade de custos por cliente

Slide 23

Slide 23 text

AI Company - Resultado Crescimento de 500% 30 dias para um protótipo funcional 60 dias para o primeiro release para um cliente MTTR == 90 minutos Lead Time for Changes => Ondemand Deploy Frequency => + 1 por dia 25 milhões de reais na rodada de investimento De 11 para 41 itens do backlog em 30 dias com 80% de certeza

Slide 24

Slide 24 text

EdTech - Contexto Desenvolver uma plataforma de acompanhamento educacional Contratar uma equipe Deﬁnir a stack tecnológica Indicadores de performance Criar uma cultura de engenharia e produto do zero

Slide 25

Slide 25 text

EdTech Contratar uma equipe para desenvolver a plataforma Gerenciamento visual Arquitetura e stack “viável” baseado no conhecimento da equipe ○ Containers, Django, PostgreSQL, Nextjs, IaC ○ CI/CD ○ Testes unitários, testes de sistema Dojos para aumentar a cobertura de testes Trunk-Based Development

Slide 26

Slide 26 text

EdTech Framework e Migrations Limitação do WIP Small Batches Identiﬁcação do “trabalho estocado” Delimitação das restrições Autonomia (atos de liderança) Cadência de release a cada 15 dias

Slide 27

Slide 27 text

EdTech - Resultado Desenvolvimento plataforma de cadastro para + 1 milhão de usuários em 15 dias Identiﬁcado o trabalho em estoque (bloqueado) com um total de +500 dias Implementação da plataforma base de gestão e acompanhamento de performance dos estudantes

Slide 28

Slide 28 text

EdTech - Resultado Deploy Frequency == +1 por dia MTTR == 2 Horas Lead Time for Changes == 2 dias

Slide 29

Slide 29 text

Muito tempo em trabalho operacional Falta de padronização de stack, processos, CI/CD, etc. Silos de equipes e serviços (Conway's law) Ciclos perpétuo de formas de trabalho, tecnologia e buzzwords Instituição "Regulada" - contexto

Slide 30

Slide 30 text

Instituição "Regulada" Reestruturação das equipes (Inverse Conway Manoeuvre) Identiﬁcação dos principais gargalos Formação de equipes de plataforma Documentação Fornecer serviços Self-service Obter métricas de Engenharia Obter métricas de uso da Plataforma

Slide 31

Slide 31 text

Instituição "Regulada" - Resultados Templates de Frameworks, libs e projetos Internal Developer Platform (CLI, Portais…) Implementação de guard-rails padronizados Desenvolvimento de uma Plataforma de CI/CD Padronização da observabilidade Automação (shift-left) dos processos de conformidade

Slide 32

Slide 32 text

Uma equipe usando a DORA Metrics e DevOps Capabilities

Slide 33

Slide 33 text

DORA Metrics da equipe Antes Agora Deploy Frequency 0,5/dia 1,60/dia Lead Time for Changes 10 horas 5 horas Change Failure Rate 26% 17%

Slide 34

Slide 34 text

Antes

Slide 35

Slide 35 text

Depois

Slide 36

Slide 36 text

Cumulative Flow Diagram

Slide 37

Slide 37 text

O que mudaram Diminuição de cerimônias síncronas Adoção de Design Docs Mudança de Scrum para Método Kanban Mudanças pequenas de código por deploy

Slide 38

Slide 38 text

Técnicas, recursos e capacidades https://pixabay.com/pt/photos/m%c3%a3os-megaminx-cubo-de-rubik-cubo-5762539/

Slide 39

Slide 39 text

Técnicas, recursos e capacidades Loosely coupled architecture Trunk-based development Continuous testing Continuous integration Use of open source technologies Monitoring and observability practices

Slide 40

Slide 40 text

Management of database changes Deployment automation Small Batches Visual management capabilities Liderança Técnicas, recursos e capacidades

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

DevOps Capabilities

Slide 43

Slide 43 text

https://pixabay.com/pt/photos/biblioteca-la-trobe-estude-alunos-1400313/ Outros insights

Slide 44

Slide 44 text

Onde a organização está? Consegue coletar as 4 keys metrics facilmente? Consegue utilizá-las com outros indicadores? ○ Cycle Time ○ Blocked Time ○ Work Item Age ○ Percentual de trabalho não planejado ○ Bugs/Defeitos que geram incidentes em produção Qual a dívida técnica principal da organização? Tem mapeado os processos atuais?

Slide 45

Slide 45 text

Para onde vai? Direcionamento claro do "Futuro" Liderança está patrocinando o direcionamento para o futuro? Conceitos e fundamentos como fundação das ferramentas, serviços e plataformas adotadas ou em desenvolvimento

Slide 46

Slide 46 text

Está na direção certa? (A cada ciclo há) revisão dos processos, automações, e funcionalidade As hipóteses e decisões são baseadas em dados? A organização entende (evolução) que hoje está melhor que ontem?

Slide 47

Slide 47 text

Equipe autônomas

Slide 48

Slide 48 text

Conway Law é “…organizações que projetam sistemas (no sentido amplo usados aqui) restringem o desenvolvimento dos projetos como cópias da estrutura de comunicação dessas organizações”

Slide 49

Slide 49 text

Equipes autônomas => Aprendizado Contínuo Feedback Loops ○ Scrum, Kanban… ○ 3 Way, CAMS… ○ Postmortem Reviews ○ PDSA/PDCA

Slide 50

Slide 50 text

Equipes autônomas => Aprendizado Contínuo % de tempo para aprendizado ○ Dojos ○ Hackathons ○ GameDay ○ Aprendizado Individual ○ Colaboração com projetos externos (OpenSource) e/ou internos

Slide 51

Slide 51 text

Equipes autônomas - Restrições https://pixabay.com/photos/caravan-desert-safari-dune-camels-339564/ Quais as restrições aqui?

Slide 52

Slide 52 text

Equipes autônomas - Quais as restrições?

Slide 53

Slide 53 text

Equipes autônomas - Restrições https://pixabay.com/photos/freight-trains-industrial-metal-846093/ Quais as restrições aqui?

Slide 54

Slide 54 text

Equipes autônomas => Aprendizado Contínuo Restrições da organização ○ Pessoas ○ Estrutura Organizacional ○ Orçamento (Dinheiro) ○ Leis, Procedimentos, Normas, etc.

Slide 55

Slide 55 text

Referências DORA Research Program DevOps State Report 2021 Accelerate: The Science of Lean Software and DevOps Continuous Delivery Kanban DevOps Capabilities Conway Law The Goal PixBay

Slide 56

Slide 56 text

Fernando Ike // linkedin.com/in/fernandoike // twitter.com/fernandoike // pontocafe.fernandoike.com