Kanban: fluxo, limite de WIP, sistema puxado, lead time × cycle time × vazão

A ideia que organiza o assunto

O Kanban não é um processo de desenvolvimento. Ele não diz como se constrói software, não define papéis, não marca reuniões e não pede estimativa. O que ele faz é governar o andamento do trabalho que já existe — e por isso cabe em desenvolvimento, em sustentação, em um cartório e em uma linha de montagem, que foi onde nasceu, no sistema de produção da Toyota.

A ideia que organiza o assunto inteiro é uma só: o trabalho é puxado pela capacidade disponível, nunca empurrado pelo plano. Um item novo só começa quando alguma coisa terminou e abriu vaga. Não é o cronograma que autoriza o início; é a saída do item anterior.

E essa ideia tem um mecanismo, um só, que é onde mora a maior parte das questões: o limite de trabalho em progresso (WIP). O limite é o número máximo de itens que podem estar simultaneamente em uma etapa. Enquanto a etapa está no limite, nada entra. Quando um item sai, abre-se uma vaga e o próximo é puxado. Sem limite, o quadro é apenas um mural bonito de tarefas e o trabalho continua sendo empurrado.

Guardado isso, quase tudo se deriva:

Por que o Kanban não tem sprint. Iteração é um lote de tempo com escopo comprometido, e lote é a forma empurrada de organizar trabalho. O Kanban trabalha item a item, em fluxo contínuo.
Por que o limite revela o gargalo. Quando a etapa enche e para de puxar, a fila se forma imediatamente antes dela. O acúmulo aponta a restrição sem que ninguém precise procurá-la.
Por que menos trabalho em progresso entrega mais rápido. Mantida a capacidade, o tempo que cada item leva para atravessar o fluxo é proporcional à quantidade de itens em progresso: o que está na frente na fila atrasa o que vem atrás. É a Lei de Little, tempo de atravessamento igual a trabalho em progresso dividido por vazão. Começar mais coisas ao mesmo tempo não acelera nada — apenas distribui o atraso.

Vale dizer desde já o que a medição mostra: a Lei de Little não é citada por nenhum item do corpus, e as palavras throughput e vazão também não aparecem nenhuma vez em 16.161 itens. A aritmética não cai; ela serve para você não errar os itens que caem.

Por que se usa (e o que custa)

Ganha-se três coisas. Adoção sem reorganização: o Kanban começa com o processo que a equipe já tem, com os cargos que já existem, e não exige redesenhar nada para começar — o que o torna adotável onde uma transição para Scrum seria briga política. Visibilidade imediata: o quadro mostra onde cada item está e onde o trabalho trava, e isso é informação que a equipe não tinha. Fluxo mais curto: com menos itens abertos ao mesmo tempo, cai a troca de contexto e cai o tempo de entrega de cada item.

Paga-se em dois lugares, e os dois costumam ser subestimados.

Perde-se o compromisso de escopo por período. No Scrum, a sprint fecha um conjunto de itens e a equipe se compromete com uma meta. O Kanban não fecha nada: a previsibilidade, quando existe, vem de estatística — a distribuição histórica do lead time, que permite dizer que 85% dos itens saem em até tantos dias. Quem precisa de data com compromisso não tira isso do quadro.

Depende inteiramente de disciplina. O limite de WIP só funciona se for respeitado quando incomoda, que é exatamente quando alguém pede para “só encaixar mais um”. Um quadro com colunas e sem limite, ou com limite que se viola toda semana, não é sistema puxado: é o mesmo trabalho empurrado, agora com cartão colorido.

Como funciona

As práticas. O método se define por um conjunto pequeno de práticas, e a ordem entre as duas primeiras importa para a prova:

Visualizar o fluxo — montar o quadro que representa as etapas reais pelas quais o trabalho passa hoje, com um cartão por item. É a primeira prática, e é pré-requisito das outras: não se limita nem se gerencia o que não se enxerga.
Limitar o trabalho em progresso — pôr um teto por etapa. Os limites são introduzidos gradualmente e ajustados conforme o fluxo é compreendido, não decretados de uma vez em todas as colunas.
Gerenciar o fluxo — observar filas, acúmulos e tempos, e agir sobre a restrição. É atividade permanente, porque o gargalo se desloca: resolvido o acúmulo em uma etapa, a restrição migra para outra.
Tornar as políticas explícitas — o critério para um cartão passar de uma coluna à seguinte tem de estar escrito no quadro.
Implementar laços de feedback — reuniões curtas diante do quadro, revisões de fluxo, medição.
Melhorar de forma colaborativa e evoluir experimentalmente.

