1. Backlog Revisado

O grupo 1 revisou e atualizou o backlog do projeto durante a 3ª sprint do dia 01/09/2025 até o dia 12/09/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: Anna Aragão, Eduarda Souza e Rafael Coutinho dividindo Pipeline ETL, Anna Aragão e Rafael Coutinho com governança de dados e Anna Aragão à frente da gestão evolutiva do projeto.

Épico 1: Governança de Dados do Projeto - versão 2

Objetivo: Documentar a segunda versão da estrutura de governança de dados, assegurando qualidade, segurança, rastreabilidade e alinhamento com boas práticas e normas regulatórias.

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 gestor de dados, quero mapear a estrutura organizacional da governança para atribuir papéis claros no ciclo de vida dos dados.	Must Have – 5	Anna Aragão	Finalizado	- Papéis de Data Owner, Steward e Custodian atribuídos e validados. - Organograma documentado no repositório.	3 dias
US2	Como responsável de qualidade, quero definir a política de qualidade de dados para garantir consistência, acurácia e confiabilidade.	Must Have – 5	Rafael Coutinho	Finalizado	- Lista de atributos de qualidade documentada. - KPIs de qualidade definidos e validados. - Ações corretivas mapeadas.	4 dias
US3	Como analista, quero gerenciar metadados e catálogo de dados para facilitar rastreabilidade e reutilização.	Must Have – 5	Rafael Coutinho	Finalizado	- Catálogo publicado em ferramenta definida. - Metadados obrigatórios listados e preenchidos em tabela de exemplo.	4 dias
US4	Como gestor de compliance, quero classificar e proteger os dados sensíveis conforme LGPD e boas práticas.	Must Have – 5	Anna Aragão	Finalizado	- Categorias de dados documentadas. - Critérios de classificação bem mapeados.	3 dias
US5	Como administrador de sistemas, quero definir políticas de segurança e acesso para proteger os dados do projeto.	Should Have – 4	Anna Aragão	Finalizado	- Perfis de acesso documentados. - Políticas de autenticação e segregação descritas.	3 dias
US6	Como analista, quero descrever o ciclo de vida dos dados para garantir rastreabilidade desde a ingestão até o descarte.	Should Have – 4	Anna Aragão	Finalizado	- Modelo do ciclo de vida descrito com texto e diagrama. - Reuso e rastreabilidade documentados.	3 dias
US7	Como gerente de governança, quero avaliar a maturidade em governança de dados para identificar gaps e planos de melhoria.	Could Have – 3	Rafael Coutinho	Finalizado	- Modelo de referência escolhido (ex.: DAMA-DMBOK). - Diagnóstico documentado com níveis de maturidade. - Plano de evolução detalhado.	4 dias

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

US1: Estrutura Organizacional da Governança de Dados

Levantar papéis de Data Owner, Steward e Custodian.
Mapear responsáveis por metadados, catálogo, qualidade, segurança e compliance.
Construir organograma e validar com stakeholders.
DoR: Lista de stakeholders validada e rascunho de organograma disponível para revisão.

US2: Política de Qualidade de Dados

Listar atributos de qualidade (acurácia, completude, consistência etc.).
Definir KPIs e metas mínimas.
Especificar ações corretivas.
DoR: Catálogo inicial mapeado com benchmarks de qualidade prontos para definição dos KPIs.

US3: Gestão de Metadados e Catálogo de Dados

Definir ferramenta de catalogação.
Criar lista de metadados obrigatórios.
Elaborar tabela de exemplo com metadados.
DoR: Ferramenta escolhida e dataset exemplo carregado para validação da estrutura de metadados.

US4: Classificação de Dados e Proteção

Definir categorias de dados.
Estabelecer critérios de classificação.
Mapear controles técnicos e organizacionais.
DoR: Normas regulatórias revisadas e dataset piloto preparado para testes de classificação.

US5: Segurança e Acesso aos Dados

Definir perfis de acesso.
Documentar segregação por camadas.
Listar práticas de segurança.
DoR: Arquitetura aprovada com requisitos de segurança incorporados às camadas de acesso.

US6: Ciclo de Vida dos Dados

Modelar ciclo de vida (diagrama ou texto).
Definir prazos de retenção e descarte.
Especificar regras de reuso e rastreabilidade.
DoR: Tipos de dados catalogados e políticas de retenção revisadas para definição do ciclo de vida.

US7: Avaliação de Maturidade em Governança

