Definições de Gerenciamento de Projeto

Descrição

• 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

• Texto

Organização do Time

• Texto

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

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 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.

• 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 (Eduardo Ballico, Leonardo Vargas Soares e Pedro Vieira).

Documento de Continuação

• Texto