11 Lições Aprendidas

Unidade 1Unidade 2Unidade 3Unidade 4

11.1 Unidade 1

A Unidade 1 foi um período de adaptação intensa, marcado pela formação de uma equipe parcialmente nova e pelo desafio de alinhar expectativas acadêmicas com a realidade de um cliente real. A seguir, detalhamos as lições extraídas dessa experiência.

Lições Aprendidas e Melhorias para o Processo

1. Dinâmica de Grupo e Comunicação Presencial

   Lição: A decisão de realizar reuniões presenciais foi um diferencial para a integração do time. Como parte dos membros não se conhecia, o contato direto facilitou a interação inicial, a tomada de decisões em conjunto e o compartilhamento rápido de conhecimento.

   Ação de Melhoria: Manter rituais presenciais ou síncronos sempre que possível para garantir que a coesão do grupo se mantenha nas fases de desenvolvimento mais complexas.

2. Escolha do Processo de Desenvolvimento

   Desafio: Identificar um processo de software que fosse eficiente para o contexto da disciplina, evitando o risco de a equipe trabalhar de forma desordenada por falta de um fluxo claro.

   Solução: A dificuldade foi superada através de discussões colaborativas baseadas no material didático da disciplina, garantindo que o método escolhido servisse como guia e não como um entrave.

3. Planejamento e Cronograma

   Lição: A ausência de um cronograma palpável no início resultou em uma sobrecarga de tarefas próximo ao prazo da proposta, o que causou erros que passaram despercebidos na revisão final.

   Ação de Melhoria: Implementar um cronograma de entregas internas mais rigoroso para as próximas unidades, permitindo tempo hábil para revisões de qualidade antes do envio oficial.

Dificuldades e Ações para Superá-las

1. Identificação do Problema e Viabilidade da Solução

   Desafio: Dificuldade em filtrar as necessidades do cliente e transformá-las em uma solução que fosse tecnicamente viável e, ao mesmo tempo, resolvesse o problema real apresentado.

   Como foi superada: O time focou nos processos de engenharia de requisitos e no diálogo constante para entender as dores do cliente, buscando o equilíbrio entre a teoria acadêmica e a prática de mercado.

2. Mudança de Stack Tecnológica e Sustentabilidade

   Desafio: Após uma escolha inicial, a equipe optou por mudar a stack tecnológica para garantir que o software final fosse sustentável e adequado à realidade do cliente a longo prazo. Isso aumentou o desafio técnico, pois muitos membros terão o primeiro contato com essas ferramentas.

   Como foi superada: A equipe aceitou o desafio em prol da qualidade do produto final, comprometendo-se com o nivelamento de conhecimento técnico entre os integrantes.

3. Gestão de Tempo e Carga Acadêmica

   Desafio: Conciliar as entregas densas da disciplina com outras matérias e a vida pessoal em um prazo curto.

   Como foi superada: A colaboração foi a chave; cada membro assumiu sua responsabilidade, e o apoio mútuo permitiu que as entregas fossem realizadas a tempo, sem sobrecarregar apenas um indivíduo.

11.2 Unidade 2

Lições Aprendidas e Melhorias para o Processo

1. Criação e Gestão do Backlog

   Desafio: A equipe teve dificuldade em organizar e priorizar o backlog, inicialmente havia incerteza sobre o escopo, falta de critérios de prioridade e pouca experiência em decompor épicos em histórias menores.

   Lição: Um backlog precisa ser vivo e iterativo; sem critérios claros e sessões regulares de refinamento, itens importantes se perdem ou viram tarefas mal definidas.

   Ação de Melhoria: Estudamos e aplicamos práticas de RAD para elaborar o backlog, estruturando épicos, histórias de usuário e tarefas menores. Definir critérios de priorização (por exemplo MoSCoW ou valor/risco), realizar reuniões de refinement periódicas, usar estimativas relativas (story points) e dividir épicos em histórias de usuário testáveis.

