Visão geral
A Metodologia Granular é um framework para times técnicos que prioriza determinismo, transparência e previsibilidade. Ela foi pensada para o desenvolvimento de software e controla o fluxo de trabalho em detalhe.
Para quem é
Para times de 3 pessoas ou mais. Times menores não têm os problemas que o framework resolve: comunicação entre várias pessoas, visibilidade do trabalho em andamento e métricas de fluxo. As regras deste manifesto, como “quem faz não valida” e os registros obrigatórios, só se pagam nessa escala, e por isso não há exceção para times menores.
O que mudou desde a v1.0
A IA passou a escrever boa parte do código, e o gargalo mudou de lugar:
- Em Desenvolvimento, que era a coluna mais longa, virou a mais rápida.
- Refinamento, review e testes ficaram mais longos do que antes.
- A demanda chega sem contexto. Ela costuma vir de outra stream (design, UX, suporte), onde as pessoas já usaram IA e discutiram bastante, mas só o resultado chega ao time de dev.
- Dá para desenvolver várias tarefas em paralelo, mas sem o contexto na cabeça fica mais difícil refinar e validar.
Começar um card ficou barato, mas terminar continua caro. Por isso, a v2.0 move o controle de WIP para o fim do fluxo e obriga cada etapa a registrar o próprio contexto.
Princípios fundamentais
- 01Fluxo determinístico com etapas bem definidas.
- 02Pare de começar, comece a terminar: o WIP apertado fica na validação, não no desenvolvimento.
- 03Quem faz não valida.
- 04O card conta a própria história: cada etapa deixa um registro escrito.
- 05Todo erro em produção tem origem, e o custo dele volta para ela.
- 06Rastreamento temporal preciso de cada fase.
- 07Transparência total do processo.
Regras fundamentais
01Fluxo fixo e rastreável
Todo card segue o mesmo caminho, pelas mesmas 10 colunas, de Backlog a Done. Existem duas raias: a raia normal e a raia de Hotfix, que usa as mesmas colunas (ver regra 5).
02WIP (Work in Progress)
| Onde | Limite | Para quem vale |
|---|---|---|
| Em Desenvolvimento | Configurável por time (ex.: 3, 5) | Autor do card |
| Code Review / Em Testes (em andamento) | 1 | Quem está revisando ou testando |
| Raia de Hotfix | 1 | Dev do hotfix |
- O limite de Em Desenvolvimento depende mais da capacidade das ferramentas de IA (créditos, por exemplo) do que da atenção do dev. Por isso ele é configurável.
- Na validação, o WIP = 1 é de quem valida, não do autor. É ali que o contexto mais pesa.
03Quem faz não valida
- O autor não revisa nem testa o próprio card. Isso evita o viés de quem desenvolveu.
- O card tem três campos diferentes: autor, revisor e testador. Quem revisa e quem testa podem ser pessoas diferentes, mas nenhum dos dois pode ser o autor.
04Empurrão para validar
O sistema bloqueia a entrada de um card novo em Em Desenvolvimento quando as duas condições abaixo valem ao mesmo tempo:
- existe card de outra pessoa aguardando em Code Review ou Em Testes;
- e o dev não está validando nenhum card.
Há 3 cards aguardando review. Pegue um antes de começar outro.
O hotfix sempre passa. A regra existe para que quem está com o desenvolvimento travado ajude a terminar o trabalho dos outros, em vez de deixar uma pilha de cards para o time validar.
05Hotfix e bug grave
- Origem é rastreio, hotfix é prioridade. Qualquer card de correção pode apontar a entrega de origem, que causou o problema, e isso alimenta o custo dela. O hotfix é um privilégio, e por isso precisa ser raro.
- Definição: hotfix é a correção de um problema em produção causado por uma entrega “quente”, que chegou ao Done há no máximo N dias. N é configurável por time, e o padrão é 2 dias. Passou disso, não é hotfix: é bug, e segue a raia normal.
- Impacto declarado: o card de hotfix tem um campo obrigatório: “o que acontece se isso esperar o fluxo normal?”.
- Quem declara: qualquer pessoa do time, de preferência quem encontrou o problema ou quem desenvolveu a entrega de origem.
- WIP: 1 hotfix por dev.
- Prioridade: na validação, o hotfix fura a fila e pode interromper um review ou teste em andamento.
- Interrupções: enquanto o hotfix está ativo, os cards interrompidos continuam contando tempo e registram a interrupção. Esse tempo também é somado ao custo da entrega de origem.
- Conclusão: o hotfix só termina quando todo o retrabalho termina: testes, backfill, limpeza e correção de dados.
- História: o hotfix herda a história da entrega de origem (ver regra 6), que serve de base para o post-mortem.
- Bug grave: um bug fora da janela segue a raia normal. Quando é grave, pode ganhar prioridade e passar na frente, mas cada card pausado para ele registra a interrupção, com o bug como justificativa. O registro explica o aumento do lead time do card pausado, e a pausa não conta contra ele.
06O card conta a própria história
Cada etapa anexa ao card um registro em Markdown. Todos são obrigatórios.
| Registro | Quem escreve | Conteúdo |
|---|---|---|
| Passagem | Stream de origem (relator) | Problema, decisões, alternativas descartadas, restrições, perguntas em aberto, critérios de sucesso, fontes |
| Refinamento | Time de dev | Respostas às perguntas em aberto, decisões técnicas, critérios de aceite |
| Desenvolvimento | Autor | O que foi feito, onde a implementação desviou do refinamento e por quê |
| Review | Revisor | O que foi revisado, problemas encontrados e como foram resolvidos, riscos |
| Validação | Testador | O que foi testado, o que ficou de fora, riscos |
- O registro de Passagem segue o estilo de uma ADR (Architecture Decision Record), com um arquivo por demanda. Ele é a condição para a demanda entrar no fluxo. Modelo no Anexo A.
- Quem já discutiu a demanda com uma IA pode pedir para ela gerar o registro a partir da conversa, então o custo de escrever é baixo.
- Os registros servem de contexto para a IA que desenvolve e de referência para quem valida. Quem revisa compara o resultado com as decisões, sem precisar reconstruir de memória o que foi pedido.
07Responsabilidades claras
- O relator escreve o registro de Passagem e participa da primeira sessão de refinamento.
- O time de dev move o card do Backlog até Ready, passando pelo refinamento.
- O autor move o card de Ready até Code Review e escreve o registro de Desenvolvimento. Também corrige os defeitos e devolve o card para a validação.
- O revisor puxa o card da fila de Code Review, escreve o registro de Review e aprova (vai para Em Testes) ou reprova (vai para Defeitos).
- O testador puxa o card da fila de Em Testes, escreve o registro de Validação e aprova (vai para Aguardando Deploy) ou reprova (vai para Defeitos).
- Quem faz o deploy move o card de Aguardando Deploy para Done.
Fluxo de desenvolvimento
- 01
Backlog
- Tarefas aguardando priorização. Nenhuma ação permitida aqui além de coleta de contexto.
- Para sair daqui, o card precisa ter o registro de Passagem.
- 02
Pronto para Refinar
- Tarefas com o registro de Passagem, aguardando sessão de refinamento.
- 03
Em Refinamento
- Tarefas em discussão e detalhamento. O tempo de permanência nesta fase é medido.
- Para sair daqui, o card precisa ter o registro de Refinamento.
- 04
Ready to Develop / To do
- Tarefa refinada, pronta para desenvolvimento sem dúvidas.
- 05
Em Desenvolvimento
- Limite de WIP configurável por time.
- Autor obrigatório antes de mover para esta coluna.
- Co-autores podem ser indicados (pair programming), e o card conta uma vez só.
- A entrada está sujeita ao empurrão para validar (regra 4).
- Para sair daqui, o card precisa ter o registro de Desenvolvimento.
- 06
Code Review
- Análise técnica obrigatória, feita por alguém que não é o autor.
- Aguardando: fila, sem revisor.
- Em andamento: com revisor. WIP = 1 por revisor.
- Para sair daqui, o card precisa ter o registro de Review.
- 07
Em Testes
- Validação funcional em ambiente de testes, feita por alguém que não é o autor.
- Aguardando: fila, sem testador.
- Em andamento: com testador. WIP = 1 por testador.
- Para sair daqui aprovado, o card precisa ter o registro de Validação.
- 08
Defeitos
- Caso a tarefa falhe nos testes ou no QA. A movimentação deve indicar a causa do defeito: falha no refinamento, falha na execução, falha na definição de "Pronto" ou falha nos testes.
- O autor corrige e devolve o card para Code Review ou Em Testes, conforme o caso. O card volta para aguardando, reservado para o mesmo revisor ou testador que reprovou, que o pega quando estiver livre.
- 09
Aguardando Deploy
- Tarefa aprovada, aguardando entrada em produção. Quem faz o deploy move o card para Done.
- 10
Done / Concluído
- Tarefa finalizada com sucesso e em produção. No caso de hotfix, só depois de todo o retrabalho.
Métricas coletadas
Da v1.0
- Lead Time por fase (Refinamento, Desenvolvimento, Teste etc.)
- Throughput diário e semanal
- Tempo de parada e bloqueio
- Taxa de retrabalho (via coluna de Defeitos)
- Aderência ao WIP
- Histórico de co-autoria
- Eficiência por estimativa (T-shirt size vs. tempo real)
- Distribuição de tarefas por categoria e tipo
Novas na v2.0
- Hotfix com métricas próprias: volume, tempo até resolver e entrega de origem. O hotfix não entra nas médias da raia normal.
- Custo da entrega de origem: o tempo do hotfix, o tempo dos cards e validações interrompidos e o retrabalho são somados à entrega que causou o problema. A ideia é medir o impacto completo de uma entrega que foi dada como pronta antes de estar pronta.
- Hotfix por entrega: se subir, ou o time está entregando “pronto antes de estar pronto”, ou está usando o hotfix como atalho.
- Interrupções justificadas: o tempo que um card ficou pausado por um hotfix ou por um bug grave aparece separado no lead time dele, com a justificativa.
Anti-patterns combatidos
- Microgerenciamento sem contexto
- Devs pulando etapas (por exemplo, do Backlog direto para desenvolvimento)
- Ambiguidade sobre "pronto para desenvolver"
- Falta de accountability por parte do relator
- Tarefas com definição solta ou dependência não analisada
- Demanda que chega só com o resultado, sem as decisões e o contexto que a geraram
- Começar muito e terminar pouco: encher Em Desenvolvimento e deixar a validação para os outros
- Autor validando o próprio trabalho
- Hotfix como atalho: tratar como hotfix um bug antigo, só para furar a fila
- "Pronto" antes de estar pronto: entregar sem validação suficiente e gerar hotfix e retrabalho
Observações
- O framework opera com análise determinística: as regras de fluxo, WIP e bloqueio são aplicadas pelo sistema, sem depender de IA generativa.
- A IA é parte do trabalho do time, tanto para escrever código quanto para escrever os registros. O framework não depende dela, mas foi desenhado considerando que ela está presente.
- Nenhuma decisão crítica é da IA: aprovar um review ou um teste é sempre decisão de uma pessoa, que responde por ela. As ferramentas que essa pessoa usa para chegar lá, IA incluída, são escolha dela e não fazem parte do método.
Anexo A: modelo do registro de Passagem
# [Nome da demanda] Origem: design | ux | suporte | ... Relator: ... Data: ... ## Problema O que dói, para quem, e como sabemos (dados, tickets, entrevistas). ## Decisões - O que foi decidido, e por quê. ## O que foi descartado - Alternativa X: por que não. ## Restrições O que não pode mudar (prazo, legal, design system, dados). ## Perguntas em aberto O que a stream de origem sabe que NÃO sabe. ## Como saber que deu certo Critérios de aceite, ou o comportamento esperado. ## Fontes Links para Figma, tickets, conversas com IA etc.
Esta versão foi escrita a partir da prática do time com desenvolvimento assistido por IA e continuará evoluindo com a aplicação em times reais.
Quer aplicar no seu time?O Mensura é o board que aplica estas regras.
Falar no WhatsApp