1. Backlog Revisado

O grupo 1 revisou e atualizou o backlog do projeto durante a 5ª sprint do dia 29/09/2025 até o dia 09/10/2025 às 23:59. Segue abaixo as definições utilizadas:

Features (Épicos): funcionalidades de alto nível do sistema.
User Stories: histórias de usuário alinhadas às features, refinadas e priorizadas.
Tasks: tarefas técnicas e de negócio detalhadas, associadas a cada user story.

Warning

O grupo possui 4 membros. A distribuição das responsabilidades foi definida por artefato e estratégia de entrega: Rafael Coutinho em Documentação Técnica do Projeto, Anna Aragão com Análise Financeira do Projeto, Eduarda Souza com Dashboards - versão 2 e Anna Aragão e Érick com gestão evolutiva do projeto.

Épico 1: Documentação Técnica do Projeto

Objetivo: Criar uma documentação técnica completa, padronizada e acessível para orientar a instalação, configuração, execução e manutenção do pipeline ETL e do Data Warehouse, garantindo reprodutibilidade e autonomia de parceiros técnicos.

User Stories

ID	História de Usuário	Prioridade (MoSCoW + Pontuação 1–5)	Responsável	Status	Critérios de Aceitação	Estimativa de Esforço
US1	Como engenheiro de dados, quero desenvolver um manual técnico de implementação do pipeline ETL, para que qualquer parceiro consiga configurar e executar o processo de forma autônoma.	Must Have – 5	Rafael Coutinho	Finalizado	- Manual `manual_implementacao_parceiro.md` criado na pasta `docs/`. - Todos os tópicos obrigatórios documentados. - Linguagem clara, com exemplos e subtítulos organizados.	4 dias
US2	Como parceiro técnico, quero instruções de instalação e dependências para preparar o ambiente e executar o ETL corretamente.	Must Have – 5	Rafael Coutinho	Finalizado	- Passos de instalação documentados. - Dependências da linguagem e frameworks listadas. - Scripts de instalação ou comandos exemplificados.	3 dias
US3	Como analista de dados, quero um guia de implantação e execução do pipeline ETL para que eu possa monitorar e rodar o processo periodicamente.	Should Have – 4	Eduarda Souza	Finalizado	- Seções sobre execução e agendamento detalhadas. - Exemplos de execução manual e automatizada. - Instruções de logs e verificações de sucesso.	3 dias
US4	Como engenheiro de software, quero documentar o processo de configuração do Data Warehouse, garantindo integração e relatórios conectados corretamente.	Should Have – 4	Rafael Coutinho	Finalizado	- Configuração do Data Warehouse explicada. - Parâmetros e variáveis de ambiente definidos. - Ajustes de relatórios documentados.	3 dias
US5	Como líder de projeto, quero garantir que o manual técnico siga padrões de clareza, organização e boas práticas de documentação, mantendo consistência e reprodutibilidade.	Could Have – 3	Rafael Coutinho	Finalizado	- Títulos e subtítulos estruturados. - Linguagem objetiva e consistente. - Revisão final de clareza e completude realizada.	2 dias

Tasks (Rastreáveis por User Story + Definition of Ready)

US1: Manual Técnico do Pipeline ETL

Criar o arquivo manual_implementacao_parceiro.md na pasta docs/.
Estruturar o documento com títulos e subtítulos claros.
Garantir que a linguagem seja objetiva e técnica.
DoR: Estrutura de diretórios do repositório criada, pipeline ETL funcional e validado.

US2: Instalação e Dependências

Documentar o processo de clonagem do repositório.
Listar as dependências da linguagem ou framework (ex.: Python, Prefect, bibliotecas).
Incluir exemplos de comandos (pip install -r requirements.txt, etc.).
DoR: Arquivos de configuração (requirements.txt, pyproject.toml) atualizados.

US3: Implantação e Agendamentos do ETL

Descrever como implantar e executar o pipeline ETL.
Instruir como criar agendamentos automáticos (ex.: Prefect, Airflow ou cron).
Adicionar exemplos de execução manual e logs de sucesso.
DoR: Pipeline ETL testado em ambiente local e orquestrador configurado.

