O documento aborda a implementação de práticas de qualidade orientadas por dados no contexto do Scrum, destacando a utilização de OKRs e KPIs para definição e acompanhamento de metas. Inclui também o mapeamento de defeitos usando tags do GitHub e métricas gerais relacionadas a bugs e incidentes. Por fim, apresenta um plano de ação com próximos passos e post-mortem para aprendizado contínuo da equipe.

1. Data-Driven Quality no Scrum

2. Bárbara Cabral
QA Engineer
@ResultadosDigitais
Bruno Tanoue
QA Engineer
@ResultadosDigitais
Quem somos?

3. Agenda
•Introdução
•Mapeamento de Defeitos (tags github)
•KPI de Qualidade
•Definindo OKR
•Métricas Gerais
– Na Release
– Na Sprint
•Post Mortem
•Próximos Passos

4. Introdução
“Working Software is the primary
measure of progress”
- Agile Manifesto -

5. Modelo Spotify
Introdução

6. Introdução - OKR & KPI
OKR (sigla para Objectives and Key Results)
● É um framework para definição de metas criado pela Intel e adotado pelo Google em 1999.
● Objetivo é a descrição qualitativa do que se espera atingir e os Key Results são métricas que
indicam se atingimos nosso objetivo.
Quais são as características de OKR?
● Ciclos curtos de definição de metas: Ciclos trimestrais de desdobramento de metas;
● Simplicidade: OKRs devem ser simples e mensuráveis, de fácil compreensão;
● Transparência: Os OKRs devem ser públicos para toda a empresa.
KPIs (sigla para Key Performance Indicators)
● São medidas quantificáveis para compreender se os objetivos estão sendo atingidos.
Consequentemente, esses indicadores determinam se é preciso tomar atitudes diferentes que
melhorem os resultados atuais

7. 2015 VersionOne. State of Agile Survey

8. Introdução - QA vs. QC
Regra 10 de Myers

9. Frequência Gravidade
Mapeamento de Defeitos
(tags github)

10. Backlog de Defeitos (automatizado via github com Google Apps Script)
#
Mês de
Abertura
Título Funcionalidade Frequência Gravidade
Score
Frequência
Score
Gravidade
Peso
Suporte
Peso
Rollbar
Score
Urgência
16 10/2014 A Feature 1 Às vezes
Consegue
realizar tarefa
2 1 0 1 4
34 04/2015 B Feature 7 Às vezes
Consegue
realizar tarefa
2 1 1 0 3
39 08/2015 C Feature 1 Sempre
Existem
alternativas
3 2 0 0 5
46 11/2015 D Feature 1 Sempre
Não
consegue
contornar
3 3 1 1 7
Mapeamento de Defeitos
(tags github)

11. - Como calcular o score médio?
Score
Urgência
4
3
5
7
4+3+5+7 = 19 = 4,75
4 4
Mapeamento de Defeitos
(tags github)

12. KPI de Qualidade: por Time
Grade por Time
Tipo Unidade A B C D E F
Incidentes Total 0 - - - - 1+
Bugs criados (mês) Total 0 <= 1 <= 2 <= 3 <= 5 5+
Backlog (acumulado) Total <= 3 <= 5 <= 7 <= 10 <= 15 15+
Score médio (acumulado) Média <= 2 <= 3 <= 4 <= 5 <= 6 6+
Pontos Janeiro Feveiro Março
Incidentes A A
Bugs criados (mês) B E
Backlog (acumulado) F F
Score médio (acumulado) D D
C D

13. KPI de Qualidade: Geral
Grade de Pontuação Geral
Tipo Unidade A B C D E F
Incidentes Total 0 1 2 3 4 4+
Bugs criados (mês) Total <= 2 <= 5 <= 10 <= 20 <= 30 30+
Backlog (acumulado) Total <= 30 <= 42 <= 54 <= 66 <= 78 78+
Score médio (acumulado) Média <= 2 <= 3 <= 4 <= 5 <= 6 6+
Janeiro
Geral Time 1 Time 2 Time 3 Time 4 Time 5 Time 6 Time 7
B A A A A A B B
E B F E F F A B
F F F F F F C A
D D D D D D D D
E C E D D E B B

14. Definindo OKR (Trimestral)
OKR Q2 Reduzir a nota do KPI de F (6,0) => E (5,0)
Dono Bárbara
Frequência de
medição
Semanal
Como é calculado Baseado nas 4 métricas:
- Incidentes
- Bugs Criados
- Backlog de bugs acumulado
- Score médio dos bugs acumulados
Valor atual 6,45 (F)
Valor alvo 5,00 (E)

15. Release: Abertos VS. Fechados - Mensal
Métricas Gerais

16. Heatmap: Bugs Abertos acumulados por Feature
Métricas Gerais
Feature 06/2015 07/2015 08/2015 09/2015 10/2015 11/2015 12/2015 TOTAL
Feature 1 6 4 4 6 11 6 10 47
Feature 2 0 0 2 1 1 0 1 5
Feature 3 1 0 0 1 0 0 1 3
Feature 4 0 4 1 3 0 1 1 10
Feature 5 5 10 7 5 5 4 7 43
Feature 6 3 5 7 1 1 2 1 20
Feature 7 3 13 6 5 11 4 1 43
Feature 8 2 1 2 2 2 1 0 10
Feature 9 3 5 1 0 1 0 0 10
Feature 10 7 5 1 2 3 3 1 22

17. Nr. de Defeitos por Urgência: Gravidade + Frequência
Gravidade Urgência
Não consegue
contornar
26 47 28 Corrigir na Sprint 93 39.41%
Existem
alternativas
24 26 18 Corrigir na Release 73 30.93%
Consegue
realizar tarefa
26 20 21 Agendar Correção 70 29.66%
Raramente Às vezes Sempre Frequência
Métricas Gerais

18. Na Sprint:
Ritmo de Correção
Release 2
Corrigidos
sem alocaçãoTime Alocados
Não
corrigidos Corrigidos
Total
Corrigidos
Time 1 4 1 3 1 4
Time 2 3 1 2 3 5
Time 3 0 0 0 4 4
Time 4 3 1 2 3 5
Time 5 4 2 2 3 5
Time 6 5 3 2 2 4
19 8 11 16 27

19. Na Sprint:
Alocação & Correção

20. Post Mortem
● Funcionalidade
● Cronologia
● Qual o impacto?
○ Quantos tickets no suporte?
○ Quantas contas afetadas?
○ Gerou perda de dados? É possível recuperá-los?
● Análise da Causa-Raiz
● Aprendizado do time
● Ações de Prevenção

21. Próximos passos
● Sla de Defeitos
● Métrica: Tempo de Resolução
● Métricas por ciclo
○ Defeitos encontrados:
#1 em fase de Solução
#2 em Desenvolvimento
#3 em Rollout
#4 em Produção

22. @barbarapcabral
http://barbaracabral.wordpress.com
@brunotanoue
bruno.tanoue@resultadosdigitais.com.br
We’re hiring!