2. Declaração e Formalização de Requisitos

   Desafio: A equipe encontrou dificuldades em declarar requisitos de forma clara e verificável, requisitos ambíguos, mistura de solução com necessidade e ausência de critérios de aceite dificultaram o desenvolvimento e a validação com o cliente.

   Lição: Requisitos bem escritos reduzem retrabalho e mal-entendidos; separar necessidade do detalhamento da solução facilita a negociação com o cliente e a implementação técnica.

   Ação de Melhoria: Passar a usar user stories no formato "Como , quero , para ", sempre acompanhadas de critérios de aceitação claros. Manter um checklist de qualidade de requisito (clareza, testabilidade, prioridade, dependências), registrar suposições/ restrições e validar requisitos com protótipos rápidos e revisões com o cliente.

3. Workshop JAD

   Desafio: A equipe não tinha muita segurança sobre como executar um workshop JAD no início, o que gerou dúvidas sobre a condução da dinâmica e o papel de cada participante.

   Lição: O workshop JAD é uma prática útil para reunir diferentes perspectivas, alinhar expectativas e detalhar requisitos com o cliente de forma colaborativa.

   Ação de Melhoria: Através de pesquisas e do estudo prévio da metodologia, a equipe conseguiu estruturar e conduzir o workshop junto ao cliente. Para as próximas vezes, a recomendação é preparar melhor o roteiro da reunião, definir os objetivos com antecedência e organizar os tópicos a serem discutidos para tornar a dinâmica mais fluida.

Dificuldades e Ações para Superá-las

1. Falta de experiência em priorização

   Como superar: Realizar um workshop de priorização com a equipe e o cliente; estabelecer regras de decisão e documentar prioridades.

2. Ambiguidade nos requisitos

   Como superar: Criar templates e exemplos padrão de user stories e critérios de aceite; promover revisões curtas de requisitos antes do desenvolvimento.

3. Integração do backlog com o planejamento

   Como superar: Vincular o backlog ao roadmap/incrementos do cronograma, garantindo entregas menores e feedbacks contínuos do cliente.

4. Acompanhamento das Atividades e Ferramentas de Gestão

   Desafio: O grupo teve dificuldades em acompanhar o progresso das atividades de forma centralizada; tarefas e responsabilidades ficaram dispersas, reduzindo a visibilidade do andamento.

   Lição: Um quadro de acompanhamento bem estruturado facilita a coordenação, a responsabilização e o ajuste de prioridades em tempo hábil.

   Ação de Melhoria: Planejamos utilizar com mais intensidade e eficiência o GitHub Projects para organizar o trabalho (boards, colunas e cartões) e vincular issues às tarefas. Também vamos estabelecer rotações de revisão para manter o controle.

11.3 Unidade 3

Lições Aprendidas e Melhorias para o Processo

1. Criação e Manutenção de Testes Automatizados

   Desafio: A elaboração dos testes (especialmente de interface e simulação de serviços com mocks) exigiu um esforço muito maior do que o planejado. A equipe enfrentou dificuldades técnicas com configurações e erros difíceis de diagnosticar, o que consumiu bastante tempo e acabou impactando o ritmo de algumas entregas.

   Lição: Deixar a criação de testes para a fase final do desenvolvimento gera muito retrabalho e frustração. O código precisa ser construído desde o início já pensando em como ele será testado, integrando essa prática na rotina diária da equipe.

   Ação de Melhoria: Desenvolver os testes em paralelo com a criação das funcionalidades, evitando acumular pendências para o fim da sprint. Focaremos em manter uma base de testes simples e funcional para cada nova tela desenvolvida, em vez de tentar cobrir fluxos complexos de uma só vez no final da unidade.