Os princípios de gestão da mudança explicam por que o Kanban se adota sem trauma: comece com o que você faz agora; concorde em buscar mudança incremental e evolutiva; respeite o processo, os papéis e os cargos atuais; estimule a liderança em todos os níveis. Ruptura, reorganização e mudança ousada são o contrário do método.

Os relógios. Três medidas de tempo são parecidas e contam coisas diferentes, e é aí que a banca trabalha.

Lead time — do pedido do cliente até a entrega. Inclui toda a espera, inclusive o tempo em que o item ficou parado na fila antes de alguém encostar nele. É a medida que o cliente sente.
Cycle time — do início efetivo do trabalho até a conclusão. É sempre menor ou igual ao lead time, e é medida de item terminado.
Idade do item de trabalho (work item age) — do início até agora, e só existe para o que ainda está em progresso. Serve para achar o cartão esquecido no quadro.

E duas medidas que não são de tempo: o WIP, contagem instantânea de itens em progresso, e a vazão (throughput), quantidade de itens concluídos por período. Estoque e taxa, respectivamente — confundir os dois é distorção registrada no corpus.

O gráfico. O Kanban acompanha desempenho pelo diagrama de fluxo cumulativo, que empilha a quantidade de itens em cada etapa ao longo do tempo — a largura horizontal de uma faixa é o tempo de atravessamento, e a vertical é o WIP. Burndown e velocidade pressupõem sprint, e portanto são do Scrum.

O que decide os itens

Kanban × Scrum. É a fronteira que decide mais itens do que qualquer outra coisa neste tópico.

	Scrum	Kanban
unidade de tempo	sprint, timebox fixo de um mês ou menos	nenhuma; fluxo contínuo
papéis	product owner, scrum master, desenvolvedores	não prescreve papel algum
compromisso	meta da sprint, escopo fechado no período	nenhum; o item flui quando há capacidade
entrada de trabalho	planejamento da sprint	limite de WIP: entra quando abre vaga
estimativa	prevista (pontos, velocidade)	não prescrita
métrica típica	burndown, velocidade	fluxo cumulativo, lead time, cycle time, vazão
mudança no meio	restrita durante a sprint	qualquer item pode ser repriorizado antes de entrar

Os dois não são excludentes: sobrepor o quadro e o limite de WIP ao Scrum tem nome, Scrumban, e a banca trata a combinação como correta. O que ela nunca aceita é o caminho inverso — importar sprint, burndown ou papel do Scrum para dentro do Kanban.

Os três relógios e as duas contagens.

medida	começa	termina	vale para
lead time	pedido do cliente	entrega	itens concluídos
cycle time	início efetivo do trabalho	conclusão	itens concluídos
idade do item	início efetivo do trabalho	agora	itens ainda em progresso
WIP	—	—	contagem em um instante
vazão	—	—	itens concluídos por período

Puxado × empurrado. Puxado: a etapa seguinte, ao liberar capacidade, autoriza a anterior a entregar-lhe trabalho. Empurrado: a etapa anterior produz conforme o plano e despeja o resultado na seguinte, formando estoque. O limite de WIP é o que implementa o puxado; o desperdício que ele evita é a superprodução.

O que o limite de WIP é e o que não é.

é	não é
teto de itens simultâneos por etapa	obrigação de concluir tudo antes de iniciar algo
introduzido gradualmente, etapa a etapa	decretado em todas as colunas desde o primeiro dia
o mecanismo que faz o gargalo aparecer	medida isolada, sem efeito sobre gargalo e melhoria
prática obrigatória do método	prática opcional, dispensável no quadro simples

O quadro. Três colunas — a fazer, fazendo, feito — são o ponto de partida clássico, não um limite: o quadro deve espelhar o fluxo real, quantas etapas ele tiver.

Como a CEBRASPE derruba você aqui

Os 28 itens deste tópico estão explicados: 14 Certos e 14 Errados. Entre os errados, quatro padrões, e o primeiro sozinho responde por mais de um terço.

Importar peça do Scrum para dentro do Kanban — 5 de 14, o mais frequente. A banca cola no Kanban aquilo que só o Scrum tem. “O Kanban e o Scrum utilizam sprints” — sprint é evento exclusivo do Scrum; o que regula a entrada de trabalho no Kanban é o limite de WIP. “devem utilizar o gráfico de Burndown”, dito de uma equipe que adotou Kanban — burndown mede o escopo restante de uma iteração, e sem iteração ele não tem eixo. O movimento também aparece do lado do Scrum, deformando o que é sprint: “Sprint é uma lista de requisitos organizados por funcionalidades priorizadas” (isso é o backlog do produto; sprint é o timebox) e “é executado em sala fechada e tem duração indeterminada” (o item chama a sprint de timeboxed e em seguida lhe tira a duração fixa). E, no limite, a própria natureza do método: “metodologia ágil para desenvolvimento de software” — o Kanban é método de gestão de fluxo, aplicável a qualquer trabalho, e não prescreve como se produz coisa alguma. A defesa é mecânica: sublinhe no item toda palavra do vocabulário do Scrum — sprint, burndown, velocidade, product owner, scrum master, planning, retrospectiva — e verifique a quem ela está sendo atribuída.

