Ir para o conteúdo

Planejado X Realizado

1. Introdução

Este documento tem como objetivo apresentar a análise comparativa entre o planejamento e a execução no desenvolvimento do projeto. Serão avaliados e comparados o Backlog com as User Stories (US), o Custo, Risco e a Qualidade, a fim de compreender o progresso do projeto.

2. Backlog

2.1. Planejado

2.2. Executado

2.3. Análise

O grupo planejou inicialmente 15 atividades no backlog e conseguiu se organizar para executar todo o planejamento. Destaca-se também a inclusão da atividade de configuração do deploy contínuo. Isso foi necessário para livrar a obrigração do grupo de atualizar o ambiente de homologação manualmente toda vez que fosse desenvolvida uma nova feture.

3. User Stories

3.1 Planjejado

3.2 Executado

3.3 Análise

Ao comparar as USs planejadas com as realizadas, podemos notar uma diferença em relação a uma parte das User Stories (em negrito).

O Backlog inicialmente planejado para o projeto contemplava as funcionalidades como Gerenciar papéis no sistema (USs 1, 2 e 3), ranking de escolas (US4), gerenciar solicitações de ações (US7), exportar dados (US9), ordenar visitas pelo melhor caminho (US6), configuração de prioridades (US5) e gerênciamento de ações (US8)

Vale destacar também que com o andamento do projeto, o cliente identificou uma nova feature essecial para o funcionamento do projeto que era a funcionalidade de gerenciamento de polos (US11). Essa funcionalidade afeta diretamente a US6 pois mudou o cálculo que antes era baseado apenas em superintendencias do DNIT para polos, que são pontos editáveis de localização (latitude e longitude) que o gestor do DNIT considera essencial para calcular o melhor custo logístico.

Entretanto a US8 que está destacada em negrito precisou sofrer alguns ajustes devido à demora na validação do seu protótipo, mudança do entendimento do cliente sobre essa feature ao longo do semestre e tempo reduzido para o desenvolvimento. Isso resultou em um escopo muito grande para um nível de US, então houve a necessidade de quebrá-la em partes menores.

4. Custo

4.1. Planejado

Segundo nosso planejamento inicial na página sumário da planilha de EVM, planejou-se para esse projeto do semestre de 2023.2 oito sprints com um custo médio por sprint de R$ 11.318,28. Para o desenvolvimento de código, foram planejados 157 pontos de história com custo de desenvolvimento de R$ 98.591,40.

4.2. Executado

A página de EVM - Valor agregado mostra que o time de fato executou as 8 sprints e que o custo incialmente planejado não foi alterado.

4.3. Análise

Ao observar o velocity do projeto, disponível na página Velocity da planilha, observa-se alguns pontos onde não foram entregues nenhum ponto de histótia, consequentemente, nehuma entrega de valor. Isso ocorreu devido a impedimentos de comunicação com o cliente que impossibilitaram a validação de features que estavam planejadas para iniciar o desenvolvimento na mesma semana.

5. Tempo

As tabelas em 5.1 e 5.2 foram montadas a partir do ROADMAP DA EQUIPE. Elas fazem a comparação entre o planejado e executado do tempo do projeto.

5.1. Planejado

Releases incicio Fim
Lean Inception 14/09/2023 16/10/2023
Treinamentos Front e Back 11/09/2023 25/09/2023
Release 1 13/10/2023 21/10/2023
Release 2 13/10/2023 27/11/2023
Release 3 28/11/2023 09/12/2023

5.2. Executado

Releases incicio Fim
Lean Inception 14/09/2023 16/10/2023
Treinamentos Front e Back 11/09/2023 25/09/2023
Release 1 13/10/2023 25/10/2023
Release 2 13/10/2023 27/11/2023
Release 3 28/11/2023 09/12/2023

5.3. Análise

O grupo conseguiu cumprir com a maior parte do prazo planejado. Entretando, o lançamento da Release 1 sofreu um atrazo devido à organização original do código do projeto. Isso levou o grupo a realizar algumas mudanças no código para facilitar futuras implementações, consequentemente atrasando um pouco a entrega da Release 1, destacado na data em negrito.

6. Qualidade

6.1. Planejado

O nosso grupo planejou melhorar a segurança e robustez do projeto em relação ao semestre passado para facilitar futuras implementações, com menor acoplamento e com alta coesão, tratando os bugs encontrados e sempre levando em conta possives fragilidades. Com uma ampla cobertura de testes em torno de 90%.

6.2. Executado

avaliação dos testes

qualidade geral projeto

6.3. Análise

O grupo manteve a preocupação de manter a cobertura de testes em torno de 90% e uma boa robustez do código. Isso está evidenciado nos gráficos gerados pelo Q-Rapids, uma ferramenta de análise da qualidade do projeto sobre os aspectos de manutenabilidade e confiabilidade. Esses graficos possuem em seu eixo y uma nota que vai de 0 a 1 e quanto mais próximo de 1 melhor é a avaliação do projeto.

7. Risco

7.1. Tabela de Resumo

7.2. Gráfico de Burndown

Versionamento

Data Descrição Autor(es)
09/12/2023 Criação do documento e item 3 Rafael
09/12/2023 Adição do item 2 Rafael
09/12/2023 Adição do item 6 Rafael
09/12/2023 Adição do item 7 Rafael
09/12/2023 Adição do item 5 Rafael
09/12/2023 Adição do item 4 Rafael