Gerenciamento do Projeto

Esta seção apresenta como a gerência do projeto foi feita, como o time está organizado, como trabalha, e quais são os processos de desenvolvimento.

Sumário

• EAP do Projeto
• Organização do Time
• Matriz de Responsabilidade
• Plano de Comunicação
• Plano de Riscos
• Git Workflow

EAP do Projeto

Para visualizar a EAP (imagem a seguir), acesse o link: EAP no Miro

Organização do Time

Nas sprints de desenvolvimento do projeto, o time se organiza em 3 diferentes equipes: A primeira responsável pelas tarefas de backend, e a segunda e a terceira equipes sendo responsáveis pelo frontend do aplicativo e do gerenciador web respectivamente. A escolha dos membros que compõem cada uma das equipes varia de sprint para sprint, levando em consideração as dificuldades das user stories atribuídas para cada equipe e o interesse dos membros do time pelas tecnologias e paradigmas que serão utilizados para o desenvolvimento. Isso cria um ambiente mais saudável, onde cada membro possui mais liberdade para a escolha de tarefas e poderá aprender todas as tecnologias utilizadas no projeto.

Matriz de Responsabilidade

Essa matriz foi desenvolvida para ajudar os membros do time a saberem seus papéis na dentro do processo de desenvolvimento.

• R: Responsável: Quem é designado para trabalhar na atividade
• A: Aprovador: Quem tem autoridade para aprovar a atividade
• C: Consultado: Quem deve ser consultado e participar da atividade
• I: Informado: Quem deve ser informado sobre o andamento da atividade

Plano de Comunicação

Plano de Riscos

1. Identificação de riscos:

Os seguintes riscos foram identificados para o desenvolvimento do projeto Rotas Rurais:

• Aumento do escopo: Os requisitos do projeto podem mudar durante o processo de desenvolvimento, levando a atrasos e aumento de custos.
• Complexidade técnica: O projeto envolve requisitos técnicos complexos, como a execução de todas funcionalidades do aplicativo móvel em modo off-line, o que pode levar a desafios imprevistos e aumento do tempo de desenvolvimento.
• Restrições de recursos: O time pode enfrentar restrições de recursos, como disponibilidade limitada do tempo dos desenvolvedores qualificados ou restrições orçamentárias, o que pode afetar o cronograma e a qualidade do projeto.
• Problemas de comunicação: A má comunicação entre os membros da equipe do projeto, partes interessadas ou clientes pode levar a mal-entendidos e atrasos no projeto.
• Problemas de integração: o software pode precisar se integrar a outros sistemas ou tecnologias, o que pode levar a problemas de compatibilidade e atrasos.

2. Avaliação de risco:

Os riscos identificados na etapa 1 foram avaliados com base em sua probabilidade e impacto:

• Aumento do escopo:
  • Probabilidade: Baixa
  • Impacto: Moderado
• Complexidade técnica:
  • Probabilidade: Moderada
  • Impacto: Alto
• Restrições de recursos:
  • Probabilidade: Baixo
  • Impacto: Moderado
• Problemas de comunicação:
  • Probabilidade: Moderada
  • Impacto: Moderado
• Problemas de integração:
  • Probabilidade: Alto
  • Impacto: Moderado

3. Mitigação de riscos:

Para mitigar os riscos identificados, serão implementadas as seguintes estratégias:

• Aumento do escopo: Um processo de gerenciamento de mudanças será estabelecido para gerenciar mudanças nos requisitos do projeto, e uma squad de contingência será alocada para cobrir os recursos adicionais.
• Complexidade técnica: Uma avaliação de risco abrangente e um plano de mitigação serão desenvolvidos, e a equipe será incentivada a colaborar e buscar informações conforme necessário.
• Restrições de recursos: O cronograma e os custos do projeto serão revisados regularmente e os ajustes serão feitos conforme necessário para garantir que os recursos sejam alocados adequadamente.
• Problemas de comunicação: canais de comunicação claros serão estabelecidos e atualizações de status regulares serão fornecidas a todas as partes interessadas.
• Problemas de integração: o teste de compatibilidade será realizado no início do processo de desenvolvimento, e a comunicação e a colaboração dos membros da equipe serão incentivadas.

Git Workflow

O Gitflow é um modelo alternativo de ramificação do Git que consiste no uso de ramificações de recursos (features) e várias ramificações primárias (main e development).

Branches

Cada branch relacionada à features será criada a partir da branch development. Nos tópicos abaixo será explicado as nomenclatura que serão utilizadas para o desenvolvimento.

Nomes

O nome da branch será em inglês e deve seguir o padrão feature/nome-da-feature, onde os nomes das features podem ser encontrados no Trello. Quando for necessário fazer alguma correção, o prefixo utilizado deverá ser fix/nome-da-feature.

Criação

Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch development antes de criar uma branch nova:

git pull origin development

Depois da execução desse comando é necessário criar a Branch, para isso, execute o seguinte comando:

git checkout -b <nomeDaBranch>

Commits

Após criar a sua branch de desenvolvimento, faça as alterações necessárias no código e commite as mudanças:

Para adicionar as mudanças é possível utilizar dois comandos:

O comando git add . , faz com que todas as alterações que foram feitas localmente sejam commitadas no repositório remoto.

git add .

O comando git add <nomeDoArquivo> , faz com que apenas as alterações do arquivo informado seja commitado no repositório remoto.

git add <nomeDoArquivo>

Após adicionar as alterações é necessário commitar elas usando o comando git commit-m"comentario-do-commit"

git commit-m"comentario-do-commit"

O comentário deve descrever o que foi alterado no código e deverá ser em inglês.

Após, se for o primeiro commit dessa branch:

git push --set-upstream origin nome-da-branch

Caso contrário utilize:

git push 

Importante: Sempre envie seus commits para o repositório remoto após realizar o seu trabalho, assim os outros desenvolvedores terão sempre as ultimas atualizações do código.

Merge Requests

Depois da sua issue ter sido desenvolvida e estiver pronta de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de development.

Antes de abrir a MR certifique-se que, não irá ocorrer conflitos da sua branch com a development, para isso, siga os seguintes passos:

git checkout development
git pull
git checkout <nome-da-branch>
git merge development

Resolva os conflitos caso ocorra, após resolvê-los, envie as alterações para o Gitlab:

git push

Criando o Merge Request

A criação pode ser realizada na seção Merge Requests do repositório em que a branch foi criada. Clicando no botão New Merge Request siga os seguintes passos:

1. Selecionar a branch de origem (sua branch de desenvolvimento);
2. Selecionar a branch de destino (branch development);
3. Selecione Compare branches and continue;
4. Em Title, escreva um título que descreva a funcionalidade adicionada ou bug corrigido;
5. Em Description, escreva uma descrição com uma breve justificativa nos arquivos que foram alterados;
6. Caso a tarefa seja visual (criação de componente/tela, correção de bug) adicione um gif exemplificando o uso (se considerar necessário);
7. Na seção Assignee, marcar o responsável pela tarefa.
8. Na seção Reviwers, marcar os AGES 3 (Arthur, Martin e Sofia).

Documento de Continuação

This browser does not support PDFs. Please download the PDF to view it: Download PDF.