Todo o desenvolvimento segue um fluxo baseado em Kanban/Scrum/Agile que segue uma sequência lógica para resolução de um problema ou implementação de uma nova funcionalidade
graph TD;
IssueOpened-->Feature;
IssueOpened-->Bug;
IssueOpened-->Adjust;
IssueOpened-->Improvement;
IssueOpened-->Quality;
IssueOpened-->Discovery;
IssueOpened-->Docs;
Feature-->Closed;
Bug-->Closed;
Adjust-->Closed;
Improvement-->Closed;
Docs-->Closed;
Quality-->Closed;
Discovery-->Closed;
Cada tipo de issue define o tipo de implementação a ser feita no código
- Feature: Novas funcionalidades, normalmente algo que ainda não existe na aplicação
- Bug: Problema a ser resolvido, que muito provavelmente impossibilita e/ou atrapalha a execução de alguma ação
- Adjust: Pequenas modificações que não chegam a ser nova funcionalidade, por exemplo, alterar a cor de algo
- Improvement: Melhoria significativa em alguma funcionalidade já existente, por exemplo, melhorar uma validação de um formulário
- Quality: Tarefas que envolvem a qualidade do código, normalmente algumra refatoração
- Discovery: Dificilmente envolvem código, mas sim, levantamento de informações sobre alguma biblioteca e/ou abordagem técnica a ser utilizada, por exemplo, uso da autenticação com GovBr
- Docs: Tarefas que envolvem criação e/ou melhoria exclusivamente da documentação, como a criação deste fluxo
Para abrir uma nova issue, clique aqui
O branch principal (produção), é o
main
, ele não é atualizado constantemente, e toda e qualquer alteração deve ser feita através de pull requests vindos diretamente da branchdevelop
---
title: Exemplo do fluxo de vida dos branches
---
gitGraph
commit
commit
branch homolog
commit
commit
branch develop
commit
checkout develop
branch fix/any-bug
commit
checkout develop
commit
merge fix/any-bug
checkout homolog
merge develop
commit
checkout main
merge homolog
Para abrir um novo Pull Request, leia aqui
Internamente a equipe se autogerencia seguindo as boas práticas da metodologia SCRUM e do desenvolvimento ágil, escolhendo, de acordo com suas habilidades e disponibilidades aquelas issues que fazem sentido e são possíveis de serem implementadas:
graph TD;
Idea-->ProductBacklog
ProductBacklog-->SprintBacklog;
SprintBacklog-->ToDo;
ToDo-->InProgress;
InProgress-->Blocked;
InProgress-->Review;
Review-->Test;
Review-->InProgress;
Test-->Done;
Test-->InProgress;
Blocked-->ProductBacklog;
Blocked-->Closed;
- Idea: é um status de uma issue ainda em criação e/ou rascunho, ao ser finalizada a mesma é automaticamente entendida como "Product Backlog"
- Product Backlog: Basicamente significa que isso deve ser entregue, não sabe-se certo quando, mas precisa ser entregue em algum momento
- Sprint Backlog: Deve ser entregue nas duas próximas semanas (ou na semana corrente)
- ToDo: Já possui alguém (auto) definido para essa task, e essa pessoa já está atrás das informações necessárias para a mesma
- InProgress: O trabalho começou a ser de fato realizado (codificando)
- Review: O código está pronto para ser revisado por outras pessoas do time
- Test: O código já foi revisado e precisa ser testado no ambiente de homologação
- Done O código já foi revisado e precisa ser testado no ambiente de homologação
- Closes: O código já foi revisado e precisa ser testado no ambiente de homologação
Prioridade | Descrição |
---|---|
Very High | Tarefa de prioridade máxima, provavelmente um bug |
High | Tarefa de prioridade alta, provavelmente algo que não esteja funcionando corretamente |
Medium | Tarefa normal |
Low | Tarefa um pouco importante |
Very Low | Tarefa que não é nem um pouco importante |
Peso | Descrição |
---|---|
1 | Tarefa muito simples |
2 | Tarefa simples |
3 | Tarefa mediana |
5 | Tarefa muito complexa |
seguindo a sequência fibonacci, se uma task tiver tamanho 8 (oito), significa que precisa ser quebrada em duas ou mais