Imagine um restaurante onde o cozinheiro tenta preparar 20 pratos simultaneamente. Nenhum prato recebe atenção adequada, todos demoram mais, a qualidade cai e o estrêsse sobe. Agora imagine que o cozinheiro decide preparar no máximo 3 pratos por vez, terminando cada um antes de começar o próximo. Os pratos ficam prontos mais rápido, com melhor qualidade, e o cozinheiro trabalha com mais calma.
Essa analogia ilustra perfeitamente o conceito de WIP Limit (Work in Progress Limit): uma restrição deliberada na quantidade de trabalho que pode estar em andamento simultaneamente. E um dos princípios mais contra-intuitivos é mais poderosos do Kanban, e quando bem implementado, transforma radicalmente a produtividade de times de desenvolvimento.
O que é WIP Limit
WIP Limit e um número máximo de itens de trabalho que podem estar em uma determinada coluna do quadro Kanban ao mesmo tempo. Por exemplo, se a coluna "Em Desenvolvimento" tem um WIP limit de 3 e já tem 3 tarefas, ninguém pode mover uma nova tarefa para essa coluna até que uma das existentes seja concluida e movida para a próxima etapa.
O WIP limit pode ser aplicado em diferentes níveis:
- Por coluna: limite de itens em cada etapa do fluxo (ex: máximo 3 em "Em Desenvolvimento", máximo 2 em "Code Review").
- Por pessoa: limite de tarefas que cada membro do time pode ter simultaneamente (ex: máximo 2 tarefas por pessoa).
- Por time: limite total de itens em progressó para o time inteiro.
Por que limitar o trabalho em progresso
1. O custo oculto do context switching
O cerebro humano não e multitarefa. O que chamamos de "multitarefa" e, na verdade, alternancia rápida entre tarefas (context switching). Cada alternancia tem um custo cognitivo significativo. Pesquisas mostram que alternar entre duas tarefas pode consumir até 40% da capacidade produtiva de uma pessoa.
Para desenvolvedores, o custo e ainda maior. Programar exige manter modelos mentais complexos na memória: a estrutura do código, as dependências, o fluxo de dados, os edge cases. Quando um desenvolvedor alterna para outra tarefa, todo esse modelo mental e perdido e precisa ser reconstruído quando ele volta.
| Tarefas simultaneas | Tempo produtivo por tarefa | Perda por context switching |
|---|---|---|
| 1 | 100% | 0% |
| 2 | 40% | 20% |
| 3 | 20% | 40% |
| 4 | 10% | 60% |
| 5+ | 5% | 75% |
Os números são claros: com 5 tarefas simultaneas, o desenvolvedor gasta mais tempo alternando entre tarefas do que efetivamente trabalhando em qualquer uma delas.
2. Lei de Little: a matematica por tras do WIP limit
A Lei de Little e um teorema matematico que estabelece uma relação direta entre três variáveis de um sistema de filas:
Lead Time = WIP / Throughput
Em termos simples: o tempo que uma tarefa leva para ser concluida (lead time) e igual ao número de tarefas em progresso (WIP) dividido pela taxa de conclusão de tarefas (throughput). Isso significa que, mantendo o throughput constante, a única forma de reduzir o lead time e reduzir o WIP.
Em termos práticos: se seu time conclui 5 tarefas por semana e tem 20 tarefas em progresso, o lead time medio e de 4 semanas. Se você reduzir o WIP para 10, o lead time cai para 2 semanas, sem nenhuma mudança na capacidade do time.
3. Visibilidade de gargalos
Sem WIP limits, problemas no fluxo ficam escondidos. Se a coluna de "Code Review" está acumulando tarefas, o time simplesmente puxa mais trabalho para "Em Desenvolvimento" e ignora o gargalo. Com WIP limits, quando a coluna de Code Review atinge seu limite, o time e forcado a parar e resolver o gargalo antes de continuar.
Isso e exatamente o que o Kanban pretende: tornar problemas visíveis e forcar o time a resove-los imediatamente, em vez de empurra-los para frente.
4. Foco e qualidade
Quando um desenvolvedor trabalha em uma única tarefa, ele pode dedicar toda sua atenção a ela. O resultado e código melhor escrito, menos bugs, soluções mais elegantes é menos retrabalho. A qualidade melhora naturalmente quando o foco aumenta.
5. Previsibilidade
Com WIP limits, o fluxo de trabalho se torna mais estável é previsível. A variação no lead time diminui, o que permite ao time fazer previsões mais acuradas sobre quando tarefas serão concluídas. Stakeholders apreciam previsibilidade mais do que velocidade.
Como definir WIP limits
Não existe uma formula magica para o WIP limit perfeito. O valor ideal depende do tamanho do time, da natureza do trabalho e da maturidade do processo. Mas existem diretrizes úteis.
Regra prática para começar
Uma boa regra para iniciar e: WIP limit por coluna = número de pessoas que trabalham nessa etapa + 1. O "+1" oferece uma pequena folga para que ninguém fique parado esperando.
Exemplo para um time de 4 desenvolvedores e 2 revisores:
| Coluna | Pessoas | WIP Limit inicial |
|---|---|---|
| To Do | - | Sem limite (e um backlog) |
| Em Desenvolvimento | 4 devs | 5 |
| Code Review | 2 revisores | 3 |
| Em Teste | 1 QA | 2 |
| Done | - | Sem limite |
Ajustando ao longo do tempo
O WIP limit inicial e apenas um ponto de partida. O time deve observar o fluxo e ajustar:
- Se ha muita ociosidade: o WIP limit pode estar baixo demais. Aumente em 1.
- Se tarefas ficam muito tempo em progresso: o WIP limit pode estar alto demais. Reduza em 1.
- Se uma coluna está sempre cheia: ha um gargalo que precisa ser resolvido (mais revisores, mais automação, etc.).
A recomendação e fazer ajustes pequenos (1 unidade por vez) e observar o efeito por pelo menos 2 semanas antes de ajustar novamente.
O que fazer quando o WIP limit e atingido
O momento mais crítico do WIP limit e quando ele e violado. E nesse momento que a magia acontece, ou não. Se o time simplesmente ignora o limite e puxa mais trabalho, o WIP limit é inútil. A disciplina de respeitar o limite e o que gera os benefícios.
Quando o WIP limit e atingido, o time tem várias opções:
- Ajudar com o gargalo: se a coluna de Code Review está cheia, desenvolvedores podem parar de codar e ajudar a revisar PRs.
- Trabalhar em pair programming: dois desenvolvedores podem trabalhar juntos em uma tarefa em vez de cada um pegar uma tarefa nova.
- Investir em melhorias: usar o tempo para refatorar, escrever testes, melhorar documentação ou automatizar processos.
- Investigar bloqueios: se tarefas estão paradas, o time deve investigar e resolver os impedimentos.
"Pare de começar, comece a terminar." Este e o mantra do WIP limit. Em vez de iniciar mais trabalho, foque em concluir o que já está em andamento.
WIP limits e Scrum: podem coexistir?
Muitos times usam Scrum e se perguntam se WIP limits se aplicam. A resposta e sim. Embora o Scrum não mencione WIP limits explícitamente, o conceito do Sprint Backlog já é uma forma de limitação de WIP: o time se compromete com uma quantidade fixa de trabalho para a sprint.
Adicionar WIP limits dentro da sprint, nas colunas do quadro Kanban, complementa o Scrum ao melhorar o fluxo diário de trabalho. Essa combinação de Scrum com práticas Kanban e frequentemente chamada de "Scrumban" e e adotada por muitos times de alta performance.
Resistencia ao WIP limit e como supera-la
"Vou ficar sem nada para fazer"
Este e o medo mais comum. Na prática, raramente acontece. Sempre ha trabalho útil a ser feito: ajudar colegas, fazer code review, refatorar código, escrever testes, melhorar documentação. O WIP limit não cria ociosidade; ele redireciona o esforço para atividades que normalmente são negligenciadas.
"O gerente vai achar que não estou trabalhando"
Esse medo reflete uma cultura de "ocupação como virtude". A solução e educar os stakeholders sobre a diferença entre estar ocupado e ser produtivo. Um desenvolvedor trabalhando em 5 tarefas simultaneamente pode parecer mais ocupado do que um trabalhando em 1, mas o segundo provavelmente está entregando mais valor real.
"Algumas tarefas precisam esperar por dependências externas"
Para tarefas bloqueadas por dependências externas, crie uma coluna "Bloqueado" ou "Aguardando" que não conte contra o WIP limit da coluna ativa. Mas monitore essa coluna de perto para evitar que se torne um deposito de tarefas esquecidas.
Métricas para monitorar o impacto do WIP limit
Após implementar WIP limits, acompanhe estas métricas para verificar o impacto:
- Lead time: deve diminuir conforme o WIP e reduzido.
- Throughput: deve se manter estável ou aumentar.
- Variação do lead time: deve diminuir, indicando maior previsibilidade.
- Cumulative Flow Diagram (CFD): as bandas devem ficar mais uniformes, indicando fluxo estável.
- Taxa de bloqueio: deve diminuir conforme gargalos são identificados e resolvidos.
WIP limits no GalagoWork
O GalagoWork suporta WIP limits nativamente no quadro Kanban. Você pode definir um limite máximo para cada coluna, e o sistema sinaliza visualmente quando o limite está próximo de ser atingido ou quando e violado. Isso torna fácil para todo o time manter a disciplina e identificar gargalos em tempo real.
Além disso, as notificações em tempo real do GalagoWork alertam o time quando tarefas ficam paradas por muito tempo em uma coluna, ajudando a manter o fluxo saudável.
Conclusão
WIP limits são uma das mudanças mais simples é mais impactantes que um time pode fazer no seu processo de trabalho. Ao limitar conscientemente o trabalho em progresso, o time reduz o context switching, melhora o lead time, aumenta a qualidade e ganha previsibilidade.
O conceito e contra-intuitivo: fazer menos coisas ao mesmo tempo para entregar mais no total. Mas a matematica e a experiência de milhares de times comprovam que funciona. Comece com limites conservadores, observe os resultados e ajuste. Em poucas semanas, você vai perceber a diferença no ritmo e na qualidade das entregas do seu time.
Lembre-se: pare de começar, comece a terminar.