Selecionar modelo de referência.
Aplicar diagnóstico no parceiro.
Elaborar plano de evolução.
DoR: Modelo de maturidade definido e entrevistas agendadas para aplicação do diagnóstico.

Épico 2: Pipeline ETL - versão 1

Objetivo: Desenvolver um pipeline ETL modular e rastreável, com monitoramento, integração contínua e alinhamento às boas práticas de engenharia de dados.

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 desenvolvedor, quero extrair dados de múltiplas fontes para alimentar o Data Warehouse com informações atualizadas.	Must Have – 5	Rafael Coutinho	Finalizado	- Dados extraídos de APIs, bancos e arquivos. - Logs de extração registrados.	4 dias
US2	Como desenvolvedor, quero transformar os dados com limpeza, validação e padronização para garantir consistência.	Must Have – 5	Rafael Coutinho e Eduarda Souza	Finalizado	- Dados transformados conforme regras definidas. - Erros registrados e tratados.	2 dias
US3	Como desenvolvedor, quero carregar os dados processados no Data Warehouse para disponibilizá-los para análise.	Must Have – 5	Rafael Coutinho	Finalizado	- Dados carregados corretamente nas tabelas destino. - Integridade dos dados verificada.	3 dias
US4	Como engenheiro de dados, quero orquestrar as tarefas ETL usando DAGs para automatizar a execução e monitorar falhas.	Must Have – 5	Anna Aragão e Rafael Coutinho	Finalizado	- DAGs definidas e agendadas. - Logs e alertas funcionando.	2 dias
US5	Como engenheiro de DevOps, quero integrar o pipeline com CI para validar alterações automaticamente.	Should Have – 4	Anna Aragão	Finalizado	- Pipeline CI acionado em push ou PR. - Testes unitários e de integração executados.	3 dias
US6	Como analista de operações, quero monitorar métricas e logs para garantir observabilidade do pipeline ETL.	Should Have – 4	Rafael Coutinho	Finalizado	- Métricas de execução, volume e status disponíveis. - Painel de monitoramento configurado.	3 dias
US7	Como arquiteto de dados, quero documentar a arquitetura e fluxos ETL para referência e manutenção futura.	Could Have – 3	Anna Aragão	Finalizado	- Diagramas UML entregues. - Documentação das visões de negócio, informação, computacional, engenharia e tecnologia completa.	1 dia

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

US1: Extração de Dados

Conectar e extrair dados de APIs, bancos e arquivos.
Registrar logs de execução e erros.
DoR: Acesso às fontes de dados disponíveis.

US2: Transformação de Dados

Limpar, validar e padronizar os dados extraídos.
Tratar inconsistências e erros.
DoR: Regras de transformação documentadas e dataset de teste disponível.

US3: Carga de Dados no Data Warehouse

Inserir dados nas tabelas destino.
Validar integridade e consistência.
DoR: Estrutura de tabelas destino criada e permissões de escrita concedidas.

US4: Orquestração com DAGs

Criar DAGs para agendamento das tarefas ETL.
Implementar monitoramento de execução e alertas.
DoR: Ferramenta de orquestração instalada e pipeline de teste definido.

US5: Integração Contínua (CI)

Configurar CI para rodar testes automaticamente.
Validar execução do pipeline a cada alteração.
DoR: Repositório configurado com CI habilitado e testes unitários implementados.

US6: Observabilidade

Coletar métricas de execução, volume e status.
Configurar painel de monitoramento (Grafana ou equivalente).
DoR: Acesso à ferramenta de monitoramento configurado e métricas instrumentadas no código.

US7: Documentação e Arquitetura

Criar diagramas UML (Casos de Uso, Componentes e Sequência).
Documentar visões de negócio, informação, computacional, engenharia e tecnologia.
DoR: Estrutura de documentação definida e templates para diagramas disponíveis.

Épico 3: Gestão Evolutiva do Projeto - versão 1

