| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 20/04/2019 | 1.0 | Criação do documento | Lucas Vitor |
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.
Abaixo se encontra uma figura representativa do processo do GQM:
Metas
O primeiro passo no processo do GQM é definir as metas do projeto e isto servirá como base para os passos seguintes. 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 Aix |
| Com o propósito de | Melhorar |
| Em relação a | Produtividade |
| Do ponto de vista da | Equipe de gerência |
| No contexto | do projeto Aix |
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 Aix |
Questões
O segundo passo é definição das questões que servem para clarificar ainda mais 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 realmente cumpre com o tempo semanal de trabalho estipulado no projeto?
- A equipe realiza entregas de forma constante?
- Os riscos estão sendo mitigados?
Questões da meta 2
- O produto apresenta uma boa manutenibilidade do software?
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: Faustop!: Tenho excelente conhecimento da tecnologia e me sinto confortável em usá-la Maneiro!: Tenho bom conhecimento da tecnologia e consigo utilizá-la sem grandes problemas Meh...: Tenho um pouco de conhecimento e consigo me virar na utilização Então né...: Tenho quase nenhum conhecimento e não consigo utilizar de forma aceitável Me ajuda...: Não possuo conhecimento sobre a tecnologia |
| Providência | Serão realizados treinamentos e pareamentos afim de que o conhecimento seja disceminado entre a equipe |
Burndown de riscos
| Objetivo da medição | Entender os riscos enfrentados pela equipe de acordo com o desenvolver do projeto, mostrando o quão reativa é a equipe com relação aos riscos |
| Descrição | Gráfico com quantidade de riscos enfrentados, de acordo com o plano de gerenciamento de riscos |
| Coleta |
Responsável: scrum master Periodicidade: ao fim de cada sprint |
| Procedimento | Ao fim de cada sprint o quadro será atualizado pelo Scrum Master da equipe, e será verificada a evolução da equipe com relação à sprint anterior |
| Análise | Analisar os riscos mitigados e os novos riscos enfrentados pela equipe |
| Providência | Serão realizadas as ações preventivas e reativas de acordo com o contexto do enfrentamento do risco |
Quadro de horas
| Objetivo da medição | Melhorar a gestão de tempo da equipe |
| Descrição | Quadro com as horas gastas pela equipe durante a semana e em cada atividade |
| Coleta |
Responsável: scrum master Periodicidade: ao fim de cada sprint |
| Procedimento | O quadro é atualizado sempre que for realizada uma atividade pela equipe. E o resultado será revisado diariamente pelo scrum master |
| Análise | Analisar as horas gastas na sprint, e as horas gastas em cada atividade realizada |
| Providência | Caso algum integrante não cumpra com a quantidade de horas estipulada, serão tomadas iniciativas para incentivá-lo a cumprir as horas. |
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çao 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 Periodicidade: ao fim de cada sprint |
| Procedimento | Através da ferramenta Coverall, 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. |
Duplicação de código
| Objetivo da medição | Melhorar a reutilização de código, melhorando, assim, a sua manutenibilidade |
| Descrição | Repetição geralmente desnecessria de trechos de código no projeto |
| Coleta |
Responsável: scrum master Periodicidade: ao fim de cada sprint |
| Procedimento | Através da ferramenta code climate, onde o código será submetido |
| Análise | De acordo com a definição do code climate, com uma nota que vai de F até A, a definição de duplicidade desnecessária será medida |
| Providência | Refetoração do código para que o nível de duplicação seja o mínimo possível |
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 ferramenta flake8, onde o código será submetido |
| Análise | De acordo com a definição do flake8, o código será considerado de acordo ou não com a folha de estilo adotada |
| Providência | Refetoração do código para que a folha de estilo seja respaitada |
Número de linhas por método
| Objetivo da medição | Possuir métodos atômicos, afim de melhorar a manutenibilidade do código |
| Descrição | Conta a quantidade de linhas em cada método. É preferível ter métodos atômicos para facilitar o entendimento e melhorar a manutenibilidade |
| Coleta |
Responsável: scrum master Periodicidade: ao fim de cada sprint |
| Procedimento | Através da ferramenta code climate, onde o código será submetido |
| Análise | De acordo com a definição do code climate, com uma nota que vai de F até A, a definição excesso de linhas de código será medida |
| Providência | Refetoração do código para que a quantidade de linhas por método seja o mais próximo possível do ideal |