-
Notifications
You must be signed in to change notification settings - Fork 4
Politicas
- Objetivos prioritários ordenados em conjunto com a PO
- Item priorizado pela PO como necessário dentro dos nossos objetivos prioritários
- Melhorias técnicas priorizadas em conjunto com a mentoria técnica
- Dupla designada para identificar critérios de aceitação junto a PO
- Critérios foram elaborados de forma colaborativa com equipe (pelo menos duas pessoas) + PO
- Todos os critérios de aceitação foram aceitos pelas PO
- Item é pequeno o suficiente para ser entregue em uma semana
- Item categorizado como fácil, médio ou difícil
- Front e back em cards separados
- Item selecionado por uma dupla para ser desenvolvido
- Cada card é trabalhado por no máximo uma dupla, outros colegas podem entrar temporariamente para ajudar em alguma questão específica, mas não ficam atribuidos ao card
- Dupla não pode trabalhar junta mais do que uma semana com matriz de pareamento sendo respeitada
Para itens que envolvem código
- Item desenvolvido em par
- Entrega cobrindo todos os critérios de aceitação identificados
- Todo o código commitado em branch específico
- Código atualizado contra a última versão do main
- Testes locais realizados pelos desenvolvedores
- Código seguindo as convenções acordadas pela equipe
- Quando modificação é significativa, item selecionado ou designado para code review por algum mentor técnico através de um pull request
- Quando modificação é pequena, code review pode ser feita por alguma outra pessoa de equipe (ou dupla)
- (depende spike hospedagem) Branch deployado e funcionando em ambiente beta
- Ajustes relevantes que foram identificados na code review adicionados no branch pela dupla que fez o desenvolvimento ou
- Item que não coloca código em produção
Somente para itens que modificam código
- Item designado para dupla ou para pessoa diferente da que fez o desenvolvimento
- Branch disponível para teste no ambiente de stage
- Interface consistente com os padrões estabelecidos para a aplicação
- Site precisa ser responsivo (não nos preocupamos com o Strapi)
- Páginas do site funcionando em Safari, Chrome
- Critérios de aceitação verificados
- Stage atualizado e funcionando
- Teste exploratório realizado para validação do comportamento geral de funcionalidades relacionadas
- Item selecionado para apresentação no próximo showcase
- (quando código) Branch mergeado com o main e disponível em stage
Somente para itens que vão para produção:
- Item aceito no showcase ou modificações sugeridas no showcase implementadas e disponíveis para deploy
Para itens que vão para produção:
- Item deployado em produção (normalmente as segundas)
-
test: indica qualquer tipo de criação ou alteração de códigos de teste. Exemplo: Criação de testes unitários.
-
feat: indica o desenvolvimento de uma nova feature ao projeto. Exemplo: Acréscimo de um serviço, funcionalidade, endpoint, etc.
-
refactor: usado quando houver uma refatoração de código que não tenha qualquer tipo de impacto na lógica/regras de negócio do sistema. Exemplo: Mudanças de código após um code review
-
style: empregado quando há mudanças de formatação e estilo do código que não alteram o sistema de nenhuma forma. Exemplo: Mudar o style-guide, mudar de convenção lint, arrumar indentações, remover espaços em brancos, remover comentários, etc..
-
fix: utilizado quando há correção de erros que estão gerando bugs no sistema. Exemplo: Aplicar tratativa para uma função que não está tendo o comportamento esperado e retornando erro.
-
chore: indica mudanças no projeto que não afetem o sistema ou arquivos de testes. São mudanças de desenvolvimento. Exemplo: Mudar regras do eslint, adicionar prettier, adicionar mais extensões de arquivos ao .gitignore
-
docs: usado quando há mudanças na documentação do projeto. Exemplo: adicionar informações na documentação da API, mudar o README, etc.
-
build: utilizada para indicar mudanças que afetam o processo de build do projeto ou dependências externas. Exemplo: Gulp, adicionar/remover dependências do npm, etc.
-
perf: indica uma alteração que melhorou a performance do sistema. Exemplo: alterar ForEach por while, melhorar a query ao banco, etc.
-
ci: utilizada para mudanças nos arquivos de configuração de CI. Exemplo: Circle, Travis, BrowserStack, etc.
-
revert: indica a reverão de um commit anterior.
COMMIT:
Mensagem de commit:
git commit -m "feat(pages/home): descrição do que eu tenha feito - @teuarroba - @outrapessoa"
BRANCHS:
Nomenclatura para branchs: 1xxx-nome-do-card
OBERSERVAÇÕES:
Commit: 1.1 colocar até no máximo 2 caminhos para não ficar muito extenso
Branch: 2.2 sempre que tiver algum espaço, colocar um "-" para fazer a separação