Planejado x Executado

Versionamento

Versão	Data	Modificação	Autor
0.1	10/12/2023	Criação do documento	Ana Carolina Rodrigues

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 Front

2.1.2 CLI

2.1.3 Action

[US - 30] - Criação e exibição de Badges através da Action do MeasureSoftGram

2.1.5 Core

2.1.4 Service

[FIX] - Refatorar acesso as métricas no Service

2.2 Realizados

2.2.1 Front

2.2.2 CLI

2.2.3 Action

[US - 30] - Criação e exibição de Badges através da Action do MeasureSoftGram

2.2.5 Core

2.2.4 Service

[FIX] - Refatorar acesso as métricas no Service

2.3 Análise

Nesse projeto, foram planejadas 21 atividades no backlog e 19 delas já foram realizadas, tendo apenas a necessidade de fazer alguns ajustes conforme os critérios de aceitação que não puderam ser reproduzidos, totalizando 19 tarefas realizadas. Duas das atividades planejadas não foram feitas, por demandar mais tempo que o temos no final do semestre para a entrega afirmativa da release final. Portanto, temos um percentual de 80% das atividades que foram planejadas já estarem implementadas e entregues ao cliente para teste. Tivemos alguns problemas no meio do densenvolvimento, como a queda do frontend, alguns entedimentos errado sobre o produto e implementações demoradas no processo conforme o entendimento do problema e o fluxo no sistema, porém ainda com esses fatores soubemos nos alinhar e desempenhar nossas atividades. Foi percebido a necessidade de refatoração do Frontend a fim de ter 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. Porém a implementação das atividades no front-end não foi possível atingir esse percentual de cobertura, pois cada nova US desenvolvida tinha a condição do lint que por vezes pontuava erros simples, mas que ao corrigir eles não eram analisados e se fossem algumas vezes acabava por quebrar a cobertura do sonar o que houve em outros repositórios. Dentro do planejamento, nosso objetivo era deixar o código mais simples de se fazer manutenção, de fácil entendimento 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 que pudessem levar a cobertura não ser efetivada ao percentual de 80%.

Executado

Como previsto a equipe se deparou com desafios em atingir as metas de qualidades planejadas devido aos problemas evidenciados acima sobre o Frontend, no qual foi identificado o problema ao criar testes e abrir PRs. Foi necessário avaliar os relacionamentos entre o core, service, CLI, front-end pois esse relacionamento estava completamente problemático não trazendo os reais valores entre métricas e medidas. Reformulando o modo da saída dos dados do core e assim corrigindo o recebimento do mesmo no CLI, front e service. Incluindo também as novas medidas implementadas no CLI que obtiveram cobertura efetiva no sonar e estão dentro do critérios de qualidade estabelecidos dentro do projeto nesse semestre. Ademais, como um semestre diferente dos demais, os MDS estiveram presentes no grupo desenvolveram atividades pertinentes ao front-end com os testes das atividades e soubemos ainda mais lidar com os padrões de qualidade, ensinando e ajudando eles a conseguirem ter uma melhor cobertura para os testes implementados.

5. Risco

5.1 Análise

No início do semestre, observamos que ocorreram os riscos R1, R3, R4, R6, R7, por fatores de mal entendimento do projeto e da arquitetura que o compunha, levando assim uma demora na faze de planejamento que ocorreu com o Lean Inception. Evidenciando o impacto mais alto nas primeiras sprints, até o ponto de percebemos esse atraso e alinharmos mais a rota conforme as atividades que deviam estar prontas.

Juntamente com as dificuldades de atraso, durante o planejamento, foi identificado a ausência do cliente (R9) mais comprometedora na relação de sanar dúvidas sobre os Epicos e quais seriam suas verdadeiras atividades. Nessa fase há também a configuração de ambiente, que por fatores de dúvidas, erros, sistema operacional, foi marcada pelo risco R16, por maior parte dos integrantes de MDS.

Outro risco que afetou o projeto foi o R2 e R12, relacionado a falta de um dos EPS que acabou trancando a disciplina um pouco depois da primeira apresentação de release, afetando o quantitativo de atividades e a sobrecarga de alguns membros com suas respectivas atividades.

Os ricos que mais impactaram o projeto foram, R11, R18, R19, R20, que por fatores da falta e falha no entendimento do produto, no passo a passo da experiência do cliente com o produto, no entendimento errado da US e por muitas vezes o entendimento duvidoso, gerava o atraso na validação da US por ter que refazer novamente, atraso na entrega na release no tempo correto e consequentemente o erro da implementação da feature tendo que refazer a mesma para estar de acordo com os critérios de aceitação do cliente.

Por fim, não enfrentamos problemas relacionados à falta de comunicação entre os membros da equipe, 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.