10. Lições Aprendidas

10.1. Unidade 1

Lições Aprendidas e Melhorias para o Processo

1. Compreensão do Processo de Desenvolvimento

   • Desafio: Dificuldade inicial em entender a melhor abordagem a ser utilizada, considerando que não existe uma solução única em Engenharia de Software.
   • Ação de Melhoria: A equipe adotou uma postura mais flexível e adaptativa, buscando analisar o contexto do projeto antes de definir abordagens, além de aprofundar o estudo sobre processos, metodologias e impacto dos requisitos.

2. Definição e Dependência do Cliente

   • Desafio: A definição tardia do cliente gerou riscos ao projeto, dificultando a comunicação inicial e podendo impactar a continuidade caso fosse necessário substituí-lo.
   • Ação de Melhoria: Foi adotada a estratégia de considerar múltiplos possíveis clientes e manter alternativas, reduzindo riscos e garantindo maior segurança no andamento do projeto.

Dificuldades e Ações para Superá-las

1. Comunicação e Disponibilidade do Cliente

   • Desafio: Houve demora no retorno do cliente e dificuldade em alinhar horários para reuniões, além de reuniões pouco objetivas com repetição de pontos já definidos.
   • Como foi superado: A equipe está buscando tornar as reuniões mais diretas e objetivas, além de propor a criação de canais de comunicação mais rápidos e incluir outros membros da instituição para ampliar as possibilidades de feedback.

2. Organização da Comunicação

   • Desafio: A comunicação com o cliente foi inicialmente pouco eficiente, dificultando a troca de informações e o andamento das decisões.
   • Como foi superada: Foi sugerida a criação de um canal de comunicação direto entre equipe e cliente, facilitando o contato contínuo e agilizando o processo de validação e alinhamento.

---

10.2. Unidade 2

Lições Aprendidas e Melhorias para o Processo

1. Compreensão do Processo de Elicitação de Requisitos

   • Desafio: Dificuldade inicial em entender melhor como elicitar requisitos desde a concepção, passando pela análise e consenso, indo até a priorização.
   • Ação de Melhoria: A equipe adotou uma postura metódica seguindo os conhecimentos obtidos por meio das aulas para montar os artefatos relacionados.

2. Elicitação de Requisitos com Stakeholders

   • Desafio: Durante o processo de elicitação, observou-se que os stakeholders tendem a se comunicar de forma genérica, superficial e, muitas vezes, focada em soluções em vez de problemas. Isso dificultou a identificação precisa das necessidades reais do negócio, gerando ambiguidades, lacunas e risco de interpretações incorretas por parte da equipe.
   • Ação de Melhoria: A equipe passou a adotar uma abordagem mais estruturada na condução das interações com os stakeholders, utilizando perguntas direcionadas, exploração do fluxo atual de trabalho (“como é feito hoje”) e validação por meio de cenários concretos.

Dificuldades e Ações para Superá-las

1. Realização Antecipada das Atividades de Engenharia de Requisitos
   • Desafio: A equipe enfrentou dificuldades ao ter que realizar atividades de Engenharia de Requisitos no projeto antes de ter aprendido formalmente os conceitos, práticas e técnicas na disciplina. Isso gerou incerteza na execução das tarefas, dúvidas sobre como estruturar os artefatos corretamente e risco de produzir entregas com baixo nível de qualidade ou desalinhadas com as expectativas acadêmicas.
   • Como foi superado: A equipe buscou estudar de forma paralela os conceitos de Engenharia de Requisitos por meio de materiais complementares. Além disso, adotou uma abordagem iterativa, revisando e refinando continuamente os artefatos produzidos à medida que novos conteúdos eram aprendidos na disciplina, permitindo evolução gradual na qualidade das entregas e maior alinhamento com as boas práticas.

10.3. Unidade 3

Lições Aprendidas e Melhorias para o Processo

1. Adequação ao Framework OpenUP
   • Desafio: Grande dificuldade de adaptação aos conceitos e rituais do OpenUP. Compreender a dinâmica de funcionamento das iterações, o ciclo de micro-incrementos e, principalmente, implementar essa sistemática na prática levando em consideração a rotina e a disponibilidade dos membros da equipe foi um desafio complexo.
   • Ação de Melhoria: A equipe realizou um estudo aprofundado das documentações oficiais e diretrizes do OpenUP. A partir disso, substituiu-se o modelo mental do Scrum tradicional por uma governança baseada em Planos de Iteração e acompanhamento centralizado por meio de uma Lista de Itens de Trabalho (Work Item List).

