Pular para o conteúdo principal

10.2 Lições Aprendidas


Retrospectiva da Unidade 2 — IT2: Vitrine Pública

Esta seção registra as lições aprendidas ao longo da segunda unidade do projeto Crianex (IT2 — Vitrine Pública), com foco na consolidação dos requisitos, estruturação do backlog e alinhamento da aplicação da metodologia FDD.


Tabela de Lições Aprendidas

CategoriaLição AprendidaAção Corretiva
Processo e MetodologiaA Engenharia de Requisitos descrevia as cerimônias das etapas 1–3 do FDD como se fossem iterativas, gerando confusão sobre o que se repete a cada iteração e o que ocorre somente no início do projetoReescrever a seção 4 separando explicitamente etapas únicas (1–3) das etapas iterativas (4–5); deixar claro no processo que Domain Modeling, Feature Discovery e Plan by Feature são fundação única do projeto
Entregas em SalaTivemos que mudar nosso modelo de captação de requisitos, para atender as necessidade da matéria de requisitos, uma vez que o professor exigiu todos os requisitos prontos e rastráveis para a apresentaçãoFizemos uma reunião rápida com o cliente para para ouvir as necessidades e desejos das CPs de outras iterações e então poder montar a rastreabilidade delas
RastreabilidadeA numeração e os nomes das Características de Produto (CPs) apresentavam inconsistências entre o arquivo solucao.md e o rastreabilidade.md, causando divergência nos mapeamentos de features e RFsDefinir um único arquivo como fonte da verdade para cada tipo de artefato e registrá-lo explicitamente no CLAUDE.md; qualquer atualização deve ser propagada a partir da fonte, não feita isoladamente em cada arquivo
Backlog e RequisitosO backlog foi estruturado inicialmente com Épicos e User Stories ao invés do formato FDD (Feature Sets → Features → RFs com rastreabilidade OE→CP→Feature→RF)Restruturar o backlog seguindo a hierarquia FDD com Feature List, tabela de RFs rastreáveis e cenários BDD; usar a rastreabilidade.md como documento central
Backlog e RequisitosAs iterações dentro do backlog tinham mapeamentos de CPs incorretos, divergindo do cronograma oficial definido em cronograma.mdSempre consultar cronograma.md como fonte da verdade para a distribuição de CPs por iteração; não preencher iterações no backlog sem confirmar com o cronograma
Gestão do TempoA organização dos artefatos de documentação (er.md, backlog, iterações) foi deixada para o final da unidade, gerando acúmulo de ajustes no prazo de entregaDefinir no Iteration Commitment quais artefatos de documentação precisam ser atualizados e atribuir responsáveis com prazo intermediário, não apenas no Artifact Closure

O que foi bem

#Ponto positivo
1A infraestrutura de documentação (MkDocs, GitHub Pages, estrutura de pastas) funcionou de forma estável durante toda a unidade
2A tabela de rastreabilidade OE → CP → Feature → RF/RNF foi construída de forma completa e coerente, cobrindo todos os 47 RFs e 24 RNFs do produto
3A separação da lição aprendida sobre as etapas únicas vs. iterativas do FDD aumentou a clareza do processo para toda a equipe
4A estrutura de evidências de entrega foi adicionada a todas as iterações, preparando o registro formal de validações para as próximas entregas
5O contexto do projeto foi organizado e segmentado adequadamente, facilitando o trabalho incremental nas próximas iterações

Ações até a Próxima Unidade — IT2: Lead Capture

AçãoResponsávelPrazo
Continuar a IT1 entregando as funcionalidadesTodos25/05
Dar andamento as cerimônias da IT2 e realizar as entregas iterativasTodos---

Histórico de Revisão
VersãoDataDescriçãoAutor(es)
1.018/05/2026Criação da retrospectiva da Unidade 2 — IT1 Vitrine PúblicaLucas A. Zanetti