Lições Aprendidas

11. Lições Aprendidas

11.1 Unidade I

Nesta primeira unidade, a equipe enfrentou alguns desafios importantes de organização e gestão, que exigiram ajustes no início do projeto para garantir a continuidade das atividades.

Reorganização da Liderança

A saída do líder original da disciplina impactou diretamente a organização do grupo, já que várias tarefas estavam centralizadas nele. Isso gerou um período de desorganização e falta de clareza na distribuição das atividades.

Para resolver essa situação, foi necessário reorganizar a equipe e redistribuir as responsabilidades entre os membros. Um dos integrantes assumiu a coordenação das atividades, ajudando a estruturar novamente o fluxo de trabalho e garantindo que cada pessoa soubesse sua função na entrega da documentação.

Comunicação com a cliente e prazos

Houve dificuldade inicial para conciliar a disponibilidade da cliente com os prazos da disciplina. Além disso, a falta de um fluxo definido de comunicação no começo levou a algumas decisões internas que ainda não tinham sido validadas.

Com a reorganização da equipe, passou-se a priorizar um contato mais frequente com a cliente e o agendamento de momentos específicos para validação. Isso ajudou a alinhar melhor as decisões do projeto com as expectativas da cliente e com os prazos acadêmicos, reduzindo riscos de retrabalho.

11.2 Unidade II

Elicitação e entendimento dos requisitos

A elicitação de requisitos apresentou dificuldades devido à necessidade de compreender regras morfológicas específicas e alinhar o funcionamento do sistema às expectativas pedagógicas da cliente. Em alguns momentos, requisitos foram interpretados de formas diferentes pela equipe. Como solução, foram realizadas reuniões frequentes com a cliente, utilização de exemplos práticos do jogo físico e refinamento contínuo dos requisitos. Além disso, diagramas, protótipos e descrições mais objetivas ajudaram a construir um entendimento comum entre equipe e cliente.

Escrita e diferenciação entre requisitos funcionais e não funcionais

Houve dificuldade inicial na escrita de requisitos claros, objetivos e verificáveis, principalmente na diferenciação entre comportamentos do sistema e restrições de qualidade ou usabilidade. A fim de resolver esse problema, a equipe passou a utilizar verbos mais específicos e padronizados na documentação dos requisitos, além de revisar coletivamente os RFs e RNFs para garantir clareza, consistência e alinhamento com o escopo do MVP.

Organização e refinamento das regras de negócio

A representação das regras morfológicas do sistema apresentou complexidade maior do que a esperada, especialmente em situações relacionadas à classificação de palavras e organização dos morfemas. Em resposta a essa dificuldade, as regras foram refinadas junto à cliente de forma incremental, utilizando exemplos reais do jogo físico e separando claramente regras de negócio dos requisitos funcionais do sistema.

Dificuldades para priorizar o backlog e definir o MVP

A definição do MVP apresentou dificuldades porque muitas funcionalidades pareciam importantes para a experiência pedagógica do sistema, tornando difícil decidir quais requisitos realmente deveriam permanecer fora da primeira versão do produto. Com as revisões realizadas, a equipe passou a utilizar critérios mais objetivos de priorização, relacionando a classificação MoSCoW ao valor de negócio e à complexidade técnica de cada requisito. Isso ajudou a justificar melhor as decisões tomadas no backlog e tornou o escopo do MVP mais consistente.

Refinamento e detalhamento dos requisitos

Alguns requisitos foram inicialmente escritos de forma muito ampla, agrupando múltiplas responsabilidades em um único item. Isso dificultava a rastreabilidade, a validação individual e a priorização dos requisitos. Após as revisões do documento, principalmente nas funcionalidades relacionadas às operações de CRUD, os requisitos foram desmembrados em partes menores e independentes, tornando-os mais claros, testáveis e rastreáveis.

Construção das matrizes de rastreabilidade e priorização

A elaboração das matrizes apresentou dificuldades relacionadas à consistência entre os diferentes artefatos do projeto. Alterações realizadas nos requisitos frequentemente impactavam objetivos específicos, características de produto, valores de negócio, priorização e definição do MVP. Além disso, a equipe encontrou dificuldades para manter coerência entre a classificação MoSCoW, o valor de negócio, a complexidade técnica e o posicionamento dos requisitos nos quadrantes da matriz. Para resolver esses problemas, foram realizadas revisões incrementais e verificações cruzadas entre os artefatos, garantindo alinhamento entre requisitos, tabelas e justificativas metodológicas. A definição de critérios objetivos também ajudou a tornar as decisões de priorização mais consistentes.

Manutenção da rastreabilidade entre os artefatos

À medida que o documento evoluiu, tornou-se mais difícil manter alinhamento entre objetivos específicos, características de produto, requisitos funcionais, requisitos não funcionais e regras de negócio. Pequenas alterações em uma seção frequentemente exigiam ajustes em várias outras partes do documento. Como forma de reduzir inconsistências, a equipe passou a utilizar identificadores padronizados e revisões integradas entre os artefatos, facilitando a manutenção da rastreabilidade e a validação das relações entre os elementos do projeto.

11.3 Unidade III

Organização do fluxo de trabalho e controle de prazos

A dependência entre tarefas, somada à ocorrência de imprevistos, acabou gerando acúmulo de atividades próximo às datas de entrega. Para resolver, a distribuição de tarefas foi ajustada entre os membros da equipe e o escopo passou por adequações para se alinhar ao tempo disponível.

Estrutura de desenvolvimento e organização das entregas

Falhas nas fases iniciais acabaram impactando etapas posteriores, o que resultou em um acúmulo de esforço concentrado na reta final do desenvolvimento. O trabalho foi reorganizado em partes menores e, com isso, as prioridades passaram a focar nas funcionalidades essenciais, garantindo maior estabilidade no avanço do sistema.

Processo de validação com a cliente

A realização das validações apenas no final da sprint reduziu o tempo disponível para ajustes, o que aumentou a quantidade de retrabalho antes da entrega. Passou-se a realizar validações de forma antecipada, utilizando protótipos e representações de fluxo ainda nas fases iniciais. Essa mudança possibilitou identificar inconsistências mais cedo e reduzir correções em etapas avançadas.