Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Data driven quality - tdc2016

910 views

Published on

Qualidade orientada a Dados, palestra apresentada ao The Developers Conference de Florianṕoilis em 2016.

Você pode assistir à palestra, aqui neste link:
https://www.eventials.com/Globalcode/data-driven-quality-no-scrum-provando-que-qa-vale-a-pena/?playlist=tdconline-floripa-2016-stadium-intel

Published in: Technology

Data driven quality - tdc2016

  1. 1. Data-Driven Quality no Scrum
  2. 2. Bárbara Cabral QA Engineer @ResultadosDigitais Bruno Tanoue QA Engineer @ResultadosDigitais Quem somos?
  3. 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. 4. Introdução “Working Software is the primary measure of progress” - Agile Manifesto -
  5. 5. Modelo Spotify Introdução
  6. 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. 7. 2015 VersionOne. State of Agile Survey
  8. 8. Introdução - QA vs. QC Regra 10 de Myers
  9. 9. Frequência Gravidade Mapeamento de Defeitos (tags github)
  10. 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. 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. 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. 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. 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. 15. Release: Abertos VS. Fechados - Mensal Métricas Gerais
  16. 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. 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. 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. 19. Na Sprint: Alocação & Correção
  20. 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. 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. 22. @barbarapcabral http://barbaracabral.wordpress.com @brunotanoue bruno.tanoue@resultadosdigitais.com.br We’re hiring!

×