O enfoque da utilização de métricas são contribuir com a produtividade e a qualidade, então quando escolhemos métricas de processo, estamos medindo a produtividade e quando medimos um produto, estamos medindo a qualidade. E, como a combinação de métricas de processo e de produto ajudaram na elaboração de um processo para os Bugs que vinham de Produção? Esta palestra tem por objetivo mostrar toda a contextualização de como estávamos antes das métricas e nossas necessidades, as hipóteses que fomos testando, as métricas que melhor foram se encaixando aos nossos objetivos, como era redistribuído a coleta de métricas, como era feito, quais ferramentas, técnicas e práticas que foram utilizada e os resultados obtidos. O case já tem um ano de duração e ainda é a base de todo o processo de suporte da empresa.

1. O uso das
métricas para
apoiar a
priorização dos
bugs de
Produção
BugMetrics

2. Olá!
Joyce Bastos
- 7 anos na área de
Qualidade
- Paraense/Gaúcha
- Métricas
- Software Quality
Engineer at TownSq
2

3. Alinhando Expectativas
Como as métricas nos
ajudaram a criar um
processo de suporte aos
stakeholders
Não faz parte desse contexto práticas adotadas no
desenvolvimento
3

4. Como estávamos a 1 ano
atrás
1 Time de Desenvolvimento < 10 DEVs
2 contextos: América do Norte e Brasil
4 Plataformas (API, WEB, Android e IOS)
Time Novo
Sistema legado de outra empresa
Sistema integrado com sistema de ERP
de contabilidade
4

5. Desenvolvimento
➜ Demandas informais
(slack, pessoalmente)
➜ Meta era
comprometida
➜ Nos cobravam prazo
de correção
➜ Interrupções
constantes
Processo Indefinido
➜ Sentimento de que
não gostavam de nós
➜ "Malabarismo" para
agradar a todos
➜ Sprint comprometida
5

6. Processo Indefinido
Suporte (BR/US)
➜ Cliente cobrava prazo
➜ Clientes com mais influência
que outros
➜ Tudo era URGENTE
➜ Os stakeholders se sentiam
pouco representados
6

7. 7
Sempre apagando incêndios

8. 8
Problema:
Como atingir meta da Sprint
e
diminuir os bugs de produção?

9. As primeiras
Métricas
Severidade x Criticidade x SLA
Severidade: mede o desempenho do
software
➜ Crítica
➜ Alta
➜ Média
Prioridade: mede o impacto no Negócio
SLA: compromisso do tempo de resolução
de um bug pela equipe de DEV
9
QA: triagem e manutenção

10. As definiçoes
Severidade
➜ Crítica: bugs bloqueantes. Impedem execução da tarefa
➜ Alta: importantes mas, não bloqueantes. A tarefa é contornada
➜ Média: não bloqueantes e pouco impacto. São visualmente não agradáveis.
Prioridade (Foi baseada nas features mais usadas)
➜ Alta: se acontecia nas 5 features mais usadas (pagamentos e segurança)
➜ Média: se acontecia entre as 6º até a 10º features mais usada.
➜ Baixa: as demais features
SLA:
➜ TIER 1: tempo de análise e correção 1 dia
➜ TIER 2: tempo de análise e correção 5 dias
10

11. Exemplo
11

12. A formalização
- Criação inicial de um workflow para Bugs
- Padronização de um formulário de cadastro de Bugs
- Uso constante de ferramenta de gerenciamento e
monitoramento
- Acordo entre o Time
os pedidos ainda vinham por slack, mas o time estava
consciente que precisava ser formalizado
- Treinamentos para outras áreas (CS, Suporte,..)
12

13. A evolução
- Verificar qual região cadastra mais bugs (US/BR):
#Defects/Country
- Verificar qual plataforma tinha mais bug (API/WEB/AND e
IOS): #Defects/Severity
- Verificar quais features tinham mais bugs:#Aging:
- Verificar bugs cadastrados por clientes (área de suporte ou
customer success): #LinkedToATicket
- Monitorar histórico de bugs por Sprint
13

14. Os dashboards
14

15. Estratégias
Diminuir o nº de Bugs
Acordo: Os Dashboards mais importantes eram:
- #TIER 1
- #TIER 2
- #LinkedToATicket
- Production Issues
15

16. Estratégias
Atingir a Meta do Planejamento
- Métricas de Processo
- Definição de um prazo de correção
- Bugs priorizados na planning
- Resolver mais rápido os bugs críticos
- Frequência nas entregas (tempo de um bug corrigido X
correção em produção)
- Identificar a média/frequencia de bugs abertos por
Sprint
16

17. E, hoje?
- Cultura de Gerenciamento de bugs na
Empresa
- O sistema + COMPLEXO e - BUGS
(aproximadamente 35)
- Desenvolvimento com práticas de Qualidade
baseada nos bugs e em analytics
- Rotação da redistribuição das
responsabilidades para corrigir os bugs de
PRD 17

18. E, hoje?
18
- Poucas métricas: #FixVersion,
#ProductIssue e OKRs

19. Lições Aprendidas
- Gerenciar Expectativas
- Comunicação
- Poder das métricas certas
- Conceito da literatura mas, adaptada para a
Empresa
- Ferramenta de Gerenciamento
- Jira Avançado
- Automatizar o processo
19

20. Lições Aprendidas
- OKRs pensados e planejados em
cima das métricas
- Planejar menos tarefas na Sprint
- Não criamos um Time L3: O Bug é
do Time
20

21. Obrigada!
21
joyce.csb@gmail.com
/Joyce Bastos
/joycecsb