Por que os Limites WIP são Importantes?

No desenvolvimento ágil, os limites WIP, ou limites do trabalho em andamento (WIP) definem a quantidade máxima de trabalho que pode existir em cada status de um fluxo de trabalho. Limitar a quantidade de trabalho em andamento facilita a identificação de ineficiência no fluxo de trabalho de uma equipe pois os gargalos no pipeline de entrega de uma equipe são claramente visíveis antes que uma situação se agrave.

Por que os limites WIP são importantes?

Os limites WIP melhoram a taxa de transferência e reduzem a quantidade de trabalho “quase pronto”, forçando a equipe a se concentrar em um conjunto menor de tarefas. Em um nível fundamental, os limites WIP incentivam a cultura de “feito”.

Mais importante, os limites de WIP tornam visíveis os impedimentos e os gargalos, onde as equipes podem se aglomerar em torno dos problemas de bloqueio para compreendê-los, implementá-los e resolvê-los quando houver um indicador claro de que trabalho existente está causando gargalo.

Depois que os impedimentos são removidos, o trabalho em toda a equipe começa a fluir novamente. Esses benefícios garantem que os incrementos de valor sejam entregues aos clientes mais cedo, tornando os limites WIP uma ferramenta valiosa no desenvolvimento ágil.

Durante o desenvolvimento, é fácil pensar em:

Ter dois problemas abertos significa alternar o contexto entre duas coisas diferentes ou transferir o trabalho entre colegas de equipe. Descobrir um problema e outro não é prejudicial – leva tempo e prejudica o foco. É quase sempre melhor trabalhar com a edição original do que iniciar uma outra atividade – e não concluir – o novo trabalho. Em outras palavras, os limites do WIP nos desencorajam a impedir nosso próprio fluxo.

Por fim, os limites WIP apontam áreas de ociosidade ou sobrecarga crônica, ajudando a equipe a identificar ineficiências em todo o processo, e não apenas na área específica em que trabalham.

Para equipes novas nos limites WIP, elas podem se sentir desencorajadas. Reserve um tempo para discuti-los nas primeiras iterações. Entenda quando e por que a equipe atingiu os limites WIP.

Resista à tentação de ajustá-los arbitrariamente a princípio pois, se uma violação se tornar consistente, isso é um sinal de que o limite WIP é muito restritivo ou o processo da equipe é ineficiente.

Usando limites WIP em equipes ágeis

Ao lançar um novo fluxo de trabalho, tome uma decisão da equipe para determinar os limites WIP para cada status. Recomenda-se definir limites WIP depois de monitorar o número médio de itens de trabalho em cada status por alguns Sprints.

Abaixo está uma visão ágil de amostra com limites WIP usada por uma equipe típica de desenvolvimento de software.

Acima, um limite WIP foi definido na revisão de código. Como a coluna está excedendo seu limite, o fundo ficou vermelho. Como não há mais nada a fazer quando o problema é solucionado, não há necessidade de um limite de WIP.

Pronto para Dev

No quadro acima, “Pronto para dev” significa que a história foi totalmente examinada pelo proprietário e pela equipe do produto.

A equipe de desenvolvimento puxa o trabalho de “pronto para dev” para “em andamento” à medida que iniciam os itens de trabalho. Como prática recomendada, é importante manter o trabalho suficiente no status “pronto para o desenvolvedor”, para que cada membro da equipe de desenvolvimento permaneça totalmente ativo.

Ao manter apenas as histórias suficientes no estado “pronto para o desenvolvimento”, o proprietário do produto não fica muito à frente do jogo quando se trata de aprofundar os requisitos, e o programa se torna mais sensível às mudanças.

Em andamento

O status “em andamento” lista o trabalho em desenvolvimento ativo. O objetivo dos limites WIP nesse caso é garantir que todos tenham trabalho a fazer, mas que ninguém se torne um membro multitarefa.

No quadro, o limite para itens “em andamento” é 4 e, atualmente, existem 3 itens nesse estado. Isso indica à equipe que eles têm capacidade para assumir mais trabalho. Como prática recomendada, algumas equipes definem o limite máximo de WIP abaixo do número de membros da equipe. A ideia é criar espaço para boas práticas ágeis.

Se um desenvolvedor terminar um item, mas a equipe já estiver no limite de WIP, ele saberá que é hora de fazer algumas revisões de código ou ingressar em outro desenvolvedor para alguma programação em pares.

Revisão de Código