2. Aplicação de V&V e Gestão do Tempo para Correções

   Desafio: O maior obstáculo técnico do período foi a janela de tempo extremamente curta que tivemos para processar, compreender e aplicar todas as correções sugeridas pelo grupo revisor no documento de feedback. Absorver os apontamentos de Verificação e Validação deles e readequar nossos artefatos sob forte pressão de prazo exigiu um effort de engenharia muito acima do normal.

   Lição: Quando o prazo para resposta é reduzido, tentar debater ou planejar demais as críticas paralisa a execução. Aprendemos que a melhor saída é aceitar os apontamentos de forma direta, dividindo as correções de forma simplificada e focando a energia apenas em alterar o código e os documentos que foram explicitamente citados como errados.

   Ação de Melhoria: Adotar uma abordagem de correção direta e simplificada. Assim que um documento de feedback externo for entregue, cada membro assumirá os erros relacionados às telas ou documentos que já desenvolveu originalmente, executando os ajustes pontuais sem a necessidade de reestruturar o quadro de tarefas ou criar novos fluxos de gestão.

3. Refinamento de Requisitos e Ajustes no MVP

   Desafio: Tivemos bastante dificuldade para aplicar as correções no MVP do projeto. O grupo precisou evoluir da fragmentação dos requisitos para uma abordagem mais centralizada utilizando Histórias de Usuário (US). Além disso, enfrentamos barreiras no refinamento, pois os critérios de aceitação estavam misturados com as regras de negócio, e foi complexo entender as dependências funcionais entre as USs e identificar a melhor forma de simplificar o cálculo da matriz.

   Lição: Centralizar os requisitos em USs facilita o controle do escopo, mas exige um cuidado extra na separação clara entre o que é o comportamento esperado da tela (critério de aceitação) e o que é a lógica interna do sistema (regra de negócio). Sem mapear as dependências e simplificar as lógicas mais densas antes do código, o desenvolvimento do MVP trava.

   Ação de Melhoria: Passar a isolar rigidamente as regras de negócio complexas (como o cálculo da matriz) dos critérios de aceitação visuais no momento de escrever as USs. Para os próximos refinamentos, a prioridade será mapear quais histórias dependem de quais antes de iniciar o desenvolvimento, garantindo que os blocos de código mais independentes sejam entregues primeiro.

4. Dinâmica do Backlog Vivo em Workshops JAD

   Desafio: Durante a realização dos workshops JAD com o cliente, a equipe percebeu na prática que o backlog planejado inicialmente mudava constantemente à medida que novos cenários eram discutidos, o que exigia rápidas readequações de escopo no momento da dinâmica.

   Lição: Um backlog de requisitos não é um documento estático, mas sim um organismo vivo. O contato direto com o cliente em sessões colaborativas faz surgir necessidades antes não mapeadas, provando que a flexibilidade para priorizar e descartar itens em tempo real é fundamental para o sucesso do projeto.

   Ação de Melhoria: Assumir o backlog como uma estrutura iterativa e maleável. Utilizaremos os momentos de refinamento para ajustar as histórias de usuário assim que novos feedbacks do cliente surgirem, mantendo a documentação atualizada sem o receio de alterar o plano original do projeto.

Dificuldades e Ações para Superá-las

1. Alta curva de aprendizado na escrita de testes

   Como superar: Documentar e salvar exemplos de testes que funcionaram perfeitamente para servirem de modelo (template) para as próximas telas, reduzindo o tempo gasto com a configuração inicial de novos arquivos de teste.

2. Curto prazo para interpretar e aplicar correções de V&V externas

   Como superar: Focar estritamente no que foi apontado no documento de feedback, realizando apenas as alterações necessárias para sanar os erros listados pelo grupo revisor, sem tentar expandir o escopo ou fazer melhorias adicionais.

3. Dificuldade em organizar a revisão técnica sob pressão de tempo

   Como superar: Realizar checagens rápidas e diretas no próprio código alterado. A "Verificação" será feita visualmente pelo próprio desenvolvedor para garantir que o erro sumiu, e a "Validação" consistirá em rodar o teste localmente para confirmar que a aplicação compila e funciona antes do envio final.

4. Confusão com regras de negócio e dependências funcionais no MVP

   Como superar: Adotar a centralização por USs de forma definitiva, mas forçando a escrita do cálculo da matriz de forma isolada do fluxo principal da interface. Criar diagramas rápidos ou anotações em texto simples para listar qual US bloqueia a outra antes de mexer na estrutura do MVP.