US4: Configuração do Data Warehouse e Relatórios

Explicar como instalar e configurar o Data Warehouse (ex.: ClickHouse, BigQuery, Redshift).
Descrever como ajustar relatórios para apontar para o banco configurado.
Incluir variáveis de ambiente, credenciais e exemplos de conexão.
DoR: Ambiente de Data Warehouse funcional e acessível.

US5: Boas Práticas de Documentação

Garantir uso de linguagem clara e objetiva.
Inserir exemplos de código e trechos de configuração quando aplicável.
Realizar revisão final para padronização de estilo e terminologia.
DoR: Versão preliminar do manual disponível para revisão e ajustes finais.

Épico 2: Análise Financeira do Projeto

Objetivo: Realizar uma análise financeira completa do projeto de dados, contemplando custos, benefícios, indicadores econômicos e riscos associados, garantindo transparência e embasamento para a tomada de decisão sobre o investimento.

User Stories

ID	História de Usuário	Prioridade (MoSCoW + Pontuação 1–5)	Responsável	Status	Critérios de Aceitação	Estimativa de Esforço
US1	Como analista financeiro, quero elaborar um resumo executivo que sintetize os objetivos, problemas resolvidos, benefícios e retorno estimado do projeto.	Must Have – 5	Anna Aragão	Finalizado	- Documento com visão geral do projeto entregue. - Objetivos, problemas e benefícios descritos. - Custos e retorno estimado apresentados.	3 dias
US2	Como engenheiro de dados, quero descrever a arquitetura técnica e o escopo funcional do projeto, detalhando ferramentas e fontes de dados.	Must Have – 5	Anna Aragão	Finalizado	- Arquitetura e camadas do DW documentadas. - Ferramentas de ETL e visualização listadas. - Escopo funcional definido por área de decisão.	4 dias
US3	Como gestor de projeto, quero apresentar uma estimativa de custos detalhada para subsidiar o planejamento financeiro e o cronograma.	Must Have – 5	Anna Aragão	Finalizado	- Custos iniciais, operacionais e de pessoal discriminados. - Tabelas por categoria e valores estimados. - Base de cálculo e premissas documentadas.	4 dias
US4	Como analista de BI, quero projetar os benefícios financeiros esperados, de forma quantificável e com base em benchmarks e hipóteses fundamentadas.	Should Have – 4	Anna Aragão	Finalizado	- Benefícios financeiros e operacionais listados. - Estimativas fundamentadas em dados e benchmarks. - Reduções e melhorias quantificadas.	3 dias
US5	Como líder técnico, quero calcular os indicadores financeiros de viabilidade (Payback, ROI, TCO, VPL) para apoiar a decisão de investimento.	Should Have – 4	Anna Aragão	Finalizado	- Cálculo de ROI, Payback, TCO e VPL realizado. - Planilha ou documento com fórmulas e resultados anexados. - Interpretação dos indicadores registrada.	3 dias
US6	Como gestor de riscos, quero identificar riscos e premissas financeiras e técnicas, definindo planos de mitigação e hipóteses operacionais.	Could Have – 3	Anna Aragão	Finalizado	- Premissas documentadas e justificadas. - Riscos identificados e categorizados. - Planos de mitigação associados a cada risco.	2 dias

Tasks (Rastreáveis por User Story + Definition of Ready)

US1: Resumo Executivo

Descrever o objetivo da solução e o problema que ela resolve.
Listar os benefícios esperados (financeiros e operacionais).
Elaborar uma síntese dos custos e retorno estimado.
DoR: Dados do escopo e cronograma do projeto disponíveis para análise.

US2: Descrição Técnica do Projeto

Apresentar a arquitetura da solução, incluindo camadas do Data Warehouse.
Descrever as ferramentas de ETL e ferramentas de visualização (ex.: Power BI, Tableau, Metabase).
DoR: Diagrama técnico do sistema e documentação de fontes de dados disponíveis.

US3: Estimativa de Custos

