[fix] - add updated status to reviewed us

Signed-off-by: saracampss <[email protected]>

docs/gestao/backlog.md

@@ -31,14 +31,17 @@ A EAP, no entanto, não permite uma visualização do que foi entregue aos P.Os,
 | US18 | Atribuir perfis | Enviada para aceitação em 08/09 |
 | US19 | Cadastrar benefícios | Aceita pelo P.O Matheus em 21/08 |
 | US20 | Cadastrar movimentações financeiras | Enviada para aceitação com correções finais em 06/09 |
-| US21 | Gerar relatório de financeiro | Enviada para aceitação em 06/09  |
+| US21 | Gerar relatório de financeiro | Aceita pelo P.O Matheus em 09/09 |
 | US22 | Acessar prestação de contas | Com a entrada da US35 no Backlog do Produto, a US22 foi despriorizada num acordo entre time e P.Os, portanto, não foi entregue |
 | US23 | Acessar histórico de contribuição dos sindicalizados | Enviada para aceitação com correções finais em 08/09 |
-| US34 | Gerenciar filiação | Enviada para aceitação com correções finais em 06/09 |
+| US34 | Gerenciar filiação | Não aceita por conta de defeitos  |
 | US35 | Cadastrar órgãos/lotações (adicionado ao Backlog do Produto com o projeto em andamento) | Enviada para aceitação em 02/09 |
 
+Apesar de entregues aos P.Os, algumas US apresentaram defeitos, que são explicitados no documento de [Melhorias e defeitos](./melhorias-defeitos.md).
+
 ## Histórico de Versões
 
-| Alteração | Data | Autor |
-| -------------------- | -------- | ----------- |
-| Criação do documento | 08/09/24 | Sara Campos |
+| Alteração | Data | Autor |
+| ---------------------------------------------------------------------------- | -------- | ----------- |
+| Criação do documento | 08/09/24 | Sara Campos |
+| Atualização a partir do feedback do P.O (Atualiza aceitação de US na tabela) | 09/09/24 | Sara Campos |

docs/gestao/evm.md

@@ -23,27 +23,23 @@ Baseando-se nos gráficos gerados por sprint com suas referências de Valor Agre
 ![r1](../assets/R1_EVM.png)
 
 A Release 1 contou com duas semanas totais de desenvolvimento, com um planejamento do valor agregado do sistema próximo à 25% do total esperado. Porém por dificuldades iniciais da equipe no processo de desenvolvimento o valor total entregue e aceito não alcançou essa meta.
-Sendo assim, a relase planejou 31 pontos e entregou 0.
 
 ### MVP
 
 ![mvp](../assets/RMVP_EVM.png)
 
 A entrega da Release MVP consistiu em 4 semanas completas de desenvolvimento. Como pode ser verificado pelo gráfico, as primeiras semanas de desenvolvimento não trouxeram nenhum valor agregado enquanto o valor planejado continuava crescendo. Quanto ao valor planejado, esse cescimento constante se dava pela utilização de metodologias ágeis por parte da equipe que se baseiam na entrega contínua de valor. Já o comportamento do valor agregado pode ser relacionado com tanto a necessidade de reescrita e organização de critérios de aceitação e histórias de usuário, quanto à demora por parte do cliente para validação das histórias entregues.
-Sendo assim, a relase planejou 34 pontos e entregou 18.
 
 ### Release N
 
 ![rn](../assets/RN_EVM.png)
 
 Para a entrega final, o projeto contou com 2 sprints de desenvolvimento. O foco dessas sprints era finalizar as histórias de usuário similarmente à conrrigir possíveis erros de funcionalidade ou compreensão de histórias de usuário anteriores, de forma que o planejamento dessas sprints trouxe menor quantidade de pontos por sprint. Porém por conta de avanço na aceitação por parte do usuário tivemos maior quantidade de pontos de história fechados.
-Sendo assim, a relase planejou 13 pontos e entregou 39.
 
 ### Análise Total
 
 ![total](../assets/TOTAL_EVM.png)
 Assim, analisando o gráfico total do projeto é possível ver uma estagnação da equipe para finalizar as entregas, muito passando pelos problemas citados de erros de comunicação levando à reescrita de histórias e critérios de aceitação, assim como a demora muitas vezes para validas as entregas já relizadas. Ainda assim, foi possível finalizar muitas das histórias do projeto.
-Sendo assim, o projeto planejou a entrega de 78 pontos e entregou 57 pontos até a data.
 
 ## Histórico de Revisão
 

docs/gestao/melhorias-defeitos.md

@@ -26,8 +26,16 @@ Nas semanas finais (Release N), quando o foco era na entrega de melhorias e corr
 - list user [feito]
 - profile (update) [feito]
 
+Por fim, o projeto é finalizado com a necessidade das seguintes correções de defeitos:
+
+| US | Defeito | Descrição | Prioridade |
+| ---- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
+| US04 | Inicialmente, havia sido levantado que as telas de cadastro de usuários teriam os dados pedidos pelos P.Os. No entanto, enquanto era desenvolvida, notou-se que essa US precisava de telas para representar usuários do tipo filiados. Essa correção, no entanto, não foi finalizada a nível de interface. | A correção foi feita apenas a nível de banco de dados, já que agora as tabelas Usuário e Filiado possuem relação de herança, mas é preciso criar protótipos de como essas telas irão funcionar com a mudança e refletir isso no frontend. | A prioridade dessa correção é considerada alta, pois afeta a performance de outras US e é uma funcionalidade básica do sistema. |
+| US34 | Quando uma solicitação é rejeitada, um email deve ser enviado ao solicitante para que ele seja informado sobre a rejeição e, caso queira, entre em contato com o sindicato | Esse defeito deve ser corrigido com uma revisão simples do código, visto que, a funcionalidade foi implementada e já havia sido testada antes, mas no momento do teste de aceitação final do usuário acabou não funcionando perfeitamente | A prioridade dessa correção não é tão alta por não afetar outras US, mas por ser uma correção rápida pode ser significativamente priorizada. |
+
 ## Histórico de versão
 
-| Alteração | Data | Autor |
-| -------------------- | -------- | ----------- |
-| Criação do documento | 08/09/24 | Sara Campos |
+| Alteração | Data | Autor |
+| --------------------------------------------------------------------- | -------- | ----------- |
+| Criação do documento | 08/09/24 | Sara Campos |
+| Atualização a partir do feedback do P.O (Adiciona tabela de Defeitos) | 09/09/24 | Sara Campos |