GQM
| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 20/09/2019 | 1.0 | Criação do documento | João Lucas |
Introdução
GQM é uma abordagem top-down - parte de conceitos mais abrangentes até os conceitos mais específicos - utilizada para facilitar o processo de medição de processos de desenvolvimento de software. Esta abordagem possui três níveis:
Conceitual: onde a equipe define as metas do software (Goals);
Operacional: onde a equipe levanta as questões (Questions) para abordar as metas; Quantitativo: onde a equipe levanta as métricas (Metrics) que respondem às questões previamente levantadas.
Metas
O primeiro passo é definir as metas do projeto e isto servirá de base para os demais passo. Para tal é utilizada a seguinte tabela:
| Analisar | o que deve ser analisado |
| Com o propósito de | o propósito da medição |
| Em relação a | o que será analisado |
| Do ponto de vista de | quem utilizará os dados coletados |
| No contexto | qual o contexto de análise |
Meta 1 - Produtividade da equipe
| Analisar | A equipe de desenvolvimento e gerência do grupo ArBC |
| Com o propósito de | Melhorar |
| Em relação a | Produtividade |
| Do ponto de vista da | Equipe de gerência |
| No contexto | do projeto ArBC |
Meta 2 - Qualidade do software
| Analisar | Código fonte |
| Com o propósito de | Melhorar |
| Em relação a | Qualidade do software |
| Do ponto de vista da | Equipe de gerência |
| No contexto | do projeto ArBC |
Questões
O segundo passo é definir das questões que servem para classificar e aperfeiçoar os objetivos.
Questões da meta 1
- O nível de conhecimento da equipe com relação às tecnologias aumenta com o passar das sprints?
- O nível de conhecimento da equipe é homogêneo?
- A equipe realiza as entregas de forma constante?
- Entre outras
Questões da meta 2
- O produto apresenta uma boa manutenibilidade do software?
- O projeto apresenta qualidade de código?
Métricas
O terceiro passo no processo é a definição das métricas que reponderam às perguntas referentes às metas estipuladas. Para tal é utilizada a seguinte tabela:
| Objetivo da medição | Qual o objetivo ao considerar a métrica |
| Descrição | Descrição da métrica |
| Coleta | Como a métrica é coletada (periodicidade e reponsável) |
| Procedimento | Como a métrica será coletada |
| Análise | Análise da métrica de acordo com categorias determinadas |
| Providência | Medidas que serão tomadas caso a métrica mostre resultados negativos |
Métricas para a meta 1
Quadro de conhecimento
| Objetivo da medição | Entender o nível de conhecimento da equipe para tomar medidas para melhorá-lo e homogeneizá-lo. |
| Descrição | Quadro com nível de conhecimento da equipe com relação às tecnologias adotadas. |
| Coleta | Responsável: Scrum Master Periodicidade: Ao fim de cada sprint |
| Procedimento | Ao fim de cada sprint o quadro será atualizado pela equipe, e será verificada a evolução da equipe com relação à sprint anterior |
| Análise | O nível de conhecimento da equipe em cada tecnologia será de acordo com as seguintes categorias: Vou Passar com SS Supremo: Tenho excelente conhecimento dessa tecnologia e me sinto confortável em usá-la e ajudar os demais membros. Passarei com SS com certeza. Vou Passar com SS: Tenho bom conhecimento da tecnologia e consigo utilizá-la sem grandes problemas, talvez pego um MS ou SS no final Vou Passar: Tenho um pouco de conhecimento e consigo me virar, espero que eu passe. Vou Retirar a Matéria: Tenho quase nenhum conhecimento e não consigo trabalhar com, talvez trancar seja melhor opção. Vou trancar o curso: Não possuo conhecimento sobre a tecnologia, minha melhor opção é trancar. |
| Providência | Serão realizados treinamentos e pareamentos afim de que o conhecimento seja disceminado entre a equipe |
Burndown
| Objetivo da medição | Verificar se as entregas estão sendo realizadas de forma contínua. |
| Descrição | O burndown se basea na pontuação das issues para criar um gráfico contendo a informação de quantos pontos foram concluídos até determinado momento. |
| Coleta | Responsável: Scrum Master Periodicidade: Ao fim de cada sprint |
| Procedimento | O quadro é criado a partir do plugin zenhub. E o resultado será coletado ao fim de cada sprint pelo scrum master |
| Análise | Existem três casos possíveis: as atividades estão mais fáceis do que deveriam, nesse caso a equipe entrega antes do prazo estipulado; as atividades estão mais difíceis do que deveriam, nesse caso a equipe não entrega ou entrega de somente ao fim da sprint; e por fim, o caso ótimo, onde a equipe entrega da forma esperada |
| Providência | As atividades da sprint serão planejadas de acordo com o feedback da sprint anterior afim de aumentar ou diminuir a dificuldade de acordo com o desempenho demonstrado. |
Velocity
| Objetivo da medição | Verificar se a equipe tem o desempenho esperado |
| Descrição | Determina a quantidade de pontos que a equipe consegue entregar por sprint. |
| Coleta | Responsável: Scrum Master Periodicidade: ao fim de cada sprint |
| Procedimento | O quadro é criado a partir do plugin zenhub. E o resultado será coletado ao fim de cada sprint pelo scrum master |
| Análise | O velocity deve ficar dentro de uma área de pontuação média, sem mudanças abruptas entra sprints, sempre tendendo a se estabelecer numa média ou aumentar no decorrer das sprints |
| Providência | As atividades da sprint serão planejadas de acordo com o feedback da sprint anterior afim de aumentar ou diminuir a quantidade de pontos de acordo com o desempenho demonstrado. |
Métricas para a meta 2
Cobertura de testes
| Objetivo da medição | Assegurar a confiabilidade e manutenibilidade do código |
| Descrição | Determina a porcentagem do código que foi efetivamente testada |
| Coleta | Responsável: Scrum Master e DevOps Periodicidade: Ao fim de cada sprint. |
| Procedimento | Através das ferramentas, onde o código será submetido. |
| Análise | A cobertura de testes do código deverá estar acima de 90% para a entrega na release 2. Por meio das informações obtidas será possível garantir certa confiabilidade do software |
| Providência | A partir da definição e obrigatoriedade da realização dos testes, os PRs serão aceitos somente se passarem nos testes. |
Formatação do código fonte
| Objetivo da medição | Possuir um padrão de desenvolvimento em relação à estética do código |
| Descrição | Leva em consideração a folha de estilo do projeto para determinar se o código está seguindo os padrões exigidos |
| Coleta | Responsável: Scrum Master Periodicidade: Ao fim de cada sprint |
| Procedimento | Através da análise dos reviews |
| Análise | O código deverá ser considerado de acordo ou não com a folha de estilo adotada |
| Providência | Refatoração do código para que a folha de estilo seja repazinada. |