Detalhar o investimento inicial, incluindo infraestrutura, licenças, desenvolvimento e treinamento.
Calcular os custos operacionais mensais, considerando hospedagem, manutenção e suporte.
Estimar os custos com pessoal, discriminando horas e valores por perfil (engenheiro de dados, analista de BI, etc.).
DoR: Dados de mercado e referência de custos disponíveis.

US4: Projeção de Benefícios Financeiros

Identificar ganhos como redução de tempo de geração de relatórios, redução de erros e melhoria nas decisões estratégicas.
Quantificar as economias com pessoal e ganhos de eficiência.
Utilizar benchmarks e hipóteses realistas para justificar estimativas.
DoR: Indicadores de performance e métricas operacionais anteriores disponíveis.

US5: Indicadores Financeiros

Calcular Payback, ROI, TCO e, opcionalmente, VPL/NPV.
Documentar as fórmulas e hipóteses adotadas nos cálculos.
Apresentar interpretação e implicações dos resultados.
DoR: Custos e benefícios validados pela pesquisa de mercado.

US6: Análise de Riscos e Premissas

Listar as premissas adotadas (volume de dados, crescimento esperado, equipe disponível).
Identificar os principais riscos (ex.: dependência de fontes externas, resistência de usuários, falhas de integração).
DoR: Versão preliminar da análise financeira e matriz de riscos do projeto disponíveis.

Épico 3: Dashboards - Versão 2

Objetivo: Implementar e validar dashboards analíticos baseados em cubos de dados, assegurando usabilidade, consistência técnica e qualidade funcional das visualizações para suporte à tomada de decisão.

User Stories

ID	História de Usuário	Prioridade (MoSCoW + Pontuação 1–5)	Responsável	Status	Critérios de Aceitação	Estimativa de Esforço
US1	Como analista de BI, quero implementar reports baseados em cubos de dados para disponibilizar indicadores e métricas consolidadas de diferentes áreas do negócio.	Must Have – 5	Eduarda Souza	Finalizado	- Reports construídos a partir dos cubos do repositório analítico. - Medidas e dimensões aplicadas corretamente. - Filtros e hierarquias configurados. -	5 dias
US2	Como designer de dados, quero criar um plano de tarefas de testes de usabilidade para validar a navegação e interação dos usuários com os painéis.	Must Have – 5	Eduarda Souza	Finalizado	- Plano de tarefas criado com cenários de interação real. - Tarefas cobrindo filtros, drill-down, comparações e cruzamentos. - Estrutura de teste documentada.	3 dias
US3	Como equipe de QA, quero executar e validar os testes de usabilidade, garantindo precisão, coerência e fluidez das visualizações.	Should Have – 4	Eduarda Souza	Finalizado	- Testes realizados com base nas tarefas definidas. - Resultados documentados e inconsistências relatadas. - Propostas de correção registradas.	4 dias
US4	Como gestor de BI, quero realizar uma avaliação da qualidade técnica e funcional dos reports, verificando clareza, coerência e aderência ao objetivo analítico.	Should Have – 4	Eduarda Souza	Finalizado	- Avaliação técnica e funcional concluída. - Critérios de clareza, consistência e fluidez atendidos. - Relatório de qualidade documentado.	3 dias

Tasks (Rastreáveis por User Story + Definition of Ready)

US1: Implementação de Reports com Base nos Cubos de Dados

Identificar cubos de dados utilizados (por tema, métrica ou área de negócio).
Definir medidas e dimensões aplicadas em cada visualização.
Configurar relacionamentos entre fatos e dimensões no modelo.
Criar filtros, segmentações e hierarquias baseadas nos cubos.
DoR: Cubos de dados disponíveis e modelo multidimensional validado.

US2: Plano de Tarefas para Testes de Usabilidade

Elaborar cenários de uso realistas para simular a interação do usuário com os painéis.
Criar tarefas envolvendo análises por filtros hierárquicos (ex.: período, região, categoria).
Incluir testes de drill-down e drill-through com base em dimensões dos cubos.
Avaliar métricas comparativas ao longo do tempo e cruzamentos entre painéis.
DoR: Reports construídos e estáveis, prontos para testes exploratórios.

