Kanban - O que é o WiP e por que limita-lo?

As pessoas que trabalham comigo já conhecem este texto, pois enviei em um email para o time. Como não falei nada específico da empresa e do cliente e, na verdade, o que fiz foi apresentar conceitos, decidi extender para a comunidade.


WiP significa Work in Progress é o que está em execução (tarefas) naquele determinado ponto do processo. Percebam bem que Kanban não é um processo, mas um sistema para mapear o processo existente na empresa e buscar a melhoria contínua através de mudanças evolutivas, com alguns princípios baseados, principalmente, na ToC (Theory of Constraints).

Limita-se o WiP porque estudos comprovaram que quanto maior o número de tarefas em andamento em determinada parte do processo, maior é o lead time. O que é Lead Time? É simplesmente o tempo em que uma tarefa fica no fluxo, isto é, do backlog ao done. O lead time mostra como está o nosso fluxo e é o principal mecanismo utilizado para mostrar pontos de melhoria. E buscar pontos de melhoria é o nosso maior objetivo, pois melhorando vamos entregar mais valor de qualidade para nosso cliente (que o fim de todo time).

O WiP, obviamente, não pode ter um limite muito grande nem muito pequeno. Não existe um número mágico e cada contexto deve descobrir o seu número ideal empiricamente. Devemos achar a cadência do nosso time.

Por que não pode ser muito pequeno?

Vamos considerar que definimos um WiP de uma tarefa por desenvolvedor. O que fazer se uma tarefa for bloqueada (estiver com algum impedimento)? Aquele desenvolvedor vai parar e, se a solução daquele impedimento não depender dele, vai continuar parado. Mas existem empresas que trabalham com o WiP limitado de forma radical de uma tarefa por desenvolvedor. Mas essas empresas já são maduras em processos e engenharia ágil e o cara que ficaria parado, pode atuar em melhorias de código (refactoring) ou parear com outro desenvolvedor.

Por que não pode ser muito grande?

Por que as pessoas simplesmente são sequenciais. Nós somos multi-tarefa preemptivos como a maioria dos processadores, não fazemos mais de uma tarefa exatamente ao mesmo tempo. Temos que parar uma para começar outra. Estudos também comprovaram que temos uma grande perda quando temos muitas tarefas simultaneas. O tempo para lembrar o que é a outra tarefa, que estava parada, e o que precisa ser feito, é nocivo para o fluxo.

Então, o número ideal para a maioria das empresas que já estão rodando o Kanban à algum tempo é em torno de 2 por desenvolvedor. Mas como eu disse, depende do contexto, e o número ideal aparecerá com a a maturidade e a experiência.

Mas o que fazer se o as duas tarefas do desenvolvedor estiverem bloqueadas? Na verdade, quando isso acontece, devemos formar uma “força tarefa” para desbloquear estas tarefas e esse desbloqueio deve ser prioridade para que o fluxo volte ao normal.

Eu acredito que seja natural perceber o que aconteceria se tivessemos, por exemplo, um WiP limitado em 10 tarefas por desenvolvedor e 9 estivessem bloqueadas (utilizei um número absurdo para ficar mais natural ainda) e, de repente, 6 destas 9 fossem desbloqueadas. Seria a mesma coisa que abrir as comportas de uma represa. Isso faria com que não tivéssemos uma cadência.

Enfim, WiP limitado é um dos principais conceitos por trás do Kanban e devemos nos esforçar para encontrar a nossa melhor cadência.