10 Lições Aprendidas

Unidade 1

Escolha de projeto

Foi preciso de um período considerável de conversas entre a equipe e stakeholders para analisar qual projeto seria mais adequada para o projeto e para a intenção dos integrantes com a disciplina.

Comunicação com o cliente

Entender qual seria o principal problema enfrentado atualmente pelo cliente foi desafiador. Porém conseguimos compreendê-lo.

Aplicação de metodologias vindas da sala de aula

Ao se aplicar as metodologias aprendidas em sala de aula, tivemos um aprendizado por conseguir identificar o problema e suas causas com mais clareza conseguindo encontrar uma solução mais viável a ele.

Análise do problema e criação de uma solução

Após conseguir compreender o problema enfrentado pelo cliente, foi necessário identificar qual seria a solução mais adequada. Primeiramente pensamos na possibilidade de criação de um CRM, contudo identificamos que isso era mais um desejo do cliente o qual não o possibilitaria de resolver o problema enfrentado. Logo após isso, identificamos que a solução mais adequada seria a criação de um e-commerce o qual aumentaria a visibilidade da empresa digitalmente.

Interação com equipe

No início, a comunicação poderia ser mais efetiva entre os membros da equipe. Todavia, isso foi melhorando conforme nossas comunicações e avanços em relação ao projeto.

Unidade 2

Engenharia de Requisitos

A engenharia de requisitos é de extrema importância no desenvolvimento de software, porque é nela que as bases do produto são estabelecidas. Fundamental para garantir que as necessidades dos clientes sejam atendidas. Uma lição importante aprendida é que a comunicação constante entre as partes interessadas é crucial, principalmente para evitar ambiguidades e falhas, envolvendo durante todo o processo os stakeholders e estabelecendo um alto grau de confiabilidade.

Requisitos de Softwares

Os requisitos não se limitam apenas ao que o sistema deve fazer, mas também em como ele deve fazer, a clareza e a precisão na especificação desses requisitos ajudam a evitar conflitos no desenvolvimento. Existem muitos métodos de levantamentos de requisitos, sejam eles funcionais ou não, além de formas diferentes para descrevê-los.

DoR e DoD

A lição aprendida de DoR e DoD é que sem uma definição clara do que significa "pronto" para iniciar uma tarefa (DoR) e "pronto" para concluir uma tarefa (DoD), é fácil que a equipe se perca em ambiguidades. A definição de DoR ajuda a garantir que os requisitos sejam compreendidos e que a equipe tenha todos os recursos necessários para começar, enquanto DoD assegura que as entregas atendam a todos os critérios necessários para serem consideradas finalizadas, sem deixar pendências que possam prejudicar o produto final.

Backlog do Produto

O backlog do produto é uma lista dinâmica de itens que precisam ser trabalhados para atender aos requisitos do software, ele não deve ser encarado como um item fixo, mas como algo que está em constante evolução. Priorizar o backlog de forma adequada, com base no valor para o cliente e no impacto no produto. Na visão do ScrumXP, um backlog bem organizado e constantemente revisado, com histórias de usuário bem definidas, facilita a execução das sprints e ajuda as equipes a entregarem valor contínuo ao cliente.

Histórico de Versões

Versão	Data	Descrição	Autor(es)	Revisor(es)
1.0	26/11/2024	Criação do Documento	Mariana Letícia	Johan, Paulo Henrique, Mariana Letícia, Mateus Cavalcante e Diogo
1.1	16/12/2024	Adicionando a unidade 10.2	Paulo Henrique	Johan, Paulo Henrique, Mariana Letícia, Mateus Cavalcante e Diogo