US3: Execução e Validação das Tarefas

Realizar os testes de usabilidade definidos no plano de tarefas.
Verificar a precisão dos dados apresentados e a resposta dos painéis aos filtros.
Avaliar a coerência dos indicadores ao navegar entre níveis de granularidade.
Registrar limitações, erros ou lentidão observados, com análise crítica e propostas de solução.
DoR: Plano de tarefas validado.

US4: Avaliação da Qualidade Técnica e Funcional dos Reports

Verificar clareza e coerência visual das visualizações.
Analisar organização lógica dos painéis e consistência entre dados exibidos e métricas dos cubos.
Avaliar fluidez na navegação e aplicação de filtros.
Confirmar aderência dos reports ao objetivo analítico da solução.
Elaborar relatório de avaliação técnica com conclusões e recomendações.
DoR: Todos os reports concluídos.

Épico 4: Gestão Evolutiva do Projeto

Objetivo: Garantir a evolução contínua e controlada do projeto, assegurando a atualização do backlog, mensuração de métricas de desempenho, registro de retrospectivas, conformidade com o Escritório de Projetos e aplicação de políticas de gestão de configuração.

User Stories

ID	História de Usuário	Prioridade (MoSCoW + Pontuação 1–5)	Responsável	Status	Critérios de Aceitação	Estimativa de Esforço
US1	Como Product Owner, quero revisar e atualizar o backlog do projeto para refletir as entregas, prioridades e responsabilidades atuais.	Must Have – 5	Anna Aragão	Finalizado	- Backlog atualizado com épicos, user stories e tasks. - Status e responsáveis atribuídos. - Priorização revisada conforme progresso da sprint.	3 dias
US2	Como Scrum Master, quero coletar e analisar as métricas da Sprint 5 para avaliar o desempenho da equipe e a eficiência do ciclo de desenvolvimento.	Must Have – 5	Érick	Finalizado	- Throughput, Cycle Time e Burndown registrados. - Interpretação dos resultados e análise de fatores. - Documentação de metas atingidas e desvios.	3 dias
US3	Como equipe de projeto, quero realizar a retrospectiva da Sprint 5, identificando boas práticas, pontos de melhoria e ações concretas para próximas sprints.	Should Have – 4	Anna Aragão	Finalizado	- Itens positivos e negativos registrados. - Ações de melhoria definidas. - Revisão de ações anteriores documentada.	4 dias
US4	Como gestor de portfólio, quero avaliar a conformidade do projeto com os critérios do Escritório de Projetos, assegurando aderência aos padrões e boas práticas institucionais.	Should Have – 4	Anna Aragão	Finalizado	- Critérios de conformidade revisados. - Evidências apresentadas e documentadas. - Planos de correção definidos, se necessário.	2 dias
US5	Como DevOps, quero aplicar políticas de gestão de configuração para garantir controle de versões, rastreabilidade e padronização do repositório.	Must Have – 5	Anna Aragão	Finalizado	- Versionamento e branches organizados. - Histórico de mudanças documentado. - Releases e tags aplicadas corretamente.	3 dias

Tasks (Rastreáveis por User Story + Definition of Ready)

US1: Backlog Revisado

Atualizar lista de épicos, user stories e tasks com base na entrega da Sprint 5.
Atribuir status e responsáveis a cada item do backlog.
Revisar prioridades com base na matriz de valor x esforço.
DoR: Última versão do backlog disponível e consolidada no sistema de gestão de projetos.

US2: Métricas da Sprint 5

Calcular Throughput (número de histórias concluídas).
Medir Cycle Time (tempo médio por história).
Construir Burndown Chart da sprint.
Interpretar resultados e causas de desvios.
DoR: Dados de execução da sprint disponíveis no Jira ou planilha de controle.

US3: Retrospectiva da Sprint 5