Deformar o limite de WIP — 4 de 14. É a prática mais cobrada do tópico e a mais adulterada. “As tarefas em andamento devem ser concluídas antes de se iniciarem novas tarefas” — o limite restringe quantidade simultânea, não sequência: havendo vaga dentro do limite, o próximo item entra. “sem impactar outros aspectos, como a identificação de gargalos e a melhoria contínua do fluxo de trabalho” — isola o limite do seu efeito principal, que é justamente fazer o gargalo aparecer. “postergando-se a visualização do fluxo para evitar interferências prematuras”, no mesmo item que exige limites “em todas as etapas do fluxo de trabalho desde o início” — as duas práticas na ordem invertida: visualiza-se primeiro, limita-se depois e gradualmente. E “em determinado período de tempo”, dito do WIP — troca estoque por taxa; quantidade por período é vazão. Antes de julgar qualquer item de limite, responda três perguntas: o limite é sobre quantidade ou sobre ordem? ele aparece antes ou depois da visualização? e o que o item diz que ele não afeta?

Fazer o Kanban prescrever ou romper — 3 de 14. “na busca por grandes mudanças consideradas ousadas em grandes projetos” — o princípio é o oposto: mudança incremental e evolutiva, respeitando processo e cargos atuais. “não podem ser utilizadas simultaneamente em um mesmo projeto ou no desenvolvimento de um mesmo produto” — premissa verdadeira (são distintos) com conclusão inventada (logo, excludentes); distinção não produz incompatibilidade. “não podendo ser representado por tarefas técnicas” — um formato recomendado, a história de usuário, transformado em regra exclusiva. Em ágil, formato é prática, não norma.

Trocar o relógio — 2 de 14. “até o momento atual, aplicando-se apenas aos itens que ainda estejam em WIP”, dito do cycle time — essa é a idade do item de trabalho; cycle time é de item concluído. E “é o tempo transcorrido na codificação dos componentes dessa história”, dito do lead time — que conta desde o pedido do cliente e engloba toda a espera. Localize onde o relógio começa e onde ele para antes de aceitar o nome que o item lhe dá.

Sobre a modalidade do verbo. O prior medido em outros tópicos de TI — o permissivo é Certo, o restritivo é Errado — vale aqui em uma só direção. Nenhum dos 14 Certos é derrubado por descrever capacidade: “permite gerenciar”, “pode mudar”, “podem surgir” abrem itens corretos, e nenhum item errado é permissivo. Do outro lado, 6 dos 14 errados carregam um absoluto do próprio redator (apenas, somente, não podem, não podendo, devem ser concluídas, em todas as etapas). Mas a exceção é decisiva e é a de sempre — de quem é o absoluto? “é necessário que se estabeleça limites de trabalhos em andamento” é Certo: a exigência é do método, não do item. Do mesmo modo, “o Kanban não prescreve interações com metas pré-definidas” é Certo: negar prescrição ao Kanban é descrevê-lo corretamente. E cuidado com o inverso: 8 dos 14 errados não têm absoluto nenhum — são descrições lisas e simplesmente falsas, como “Kanban é uma metodologia ágil para desenvolvimento de software”. Neste tópico, a gramática ajuda; o conteúdo decide.

Erros clássicos

Achar que limite de WIP é fila de um. Limite três significa até três itens simultâneos, não um de cada vez nem esvaziar a coluna antes de puxar o próximo.

Confundir lead time com cycle time. O lead time é a experiência do cliente e começa no pedido; o cycle time começa quando alguém efetivamente pega o item. Todo lead time contém um cycle time.

Medir o Kanban com régua de Scrum. Burndown e velocidade precisam de sprint. No Kanban, mede-se fluxo cumulativo, lead time, cycle time e vazão.

Tratar Kanban e Scrum como incompatíveis. A distinção entre os dois é real e cai muito; a incompatibilidade é invenção do item.

Chamar Kanban de metodologia de desenvolvimento. A banca aceita técnica, ferramenta, método e sistema de gestão do fluxo, e recusa metodologia de desenvolvimento de software — o Kanban não diz como se produz nada.

Achar que o gargalo se resolve de uma vez. Ele se desloca: tratada uma restrição, outra assume o posto. Por isso gerenciar o fluxo é prática contínua.

Montar o quadro e parar aí. Quadro sem limite de WIP e sem políticas explícitas de passagem entre colunas não implementa sistema puxado; é mural de tarefas.