O status “revisão de código” indica histórias que foram totalmente escritas, mas precisam ser revisadas antes de serem incorporadas à base de código. Revisões oportunas de código são uma prática recomendada pois:

• Estabelece qualidade;
• Lança novas inovações no mercado mais rapidamente;
• Facilita as fusões;
• Reduzi filas abertas;
• Espalha conhecimento por toda a equipe de engenharia.

Os itens nesse estado devem ser tratados com urgência, por alguns motivos:

• O código não envelhece quando os membros da equipe fazem check-in no novo código;
• O desenvolvedor não perde o contexto que ganhou ao escrever o código original;
• O recurso pode ser mesclado na ramificação principal para liberação.

Os limites WIP garantem que o código não revisado não se acumule.

Observe que, no quadro ágil acima que a equipe tem muitas revisões de código; portanto, a coluna ficou vermelha para indicar esta situaçãoso.

Anti padrões

• Os limites WIP são aumentados conforme necessário para que a equipe não os atinja mais;
• Todo mundo tem uma grande “tarefa em segundo plano” em seu prato para mascarar os momentos em que eles estariam ociosos;
• Os membros da equipe ficam ociosos aguardando mais trabalho, em vez de se encher de gargalos;
• Jogar mais horas por pessoa em gargalos persistentes é preferível a melhorias nas práticas de engenharia ou processos de equipe.

Desafios para equipes que atuam com Limites WIP

Como qualquer nova atividade, os limites WIP podem parecer estranhos no começo. O objetivo aqui é otimizar a equipe a médio prazo. Isso faz com que a equipe sinta alguns pontos negativos em seu processo.

Depois que a equipe trabalha dentro dos limites WIP por algumas semanas, faça os ajustes necessários. Resista à tentação de aumentar um limite de WIP apenas porque a equipe continua atingindo.

Aproveite essa oportunidade para aumentar a capacidade – idealmente, educando a equipe e dando a cada membro novos conjuntos de habilidades ou tornando alguns aspectos do processo de desenvolvimento mais eficientes.

Desafio 1

Dimensionar tarefas individuais de forma consistente. Ao quebrar requisitos e histórias de usuários, é importante manter as tarefas individuais com no máximo 16 horas de trabalho.

Isso aumenta a capacidade da equipe de  estimar com  confiança e ajuda a evitar gargalos. Nada diminui a velocidade da equipe e agrava os limites WIP como um grande item de trabalho entupindo o pipeline.

Quando os limites do trabalho em andamento estão funcionando para a equipe, o tempo de ciclo – tempo necessário para concluir uma atividade – diminui. Tempo de ciclo é o tempo necessário para concluir um problema.

Desafio 2

Mapear os limites WIP para as habilidades da equipe. O exemplo acima supõe que os membros da equipe tenham conjuntos de habilidades semelhantes. Se sua equipe tiver especialistas os limites do trabalho em andamento poderão diferir quando o especialista estará pronto ou disponível.

Crie um status específico para o trabalho do especialista. Se ocorrerem gargalos nesse status, use a oportunidade de educar outros membros da equipe para adicionar capacidade adicional aos conjuntos de habilidades do especialista e aumentar o fluxo em toda a equipe.

Desafio 3

Reduzir a ociosidade. Quando um membro da equipe tiver algum tempo de inatividade, incentive-o a ajudar um membro da equipe com as atividades restantes. Eles contribuirão para a produtividade geral da equipe e aprenderão algo ao longo do caminho!

Desafio 4

Proteger uma  cultura de engenharia sustentável. Os limites do trabalho em andamento não significam que os desenvolvedores precisam acelerar para evitar sobrecarga de trabalho em um status específico.

Eles têm como objetivo apoiar práticas de engenharia ágeis sólidas que protegem a qualidade do produto e a integridade da base de código.

Referência

• https://www.atlassian.com/agile/kanban/wip-limits

Sobre o autor:

Jefferson Duarte – Gerente de Programas e Projetos na empresa Claro Brasil. Certificaçação PMP®, ITIL® e MCTS® em Microsoft Project. MBA Executivo Internacional em Gerenciamento de Projetos pela FGV e Gestão de Projetos de T.I. pelo IBTA. Pós-Graduado em Tecnologia WEB para Sistemas de Gestão Empresarial. Graduado em Ciências da Computação. Atuação profissional na área de T.I. com Processos e Projetos por mais de 15 anos. E-mail: contato@gp4us.com.br e site: https://www.gp4us.com.br