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 |