Revisar objetivos e entregas da sprint.
Registrar o que funcionou bem e o que não funcionou.
Identificar ações de melhoria concretas e mensuráveis.
Revisar ações anteriores e avaliar impacto.
DoR: Métricas e atas da sprint disponíveis para análise pela equipe.

US4: Conformidade com os Critérios do Escritório de Projetos

Listar critérios exigidos pelo Escritório de Projetos.
Mapear evidências de atendimento (documentos, links, relatórios).
Registrar planos de correção para critérios pendentes.
DoR: Checklist de conformidade disponibilizado e acessível à equipe.

US5: Políticas de Gestão de Configuração

Validar controle de versões no repositório Git.
Padronizar nomenclaturas de branches e commits.
Registrar mudanças e releases com histórico no CHANGELOG.md.
Publicar tags para marcos importantes do projeto.
DoR: Repositório organizado com estrutura de versionamento validada pela equipe de DevOps.

2. Métricas da Sprint 5

Usamos o Corrello para extrair e acompanhar as métricas principais da sprint. Abaixo estão os gráficos e suas interpretações.

2.1 Velocidade por membro

Anna Aragao: 8 pontos
Eduarda Souza: 2 pontos
Erik Freundt: 4 pontos
Rafael Montenegro: 4 pontos

A distribuição mostra uma boa divisão de entregas, com Anna Aragao mantendo o maior volume, mas sem concentração extrema. O restante da equipe também apresentou produtividade estável, o que demonstra maior equilíbrio entre os membros em comparação à sprint anterior.

📈 Cumulative Flow Diagram (CFD)

O CFD mostra o acúmulo e fluxo de trabalho ao longo da sprint:

O volume de WIP se manteve baixo até o final de setembro, com crescimento visível a partir de 30 de setembro.
O pico de entregas ocorreu em 6 de outubro, com 8 cards ativos, sendo:
- 2 “Em Desenvolvimento”
- 4 “Aguardando Review”
- 2 “Em Review”

Esse comportamento indica que a equipe concentrou os esforços de desenvolvimento e revisão nos últimos dias da sprint, sugerindo acúmulo de tarefas próximo ao encerramento.

Apesar disso, não há evidências de gargalos significativos, já que o fluxo retornou ao normal no final do ciclo.

🔻 Sprint Burndown

Linha azul: progresso real.
Linha pontilhada: progresso ideal.

O gráfico mostra uma redução estável dos pontos ao longo da sprint.

Entre os dias 6 e 7 de outubro, houve uma aceleração nas entregas.
A sprint terminou com todas as histórias concluídas.
Foram 10 pontos completados, 6 adicionados, e 0 removidos.

O comportamento indica boa adaptação e resposta rápida a ajustes de escopo, mantendo o ritmo de entrega e evitando acúmulos críticos no final.

🚀 Release Forecast (Burnup)

Linha amarela: escopo total planejado.
Linha azul: progresso de entregas.

O gráfico mostra que o escopo total subiu rapidamente até o dia 29 de setembro e permaneceu estável até o final da sprint.
As entregas (linha azul) cresceram de forma gradual, com aceleração entre os dias 6 e 8 de outubro, alcançando o escopo planejado.

O resultado mostra execução consistente, com o time conseguindo entregar tudo o que estava previsto, sem aumento de escopo relevante na reta final.

🔄 Cycle Time

50% dos cards concluídos em até 1 dia.
85% dos cards concluídos em até 2 dias.
95% dos cards concluídos em até 3 dias.

Por lista:

Em Desenvolvimento: 50% em até 1 dia, podendo chegar a 6 dias em casos isolados.
Aguardando Review: 85% finalizados em até 1 dia.
Em Review: todos concluídos em 1 a 2 dias.

Esses números demonstram alta eficiência do fluxo de desenvolvimento, com pouquíssimos outliers e baixa variação de tempo entre as etapas.

📐 Análise da Sprint

Interpretação Quantitativa

O Throughput foi estável, com todas as user stories concluídas dentro da sprint.
O Cycle Time médio ficou em torno de 2 dias, mostrando agilidade e consistência na execução.
O Burndown Chart indica que as tarefas foram finalizadas de forma contínua, com aceleração natural próxima ao encerramento.
O CFD mostrou boa fluidez de tarefas, com picos controlados e rápido escoamento do WIP.

