Lições aprendidas¶
Histórico de Revisão
| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 08/11 | 1.0 | Criação do tópico de lições aprendidas | Maykon Júnio dos Santos Soares |
| 15/12 | 1.1 | Adição de lições aprendidas da unidade 2 | Henrique Martins Alencar |
| 20/01 | 1.2 | Adição de lições aprendidas da unidade 3 | Erick Miranda Santos |
Unidade 1¶
Introdução ao Desenvolvimento de Projetos¶
Na sala de aula, começamos nossa jornada de aprendizado com o desenvolvimento de habilidades práticas voltadas para projetos. Este foi apenas o início, mas crucial para entendermos as metodologias que guiarão nosso trabalho.
Metodologias de Desenvolvimento¶
Exploramos as principais metodologias de desenvolvimento de software, compreendendo suas diferenças e como escolher entre elas com base no **triângulo de ferro:
- Metodologias orientadas a plano: Estruturadas e detalhadas, com foco no planejamento rigoroso.
- Metodologias ágeis: Flexíveis e adaptáveis, favorecendo a colaboração e a entrega contínua de valor.
Dessa forma, conseguimos avaliar as vantagens e limitações de cada abordagem e definir qual delas é mais apropriada para diferentes tipos de projeto.
Ferramentas Ágeis no Mercado¶
Nos aprofundamos em duas das metodologias ágeis mais populares e suas práticas específicas:
- Scrum: Uma abordagem iterativa que organiza o trabalho em ciclos curtos, chamados de "sprints", para melhorar a produtividade e a entrega.
- eXtreme Programming (XP): Focado em garantir a qualidade do código através de práticas como testes automatizados e programação em par.
Essas ferramentas, ricas em processos e práticas, fornecem uma base sólida para o desenvolvimento de software de alto padrão.
Novas Ferramentas e Tecnologias¶
Além das metodologias, a equipe teve a oportunidade de explorar novas ferramentas que facilitarão o desenvolvimento do projeto:
- GitHub Pages: Plataforma gratuita de hospedagem que a equipe utilizará para **documentar o projeto de forma clara e acessível, garantindo que todos os membros estejam alinhados quanto aos processos e etapas.
Unidade 2¶
Processo de Engenharia de Requisitos¶
Aprendemos a importância de compreender profundamente as necessidades dos stakeholders e transformá-las em requisitos claros e definidos, pois nos ajudam a organizar e priorizar as etapas do desenvolvimento, trazendo um trabalho eficaz. A comunicação efetiva entre os principais interessados e a equipe de desenvolvimento é crucial para minimizar a ambiguidade e o retrabalho.
Requisitos Funcionais e não funcionais¶
Compreendemos que os requisitos funcionais definem o que o sistema deve fazer, enquanto os não funcionais especificam como o sistema deve funcionar. Aprendemos que ignorar requisitos não funcionais, como desempenho, segurança e usabilidade, pode comprometer a qualidade final do produto. Um desafio foi compreender quais são cada um desses requisitos de forma alinhada com os objetivos do projeto.
Elaboração de Backlog¶
Durante a elaboração do backlog, aprendemos que a clareza das tarefas são cruciais para o sucesso da equipe. Organizar os requisitos separando-os por temas e épicos e atribuindo histórias de usuário nos ajudou a compreender melhor o que exatamente desenvolver para o cumprimento dos requisitos, com o objetivo de entregar um produto de maior qualidade.
Priorização do Backlog¶
A priorização do backlog nos ensinou a equilibrar as necessidades do negócio com as restrições técnicas e de tempo. A utilização de critérios de prioridade com pesos atribuídos, como valor de negócio, complexidade, criticidade e independência, nos ajudou a definir que requisitos tinham maior importância em nosso projeto, o que nos permite ter uma melhor organização, possibilitando entregas que estejam mais alinhadas com os objetivos do projeto.
Definição de MVP¶
A definição do MVP (Minimum Viable Product) foi um exercício valioso para aprender a entregar valor rápido com recursos limitados. A definição do que é essencial nos permite focar nas funcionalidades mais críticas e de maior valor para o produto, garantindo que as necessidades principais sejam entregues dentro do prazo determinado.
Unidade 3¶
Product Backlog Building (PBB)¶
Durante o Product Backlog Building (PBB), aprendemos que o sucesso de um projeto ágil depende da clareza e da evolução constante do backlog. O processo de revisar e refinar o backlog periodicamente é essencial para ajustar as prioridades e garantir que os itens mais importantes sejam tratados primeiro, permitindo entregas contínuas de valor ao cliente.
- Lição Aprendida: A construção de um backlog bem estruturado e a revisão constante do mesmo são cruciais para o sucesso de um projeto ágil. Adaptar as prioridades de acordo com o progresso do projeto e as necessidades do cliente ajuda a mitigar riscos e a garantir que o trabalho esteja sempre alinhado com os objetivos do produto.
User Story Mapping (USM)¶
O User Story Mapping é uma técnica essencial para visualizar as funcionalidades do produto de maneira estruturada e alinhada com as necessidades do usuário. Durante esta unidade, aprendemos a importância de mapear histórias de usuário para garantir que todas as funcionalidades necessárias para atender ao objetivo do projeto sejam contempladas de forma clara. Essa técnica permite uma melhor comunicação entre a equipe e facilita o planejamento das entregas de acordo com o valor de cada história.
- Lição Aprendida: O uso de User Story Mapping proporciona uma visão clara das funcionalidades do sistema e facilita a priorização das tarefas com base no valor que elas agregam ao produto. É fundamental garantir que todas as histórias de usuário estejam bem definidas e alinhadas com os objetivos do projeto.
Integração de PBB e USM¶
Durante o processo de integração entre Product Backlog Building (PBB) e User Story Mapping (USM), percebemos como essas duas metodologias se complementam. O PBB ajuda a organizar o trabalho de maneira eficiente, enquanto o USM oferece uma visão detalhada das funcionalidades, permitindo que a equipe foque nas histórias mais relevantes para o produto. A integração de ambas as técnicas é essencial para garantir que o backlog esteja bem estruturado e alinhado com as necessidades do usuário.
- Lição Aprendida: A integração de PBB e USM deve ser feita de forma cuidadosa, garantindo que o planejamento estratégico do projeto seja complementado pela visão detalhada das histórias de usuário. Isso permite que o trabalho seja executado de forma mais eficiente e alinhada com os objetivos do produto.
Unidade 4¶
Diagrama de Caso de Uso¶
O Diagrama de Caso de Uso é uma ferramenta visual utilizada para representar as interações entre os atores e o sistema. Ele auxilia na identificação dos principais casos de uso e na compreensão do escopo do sistema de forma clara e objetiva. Esse diagrama facilita a comunicação entre stakeholders, analistas e desenvolvedores, promovendo um entendimento compartilhado sobre as funcionalidades esperadas.
- Lição Aprendida: A construção de um Diagrama de Caso de Uso bem elaborado ajuda a visualizar os limites do sistema e suas interações com os usuários. Esse mapeamento inicial é essencial para alinhar expectativas e evitar ambiguidades na definição dos requisitos.
Especificação de Caso de Uso¶
A Especificação de Caso de Uso descreve detalhadamente o comportamento do sistema para cada caso de uso identificado. Esse documento contém informações como fluxo principal, fluxos alternativos, pré-condições e pós-condições, garantindo uma definição precisa das interações esperadas. Essa especificação é fundamental para o desenvolvimento e teste do sistema, reduzindo incertezas e inconsistências.
- Lição Aprendida: A documentação detalhada da Especificação de Caso de Uso é essencial para garantir que todas as possíveis interações sejam consideradas. Uma especificação bem definida melhora a comunicação entre as equipes e reduz falhas na implementação, contribuindo para um desenvolvimento mais eficiente e alinhado com os requisitos do cliente.