Dificuldades e Ações para Superá-las

1. Eliminação de Resquícios de Metodologias Anteriores e Refatoração de Processos
   • Desafio: A transição metodológica exigiu um volume significativo de retrabalho. O projeto apresentava diversos resquícios e nomenclaturas exclusivas do Scrum (como Sprints, Cards e Story Points), e desvincular a equipe desse modelo consolidado para migrar para a semântica e fluxo do OpenUP foi uma tarefa árdua.
   • Como foi superado: A equipe realizou uma varredura crítica em toda a documentação, reestruturando as tabelas de requisitos em Casos de Uso funcionais e vinculando-os diretamente ao cronograma de fases do projeto. Além disso, o grupo focou em gerar e adicionar evidências claras da execução das atividades de engenharia e, com o processo alinhado, conseguiu engrenar uma esteira de desenvolvimento produtiva, resultando em uma evolução sólida e segura das funcionalidades do SGES.

---

10.4. Unidade 4

Lições Aprendidas e Melhorias para o Processo

1. Aprendizado em gestão e organização de horários

   • Desafio: Lidar com alta carga das disciplinas da universidade e com demandas externas foi um grande desafio, dado que este momento de final de semestre é extremamente complexo.
   • Ação de Melhoria: A equipe se organizou por meio de ferramentas de organização como Notion e Google agendas para se adaptar a sobrecarga e alta quantidade de demandas.

2. Validação Técnica de Usabilidade (Homologação Prática)

   • Desafio: Garantir que ferramentas, como relatórios gerenciais consolidados e chamadas diárias, fossem fáceis e ágeis o suficiente para serem utilizadas na rotina real de instrutores voluntários.
   • Ação de Melhoria: O grupo compreendeu a necessidade de não focar apenas no código funcional, mas também na experiência de uso. Passou-se a adotar simulações operacionais internas em ambientes controlados com usuários fictícios antes da entrega de cada Caso de Uso final, garantindo clareza e agilidade na validação das interfaces.

Dificuldades e Ações para Superá-las

1. Unificação de Iterações e Gestão de Prazos no Fim do Ciclo de Construção

   • Desafio: A fusão das antigas iterações 2 e 3 da Construção em uma única janela unificada gerou um volume concentrado de entregas funcionais (CSU12 a CSU16). Conciliar o fechamento de múltiplos Casos de Uso com os prazos finais da disciplina e a necessidade de estabilizar o produto trouxe uma sobrecarga de esforço ao grupo.
   • Como foi superada: A equipe aplicou a gerência focada em micro-incrementos do OpenUP. Centralizou-se o monitoramento diário da Lista de Itens de Trabalho (Work Item List), dividindo as frentes de codificação e de documentação de forma paralela. Com o uso constante de revisões técnicas cruzadas (Pull Requests) e testes de integração contínua, o grupo garantiu que todas as funcionalidades fossem entregues com qualidade, sem gerar inconsistências ou quebras de caminhos no Git Pages.

2. Impacto do Adiantamento da Entrega Final

   • Desafio: A antecipação da data de entrega final do projeto gerou um encurtamento do tempo hábil para a conclusão da fase de Construção (Iteração 2) e para o polimento dos artefatos da fase de Transição. Isso causou uma sobrecarga repentina na equipe e ameaçou a estabilidade do sistema, exigindo uma reorganização emergencial do cronograma para garantir que todos os Casos de Uso finais fossem codificados, testados e documentados a tempo.
   • Como foi superado: A equipe precisou demonstrar alta capacidade de adaptação e gestão de crise. Para mitigar o impacto do prazo curto, intensificamos drasticamente as interações assíncronas e realizamos "mutirões" de desenvolvimento com revisões pareadas. Além disso, aplicamos de forma rigorosa os critérios de Definition of Done (DoD) para fechar o escopo estritamente no necessário para o MVP, evitando qualquer perfeccionismo desnecessário que pudesse atrasar a entrega da versão funcional.