Interpretação Qualitativa

O time manteve um ritmo constante de entrega e melhor equilíbrio entre membros.
Houve maior previsibilidade na execução, refletida na estabilidade do burndown e na baixa variação do cycle time.
As revisões foram feitas de forma rápida, com bom tempo de resposta entre etapas.
A equipe mostrou maturidade no fluxo, evitando bloqueios e sobrecarga.

Justificativas por Épico

Épico 1 – Documentação Técnica do Projeto: aproximadamente 6 dias, com foco na atualização completa da documentação com foco no detalhamento dos processos de desenvolvimento para garantir maior clareza e rastreabilidade.
Épico 2 – Análise Financeira do Projeto: cerca de 10 dias, voltado à consolidação dos dados financeiros, análise de indicadores de custo-benefício, projeções de retorno e elaboração de relatórios interpretativos para apoio à tomada de decisão.
Épico 3 – Dashboards - Versão 2: aproximadamente 12 dias, dedicado à ajustes visuais e melhorias, garantindo melhor usabilidade e consistência dos dados apresentados.
Épico 4 – Gestão Evolutiva do Projeto: cerca de 8 dias, focado em revisão do backlog, priorização de tarefas, definição de critérios de aceite e acompanhamento de métricas de desempenho da equipe.

✅ Conclusões da Sprint 4

A equipe entregou todo o escopo planejado com consistência e previsibilidade.
Houve boa distribuição de tarefas entre os membros, sem concentração excessiva.
O cycle time curto reflete alta eficiência operacional e bom fluxo de trabalho.
O CFD e o Burndown mostram que o time evitou gargalos e conseguiu manter ritmo constante.
Recomenda-se manter esse padrão de execução, reforçando práticas de revisão rápida e fluxo contínuo.

3. Retrospectiva da Sprint 5

Segue a documentação detalhada das atividades essenciais da sprint, incluindo tabelas para melhor visualização.

Revisão dos objetivos do projeto

Objetivo	Status	Observações
Atualizar e padronizar a documentação técnica do projeto	Concluído	Todas as seções principais documentadas e revisadas
Consolidar análise financeira do projeto	Concluído	Indicadores calculados e relatórios apresentados
Melhorar dashboards e filtros analíticos	Concluído	Ajustes de feedbacks anteriores aplicados
Revisar backlog e priorizar tarefas	Concluído	Critérios de aceite definidos e tarefas organizadas

Observação: Todos os entregáveis planejados foram concluídos.

Análise do que funcionou bem

Aspecto	Prática / Contribuição	Impacto
Comunicação	Daily meetings diárias revisitando gargalos e solicitando apoio	Redução de atrasos e alinhamento constante
Usabilidade	Érick realizou testes de usabilidade	Feedback rápido sobre ajustes necessários
Organização	Duda organizou tarefas e apoiou com slides e revisões	Maior clareza nos entregáveis e processo
Desenvolvimento	Rafael implementou funcionalidades adicionais (Soundex)	Enriquecimento do produto final
Gestão	Anna geriu esforços e garantiu qualidade	Equilíbrio entre prazo e entregáveis de alta qualidade

Conclusão: As boas práticas de comunicação ativa e divisão clara de responsabilidades foram determinantes para o sucesso da sprint.

Identificação do que não funcionou bem

Problema	Causa	Consequência
Revisões realizadas em cima da hora	Falta de planejamento detalhado das revisões	Maior pressão e risco de retrabalho
Dificuldade de foco	Semana de provas coincidiu com a sprint	Redução de atenção em algumas tarefas
Falta de recursos	Conta Microsoft limitada para Power BI	Impedimento em explorar funcionalidades avançadas como segurança no dashboard

Sugestões de melhoria