Objetivo: Garantir atualização contínua do backlog, monitoramento da sprint e conformidade com critérios de gestão de projetos para assegurar eficiência e rastreabilidade.

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
US8	Como gerente de projeto, quero revisar e atualizar o backlog para garantir que todas as features e user stories estejam alinhadas ao planejamento do projeto.	Must Have – 5	Anna Aragão	Finalizado	- Backlog atualizado com todas as features e user stories. - Prioridades revisadas e aprovadas pelo time.	3 dias
US9	Como analista de métricas, quero calcular e apresentar as métricas da Sprint 3 para avaliar performance e identificar melhorias.	Must Have – 5	Anna Aragão	Finalizado	- Throughput, Cycle Time e Burndown Chart apresentados. - Interpretação dos resultados documentada.	2 dias
US10	Como planejador de sprints, quero atualizar o planejamento da Sprint 4 considerando aprendizados da Sprint 3 para otimizar execução.	Must Have – 5	Anna Aragão	Finalizado	- User stories selecionadas e tasks planejadas. - Quadro Kanban atualizado ou link para ferramenta de gestão disponível.	2 dias
US11	Como auditor de processos, quero verificar conformidade com os critérios do Escritório de Projetos para assegurar aderência a boas práticas.	Should Have – 4	Anna Aragão	Finalizado	- Checklist de conformidade preenchido. - Plano de correção de não conformidades registrado.	1 dia
US12	Como responsável pela configuração do projeto, quero aplicar políticas de gestão de configuração para manter controle e rastreabilidade de documentos e código.	Should Have – 4	Anna Aragão	Finalizado	- Controle de versões, histórico de mudanças e convenções de repositório aplicados. - Evidências documentadas (commits, PRs, tags).	2 dias

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

US8: Backlog Revisado

Revisar todas as features e user stories existentes.
Atualizar prioridades e status.
DoR: Lista completa de features e user stories disponível e backlog acessível no repositório/ferramenta de gestão.

US9: Métricas da Sprint 3

Coletar dados de throughput, cycle time e burndown.
Gerar gráficos e interpretação dos resultados.
DoR: Histórico de tarefas da sprint 3 disponível e ferramenta de métricas configurada.

US10: Planejamento da Sprint 4

Selecionar user stories e detalhar tasks para execução.
Atualizar quadro Kanban ou ferramenta de gestão.
DoR: Sprint 3 finalizada e lições aprendidas documentadas.

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

Avaliar aderência a políticas e critérios estabelecidos.
Registrar plano de correção para gaps identificados.
DoR: Critérios do Escritório de Projetos revisados e checklist de auditoria preparado.

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

Aplicar controle de versões, histórico de mudanças e padronização de nomenclaturas.
Registrar evidências de commits, tags e pull requests.
DoR: Repositório configurado e acessível, convenções documentadas e aprovadas.

2. Métricas da Sprint 3

_{Figura x: Métricas da Sprint 3}

^{Fonte: Grupo 1 (2025)}

Work in Progress (WIP)

O WIP médio foi calculado com base no esforço total em dias dividido pela duração da sprint:

WIP = Esforço total em dias ÷ Duração da Sprint
WIP = 38 ÷ 14 ≈ 2,71

Isso significa que, em média, 2,7 histórias estavam em progresso por dia.

Interpretação:

Havia raramente mais de 3 histórias em paralelo.
A equipe manteve um nível de concorrência moderado, priorizando foco e conclusão de tarefas.
O WIP foi adequado, pois todas as user stories foram entregues dentro da sprint.

Dados Coletados

A coleta de dados para métricas da Sprint foi realizada manualmente. A seguir, apresentamos os dados quantitativos e uma interpretação qualitativa do desempenho.

Se quiser ver de forma exaustiva o Google Colab

Métrica	Valor	Observações
Throughput (User Stories)	19 USs concluídas	Todas as User Stories planejadas foram finalizadas.
Cycle Time	2,74 dias (média)	Cada user story levou, em média, 2,74 dias para ser concluída.
Burndown Chart	Disponível	O gráfico reflete o ritmo de trabalho real da equipe, evidenciando progresso gradual ao longo da sprint de 14 dias.
WIP (Work in Progress)	2,7 por dia	O WIP médio foi calculado dividindo o esforço total (38 dias) pela duração da sprint (14 dias), indicando que, em média, 2 a 3 histórias estavam em andamento simultaneamente.

Interpretação Quantitativa

O Throughput demonstra que todas as US planejadas foram concluídas, mantendo a capacidade de entrega da equipe.
O Cycle Time médio de 2,74 dias mostra eficiência na conclusão das user stories, considerando a complexidade variada.
O Burndown Chart apresenta a evolução diária das tarefas concluídas, evidenciando a finalização gradual das user stories ao longo da sprint.
O WIP (Work in Progress) foi de 2,7 histórias por dia, indicando que a equipe conseguiu gerenciar múltiplas histórias em paralelo sem comprometer a entrega.

Interpretação Qualitativa

