Lições Aprendidas

Unidade 1

Nesta Unidade foram estudados os Processos de Engenharia de Software e de Engenharia de Requisitos.

Conseguimos olhar para o problema da nossa Cliente e escolher a melhor abordagem, ciclo e processo possíveis, visando o maior conforto para a Cliente. Além de conseguir distinguir onde cada atividade da Engenharia de Requisitos está presente no processo escolhido.

Nesse começo a equipe foi bem unida com comunicação constante pelo Whatsapp, todos bem comprometidos com as reuniões síncronas, feitas no melhor horário para todos os integrantes.

Algo a ser melhorado seria descentralizar algumas tarefas do time, uma boa abordagem a ser seguida seria um rodízio em certas atividades no decorrer do projeto.

A maior dificuldade que tivemos foi a escolha do Processo que iríamos utilizar para o projeto, porém com o auxílio do framework Gupta, conseguimos decidir que o RAD seria a melhor opção. Porém como o grupo todo já teve experiência com o Scrum, decidimos adotar o framework para nossa organização. As aulas com o professor também foram de suma importância para sabermos se estávamos no caminho certo.

Unidade 2

Nesta Unidade foram estudadas as técnicas de cada atividade da Engenharia de Requisitos, o que são os Requisitos Funcionais e Não Funcionais, assim conseguimos criar a lista de requisitos do nosso projeto. Com essa lista em mãos, aprendemos a estrutura do SAFe e modelamos nossos requisitos em Tema, Épicos, Capacidade, Features e USs. Assim construímos nosso Backlog, o priorizamos e conseguimos eleger os MVPs, artefatos estes que guiarão o desenvolvimento do projeto.

A equipe continuou bem unida e sempre presente nas reuniões para conseguirmos realizar o trabalho. Conseguimos melhorar a questão de descentralizar certas tarefas, tópico pontuado na retrospectiva passada, para não ficar muito pesado para alguns integrantes. O nível de organização da equipe subiu de patamar, foi criada uma lista de tarefas para guiar o time do que fazer fora do projeto, em relação a apresentações pedidas, feedbacks atendidos, entre outros.

Uma das dificuldades encontradas foi fazer a Validação e Verificação de outro projeto, o fato de não ser o nosso próprio dificultou o entendimento de alguns requisitos e ideias apresentadas, porém resolvemos isso fazendo uma reunião com o outro grupo, e assim foi possível sanar as dúvidas e concluir a atividade. Outra dificuldade foi priorizar nosso Backlog e montar os MVPs 1 e 2, erramos na hora de granularizar nossos requisitos em épicos, capacidades e features, porém com o feedback do outro grupo e do professor, acreditamos ter conseguido encontrar uma bom Backlog, e por sua vez MVPs condizentes com a realidade do problema.

Unidade 3

Nesta Unidade foram estudados dois métodos de gerenciamento de projeto, o PBB (Product Backlog Building) e o USM (User Story Map). O Canvas PBB seria algo mais focado nas funcionalidades do produto de software, enquanto o USM foca um pouco mais nos objetivos e as atividades do negócio. Ambos trabalham com personas, de uma forma levemente diferente, e os dois chegam nas Histórias de Usuário.

O USM leva em consideração a conexão entre objetivo, atividade e história de cada persona, enquanto o PBB trabalha com problemas, funcionalidade, e PBIs (Product Backlog Itens) de cada persona. Cada um tem sua utilidade tendo como grande foco a visualização, a organização de ambos devem ser seguida para melhor aproveitamento dos métodos.

Outra coisa estudada foi o BDD (Behavior Driven Development), que é uma forma de validação para os critérios de aceitação, escrita em linguagem natural mesmo. Foi utilizado nas USs feitas no PBB. No começo foi difícil por conta dos nossos critérios não estavam condizentes, logo não foi possível fazer os BDDs. Entretando com bastante refinamentos, foi possível criar os BDDs. O feedback do professor foi de suma importância para a realização dessa tarefa.

Uma das maiores dificuldade nessa Unidade foi o trabalho necessário para as duas atividades de sala, que foram a elaboração do PBB e do USM. Como foram feitos muitos refinamentos de acordo com o avanço das aulas, acabamos demorando muito nessas atividades e deixando o projeto um pouco de lado, o que ocasionou um atraso para o começo da implementação do MVP 1. Sendo o principal motivo de não entregar tudo que foi requisitado, porém mesmo não podendo ser entregue na data estipulada, continuaremos com o desenvolvimento do projeto.

Unidade 4

Nesta Unidade, exploramos a estratégia de utilizar Casos de Uso, uma abordagem completamente distinta das Histórias de Usuário. Enquanto estas buscam ser concisas e simples, funcionando como lembretes a serem detalhados posteriormente, os Casos de Uso têm a finalidade oposta. Cada Caso de Uso é uma especificação completa, projetada para permitir que uma equipe de desenvolvimento implemente uma funcionalidade sem a necessidade de consultar continuamente um Product Owner, por exemplo.

Um passo crucial anterior à elaboração da especificação é a criação do diagrama de casos de uso. Esse diagrama destaca as interações dos usuários com o sistema (atores) e vincula cada interação a um requisito funcional específico. A habilidade de construir um diagrama de casos de uso não apenas facilita a visualização das interações, mas também auxilia na identificação de uma lista clara de requisitos funcionais, mantendo o foco na solução do problema como um todo.

Quanto às dificuldades enfrentadas nesta unidade, a equipe demonstrou um desempenho satisfatório ao assimilar o uso de casos de uso. No entanto, um desafio significativo foi a implementação da solução de software proposto pela equipe, isso se deve a falta de planejamento para gerenciar as demais atividades de requisitos da unidade, ou seja, a realização do PBB, do BDD, do USM e das UCs, que se tornaram mais complexas do que o esperado e afetaram consideravelmente o tempo que a equipe havia planejado inicialmente para o projeto.

O desenvolvimento da plataforma, mesmo não atingindo as expectativas ou alcançando o sucesso desejado, representou uma experiência de grande relevância para o crescimento pessoal de cada membro da equipe. Durante esse período, ao confrontar desafios relacionados ao planejamento e gerenciamento de equipe, assim como lidar com as dificuldades uns dos outros, houve um amadurecimento individual significativo. Essa experiência coletiva de superar obstáculos em prol de um objetivo comum contribuiu para o amadurecimento dos membros da equipe, tornando-os mais preparados para enfrentar desafios similares e facilitando o planejamento e execução de projetos futuros.