Sugestão	Como implementar	Benefício esperado
Apoio proativo entre membros	Criar check-ins adicionais quando sobrecarga é identificada	Distribuição equilibrada de tarefas
Foco em reviews	Reservar tempo específico para revisão de entregáveis	Garantia de qualidade consistente
Checklists de qualidade	Criar checklist padrão para cada user story	Redução de erros e retrabalho

Análise de métricas e dados

Métrica	Valor / Observação	Interpretação
Throughput	Todas as user stories concluídas	Capacidade de entrega estável
Cycle Time médio	~2 dias	Agilidade e consistência na execução
Burndown Chart	Entregas contínuas, aceleração no final	Boa execução e cumprimento de prazos
CFD	Boa fluidez de tarefas, picos controlados	Equilíbrio entre WIP e escoamento de atividades

Obs: Toda a Análise de métricas e dados foi realizada na seção 2. Métricas da Sprint 5. Temos aqui somente uma visão geral de todo o deep dive realizado anteriormente

Seleção de ações de melhoria

Implementar suporte proativo entre membros em sobrecarga;
Aumentar foco em revisões de entregáveis para garantir qualidade;
Criar checklists de qualidade antes da entrega final de cada user story.

Revisão de ações de retrospectivas anteriores

Ação Anterior	Implementada?	Impacto
Melhorar comunicação diária	Sim	Redução de gargalos e alinhamento constante
Priorização do backlog	Sim	Maior clareza nas entregas e eficiência
Revisão de entregáveis	Sim	Qualidade aumentada e menos retrabalho

Conclusão Geral: A sprint 5 foi bem-sucedida, com todos os entregáveis concluídos, boa organização, comunicação ativa e métricas consistentes que indicam eficiência e qualidade no trabalho da equipe.

Quadro Kanban

O acompanhamento da Sprint 5 será feito pelo Trello:
Link do quadro de gestão no Trello

4. Conformidade com os Critérios do Escritório de Projetos

Abaixo apresentamos a análise de conformidade do grupo 1 em relação aos critérios definidos pelo Escritório de Projetos.

Obs: Foi adicionado o Sumário de todos os .md que temos no projeto em docs

Checklist de Conformidade

Estrutura dos Repositórios

README do Repositório de Documentação

README dos Repositórios de Desenvolvimento

É possível verificar e analisar a conformidade em nosso repositório: Link do repositório

Interpretação e Planos de Correção

Atendidos: A estrutura de pastas, documentação e organização do repositório já está em conformidade.

5. Políticas de Gestão de Configuração

As políticas de gestão de configuração foram atualizadas, incorporando convenções e formalizações para garantir padronização, rastreabilidade e boas práticas de desenvolvimento.

1. Controle de Versões dos Documentos

Uso de Git para versionamento.
Pull Requests revisadas antes do merge.
Evidências: Exemplo de Pull Request revisada

2. Convenções de Branches e Integração

Branch main → versões estáveis.
Branch develop → integração de features prontas.
Branches dedicadas:
- feature/<nome> → novas funcionalidades.
- hotfix/<nome> → correção de bugs críticos.
- docs/<nome> → novas documentações.
Pull Requests obrigatórios para merges em develop ou main.
Evidências: Branches do repositório

3. Convenções de Commit

Mensagens de commit seguem Conventional Commits:
- feat: → nova funcionalidade
- fix: → correção de bug
- docs: → atualização de documentação
- chore: → tarefas administrativas ou de build
- refactor: → refatoração sem mudança de comportamento
Exemplos:
- feat: adicionar pipeline ETL automatizado
- fix: corrigir bug na extração de dados
- docs: atualizar instruções do README

4. Tags

Criação de tags para marcar versões específicas do código no repositório.
Convenção de nomenclatura: v<versão> (ex.: v1.0.0)
Uso de tags:
- Identificação de versões estáveis
- Referência em releases
Evidências: Todas as tags recentes seguem a nomenclatura padrão.

_{Figura x: Tags}

^{Fonte: Grupo 1 (2025)}

A tag v.0.5.0 foi adiciona após a finalização de todos os artefatos na main. Podem conferir em AQUI

5. Releases