A equipe manteve foco e consistência na execução das tarefas, equilibrando o ritmo de trabalho entre as semanas.
Na primeira semana, o progresso foi mais lento, mas houve aceleração na segunda semana, garantindo a conclusão de todo o esforço planejado.
A sprint mostrou que a equipe consegue entregar todas as user stories dentro do prazo, mesmo com variação na velocidade diária.

Justificativas por Épico

Épico 1 – Governança de Dados: aproximadamente 6 dias, abrangendo políticas, catálogos e classificações.
Épico 2 – Pipeline ETL: cerca de 20 dias, devido às tarefas de extração, transformação, carga e orquestração.
Épico 3 – Gestão Evolutiva do Projeto: concluído em 12 dias, incluindo revisão de backlog, métricas e planejamento da próxima sprint.

3. Planejamento da Sprint 4

Com base nos aprendizados da Sprint 3, o planejamento da Sprint 4 busca evoluir a governança de dados e aprimorar o pipeline ETL, incluindo dashboards analíticos e integração contínua. O foco está em finalizar a ETL e gerar dashboards com observabilidade.

Objetivos da Sprint 4

Pipeline ETL v2: Atualizar e otimizar o pipeline ETL com integração contínua, orquestração de DAGs e observabilidade aprimorada.
Dashboards v1: Implementar reports baseados em cubos de dados, testar e validar a usabilidade e qualidade técnica.
Gestão Evolutiva do Projeto: Revisar backlog, consolidar métricas da sprint, planejar a próxima etapa e garantir conformidade com padrões do Escritório de Projetos.
Boas Práticas e Entregáveis de Arquitetura: Garantir código limpo, modular e documentação de arquitetura completa.

User Stories e Planejamento

ID	História de Usuário	Épico	Prioridade (MoSCoW + 1–5)	Estimativa (dias)	Responsável	Capacidade Estimada (dias/pessoa)	Dependências	Métricas Impactadas	Critério de Aceitação
US1	Atualizar pipeline ETL para versão 2, incluindo módulos de processamento, orquestração, integração contínua e observabilidade.	Pipeline ETL - v2	Must (5)	10	Rafael Coutinho, Eduarda Souza	Rafael: 5, Eduarda: 5	US31 (Sprint 3)	Tempo médio de execução ETL, % de falhas de pipeline, cobertura de testes	Pipeline funcionando com monitoramento ativo, CI configurada, DAGs orquestradas e testes automatizados executados.
US2	Implementar dashboards analíticos com base em cubos de dados, garantindo qualidade e usabilidade.	Dashboards v1	Should (4)	7	Rafael Coutinho, Eduarda Souza, Anna Aragão	Rafael: 2, Eduarda: 3, Anna: 2	US41	Tempo de geração de reports, satisfação do usuário (testes de usabilidade), % de dashboards validados	Reports implementados, validados com testes de usabilidade, feedback registrado e ajustes realizados.
US3	Consolidar métricas da Sprint 4 e planejar a próxima etapa para garantir evolução contínua do projeto.	Gestão Evolutiva do Projeto	Must (5)	3	Anna Aragão, Érick	Anna: 2, Érick: 1	US41, US42	Métricas de sprint consolidadas, backlog atualizado, conformidade com critérios do Escritório de Projetos	Métricas coletadas, backlog revisado, planejamento da Sprint 5 definido e conformidade verificada.

Tasks Planejadas por User Story

US1 - Pipeline ETL v2

Task	Descrição	Responsável	Estimativa (dias)	Dependências	Métricas Impactadas
Módulo de Processamento ETL	Desenvolver e otimizar transformações de dados	Rafael Coutinho, Eduarda Souza	4	-	Tempo médio de execução ETL, % de erros de transformação
Gerenciador de DAGs	Configurar orquestração de workflows com Prefect	Rafael Coutinho	2	Módulo de Processamento ETL	% de DAGs executadas com sucesso, tempo de execução
Integração Contínua (CI)	Configurar pipeline CI/CD para deploy do ETL	Eduarda Souza	2	Módulo de Processamento ETL	Tempo de deploy, % de falhas no build
Observabilidade e Monitoramento	Implementar logging, métricas e alertas	Rafael Coutinho	2	Gerenciador de DAGs	Cobertura de monitoramento, tempo de resposta a alertas
Testes Automatizados	Criar e executar testes unitários e de integração	Eduarda Souza	3	Módulo de Processamento ETL	Cobertura de testes, % de testes aprovados
Entregáveis de Arquitetura e Modelagem	Documentar arquitetura em camadas e modelagem de dados	Érick	2	Módulo de Processamento ETL	Conformidade da documentação, rastreabilidade de dados
Boas Práticas de Código	Revisão e padronização do código	Rafael Coutinho	1	Entregáveis de Arquitetura	Linhas de código limpas, padronização aplicada

