Lições Aprendidas

Unidade 1:

A equipe aprendeu a desenvolver um dos métodos de elicitação de requisitos, por meio da realização do Workshop Lean Inception. Apesar de desgastante, a ferramenta proporciona uma visão de produto extremamente clara para os membros de desenvolvimento e os stakeholders, estabelecendo os limites de até onde o produto se define como MVP, e incremental.

Nesta Unidade, também aprendemos sobre a importância de pensar em uma metodologia que contemplasse a disponibilidade dos stakeholders e da forma que ele iria interagir com o time de desenvolvimento. Para isso, foi utilizado a ferramenta Gupta para tomar a melhor decisão de metodologia, avaliando referenciais como a capacidade do time, riscos envolvidos do projeto, interação com o cliente e tempo ou recursos disponíveis. Ao fim, foi estabelecido o Processo Scrum XP de desenvolvimento.

Aprendemos como a comunicação e a colaboração com os stakeholders ao longo da elicitação dos requisitos é de suma importância, pois o sucesso do desenvolvimento depende de como os problemas são expostos ao time e quais são as expectativas de intervenções a este problema o software buscará atender.

Por último, aprendemos que qualquer software produzido para uma empresa ou pessoas, promove uma intervenção social, e é por isso que sua produção precisa ser colaborativa entre o time e stakeholders para ser entregue de forma mais alinhada ao contexto do cliente.

Unidade 2:

A nossa equipe aprendeu a aperfeiçoar as técnicas de elicitação de requisitos, principalmente na definição de prioridades considerando o tempo disponível e o quanto as funcionalidades agregam para o negócio dos stakeholders.

Aprendemos também a identificar funcionalidades que possuem características de granularidade alta e reduzí-los em escopo menores, classificando-os pelo modelo User Story: Temas, Épicos e User Story's.

Estabelecer os parâmetros para inicialização das atividades e de sua finalização também foi aprendida pela equipe e, de fato, vimos o quão importante é ter tais fases definidas de forma padronizada e clara para toda a equipe.

Por fim, conseguimos enxegar os processos de nossa metodologia dentro da Engenharia de Requisitos, identificando em quais fases são realizadas a elicitação e descoberta, análise e consenso, declaração, representação, verificação e validação e atualização e organização.

Unidade 3:

Na Unidade 3, a equipe aprofundou o conhecimento em técnicas de organização e planejamento de projetos, consolidando habilidades essenciais para o desenvolvimento eficiente de produtos de software. Além do uso do método Product Backlog Building (PBB) para estruturar o backlog de produto, foi possível entender como priorizar itens de backlog utilizando ferramentas como o COORG, garantindo que os PBI's (Product Backlog Items) fossem organizados pela ordem de execução mais adequada às necessidades do projeto.

Aprendemos também a importância de detalhar cada item do backlog em histórias de usuário, que servem como descrições claras do valor entregue ao cliente. Esses itens foram enriquecidos com critérios de aceitação, que ajudam a definir quando um PBI pode ser considerado completo, e com a elaboração de BDD's (Behavior-Driven Development), promovendo uma visão colaborativa entre as áreas de desenvolvimento e negócios.

Outro ponto marcante foi o aprendizado e a aplicação do User Story Mapping, uma técnica que permitiu visualizar o fluxo completo do produto de forma linear e coesa, facilitando a identificação das etapas mais críticas para garantir o valor entregue ao cliente final.

Unidade 4:

Na prática, percebemos que os casos de uso são essenciais para entender como um sistema deve se comportar em diferentes cenários. Inicialmente, tivemos dificuldades para diferenciar atores primários e secundários, mas com os exemplos discutidos em equipe, conseguimos visualizar melhor o papel de cada um na interação com o sistema. Além disso, aprendemos a importância de identificar corretamente os fluxos principais e alternativos para garantir que o sistema atenda a todas as necessidades dos usuários.

Outro aprendizado importante foi sobre a especificação dos casos de uso. No início, tentamos descrever tudo de forma muito ampla, o que tornava difícil compreender os detalhes de cada interação. Depois, percebemos que estruturar as informações de maneira padronizada, com elementos como pré-condições, pós-condições e descrições claras dos passos, facilitava tanto o entendimento do sistema quanto a comunicação com o restante da equipe. Esse processo nos ajudou a enxergar como documentar um sistema de forma mais organizada.

Por fim, aprendemos que os casos de uso não são apenas uma formalidade, mas sim uma ferramenta essencial para evitar falhas no desenvolvimento. Ao revisar e refatorar nossos próprios casos, notamos que algumas interações do sistema não estavam bem definidas, o que poderia gerar problemas na implementação. Com isso, passamos a valorizar mais a validação conjunta dos casos de uso, garantindo que todos os fluxos estivessem bem cobertos antes de avançarmos para as próximas etapas do projeto.