5. Instabilidade no escopo durante os levantamentos de requisitos

   Como superar: Manter uma postura flexível durante os workshops com o cliente, anotando as novas demandas como possíveis substituições ou refinamentos de histórias já existentes, garantindo que o backlog acompanhe a evolução do entendimento do produto.

11.4 Unidade 4

Lições Aprendidas e Melhorias para o Processo

1. Refinamento e Consistência do Backlog de Histórias de Usuário

   Desafio: Ao revisar o backlog no Ciclo 4, a equipe identificou diversas incoerências acumuladas entre as USs já cadastradas, dependências mal mapeadas, critérios de aceite desalinhados com a evolução do produto e histórias que não refletiam mais o entendimento atual do escopo, exigindo uma análise completa e o refinamento de todo o backlog, e não apenas das histórias da sprint corrente.

   Lição: Um backlog não pode ser tratado como algo definido uma vez e esquecido. Conforme o produto evolui, é necessário revisar periodicamente todas as histórias já registradas, não só as novas, para garantir coerência entre elas e evitar que inconsistências se acumulem silenciosamente ao longo dos ciclos.

   Ação de Melhoria: Passar a reservar checkpoints específicos a cada novo ciclo exclusivamente para auditar o backlog como um todo, verificando dependências entre USs, coerência dos critérios de aceite e alinhamento com o entendimento mais recente do produto, evitando refinamentos emergenciais e concentrados.

2. Aplicação Correta da Metodologia JAD

   Desafio: Em avaliação com o professor, a equipe constatou que o Workshop JAD não vinha sendo aplicado de acordo com o que a metodologia prevê, o que impediu que essa técnica fosse validada como efetivamente utilizada e exigiu reestruturar partes do processo e da documentação do projeto para refletir a realidade do que havia sido feito.

   Lição: Aplicar o nome de uma metodologia sem seguir rigorosamente suas etapas gera retrabalho e compromete a credibilidade da documentação do processo. Entender a essência e os papéis previstos pela técnica é tão importante quanto executá-la na prática.

   Ação de Melhoria: Estudar formalmente os passos, papéis e artefatos definidos pelo JAD antes de reivindicar seu uso, documentando evidências claras de cada etapa (preparação, facilitação, sessão conjunta e documentação final) para garantir que a técnica seja, de fato, aplicada corretamente nos próximos ciclos.

3. Entrega Final e Validação com o Cliente (UAT Final)

   Desafio: Consolidar, apresentar e validar presencialmente a entrega final do produto junto aos stakeholders, incluindo a implementação da última história de usuário pendente (US-12), exigiu forte alinhamento entre toda a equipe para garantir uma demonstração técnica coesa e sem falhas.

   Lição: Reuniões presenciais de validação final concentram grande responsabilidade, pois qualquer falha de alinhamento entre os membros da equipe fica evidente diante do cliente. A preparação prévia é decisiva para o sucesso da aprovação e para transmitir confiança na entrega.

   Ação de Melhoria: Ensaiar a demonstração final de forma coletiva antes do UAT, garantindo que todos os membros dominassem o funcionamento das funcionalidades entregues. A experiência positiva dessa entrega passa a servir de referência para conduzir futuras apresentações e validações com o cliente.

Dificuldades e Ações para Superá-las

1. Incoerências acumuladas no backlog

   Como superar: Mapear todas as USs existentes em uma revisão cruzada, identificando duplicidades, dependências não documentadas e critérios de aceite desatualizados, corrigindo-os antes de dar continuidade ao desenvolvimento.

2. Uso incorreto da metodologia JAD

   Como superar: Revisitar a bibliografia sobre JAD, redefinir claramente os papéis dos participantes e reestruturar a documentação do projeto para refletir com precisão as técnicas efetivamente aplicadas em cada workshop.

3. Alinhamento da equipe para a entrega final

   Como superar: Realizar um ensaio geral da demonstração antes da reunião de UAT com os stakeholders, distribuindo claramente entre os membros quem apresentaria cada funcionalidade e validando previamente o funcionamento de tudo o que seria mostrado.