ADR-004: Metodologia Ágil e Gestão de Capacidade
Título
Adoção do Scrum-ban Adaptativo com sprints semanais e regra de Capacidade Declarada para gestão do desenvolvimento.
Status
Aceito
Data
2026-02-27
Contexto
A equipe é composta por estudantes universitários sujeitos à flutuação constante de carga horária acadêmica, semanas de provas, trabalhos e demais obrigações de outras disciplinas. O uso de um framework ágil tradicional e rígido poderia gerar sobrecarga, atrasos artificiais e frustração, comprometendo a qualidade das entregas e o bem-estar da equipe.
Decisão
A equipe adotou a metodologia Scrum-ban Adaptativo, gerenciada via GitHub Projects, com as seguintes regras:
- Duração da Sprint: 1 semana, alinhada à reunião periódica com o professor orientador.
- Rito único: A reunião semanal com o orientador serve simultaneamente como Review, Retrospectiva e Planning.
- Capacidade Declarada: Em semanas de alta carga acadêmica, a equipe pode declarar "baixa capacidade", reduzindo intencionalmente as tarefas da Sprint ou acionando uma "Sprint de Pausa" focada apenas em documentação.
- Prazo máximo por issue: Tarefas só são aceitas na Sprint se puderem ser concluídas em até 3 dias úteis. Tarefas maiores são obrigatoriamente fatiadas em subtarefas menores.
A alternativa descartada foi o Scrum Tradicional com sprints de 2 a 4 semanas e metas fixas de Story Points, inadequado para a variabilidade do calendário acadêmico.
Consequências
Positivas:
- Adaptação à realidade acadêmica: O ciclo curto e a flexibilidade de capacidade evitam sobrecarga e atrasos artificiais.
- Rastreabilidade para PIVIC: A integração das Issues do GitHub com o quadro Kanban assegura trilha contínua para os relatórios de Iniciação Científica.
- Alinhamento com orientação: A Sprint semanal casa exatamente com o ritmo das reuniões de orientação.
Negativas:
- Imprevisibilidade de Velocity: A flutuação constante de capacidade dificulta o cálculo preciso da velocidade da equipe e a estimativa de datas de conclusão de Épicos maiores.
Conformidade
- Toda tarefa deve ser registrada como uma Issue no GitHub Projects antes de ser iniciada.
- Issues aceitas em uma Sprint devem ser concluíveis em no máximo 3 dias úteis; caso contrário, devem ser fatiadas.
- A declaração de "baixa capacidade" ou "Sprint de Pausa" deve ser registrada no comentário da reunião semanal correspondente no GitHub.
Observações
- Autor: João Pedro Santos de Brito
- Versão: 1.0
- Changelog:
- 1.0 - 27/02/2026: versão inicial (João Pedro S. de Brito)
Referências: