Home | USs | Sprints | Mockups | Arquitetura | Database | Estudos | Gerenciamento | Configuração |
---|
Sumário
Git Workflow
Branches
Requisitos
Antes de criar uma branch nova certifique-se de que:
- Consta um card no Trello atribuido a você ou a sua Squad.
- Está na branch principal
dev
.
Criando branchs
Primeiro atualize sua branch local, com o seguinte comando
git pull
Para criar uma nova branch, execute o comando:
git checkout -b <nomeDaBranch>
Como padrão para nomes de branches, foi decidido o seguinte:
<código da tarefa>-<nome da tarefa utilizando camelCase quando necessário>
Por exemplo:
git checkout -b US01-tipoUsuario
Assim que a branch for criada execute o seguinte comando:
git push --set-upstream origin <nome da branch>
Dessa forma a branch será enviada para o repositório remoto no GitLab
Commits
Antes de fazer o commit é necessário preparar as alterações. Temos 2 maneiras de fazer isso:
O comando git add .
prepara todas as alterações que foram feitas localmente sejam adicionadas ao commit:
git add .
O comando git add <nomeDoArquivo>
prepara apenas as alterações do arquivo informado sejam adicionadas ao commit.
git add <nomeDoArquivo>
Após adicionar as alterações é necessário commitar elas usando o comando
git commit -m "comentario-do-commit"
Faça commit sempre que alguma funcionalidade for alterada, assim garantindo um método fácil de recuperação do código (caso necessário).
Após o commit, compartilhe as alterações no repositório remoto utilizando o comnado git push
git push
Merge Requests
Assim que uma tarefa for finalizada execute o seguinte comando:
git pull origin dev
O mesmo irá garantir que sua branch está atualizada com a branch dev (caso haja conflitos, resolva-os) e realize um commit com o seguinte nome:
Merge branch 'dev' into '<nome da branch>'
Depois de estar com a sua branch remota pronta para merge, crie um Merge Request no GitLab e preencha com as seguintes informações:
- Source Branch: Sua branch.
- Target Branch: branch
dev
. - Título:
<código da tarefa>-<nome da tarefa utilizando camelCase quando necessário>
- Descrição: Descrição da tarefa e/ou das mudanças no código
Assim que for criado o Merge Request, passe o card da sua tarefa no trello para "Review"
e avise um AGES 3, AGES 4 ou líder da Squad.
Matriz de Responsabilidade
Atividades | AGES I | AGES II | AGES III | AGES IV |
---|---|---|---|---|
Alimentar a wiki | R | R | R | R |
Definir organização do time | I | I | C | R |
Definir épicos da sprint | I | I | I | R |
Criar User Stories | I | I | C | R |
Definir arquitetura | I | I | R | A |
Definir tecnologias back e front | C | C | R/A | C/A |
Quebrar tasks da sprint | I | I | I | R |
Desenvolver as tarefas da sprint | R | R | R/A | R |
Desenvolver mockups | R | R | C/A | C/A |
Code review | I | I | R/A | I/C |
Criar testes | R | R | A | I/C |
Executar testes funcionais | R | R | R | R |
Deploy da aplicação | I | I | R | I |
Modelar o Banco de Dados(conceitual e lógico) | I | R | C/A | C/A |
Apresentação da review | I | I | I | R |
Legenda:
- I: Deve ser informado
- C: Deve ser consultado
- R: Responsável
- A: Aprova
Plano de Comunicação
Evento | Objetivo | Responsáveis | Envolvidos | Frequência | Duração |
---|---|---|---|---|---|
KickOff | É o primeiro encontro entre o time e cliente. Neste momento o cliente apresenta o projeto e o seu objetivo. Neste momemento o time faz perguntas a fim de entendimento. | Cliente | Todo o time | Uma vez | 1 hora e meia |
Reunião de alinhamento com cliente | Validar com o cliente as estratégias do produto e tirar possíveis dúvidas que possam surgir ao longo do desenvolvimento do trabalho. | AGES IV | AGES IV e cliente | Uma vez a cada sprint | 1 hora |
Daily | Atualizar para o time o status atual da task pela qual está responsável, informando o que foi feito, o que pretende fazer e se possui algum impeditivo. | AGES IV | AGES I, II, III, IV | Sexta-feira 19:15(Início da Aula) e Terça-feira (assíncrono) | 15 minutos |
Planning | Planejar objetivos de entrega da nova sprint. | AGES IV | AGES I, II, III, IV | A cada duas semanas | 1 hora e meia |
Retro | Melhoria contínua do processo de desenvolvimento. | AGES IV | AGES I, II, III, IV | A cada duas semanas | 1 hora |
Review | Apresentação das entregas da sprint para stakeholders. | AGES IV | AGES I, II, III, IV e cliente | A cada duas semanas | 30 minutos |
Plano de Riscos
Risco | Prevenção | Contingência | Estratégia |
---|---|---|---|
Não ter bem definido o que o cliente deseja | Definir e tirar qualquer dúvida que ficar com o cliente referente aos requisitos do projeto. | Entrar em contato com o cliente imediatamente para sanar as dúvidas que ficaram. | Eliminar |
Cliente querer aumentar o escopo do projeto | Definir o escopo informando o trabalho que precisa ser feito, o que precisa ser entregue e quais os limites do projeto e encaminhar isso com o cliente. | Reuniões com o cliente para entender o porquê desse aumento, mostrar quais impactos que terá e analisar se realmente é necessário e chegar a uma conclusão que fique bom para ambas as partes. | Eliminar |
Comunicação com o cliente | Possuir meios de comunicação que facilite a comunicação com o cliente, por exemplo: reuniões quinzenais para o cliente ver o andamento do projeto. | Criar meios de comunicação que facilitem a comunicação com o cliente. | Eliminar |
Estimativas irreais | Estimar a quantidade de trabalho junto com o time responsável, levando em consideração a quantidade de pessoas e os conhecimentos técnicos que elas possuem. | Conversar com o time responsável e entender qual foi o equívoco na estimação e tentar melhorar isso nas próximas estimativas. | Eliminar |
Falta de pessoal | Tendo o cronograma, acompanhar a quantidade de pessoas que estão trabalhando nas tarefas previstas nele, cuidando dos prazos de férias de cada uma e ficar atento a imprevistos que podem surgir como por exemplo uma pessoa sair. | Procurar se não tem alguém em outra equipe da empresa que esteja apto a ocupar o cargo ou então abrir novas vagas, procurar novos colaboradores. | Aceitar |
Sobrecarga de trabalho das pessoas envolvidas | Não fazer estimativas muito irreais e tentar ter mais de uma pessoa que conheça sobre a tarefa em questão, para que caso fique muitas coisas, elas possam se ajudar. | Acionar o gerente de projeto e ele junto com o líder da equipe tentar realocar outra pessoa para dar um suporte ou o líder presta esse suporte. | Mitigar |
Falta de reuniões de alinhamento e planejamento com o time | Fazer reuniões com todos os envolvidos no projeto para validar o planejamento do mesmo, alinhar a divisão de trabalho e entender o que já foi feito, o que precisa ser feito e se tem algum impedimento. | Reorganizar o planejamento e incluir essas reuniões com a equipe. | Eliminar |
Desorganização do time no desenvolvimento do projeto | Ter uma pessoa responsável para acompanhar o time e ajudar ele a manter uma organização no desenvolvimento de tarefas e fazer com que o time mantenha uma boa comunicação. | Alocar uma pessoa para ser responsável por manter a organização do time. | Mitigar |
Comunicação ruim | Possuir meios de comunicação que facilite para todos os envolvidos o entendimento do que está ocorrendo no projeto. | Criar meios de comunicação que facilite para todos os envolvidos o entendimento do que está ocorrendo no projeto. | Eliminar |