Este documento tem por finalidade definir os objetivos qualitativos que este projeto pretende alcançar em relação ao produto final gerado e a equipe. Para tal será utilizado como base o modelo GQM - Goals, Questions and Metrics.
Modelo
Objetivos Estratégicos
Objetivo 1: Boa usabilidade
| Analisar |
com o propósito de |
com respeito a |
sob o ponto de vista |
no contexto |
| usabilidade do software |
melhorar |
facilidade de uso |
usuário final |
Produto IndicaAi |
| Foco da Qualidade | Fatores de Variação |
|---|
- Número de Cliques pra executar uma funcionalidade
- Nível de satisfação do usuário
- Padronização para execução de tarefas
|
- O caminho que deve ser percorrido até chegar de fato na funcionalide pode afetar o usuário
- A satisfação do usuário pode melhorar a medida que ele aprende a usar o software
- O conhecimento do usuário de outras ferramentas
|
| Hipóteses de Baseline | Variações nas hipóteses |
|---|
- 3 cliques
- 3 de satisfação
- Espera-se que funcionalidades semelhates tenham o fluxo parecido
|
- A complexidade da funcionalidade pode impactar que ela seja quebrada em várias etapas
- O interesse do usuário pela aplicação
- Nos outros módulos do App podem ser aplicados padrões distintos
|
Objetivo 2: Código Manutenível
| Analisar |
com o propósito de |
com respeito a |
sob o ponto de vista |
no contexto |
| código da aplicação |
conhecer, entender e melhorar |
manutenção |
desenvolvedor |
Produto IndicaAi |
| Foco da Qualidade | Fatores de Variação |
|---|
- Código reaproveitado
- Aplicação de padrões de escrita de código
- Complexidade de caminhos no código
- Quantidade do software que foi testada
|
- Experiência do desenvolvedor com as ferramentas
- Qualidade dos testes
|
| Hipóteses de Baseline | Variações nas hipóteses |
|---|
- Máximo de código reaproveitado
- Padrão de escrita aplicado a todo o código
- Baixa complexidade no código
- Alta cobertura de testes
|
- Códigos muito semelhantes mas com propósitos diferentes podem ser considerados duplicados pelas ferramentas de análise.
- Podem ocorrer exceções quanto a folha de estilo de casos particulares em que o Scrum Master opte pela integridade do código ao invés da folha de estilo.
|
Objetivo 3: Capacitação da Equipe
| Analisar |
com o propósito de |
com respeito a |
sob o ponto de vista |
no contexto |
| capacitação da equipe |
conhecer, entender e melhorar |
aquisição de conhecimento |
estudante |
disciplinas de EPS e MDS |
| Foco da Qualidade | Fatores de Variação |
|---|
- Conhecimento da equipe
- Disseminação do conhecimento na equipe
|
- Desenvolvimento de habilidades por meio de projetos não relacionados com este
|
| Hipóteses de Baseline | Variações nas hipóteses |
|---|
- Melhora de conhecimentos a cada sprint
- Rodízio constante nas duplas de pareamento
|
- Ao ter mais contato com determinada tecnologia, o estudante pode perceber que não a conhece tão bem e diminuir a classificação do seu conhecimento em relação a ela.
- Por questões de prazo de entregas uma dupla pode ser não rotacionada na sprint seguite por já estar familiarizada com código.
- Histórias pequenas podem ser entregues antes do previsto
- Histórias podem ser mal dimensionadas e levar mais tempo que o previsto
|
Objetivo 4: Produtividade da Equipe
| Analisar |
com o propósito de |
com respeito a |
sob o ponto de vista |
no contexto |
| capacitação da equipe |
conhecer, entender e melhorar |
aquisição de conhecimento |
estudante |
disciplinas de EPS e MDS |
| Foco da Qualidade | Fatores de Variação |
|---|
- Burndown
- Velocity
- Capacidade produtiva de cada desenvolvedor
|
- Sprints em que determinado desenvolvedor fique responsável por assumir um papel da metodologia, ele pode acabar produzindo menos linhas de códigos.
|
| Hipóteses de Baseline | Variações nas hipóteses |
|---|
- A produtividade do desenvolvedor deve se manter constante ou aumenta a cada sprint.
- Espera-se que o velocity da equipe seja em torno de 20 a 30 pontos.
|
- Dificuldades por baixo conhecimento da tecnologia podem surgir nesse processo e influenciar na quantidade de linhas produzidas
- Histórias pequenas podem ser entregues antes do previsto
- Histórias podem ser mal dimensionadas e levar mais tempo que o previsto
|
Métricas de Medição
| Número de Cliques |
|---|
| Objetivo da Medição |
Obter o número mínimo de cliques necessários para executar uma funcionalidade no sistema. |
| Fórmula |
Apartir da página na qual obtem-se acesso a funcionalidade contar todos os cliques necessários para executar a funcionalidade por completo. |
| Escala de Medição |
Racional |
| Coleta |
- Responsável: Product Owner
- Periodicidade: a cada Pull Request associado a interface da aplicação.
- Procedimento: Acessar a página onde se tem acesso a funcionalidade e então executar a funcionalidade contando o número de cliques necessários para concluí-la. Caso hajam vários caminhos que a funcionalidade pode seguir, deve-se testar cada um desses caminhos e realizar uma média aritimética simples para obter o valor final.
|
| Análise |
- 1 a 2 cliques: Nível aceitável, mas verificar se não faltam informações/passos pertinentes ao usuário.
- 3 a 4 cliques: Nível aceitável
- 5 a 7 cliques: Nível preocupante
- 8 ou mais cliques: Nível alarmante. Reavaliar a lógica de intereção.
|
| Nível de Satisfação do Usuário |
|---|
| Objetivo da Medição |
Identificar o quão fácil ou confortável o usuário se sente para mecher no sistema. |
| Fórmula |
Em uma escla de 0 a 10 o usuário deve relatar o quão avontade ele se sente ao mecher no sistema. |
| Escala de Medição |
Intervalar |
| Coleta |
- Responsável: Product Owner
- Periodicidade: Ao final de cada sprint, na entrega de funcionalidades associadas a interface da aplicação.
- Procedimento: Selecionar dois prováveis usuários do sistema, pedir que usem o aplicativo, testando as novas funcionalidades implementadas e por fim, pedir para eles avaliarem em uma escala de 0 a 10 o quão intuitivo e prático foi mecher na aplicação.
|
| Análise |
- 0 a 2: Ruim. Deve-se repensar toda a lógica de interação.
- 3 a 5: Razoável. Deve-se promover melhoras na lógica de interação.
- 6 a 8: Satisfatório
- 8 a 10: Excelente
|
| Duplicidade de Código |
|---|
| Objetivo da Medição |
Verificar se existe código duplicado que poderia ser reaproveitado dentro da aplicação. |
| Fórmula |
Quantidade de sintaxes idênticas ou semelhantes presentes no código. |
| Escala de Medição |
Racional |
| Coleta |
- Responsável: Scrum Master
- Periodicidade: a cada fechamento de Sprint
- Ferramenta: Rubocop
- Procedimento: Após o último Pull Request aprovado da Sprint, rodar a ferramenta sobre a branch devel e pegar o resultado da métrica.
|
| Análise |
- Índicie de Duplicação > 25: Preocupante. Medidas devem ser tomadas para reaproveitar melhor o código da aplicação.
- Índicie de Duplicação <= 25: Satisfatório
|
| Folha de Estilo |
|---|
| Objetivo da Medição |
Verificar se o código está sendo escrito de acordo com os padrões adotados. |
| Fórmula |
Não se aplica. |
| Escala de Medição |
Racional |
| Coleta |
- Responsável: Scrum Master
- Periodicidade: ao final de cada sprint
- Ferramenta: Rubocop
- Procedimento: Após o último Pull Request aprovado da Sprint, rodar a ferramenta sobre a branch devel e pegar o resultado da métrica.
|
| Análise |
Caso a ferramenta acuse trechos de código em inconformidade com os padrões, deve-se abrir uma história técnica para consertar o trecho acusado.
|
| Manutenibilidade |
|---|
| Objetivo da Medição |
Monitorar e melhorar a manutenibilidade do código que está sendo gerado. |
| Fórmula |
Não se aplica. |
| Escala de Medição |
Racional |
| Coleta |
- Responsável: Scrum Master
- Periodicidade: ao final de cada sprint
- Ferramenta: CodeClimate
- Procedimento: Após o último Pull Request aprovado da Sprint, rodar a ferramenta sobre a branch devel e pegar o resultado da métrica.
|
| Análise |
Caso a manutenibilidade esteja abaixo de B, o código deverá ser considerado como prioridade para ser refatorado.
|
| Complexidade Ciclomática |
|---|
| Objetivo da Medição |
Verificar a quantidade de caminhos de execução independentes. |
| Fórmula |
V(G) = e - n + p
Onde V(G) é a complexidade ciclomática, n = vértice, e = aresta, p = componentes conectados
A média é feita, M(V(G)), dando a complexidade ciclomática média.
|
| Escala de Medição |
Racional |
| Coleta |
- Responsável: Scrum Master
- Periodicidade: ao final de cada Sprint
- Ferramenta: Rubocop
- Procedimento: Após o último Pull Request aprovado da Sprint, rodar a ferramenta sobre a branch devel e pegar o resultado da métrica.
|
| Análise |
Caso a ferramenta acuse algum problema de complexidade, o código deverá ser corrigido.
|
| Cobertura de Testes |
|---|
| Objetivo da Medição |
Verificar a porcentagem do código que está sendo testado, afim de garantir a manutenabilidade. |
| Fórmula |
Cobertura = Linhas testadas / Linhas totais |
| Escala de Medição |
Racional |
| Coleta |
- Responsável: Scrum Master
- Periodicidade: ao final de cada sprint
- Ferramenta: Converalls
- Procedimento: Após o último Pull Request aprovado da Sprint, rodar a ferramenta sobre a branch devel e pegar o resultado da métrica.
|
| Análise |
- 0 a 89%: Preocupante. Deve-se abrir histórias técnicas para a testar a aplicação
- 90% ou mais: Satisfatório
|
| Quadro de Conhecimentos |
|---|
| Objetivo da Medição |
Acompanhar a evolução da equipe quanto as tecnologias e habilidades trabalhadas. |
| Fórmula |
Não se aplica. |
| Escala de Medição |
Intervalar |
| Coleta |
- Responsável: Scrum Master
- Periodicidade: ao final de cada sprint
- Procedimento: Antes de começar a sprint review, todos os membros devem atualizar o quadro de conhecimentos com os conhecimentos adquiridos durante aquela sprint.
|
| Análise |
- 0 a 2: Baixíssimo ou nenhum conhecimento
- 3 a 5: Um pouco de conhecimento
- 6 a 7: Conhecimento razoável
- 8 a 10: Conhecimento satisfatório
|
| Número de Pareamentos |
|---|
| Objetivo da Medição |
Verificar se diferentes membros estão interagindo com o intuido de difundir diferentes conhecimentos. |
| Fórmula |
Não se aplica |
| Escala de Medição |
Racional |
| Coleta |
- Responsável: Scrum Master
- Periodicidade: ao final de cada Sprint
- Procedimento: Antes de começar a sprint review, um membro de cada par deve atualizar o quadro de número de pareamentos indicando com quais pessoas ele pareou durante a sprint.
|
| Análise |
Quanto mais homogêneo estiver o quadro de número de pareamentos, entende-se que o conhecimento está sendo difundido entre toda a equipe. Caso, algum valor seja muito discrepante em relação aos outros deve-se averiguar o motivo e tomar providências para que tais pessoas pareem com outras, afim de disseminar as habilidades desenvolvidas.
|
| Burndown |
|---|
| Objetivo da Medição |
Acompanhar a entrega contínua de atividades dentro da sprint |
| Fórmula |
Não se aplica
|
| Escala de Medição |
Não se aplica |
| Coleta |
- Responsável: Scrum Master
- Periodicidade: ao final de cada sprint
- Ferramenta: ZenHub
- Procedimento: Após o fechamento da sprint, coletar a imagem do gráfico gerado por meio da ferramenta utilizada.
|
| Análise |
Se histórias são entregues constantemente durante a sprint entende-se que há constância na produtividade da equipe. Se as histórias são entregues somente no final, ou não são entregues, a forma de planejar a sprint deve ser repensada e as histórias analisadas, talvez, seja melhor para a equipe transformar a história em um épico e quebrá-la em histórias menores.
|
| Velocity |
|---|
| Objetivo da Medição |
Acompanhar a capacidade de produção da equipe para auxiliar no planejamento das próximas sprints |
| Fórmula |
Média de pontos entregues por sprints |
| Escala de Medição |
Racional |
| Coleta |
- Responsável: Scrum Master
- Periodicidade: ao final de cada sprint
- Ferramenta: ZenHub
- Procedimento: Após o fechamento da sprint, coletar a imagem do gráfico gerado por meio da ferramenta utilizada.
|
| Análise |
Com base nos resultado do velocity deve-se estimar a próxima sprint em torno da mesma quantidade de pontos. Caso perceba-se que dado o velocity da equipe e a quantidade de pontos totais do projeto, a equipe não seja capaz de entregar todas as funcionalidades em tempo hábil, deve-se fazer um reavaliação do escopo.
|
| Número de Commits por dia |
|---|
| Objetivo da Medição |
Acompanhar a produtividade diária das sprints, afim de averiguar se está havendo integra contínua |
| Fórmula |
Não se Aplica |
| Escala de Medição |
Racional |
| Coleta |
- Responsável: Scrum Master
- Periodicidade: ao final de cada sprint
- Procedimento: Após o fechamento da sprint, coletar no Insights do GitHub a relação de commits por dia durante a sprint
|
| Análise |
Caso os commits ocorram apenas no sexto ou sétimo dia da sprint, deve ser avaliado o motivo das entregas emcima da hora (sobrecarga dos desenvolvedores, issues muito grandes ou descaso). Cabendo ao Scrum Master tomar alguma medida corretiva sobre o problema.
|