US2 - Dashboards v1

Task	Descrição	Responsável	Estimativa (dias)	Dependências	Métricas Impactadas
Implementação de Reports	Criar dashboards baseados em cubos de dados	Rafael Coutinho, Eduarda Souza	3	US41 - Pipeline ETL v2	Tempo de geração de reports, % de dados corretos
Plano de Tarefas para Testes	Definir cenários e critérios de usabilidade	Anna Aragão	1	Implementação de Reports	Número de cenários testados
Execução e Validação	Realizar testes de usabilidade e qualidade	Anna Aragão	2	Plano de Tarefas para Testes	Satisfação do usuário, número de bugs encontrados
Ajustes e Feedback	Incorporar ajustes após feedback	Rafael Coutinho, Eduarda Souza	1	Execução e Validação	% de ajustes concluídos
Avaliação Técnica	Revisar qualidade técnica dos reports	Érick	1	Ajustes e Feedback	Conformidade técnica, aderência a padrões de BI

US3 - Gestão Evolutiva

Task	Descrição	Responsável	Estimativa (dias)	Dependências	Métricas Impactadas
Backlog Revisado	Atualizar backlog com novas USs e tasks	Anna Aragão, Érick	1	US41, US42	% de backlog atualizado
Métricas da Sprint 4	Coletar e analisar métricas de desempenho	Anna Aragão	1	Backlog Revisado	Métricas consolidadas, indicadores de performance
Planejamento da Sprint 5	Definir objetivos e escopo da próxima sprint	Anna Aragão	1	Métricas da Sprint 4	Planejamento completo e alinhado com KPIs
Conformidade	Revisar critérios do Escritório de Projetos	Érick	1	Planejamento da Sprint 5	% de conformidade atendida
Políticas de Gestão de Configuração	Atualizar políticas existentes	Érick	1	Conformidade	% de políticas aplicadas

Critérios de Pronto (Definition of Done)

Item	Critério
Código	Pipeline ETL v2 funcionando com CI/CD, DAGs orquestradas, testes automatizados e boas práticas aplicadas
Dashboards	Reports implementados, testados em usabilidade e qualidade técnica, feedback incorporado
Documentação	Arquitetura, modelagem e políticas documentadas, revisadas e publicadas por Érick
Métricas	Métricas da sprint coletadas, analisadas e apresentadas, vinculadas às USs correspondentes
Revisão	Reunião de revisão da sprint realizada com registro de feedback
Repositórios	Repositórios atualizados conforme checklist do Escritório de Projetos

Distribuição da Carga de Trabalho, Capacidade e Sequenciamento

Capacidade estimada total da equipe:
- Rafael Coutinho: 7 dias
- Eduarda Souza: 8 dias
- Anna Aragão: 6 dias
- Érick: 5 dias
Sequenciamento justificado:
- ETL v2 deve ser concluído antes de dashboards, garantindo que os cubos de dados estejam corretos.
- Métricas e planejamento dependem da conclusão das entregas técnicas e analíticas.
Vínculo com métricas:
- Cada US e task possui indicadores claros de performance, qualidade ou satisfação de usuário.
- Garantia de rastreabilidade entre entregáveis e resultados medidos, permitindo evolução contínua.

Quadro Kanban

O acompanhamento da Sprint 4 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.

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 maior parte da estrutura de pastas, documentação e organização do repositório já está em conformidade.
Pontos a melhorar:
- Completar o histórico de lançamentos ao final do módulo.

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.3.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 3 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-3.md

Latest commit

History

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

File metadata and controls

1. Backlog Revisado

Épico 1: Governança de Dados do Projeto - versão 2

User Stories

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

Épico 2: Pipeline ETL - versão 1

User Stories

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

Épico 3: Gestão Evolutiva do Projeto - versão 1

User Stories

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

2. Métricas da Sprint 3

Work in Progress (WIP)

Dados Coletados

Interpretação Quantitativa

Interpretação Qualitativa

Justificativas por Épico

3. Planejamento da Sprint 4

Objetivos da Sprint 4

User Stories e Planejamento

Tasks Planejadas por User Story

US1 - Pipeline ETL v2

US2 - Dashboards v1

US3 - Gestão Evolutiva

Critérios de Pronto (Definition of Done)

Distribuição da Carga de Trabalho, Capacidade e Sequenciamento

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