Regras de Trabalho

🎯 1. Issues no GitLab — 8 critérios obrigatórios

• 1
  Título com verbo no infinitivo. Ex.: Implementar tela de login, Criar diagrama de classes. Não use substantivo (Tela de login).
• 2
  Descrição presente com pelo menos um parágrafo de contexto e objetivo (mais de 40 caracteres).
• 3
  Objetivo explícito dentro da descrição. Use o cabeçalho **Objetivo da tarefa:** e descreva em 1–2 linhas.
• 4
  Critérios de DoD (Definition of Done). Use **DoD:** com checklist verificável: [ ] testes passando · [ ] PR aprovado · [ ] docs atualizada.
• 5
  Critérios de DoR (Definition of Ready). Use **DoR:** listando pré-condições para começar: design aprovado, API documentada, ambiente ok.
• 6
  Responsável atribuído (assignee). A pessoa que pegar o card para fazer tem que colocar o próprio nome no campo Assignee da issue. Cada issue = um único dono = quem está executando.
• 7
  Labels definidas. Pelo menos: tipo (FEATURE, BUG FIX, DOCUMENTATION), tamanho (SIZE_PP, SIZE_P, SIZE_M, SIZE_G) e prioridade (PRIORIDADE ALTA).
• 8
  Vinculada a milestone (sprint). Todo trabalho mora dentro de Sprint 01, Sprint 02, etc. Issue sem milestone = trabalho fora do sprint.

Template mínimo de issue (cole na descrição)

**Objetivo da tarefa:** <1-2 linhas>

**Contexto:** <por que estamos fazendo isso>

**DoR (Definition of Ready):**
- [ ] Design aprovado
- [ ] Dependências mapeadas
- [ ] API contract definido

**DoD (Definition of Done):**
- [ ] Implementado
- [ ] Testes unitários passando
- [ ] MR aprovado por 1 revisor
- [ ] Documentação atualizada

💬 2. Conventional Commits — semântico + vinculado a issue

