10. Lições Aprendidas

10.1 Unidade 1

1. Definir efetivamente o ciclo e metodologia utilizada no começo

   • Dificuldade: A equipe teve dificuldade na identificação do processo de desenvolvimento ideal para o contexto do projeto, o que causou um atraso na definição da estratégia.

   • Lição aprendida: É importante alinhar o ciclo de vida e a abordagem desde o começo do projeto, para garantir fluidez nas decisões e sucesso no projeto.

2. Alinhar expectativas com o cliente

   • Dificuldade: Como o cliente possui pouco conhecimento técnico, houve dificuldades iniciais de comunicação, superadas rapidamente com a adaptação da linguagem da equipe e a apresentação de imagens de aplicativos semelhantes, que facilitaram a compreensão do escopo e das funcionalidades da solução.

   • Lição aprendida: Tal ação é importante para não gerar atrasos de mudança de curso e escopo mal definidos.

3. Melhor compreensão de problema

   • Dificuldade: No início, a equipe partiu de suposições sobre o funcionamento da barbearia. Foi necessário realizar reuniões com o cliente e revisar o entendimento inicial para se aproximar da realidade dele.

   • Lição aprendida: Investir mais tempo na fase de entendimento de problema e elicitação de requisitos, para que o projeto possa correr de forma efetiva e sem percalços.

4. Comunicação interna da equipe

   • Dificuldade: A equipe identificou a necessidade de padronizar os canais de comunicação e marcar reuniões de acompanhamento com frequência regular, tendo em vista que houve momentos de desencontro na divisão de tarefas, o que impactou o andamento de algumas entregas.

   • Lição aprendida: A comunicação constante e organizada entre os membros da equipe é essencial para manter o andamento e evitar desalinhamentos do projeto.

10.2 Unidade 2

1. Revisão contínua de requisitos

   • Dificuldade: Essa prática busca adaptar o software à evolução das necessidades do cliente durante o projeto,exigindo comunicação constante, processos flexíveis e análises de impacto para incorporar alterações, mantendo o alinhamento e a relevância da solução.

   • Lição aprendida: A flexibilidade para adaptar requisitos via comunicação constante e análise de impacto é crucial para alinhar o software às necessidades evolutivas do cliente.

2. Regras de Negócios

   • Dificuldade: Assegurar que as diretrizes operacionais da empresa fossem registradas e compreendidas de maneira inequívoca por todos os envolvidos, prevenindo divergências de entendimento.

   • Lição aprendida: A formalização e validação conjunta das regras de negócio são essenciais para um entendimento unificado e para evitar falhas de implementação.

3. Dominar as Ferramentas da Engenharia de Requisitos

   • Dificuldade: Identificar a aplicação prática das metodologias de requisitos em cada etapa do ciclo de vida OpenUP e RAD, garantindo o alinhamento entre as atividades propostas e as necessidades específicas de cada fase.

   • Lição aprendida: O domínio das técnicas de Engenharia de Requisitos em OpenUP e RAD requer adaptar a aplicação prática de cada método aos objetivos e natureza iterativa específica de cada fase do ciclo de vida.

10.3 Unidade 3

1. Atividades da Engenharia de Requisitos (PBB, BDD e USM)

   • Dificuldade: No início, tivemos dificuldade para aplicar corretamente os métodos. Esquecíamos de incluir tópicos importantes e, muitas vezes, deixávamos as descrições vagas ou subjetivas, o que prejudicava a clareza dos elementos do backlog.

   • Lição Aprendida: Aprofundamos nosso conhecimento nos métodos de construção de Product Backlog. Através de atividades práticas e estudos teóricos, conseguimos entender melhor como aplicar cada abordagem e como estruturar e manter o backlog de forma organizada e alinhada com os objetivos do projeto.

2. Melhor compreensão do DoR e DoD

   • Dificuldade: As mesmas falhas de subjetividade apareceram também no DoR e no DoD. Inicialmente, escrevemos critérios vagos, com termos pouco claros e sem detalhamento do que realmente precisava ser feito. Além disso, tivemos dificuldade para entender em qual etapa da engenharia de requisitos o DoD deveria ser aplicado de forma mais efetiva.

   • Lição Aprendida: Com a devolutiva do professor e uma análise mais cuidadosa, passamos a compreender melhor como devem ser definidos o DoR (Definition of Ready) e o DoD (Definition of Done). Ajustamos nossos critérios para torná-los mais objetivos, claros e úteis, garantindo que todos tivessem uma noção precisa do que define uma tarefa pronta para começar e do que a torna concluída.

3. Desenvolvimento mais incremental

   • Dificuldade: Percebemos que, da forma como estávamos conduzindo o projeto no início, acabamos nos afastando da ideia de entregas incrementais. Nossa abordagem estava mais próxima de um modelo preditivo, o que dificultava ajustes e tornava o desenvolvimento mais engessado.

   • Lição Aprendida: Aprendemos a tornar o desenvolvimento mais incremental, estruturando nosso trabalho em entregas menores, contínuas e com valor agregado. Isso nos permitiu revisar o cronograma e adaptar nosso processo para uma abordagem mais flexível, que favorece ajustes e melhorias ao longo do caminho.

Histórico de Versão

Data	Versão	Descrição	Autor
20/04/2025	1.3	Inserção do Tópico 6.1	Caio Sabino
26/05/2025	2.0	Lições Aprendidas Unidade 2	Felipe Henrique
23/06/2025	3.0	Lições Aprendidas Unidade 3	Vinícius Rufino