Skip to content

Lições Aprendidas

Unidade 1

Durante a Unidade 1 da disciplina de requisitos de software, foram obtidos os seguintes aprendizados fundamentais no desenvolvimento do projeto:

1. Gestão de Tempo e Contato com o Cliente

  • Desafio: O grupo percebeu que o contato com o cliente é um processo de construção que demanda mais tempo e esforço do que inicialmente planejado.
  • Ação de melhoria: Estabelecer uma rede de contato mais profunda com o cliente, seja por meio de reuniões ou por mensagem

2. Alinhamento de Expectativas e Entendimento do Projeto

  • Desafio: Nem todos os membros tinham a mesma compreensão da proposta do sistema.
  • Ação de melhoria: Trabalhar melhor os ritos do Scrum de forma que, ao final dos ciclos de atividade, quaisquer dúvidas e dificuldades sejam levados em discussão.

Unidade 2

Durante a Unidade 2 da disciplina de requisitos de software, foram obtidos os seguintes aprendizados fundamentais no desenvolvimento do projeto:

1. Importância de Definir Requisitos de Forma Clara

A categorização e detalhamento dos requisitos funcionais e não funcionais facilitaram a priorização e planejamento das entregas. Histórias de usuários e critérios de aceitação ajudaram a alinhar as expectativas das partes interessadas e guiaram o desenvolvimento.

2. Gerenciamento de Backlog e MVP

O uso do backlog como ferramenta de priorização mostrou-se essencial para o foco em itens de maior valor agregado. A definição do MVP acelerou o aprendizado sobre as funcionalidades mais críticas, garantindo entregas iterativas.

3. Colaboração Contínua

O formato de user stories, aliado a uma comunicação constante com stakeholders, reforçou a importância do alinhamento entre cliente e equipe para esclarecer ambiguidades e detalhar expectativas de forma iterativa.

4. Benefícios do DoR e DoD

As definições de Pronto (DoD) e de Preparado (DoR) foram fundamentais para garantir a qualidade das entregas, ao mesmo tempo em que estabeleceram um fluxo claro de início e conclusão das tarefas.

5. Adaptação ao Contexto Organizacional

Considerar aspectos técnicos, como uso de tecnologias específicas (Node.js, SQLite), e atender a requisitos organizacionais, como criptografia de dados e uso de servidores internos, garantiram a viabilidade técnica e de conformidade com os processos da empresa.

Unidade 3 - Lições Aprendidas

1. Estruturação e Priorização com PBB

  • Desafio: Traduzir as necessidades das personas em histórias de usuário claras e priorizáveis mostrou-se mais complexo do que o esperado.
  • Ação de Melhoria: O uso do PBB auxiliou o grupo a organizar requisitos de forma lógica, garantindo que os itens prioritários fossem os mais alinhados às dores dos usuários.

2. Visão Colaborativa com USM

  • Desafio: Criar um mapeamento que englobasse o ponto de vista de todos os stakeholders (exemplo de caso) sem perder o foco no MVP.
  • Ação de Melhoria: A utilização do User Story Mapping ajudou a decompor o produto em etapas, permitindo a priorização do que seria entregue no primeiro lançamento e promovendo maior clareza na entrega de valor.

3. Validação e Alinhamento com BDD

  • Desafio: A escrita de cenários de teste no formato Given-When-Then demandou um alinhamento mais detalhado entre os membros da equipe e os stakeholders (exemplo de caso).
  • Ação de Melhoria: O BDD facilitou a validação de comportamentos esperados do sistema, ajudando a equipe a evitar ambiguidades e garantindo que os critérios de aceitação fossem claros e objetivos.

Unidade 4 - Lições Aprendidas

Durante a Unidade 4 da disciplina de requisitos de software, foram obtidos os seguintes aprendizados fundamentais no desenvolvimento do projeto:

1. Modelagem Estruturada de Casos de Uso

Desafio: A construção de casos de uso de maneira estruturada exigiu um esforço inicial maior para identificar corretamente os atores, fluxos e exceções.

Ação de Melhoria: Aplicar uma abordagem sistemática para garantir que todos os cenários relevantes sejam considerados, utilizando fluxos básicos e alternativos bem definidos.

2. Clareza na Especificação de Casos de Uso

Desafio: A escrita de descrições de casos de uso que fossem compreensíveis para todas as partes envolvidas, evitando ambiguidades e redundâncias.

Ação de Melhoria: Padronizar a estrutura das especificações utilizando descrições contínuas, numeradas ou particionadas, conforme apropriado ao contexto.

3. Relação entre Requisitos e Casos de Uso

Desafio: Garantir que todos os requisitos funcionais estivessem corretamente representados nos casos de uso, evitando lacunas no desenvolvimento do sistema.

Ação de Melhoria: Mapear explicitamente cada requisito funcional a um ou mais casos de uso e revisar essa relação continuamente durante o processo de desenvolvimento.

4. Benefícios da Representação Visual

Desafio: A interpretação dos diagramas de casos de uso nem sempre foi intuitiva para todos os membros da equipe.

Ação de Melhoria: Complementar os diagramas UML com descrições textuais detalhadas e exemplos práticos, tornando a documentação mais acessível para todos os envolvidos.

5. Importância da Validação de Casos de Uso

Desafio: Testar se os casos de uso modelados eram suficientemente robustos para cobrir todos os cenários reais de utilização do sistema.

Ação de Melhoria: Realizar revisões iterativas com stakeholders e aplicar critérios como DoR (Definition of Ready) e DoD (Definition of Done) para garantir a completude e qualidade dos casos de uso antes de sua implementação.

Histórico de Versão

Data Versão Descrição Autor
20/11/2024 1.0 Adição das lições João Lucas Araujo
20/01/2025 1.1 Adição da lição Rafael Matuda