Resultado da Melhoria 1
Esta página tem por objetivo armazenar as métricas de melhoria de processo para a primeira melhoria proposta, que podem ser encontradas neste link, bem como analisar se os benefícios esperados com as mudanças foram realmente alcançados.
Vale ressaltar que algumas das métricas de melhoria definidas não foram coletadas para essa Sprint, devido a impossibilidade de fazê-lo, levando em conta que a Sprint já havia começado e terminado algum tempo antes destas métricas estarem definidas de fato.
- Percentual de código testado
O percentual de código testado foi obtido da análise a partir da ferramenta incluída na integração contínua, o coveralls.
A cobertura de testes no Repositório do APP é de 38% na branch develop.
A cobertura de testes no Repositório da API é de 86.832% na branch develop.
- Número de erros referentes a folha de estilo proposta
O número de erros foi obtido através da análise realizada pela ferramenta eslint incluída na integração contínua.
O número de erros encontrados pelo eslint no Repositório do APP foi 0.
Não há folha de estilo configurada na integração contínua do Repositório da API.
- Percentual de código testado
O percentual de código testado foi obtido da análise a partir da ferramenta incluída na integração contínua, o coveralls.
A cobertura de testes no Repositório do APP é de 23.96% na branch develop.
A cobertura de testes no Repositório da API é de 87.405% na branch develop.
- Número de erros referentes a folha de estilo proposta
O número de erros foi obtido através da análise realizada pela ferramenta eslint incluída na integração contínua.
O número de erros encontrados pelo eslint no Repositório do APP foi 0.
Não há folha de estilo configurada na integração contínua do Repositório da API.
A complexidade ciclomática foi obtida através da análise na ferramenta Sonar.
No Repositório do APP a ferramenta reportou uma complexidade ciclomática de 180, dividida em 141 métodos, caracterizando uma complexidade de 1.27 por método.
No Repositório da API, a ferramenta reportou uma complexidade ciclomática de 149, dividida em 94 métodos, caracterizando uma complexidade de 1.58 por método.
A complexidade ciclomática foi obtida através da análise na ferramenta Sonar.
No Repositório do APP a ferramenta reportou uma complexidade ciclomática de 244, dividida em 186 métodos, caracterizando uma complexidade de 1.31 por método.
No Repositório da API, a ferramenta reportou uma complexidade ciclomática de 165, dividida em 102 métodos, caracterizando uma complexidade de 1.61 por método.
A porcentagem de duplicação de código foi obtida através da análise realizada pela ferramenta sonar.
No Repositório do APP, não foram encontrados blocos de código duplicado segundo a análise da ferramenta sonar.
No Repositório da API, também não foram encontrados blocos de código duplicado.
A porcentagem de duplicação de código foi obtida através da análise realizada pela ferramenta sonar.
No Repositório do APP, não foram encontrados blocos de código duplicado segundo a análise da ferramenta sonar.
No Repositório da API, também não foram encontrados blocos de código duplicado.
| Data | Auditoria | Resultado | Não conformidade |
|---|---|---|---|
| 23/05/2018 | Teste de Software | Resultado | Não |
| 21/05/2018 | Backlog da Release 2 Refinado | Resultado | Sim |
| 22/05/2018 | Plano de medição ciclo 02 | Resultado | Não |
| 24/05/2018 | Subprocesso de Desenvolvimento | Resultado | Não |
| 23/05/2018 | Backlog Refinado | Resultado | Não |
| 23/05/2018 | Relatório de Retrospectiva | Resultado | Sim |
| 23/05/2018 | Backlog Validado sprint 2 | Resultado | Não |
| 21/05/2018 | Backlog | Resultado | Não |
| 23/05/2018 | Documentação da análise das Métricas | Resultado | Não |
| 26/05/2018 | Relatório de Desempenho sprint 2 | Resultado | Sim |
| 28/05/2018 | Requisitos | Resultado | Não |
| 28/05/2018 | Métricas de código | Resultado | Não |
Com os dados na tabela acima é possível inferir que exitiram 12 auditorias referentes a sprint 2, sendo assim a quantidade de auditorias(QTA) igual a 12. E que dessas 12, 3 apresentam ao menos uma não conformidade. Desta forma a aderência ao processo é:
QTA = 12;
QTDANC = 3;
AP = (1 - 3/12) * 100 = 75%
Por isso, com base no resultado de 75% se encontra na baixa de Regular, apresentando uma aderência ao processo, segundo as auditorias feitas. No entanto é importante que a aderência ao processo seja maior nas próximas coletas, com a diminuição de não-conformidades com a contribuição de mudanças feitas utilizando o modelo IDEAL para melhoria do processo.
Não foi possível coletar a métrica de aderência do processo, o fato é que a métrica é baseada nas auditorias feitas pela equipe de Garantia de Qualidade e estas não foram feitas para a sprint em questão. Dado isso não é possível nem fazer análise e nem agir sobre a possível não aderência ao processo.
Para se ter os valores de pontos concluídos nas sprints será utilizado a imagem do velocity até então.
Com base no velocity da equipe de desenvolvimento tem-se que o percentual de pontos concluídos nas sprints são:
Sprint 1: PES = 8/25 = 32%
Sprint 2: PES = 9/50 = 18%
Sprint 3: PES = 6/31 = 19,35%
PES = (QPC/QPP) * 100,
Onde:
PES = percentual de pontos entregues por sprints
QPC = a quantidade de pontos concluídos
QPP = a quantidade de pontos planejados
De acordo com os dados acima, o percentual de pontos de histórias completas na sprint anterior a implantação das melhorias era de 18% (9 pontos concluídos de 50 planejados). Que está na faixa RUIM (Entre 0% e 49%) de acordo com o métrica definida.
Após a mudança no processo, o percentual de pontos de histórias completas aumentou para 19,35% (6 pontos completos de 31 planejados) entretanto pode-se perceber que por mais que a porcentagem tenha aumentado o número de pontos completos diminuiu, e por mais que esse número não tivesse diminuído a essa porcentagem ainda está na faixa RUIM de acordo com a métrica definida.
Com base nos dados coletados até agora, não é possível dar um parecer se as mudanças auxiliaram ou pioraram o desenvolvimento das histórias pois desde a primeira sprint o time de desenvolvimento não consegue concluir boa parte das histórias da sprint e está com uma porcentagem muito baixa na métrica.
A aplicação do questionário não contemplou perguntas que diferenciassem o processo anterior e após a mudança.
Sobre a aplicação e participação dos integrantes das equipes podemos, primeiramente, observar a aderência dos times perante a documento aplicado:
- Da equipe de Desenvolvimento:
- Da equipe de Qualidade:
- Da equipe de Processo:
Pode-se observar que a maior aderência foi da equipe de processos (12/12) e a menor aderência foi da equipe de desenvolvimento (5/14). Com isso os dados apresentados a seguir podem não refletir a total opinião das equipes, já que nem todos participaram do forms.
Fora disponibilizado formulários em que era solicitado a votação, de 1 a 10, onde 1 era nenhuma participação e 10 participação plena do projeto, para todos os integrantes da sua equipe. Utilizando de recursos estatísticos, foi obtido a variância das notas de cada integrante, pois dessa forma era possível analisar a participação de cada aluno perante a visão de toda a equipe no qual ele pertence.
Na equipe de Desenvolvimento houve:
Na equipe de Qualidade houve:
E na equipe de Processo houve:
Com isso pode-se observar que, quanto menor o resultado do índice, menor é a divergência da opinião da equipe em relação ao integrante; caso o índice seja alto é um pouco inconclusivo chegar em algum resultado já que há muita divergência dos integrantes em relação ao indivíduo.
[FAZER]
Não foi possível realizar a coleta da métrica pois não foram disponibilizados pela Alta Gerência as notas de apresentação parcial e os tópicos insatisfatórios. Assim, essa métrica tem sua análise e providência também impedidas.
Antes da mudança do processo, a definição dessa métrica ainda não estava feita.Logo, não foram realizadas as atividades necessárias para que os insumos utilizados no cálculo do seu valor fossem coletadas.
Essa comparação será realizada no próximo ciclo,utilizando como insumo o valor desse ciclo.
O objetivo dessa métrica é verificar se a metodologia está adequada a disciplina. Seu cálculo é baseado no número de alterações realizadas, onde essas alterações são elencadas com todas as equipes e depois verificado o que destes pontos levantados foram realmente implementadas soluções de melhoria. Para esse ciclo considerou-se que as mudanças propostas foram as encontradas como GAP's do processo considerado IDEAL.Sendo assim a métrica possuiu o valor 6, fazendo com que a metodologia seja considerada adequada.
NAI = 0 (AIGQA) + 4 (AIDEV) + 2 (AIPROC) + 0 (AIMPS)
No próximo ciclo deve-se realizar no início do mesmo o levantamento para que assim a métrica possa ser avaliada novamente posteriormente.
Antes da mudança do processo, a definição dessa métrica ainda não estava feita.Logo, não foram realizadas as atividades necessárias para que os insumos utilizados no cálculo do seu valor fossem coletadas.
Essa comparação será realizada no próximo ciclo,utilizando como insumo o valor desse ciclo.
Essa métrica busca verificar a satisfação dos alunos quanto ao desempenho obtido na disciplina. Seu funcionamento ocorre com o preenchimento de formulário online para verificar qual a nota que a equipe recebeu, o quão correta foi essa nota, o quanto o aluno percebeu que contribuiu ao projeto e se a avaliação foi coerente.
Não é possível realizar no momento o cálculo do valor dessa métrica, pois a mesma tem como um de seus coeficientes de cálculo a Nota de avaliação da Auto Gerência, que é divulgada somente após o término do ciclo.Isso ocorreu porque esta métrica foi definida ao decorrer do ciclo, demandando assim que ocorra uma mudança no planejamento do formato de divulgação de notas da disciplina, o que não foi possível ocorrer até o momento.
[FAZER]
[FAZER]
Até o dia 7 de Junho de 2018 às 01:34 as notas não foram disponibilizadas pelo cliente.
Até o dia 7 de Junho de 2018 às 01:34 as notas não foram disponibilizadas pelo cliente.
Antes da mudança do processo, na sprint 02 foram entregues 3 histórias (como débito da sprint 01) que representa 30% da sprint e 20% da release 02 e se está na faixa ruim, seguindo as métricas de avaliação
| Sprint | Porcentagem | Análise |
|---|---|---|
| 01 | 15% | Ruim |
| 02 | 20% | Ruim |
Após a mudança no processo, na sprint 03 até o dia 07 de Junho de 2018 às 01:27 foram entregues 9 histórias, representando 45% da release. Significa que está na faixa ruim ainda, mesmo que tenha aumentado o número de histórias entregues.
Em relação às métricas para medir a mudança na qualidade do produto após a aplicação de um novo processo, não foi possível observar mudança alguma, ou seja, as métricas de manutenibilidade se mantiveram em estado igual ou muito similar tanto antes quanto depois da execução do novo processo.
Existem algumas interpretações possíveis para este fato. Uma delas é a de que não existiu nenhum impacto causado pelas novas mudanças. De fato, é possível que algumas métricas não tenham observado alteração porque, de certa maneira, apesar do aspecto não ter sido definido no processo, estava sendo implementado na execução. Isto é uma possibilidade real, já que a equipe de melhoria priorizou os GAPs do processo em relação a sua definição, e não a sua implementação.
Outra possível interpretação é a de que as mudanças propostas não foram de fato implementadas. De fato, algumas das mudanças propostas não foram implementadas na sua totalidade, como por exemplo a padronização do código, que não foi aplicada (por meio de folha de estilo) no repositório da API.
A recomendação a ser feita para melhorias futuras é que os focos de melhoria sejam identificados em relação ao que está ou não implementado de fato na execução do processo. Isto pode causar mudanças mais visíveis na organização, que poderão ser medidas, e, desta forma, a melhoria poderá ser de fato constatada.
As métricas relacionadas a visão macro do projeto não é possível inferir se as mudanças propostas contribuiram para a melhoria ou piora do processo. Uma pelo fato de não existir insumo de para comparação entre antes e depois da adoção das mudanças e a outra pelo fato de estar estagnada no mesmo valor desde o início do ciclo.
Alguns membros das equipes de desenvolvimento e qualidade não responderam ao formulário, o que compromete a amostra, já que a população limitada já é pequena. Assim como a falta de algumas perguntas comprometeu a análise de antes da mudança do processo.
[FAZER]
[FAZER]
Para a análise da satisfação do cliente é preciso as notas de avaliação que ainda serão entregues. E para as histórias entregues foi observado a importância do uso correto da ferramenta utilizada (ZenHub) como colocar as informações mínimas necessárias como labels, milestones, sprints e estimativa.