Planejado x Executado

1. Introdução

O documento presente tem como objetivo realizar a análise comparativa entre o planejado e o executado durante o desenvolvimento do projeto. Serão avaliados e comparados o Backlog, as Histórias de Usuários (HU) ou User Cases(US), o Custo, a Qualidade e o Risco, visando compreender o progresso do projeto. Além disso, serão realizadas análises adicionais e avaliações para aprimorar a compreensão do estado atual do projeto.

2. Backlog

2.1 Planejadas

2.1.1 Etapas

2.1.2 Unidades

2.1.3 Rastreabilidade

2.1.4 Informação

2.1.5 Pesquisa

US20 - Implementar Pesquisa (tinha mas não em todas as páginas)
US21 - Visualização de processos na etapa de um fluxo não tem.
US22 - Identificação por prioridade --> tem, provavelmente ja tinha?
US23 - Ordenar processos por tempo --> não tem, e não precisa?
US24 - Modos de ordenação numerica e alfabética --> não tem

2.1.6 Acesso

[US - 25] - Gerenciar perfis
[US - 26] - Gerenciar permissões
[US - 27] - Mapeamento pela interface; Não é mais necessario após validação com cliente.
[US - 28] - Registro sem restrições

2.1.7 Estatísticas

US29 - Visualizar Quantidade de processos em cada etapa
US30 - Visualizar tempo de conclusão de etapa
US31 - Visualizar Relatório com Quantidade de processos concluidos
US32 - Visualizar Relatório com Filtro de data vencimento
US33 - Visualizar Relatório de processo

2.2 Realizados

2.2.1 Etapas

2.2.2 Unidades

2.2.3 Informação

2.2.4 Acesso

[US - 25] - Gerenciar perfis
[US - 26] - Gerenciar permissões
[US - 27] - Mapeamento pela interface Não é mais necessario após validação com cliente.
[US - 28] - Registro sem restrições

2.3 Tarefas extras

2.3.1 Melhorias de Desempenhos

2.4 Análise

Foram planejadas 38 atividades no backlog e 25 delas já foram realizadas, surgindo a necessidade de implementação de mais duas tarefas extras relacionadas a melhoria de desempenho, totalizando 27 tarefas realizadas. Vale notar que a US17 foi duplicada já sendo tratada na US19 e a US27 foi fechada devido a novas validações sobre as regras de negócio com o cliente. Com isso considerando 38 tarefas planejadas e 25 implementadas, significa que 65% de atividades planejadas já foram implementadas. Um dos motivos para ter esse valor foi o trabalho em entregar os microsserviçoes e a necessidade de refatorar o Front inteiro do semestre passado. Essa decisão de refatorar o Front foi tomada a fim de entregar um sistema com qualidade e de fácil manutenção para o cliente e os envolvidos.

3. Custo Executado

4. Qualidade

Planejado

Com a finalidade de realizar uma entrega mais segura e confiável para o cliente, a equipe almejou uma cobertura acima de 80% para todos os repositórios. Devido a implementação dos microserviços e decisão de refatoração do front já foi imaginado também que seria um desafio atingir essa meta devido a reformulação de testes no Backend para cada microserviço e criação de testes para todo o frontend. Dentro do planejamento, nosso objetivo era deixar o código seguro e mais robusto para futuras implementações, com menor acoplamento e com alta coesão, tratando os bugs encontrados e sempre levando em conta as possíveis vulnerabilidades.

Executado

Como previsto a equipe se deparou com desafios em atingir as metas de qualidades planejadas devido a refatoração do Frontend e criação dos microserviços. Além disso, identificamos um problema nos testes. Semestres anteriores criaram uma estrutura de fazer mock do Banco de Dados, essa estrutura quebrou após alterar a tabela Roles.

O setup estava tão ruim que estava utilizando sqlite3, sendo que toda a aplicação é feita para trabalhar com postgres. Por conta disso, ao adicionar um novo atributo na tabela Roles, que usa uma feature exclusiva do postgres, 100 testes falharam.

Desse modo, toda essa estrutura de mock do Banco foi descartada, visto que era muito trabalhoso alterar ela para se adaptar ao postgres. Assim, reescrevemos todos os testes utilizando mocks de funções com axios.

Um bom ponto a comentar é que atualmente a equipe atingiu 100% de cobertura nos endpoints

5. Risco

5.1 Análise

Ao analisar a tabela de riscos, observamos que ao longo do projeto ocorreram os riscos R1 e R3, nos quais alguns membros não puderam participar de reuniões e treinamentos presencialmente. No entanto, o impacto não foi tão alto quanto o esperado.

Em algumas sprints, durante o planejamento, foram consideradas histórias mais fáceis do que realmente eram, assim como US's mais difíceis do que pareciam. Isso resultou em um alto impacto no projeto e na entrega das features, como evidenciado pelo risco R4.

Outro risco que afetou o projeto foi o R4, relacionado à dificuldade com a tecnologia de desenvolvimento. Esse desafio foi particularmente notado no desenvolvimento do Frontend, onde tanto membros de EPS quanto de MDS tiveram dificuldades para entender o funcionamento das tecnologias. No entanto, a realização de treinamentos, mencionados como medida de prevenção, ajudou a equipe a superar esses obstáculos.

No início do projeto, vários membros de MDS enfrentaram dificuldades com a configuração do ambiente de desenvolvimento (Risco R10). Em alguns casos, a dockerização do projeto não foi suficiente, pois algumas histórias exigiam um ambiente local de desenvolvimento em execução. Graças às medidas de contenção adotadas, a equipe conseguiu superar esse desafio.

Não foram identificados problemas relacionados à falta de comunicação entre os membros da equipe e o cliente, devido à implementação de medidas de prevenção desde o início do projeto. Além disso, todos os membros da equipe permaneceram motivados e bem integrados nas primeiras semanas.

6. Earned Value Management (EVM) - Capju

Histórico de versão

Data	Versão	Descrição	Autor(es)
08/07/2023	0.0.1	Criação da página de documentação dos planejados vs executados	Peniel Etèmana e Vinícius Vieira