Os efeitos da redução do WIP

Introdução

A Figura 1 é uma fotografia do quadro kanban do desenvolvimento de software judicial no TST de dezembro de 2014. Cada post-it é um defeito ou uma história de usuário. Os post-its verdes são quase todos de correção de defeitos. Cada uma das outras cores representam um projeto diferente.

Esta figura mostra dois problemas principais: muito trabalho em progresso (WIP) e lotes grandes. Muito trabalho em progresso é um problema pois dificulta a coordenação dos trabalhos e é uma grande fonte de interrupções nas demandas que ainda estão em desenvolvimento. O que faz com que estas últimas demorem mais para serem terminadas. Lotes grandes, como o ilustrado pelo círculo na Figura 1, são um problema quando entram em produção. Normalmente, uma entrega grande em produção é seguida de uma sequência de defeitos reportados.

Figura 1 - kanban de dezembro de 2014

O que fizemos?

Então, a partir do início do ano, mas com mais intensidade a partir de fevereiro, começamos a tomar ações para reduzir o WIP do sistema de trabalho. Abaixo listo uma sequência de ações executadas e fatos que se sucederam:

1. O projeto em azul (Figura 1) foi implantado no início janeiro;
2. Os limites de WIP foram retirados do quadro kanban. Isto parece contraditório, mas pela Figura 1 podemos ver que os limites, mesmo altos, não eram respeitados pela equipe. Então retiramos os limites, para recolocá-los quando o WIP já estivesse mais baixo.
3. Em fevereiro começaram a aparecer os defeitos da implantação do projeto em azul. A equipe de desenvolvimento trabalhou quase que exclusivamente todo o mês para corrigi-los de forma imediata.
4. Para favorecer a correção destes defeitos e não permitir o aumento do WIP, não foi priorizado nenhum item que não fosse imediato até o início de março (círculo na Figura 2);
5. Com o WIP mais baixo, no início de março foram recolocados os limites de WIP. Por exemplo, o limite do desenvolvimento que antes estava em 28 itens passou para 6, o limite do teste e homologação que antes era 30 passou para 6.
6. Então, no final de março, com os limites já sendo respeitados voltamos a priorizar itens não emergenciais para serem desenvolvidos.

Figura 2 - kanban do início de março de 2015

E onde isto nos levou?

O Lead Time, que é o tempo desde que uma história de usuário entrou em desenvolvimento até o momento em que ela foi colocada em produção, tem caído para a maior parte destas histórias. A Tabela 1 mostra a média e a mediana para quatro períodos. Apesar da média não ter caído tanto, pois algumas histórias antigas ainda puxam a média para cima, a mediana mostra que para 50% das histórias a tendência é de queda no tempo de entrada em produção. 

Tabela 1 - Lead Time

A taxa de entrega mensal (throughput) de março só não foi superior aos meses de agosto de 2014 e de janeiro de 2015, considerando os últimos 12 meses (Gráfico 1). Por outro lado, nestes dois meses existiram entregas grandes em produção que haviam ficado acumuladas, como aquela da Figura 1. Assim, isto nos indica que esta taxa de entrega mais alta veio das ações descritas anteriormente.

Gráfico 1 - Taxa de entrega mensal

Conclusão

A redução do WIP teve impacto não só na redução do Lead Time e no aumento da taxa de entrega (que ainda precisamos confirmar se irá se manter nos próximos meses), mas também facilitou a coordenação do trabalho da equipe no dia a dia.