Criação de releases no GitHub a partir das tags.
Convenção de nomenclatura de releases: Release v<versão>
Plano de Correção Atual: Garantir que todas as releases a partir desta sprint possuam changelog completo.

_{Figura x: Releases}

^{Fonte: Grupo 1 (2025)}

A Release da Sprint 5 foi adiciona após a finalização de todos os artefatos na main. Podem conferir em AQUI

6. Arquivos de Governança

CONTRIBUTING.md

O arquivo CONTRIBUTING.md define regras claras para contribuições no projeto, incluindo:

Padrões de Branch:
- main: versão estável do projeto.
- develop: branch de integração de features.
- feature/<nome-da-feature>: desenvolvimento de novas funcionalidades.
- hotfix/<nome-do-hotfix>: correção rápida de bugs em produção.
Padrões de Commit:
- Mensagem de commit no formato tipo: descrição curta.
- Tipos recomendados: feat, fix, docs, style, refactor, test, chore.
Checklist de Pull Requests:
- Código revisado e testado.
- Documentação atualizada.
- Nenhum conflito com a branch develop.
- Todas as tasks associadas à user story concluídas.
Testes: Instruções para rodar testes automatizados e garantir integridade do código.
Comunicação: Orientações sobre como abrir PRs e reportar issues de forma padronizada.

CODEOWNERS

O projeto define revisores obrigatórios por tipo de responsabilidade, e não por diretório:

Revisão de código: qualquer PR deve ser revisado por pelo menos um dos membros da equipe.
- Anna Aragão → revisões de modelagem e código ETL.
- Rafael Coutinho → revisões de governança de dados e políticas.
- Eduarda Souza → revisões de dashboards e visualizações.
Objetivo: garantir qualidade, consistência e rastreabilidade das alterações sem depender de diretórios específicos.

7. Templates para PRs e Issues

Pull Request Template

## Descrição
Explicação do que foi adicionado no PR

## Responsáveis
- Autor da PR: Nome da pessoa que criou a PR 
- Revisor(es) designado(s): Nome(s) do(s) membro(s) responsável(is) pela revisão

FilesExpand file tree

Gestão-Evolutiva-do-Projeto-Sprint-5.md

Latest commit

History

Gestão-Evolutiva-do-Projeto-Sprint-5.md

File metadata and controls

1. Backlog Revisado

Épico 1: Documentação Técnica do Projeto

User Stories

Tasks (Rastreáveis por User Story + Definition of Ready)

Épico 2: Análise Financeira do Projeto

User Stories

Tasks (Rastreáveis por User Story + Definition of Ready)

Épico 3: Dashboards - Versão 2

User Stories

Tasks (Rastreáveis por User Story + Definition of Ready)

Épico 4: Gestão Evolutiva do Projeto

User Stories

Tasks (Rastreáveis por User Story + Definition of Ready)

2. Métricas da Sprint 5

2.1 Velocidade por membro

📈 Cumulative Flow Diagram (CFD)

🔻 Sprint Burndown

🚀 Release Forecast (Burnup)

🔄 Cycle Time

📐 Análise da Sprint

Interpretação Quantitativa

Interpretação Qualitativa

Justificativas por Épico

✅ Conclusões da Sprint 4

3. Retrospectiva da Sprint 5

Revisão dos objetivos do projeto

Análise do que funcionou bem

Identificação do que não funcionou bem

Sugestões de melhoria

Análise de métricas e dados

Seleção de ações de melhoria

Revisão de ações de retrospectivas anteriores

Quadro Kanban

4. Conformidade com os Critérios do Escritório de Projetos

Checklist de Conformidade

Estrutura dos Repositórios

README do Repositório de Documentação

README dos Repositórios de Desenvolvimento

Interpretação e Planos de Correção

5. Políticas de Gestão de Configuração

1. Controle de Versões dos Documentos

2. Convenções de Branches e Integração

3. Convenções de Commit

4. Tags

5. Releases

6. Arquivos de Governança

CONTRIBUTING.md

CODEOWNERS

7. Templates para PRs e Issues

Pull Request Template