📈 Atividade 19: Métricas de Software, Estimativas e DORA

Aprenderemos sobre técnicas de estimativas ágeis e conheceremos as famosas Métricas DORA, a referência global e científica de mercado usada para medir a velocidade de entrega e a estabilidade de equipes de alto desempenho em DevOps.

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

• Diferenciar estimativas tradicionais de estimativas ágeis (Story Points).
• Calcular a velocidade de desenvolvimento (Velocity) de um time de desenvolvimento.
• Compreender e calcular as 4 Métricas Chaves da DORA (Deployment Frequency, Lead Time, MTTR, Change Failure Rate).
• Mapear e classificar o nível de maturidade operacional de uma equipe de software.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, a diretoria estava insatisfeita. Os projetos sempre atrasavam, as estimativas em "horas" eram imprecisas e, pior, ninguém sabia medir se as recentes automações (CI/CD, Docker e testes JUnit) realmente trouxeram melhorias reais para a velocidade ou se apenas aumentaram a complexidade técnica.

Os gerentes cobravam relatórios baseados em "linhas de código escritas por dia", o que incentivava os programadores a escreverem códigos inchados e ruins apenas para bater a meta.

"Seu desafio como Tech Lead / Agile Coach é reformular a forma de planejar e medir a eficácia do time da TecProExpress. Você calculará a capacidade da equipe em Story Points, estimará a entrega de um backlog crítico de rotas e implantará os indicadores DORA para provar cientificamente os benefícios das práticas DevOps no negócio."

🧠 Fundamentos: A Teoria Traduzida

1. Estimativas Ágeis vs Tradicionais

• Estimativa Tradicional (Horas/Dias): Tenta adivinhar o tempo exato de uma tarefa. Costuma falhar porque ignora a complexidade subjetiva, interrupções e riscos técnicos.
• Story Points (Estimativa de Esforço): Medida relativa baseada na Sequência de Fibonacci (1, 2, 3, 5, 8, 13...) que avalia o esforço, complexidade e incerteza de um item do backlog, comparando-o com tarefas já conhecidas.
• Velocidade (Velocity): A soma de Story Points de tarefas que o time consegue entregar (mudar para o status 'Done') no período de uma Sprint (normalmente 2 semanas).

2. As 4 Métricas DORA (DevOps Research and Assessment)

O grupo de pesquisa do Google (DORA) comprovou estatisticamente que a performance de engenharia de software é classificada por 4 métricas equilibradas entre Velocidade de Entrega e Estabilidade do Sistema:

📊 O Quadrante de Indicadores DORA

• Deployment Frequency (DF): Com que frequência sua equipe publica código em produção. (Meta Elite: Múltiplos deploys por dia).
• Lead Time for Changes (LT): Quanto tempo leva para um commit de código sair da máquina do desenvolvedor e rodar com sucesso em produção. (Meta Elite: Menos de 1 hora).
• Change Failure Rate (CFR): Qual a porcentagem de deploys em produção que causam falhas no sistema e exigem correção imediata (hotfix/rollback). (Meta Elite: 0% a 15%).
• Mean Time to Restore (MTTR): Quanto tempo a equipe leva, em média, para recuperar o sistema de uma pane em produção. (Meta Elite: Menos de 1 hora).

📖 Exemplo Guiado: Calculando Capacidade e Métricas DevOps

A equipe de desenvolvimento da TecProExpress possui um histórico de desempenho nas últimas 3 Sprints de 15 dias:

• Sprint 1: Entregou 24 Story Points.
• Sprint 2: Entregou 30 Story Points (equipe mais focada).
• Sprint 3: Entregou 21 Story Points (feriado e impedimento técnico).

1. Calculando a Velocidade Média do Time

$\text{Velocidade Média} = \frac{24 + 30 + 21}{3} = 25 \text{ Story Points por Sprint}$

Se o backlog total para o lançamento do novo módulo de motoristas tem um esforço estimado de 100 Story Points, o número de Sprints necessárias para entregar o projeto será: $\text{Previsão de Sprints} = \frac{100 \text{ SP (Escopo)}}{25 \text{ SP (Velocidade)}} = 4 \text{ Sprints (aproximadamente 2 meses de trabalho)}$

2. Painel de Indicadores DORA do Projeto (Simulado)

Com a adoção do pipeline CI/CD e Docker, o time registrou a seguinte performance no último mês:

• Deploys em produção: 20 deploys efetuados no mês.
  • Deployment Frequency: Aprox. 1 deploy por dia útil (Nível: Alto).
• Tempo de Commit a Produção: Em média 4 horas (desde o merge na main até rodar no servidor).
  • Lead Time for Changes: 4 horas (Nível: Alto).
• Falhas pós-deploy: De 20 deploys, apenas 1 causou queda na API e exigiu rollback.
  • Change Failure Rate: $1 / 20 = \mathbf{5\%}$ (Nível: Elite).
• Tempo de recuperação da falha: O rollback demorou exatamente 20 minutos para ser efetuado.
  • Mean Time to Restore (MTTR): 20 minutos (Nível: Elite).

🛠️ Prática Obrigatória 1: Estimando o Backlog Ágil

Cenário: Planejando as entregas do projeto final de Engenharia de Software.

1. Crie uma tabela Markdown listando 5 requisitos/funcionalidades chave restantes para a consolidação final do seu projeto de grupo.
2. Atribua a cada funcionalidade uma estimativa em Story Points usando a escala de Fibonacci (1, 2, 3, 5, 8, 13). Justifique por que uma funcionalidade recebeu pontuação maior (ex: complexidade de banco de dados, API de terceiros) em comparação a uma simples (ex: CRUD básico).
3. Defina uma velocidade média hipotética para o seu grupo (ex: 8 SP por Sprint de 1 semana) e calcule em quantas Sprints o grupo entregará o backlog total.

🛠️ Prática Obrigatória 2: Diagnóstico DORA do Time

Cenário: Avaliando a maturidade operacional e qualidade do processo de desenvolvimento.

1. Crie uma seção no seu documento Markdown chamada "Painel DORA do Projeto".
2. Defina e explique como seu grupo coletará ou simulará cada uma das 4 métricas DORA no fluxo de trabalho de desenvolvimento de vocês.
3. Classifique o nível de maturidade simulada da sua equipe (Baixo, Médio, Alto ou Elite) com base em cada indicador de velocidade e estabilidade.

📤 Instruções de Entrega (Microsoft Teams)

Após estruturar os seus planos de estimativas e o painel DORA:

1. Salve o arquivo de especificações com o nome Atividade_19.md na pasta es-atv-19-metricas-estimativas/ do seu repositório GitHub.
2. Certifique-se de fazer o commit e push para o repositório público.
3. Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

📊 Rubrica Formativa de Avaliação