O dashboard só conta o commit como verde (adequado) se ele for semântico E referenciar uma issue da sprint pelo número (#N). Caso contrário ele aparece como vermelho (não conforme) nas barras por autor.

Formato

<tipo>(<escopo opcional>): <descrição curta> (#<issue>)

[corpo opcional explicando o porquê]

[footer opcional: BREAKING CHANGE: …, Closes #N]

11 tipos aceitos

O dashboard aceita commits que casam com este regex:

^(feat|fix|docs|style|refactor|test|chore|perf|ci|build|revert)(\(.+\))?(!)?\s*:

Regras de ouro

1. Sempre referencie a issue com #N em algum lugar da mensagem (título ou corpo). Sem isso o dashboard marca como não conforme.
2. Imperativo no infinitivo, não no passado: adicionar ✅ — adicionei ❌.
3. Descrição curta (máximo 72 caracteres na primeira linha).
4. Breaking change: use ! após o tipo e BREAKING CHANGE: no rodapé. Ex.: feat(api)!: trocar /v1/users por /v2/users.
5. Um commit = uma intenção. Não misture feat com refactor no mesmo commit.

🌿 3. Git Flow + Merge Requests

Branches permanentes

• main — espelho do que está em produção. Protegida: ninguém faz push direto.
• develop — integração contínua do sprint. Toda feature finalizada faz merge aqui antes de ir pra main.

Branches de trabalho

O dashboard valida o nome da branch contra:

^(feature|feat|fix|bugfix|hotfix|docs|doc|style|refactor|test|chore|perf|ci|build|release)/

Ou seja: o nome deve começar com um desses prefixos seguido de barra:

Convenção de nome: tipo/descricao-curta-em-kebab-case. Ex.: feature/login-com-google, fix/validar-email-no-cadastro, docs/readme-setup.

Fluxo padrão de uma feature

git checkout develop && git pull
git checkout -b feature/login-com-google

# … codifique, commite com Conventional Commits …
git commit -m "feat(auth): adicionar provedor Google OAuth (#12)"
git commit -m "test(auth): cobrir fluxo de callback (#12)"

git push -u origin feature/login-com-google
# Abrir Merge Request no GitLab → develop

8 critérios obrigatórios do Merge Request

O dashboard pontua cada MR pelos mesmos checklists:

• 1
  Título descritivo, mais de 3 palavras, sem WIP: ou Draft:. Use o mesmo formato do commit principal.
• 2
  Descrição substantiva (mais de 40 caracteres) com seções ## O que foi feito e ## Como testar.
• 3
  Linkado bidirecionalmente com a issue. Vale qualquer uma das duas formas (ou as duas):
  • #N da issue dentro da descrição do MR — ideal: Closes #N, que fecha a issue automaticamente quando o MR for mergeado.
  • Link do MR dentro da descrição da issue — cole a URL completa, ex.: https://git.inteli.edu.br/…/-/merge_requests/42.
  Sem esse vínculo, o dashboard não consegue rastrear "qual MR entregou qual issue" e o sprint perde pontuação de rastreabilidade.
• 4
  Reviewer designado antes de pedir merge — campo Reviewers.
• 5
  Branch de origem padronizada (feature/, fix/, docs/, etc.). Branches desenvolvimento-fulano são reprovadas.
• 6
  Labels definidas no MR (FEATURE, BUG FIX, DOCUMENTATION).
• 7
  Vinculado a milestone (a mesma sprint da issue de origem).
• 8
  Revisão com comentários (mais de 0 notas). MR aprovado num clique não conta como revisão real.

Template mínimo de MR (cole na descrição)

Closes #<número da issue>

## O que foi feito
- <ponto principal>
- <ponto secundário>

## Como testar
1. <passo>
2. <passo>
3. <resultado esperado>

## Checklist
- [ ] Testes unitários passando
- [ ] Sem warnings de lint
- [ ] Documentação atualizada (se aplicável)

🏁 4. Sprint, Kanban & Scrum no Inteli

Cadência: 5 sprints de 2 semanas cada. Cada sprint é uma milestone no GitLab (Sprint 01 … Sprint 05). Toda issue e todo MR obrigatoriamente apontam para um milestone.

Quadro Kanban — 6 colunas obrigatórias

Espelhe os labels do GitLab Board:

🐞 Bug encontrado em review — protocolo

Quando uma issue está em review e o revisor identifica um bug, não empurre o trabalho de volta no mesmo card. Siga este protocolo para preservar rastreabilidade:

• 1
  Aplicar label BUG na issue original que está em review (ela permanece em review, agora marcada como contendo bug detectado).
• 2
  Criar uma nova issue para tratar o bug. O título da nova issue deve conter a cerquilha com o número da issue original. Ex.: Corrigir validação de e-mail reportada em #42.
• 3
  Vincular a nova issue ao mesmo MR onde a revisão detectou o bug (a correção entra no mesmo merge — não abra outro MR).
• 4
  Aplicar label BUG também na nova issue, junto com as labels usuais (tamanho, prioridade, milestone).
• 5
  Fechamento conjunto: quando a nova issue (do bug) for concluída e revisada com sucesso, ambas — a original e a do bug — passam para closed ao mergeio do MR compartilhado.

🚧 Impedimento no desenvolvimento — label BLOCK

Se você está em doing e algo externo trava o trabalho (dependência de outro time, ambiente fora, decisão pendente, API quebrada, etc.), não mantenha o card em silêncio:

• 1
  Aplicar label BLOCK na issue imediatamente.
• 2
  Adicionar um comentário na issue (campo Comments — não editar a descrição) explicando o porquê do block: o que está bloqueando, de quem/do quê depende, e desde quando.
• 3
  Levar para a próxima Daily — impedimentos são uma das 3 perguntas obrigatórias do stand-up.
• 4
  Adicionar novo comentário quando o impedimento for resolvido (ex.: "Desbloqueado em 21/05 — time de infra liberou o acesso ao banco staging") e remover a label BLOCK.

Cerimônias Scrum (versão Inteli)

Papéis (rotativos a cada sprint)

Para o time aprender todos:

• Product Owner (PO): dono do backlog, prioriza, garante que issues têm DoR.
• Scrum Master (SM): facilita cerimônias, remove impedimentos, defende o time.
• Dev Team: implementa, revisa, testa. Auto-organizado.

O que o Dashboard mede automaticamente

• Burndown Chart — trabalho restante vs ideal (descobre se vão entregar).
• Cumulative Flow — engrossamento por coluna = gargalo (descobre onde o trabalho trava).
• Throughput semanal — issues fechadas por semana (consistência mais que pico).
• Lead Time — dias entre criar e fechar uma issue (verde até 3 / âmbar 4–7 / vermelho mais de 7).
• WIP — issues abertas por dia (descobre sobrecarga).
• Cycle Time de MR — dias entre abrir e mergear MR (revisão lenta = sinal de alerta).
• Matriz Autor × Revisor — quem revisa quem (revela "quem nunca revisa ninguém").
• Frequência de commits por dia — distribuído mais que commit storm na sexta da entrega.

📌 Checklist final — antes de fechar a sprint

• ✓
  Toda issue da sprint nasceu em open e seguiu o fluxo do Kanban sem pular colunas.
• ✓
  Toda issue da sprint tem milestone, assignee, labels, DoD e DoR preenchidos.
• ✓
  Todos os commits seguem Conventional Commits + #N da issue.
• ✓
  Branches usam prefixo padrão (feature/, fix/, docs/, etc.) em kebab-case.
• ✓
  Todo MR tem reviewer, milestone, labels, descrição com "O que foi feito" e "Como testar", e pelo menos 1 comentário de revisão real.
• ✓
  Cards do Kanban movidos diariamente — sem cards parados em doing ou waiting review por mais de 3 dias.
• ✓
  Daily, Review e Retrospective aconteceram e geraram saídas concretas.
• ✓
  Sem commit storm: commits distribuídos ao longo das 2 semanas.