Colocar o fluxo de volta ao fluxo de trabalho com limites de WIP

Em desenvolvimento ágil, os limites de 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 da ineficiência no fluxo de trabalho de uma equipe.

Obstáculos no pipeline de entrega de uma equipe podem ser vistos com clareza antes de uma situação se tornar extrema. Ao se concentrar em concluir tarefas antes de começar novas, as equipes (de todos os tipos) aumentam a eficiência, reduzem a mudança de contexto e oferecem uma melhoria significativa nos resultados.

Então, agora você está pensando, "Conte mais!"

Os limites de WIP melhoram o rendimento e reduzem a quantidade de trabalho “quase feito”, fazendo a equipe se concentrar em um conjunto menor de tarefas. No nível básico, os limites de WIP incentivam uma cultura de “concluído”.

O mais importante é que eles tornam visíveis os bloqueadores e gargalos. As equipes podem se concentrar nos itens de bloqueio para entender, implementar e resolver todos eles quando há um claro indicativo sobre qual trabalho está causando um gargalo. Após a remoção dos bloqueios, o trabalho da equipe começa a fluir de novo.

Esses benefícios garantem que incrementos de valor sejam entregues aos clientes com mais rapidez, o que torna os limites de WIP uma ferramenta importante no desenvolvimento ágil.

Durante o desenvolvimento, é comum pensar: "Vou fazer uma pausa em relação a esse item enquanto começo a trabalhar em outro". Ter dois itens em aberto exige mudar de contexto entre duas coisas diferentes ou transferir trabalho entre colegas de equipe. Ir de um item para o outro não é fácil. Leva tempo e diminui o foco.

Quase sempre é melhor trabalhar no item original do que começar — e não concluir — um novo trabalho. Ou seja, os limites de WIP desencorajam a obstrução do fluxo. 

Finalmente, os limites de WIP mostram as áreas com ociosidade crônica ou sobrecarga. Eles ajudam a equipe a ver as ineficiências no processo todo em vez de apenas em uma área específica de trabalho.

Agora que você sabe sobre o valor desses limites, vamos ao que interessa.

Ao lançar um novo fluxo de trabalho, tome uma decisão em equipe para determinar os limites de WIP para cada status. A recomendação é definir os limites de WIP depois de monitorar a média de itens de trabalho em cada status de alguns sprints. Confira a seguir um exemplo de quadro ágil com os limites de WIP usados por uma típica equipe de desenvolvimento de software.

Acima, um limite de WIP foi definido na revisão de código. Como a coluna está excedendo seu limite, o histórico ficou vermelho.

Como não resta nada a fazer quando um item é concluído, não há necessidade de um limite de WIP. No quadro Kanban acima, "Pendente" significa que a história foi examinada por completo pelo proprietário do produto e pela equipe. A equipe de desenvolvimento passa o trabalho de "Pendente" para "Em andamento" à medida que começam a trabalhar nos itens. Como melhor prática, é importante manter trabalho suficiente no status "Pendente" para que cada membro da equipe de desenvolvimento permaneça trabalhando. Ao manter apenas histórias suficientes no estado "Pendente", o proprietário do produto não fica muito à frente quando se trata de expor os requisitos, e o programa se torna mais responsivo a mudanças.

O status "em andamento" lista o trabalho que está sob desenvolvimento ativo. A meta dos limites de WIP nesse caso é garantir que todos tenham trabalho para fazer, mas ninguém esteja fazendo múltiplas tarefas. No quadro cima, o limite para os itens "em andamento" é quatro e há, no momento, três itens nesse estado. Isso mostra à equipe que eles conseguem assumir mais um trabalho. Como melhor prática, algumas equipes definem o limite de WIP máximo abaixo do número de membros da equipe. A ideia é preparar o espaço para as boas práticas ágeis. Se um desenvolvedor finalizar um item, mas a equipe já estiver no limite de WIP, eles saberão que é a hora de resolver algumas revisões de código ou chamar outro desenvolvedor para ajudar na programação.

O status "revisão de código" indica as histórias que foram totalmente escritas, mas precisam de revisão antes de serem mescladas na base de código. As revisões oportunas de código são uma melhor prática que estabelece qualidade, levam as inovações mais rapidamente ao mercado, tornam as mesclagens mais rápidas ao reduzir ramificações abertas e proporcionam conhecimento para toda a equipe de engenharia. É necessário atuar em itens nesse estado urgentemente pelos seguintes motivos:

• O código não se torna inutilizável à medida que os membros da equipe verificam um novo código

• O desenvolvedor não perde o contexto ganho ao escrever o código original

• A função pode ser mesclada na ramificação principal para liberação

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

Observe que, no quadro acima, a equipe tem muitas revisões de código, então a coluna ficou em vermelho para indicar isso.

Como em qualquer outra atividade, os limites de WIP podem parecer estranhos no começo. O objetivo aqui é otimizar a equipe a médio prazo, e a estranheza a curto prazo é realmente algo bom. Faz com que a equipe perceba alguns pontos problemáticos no processo. Após a equipe usar os limites de WIP por algumas semanas, será necessário fazer ajustes. Resista à tentação de criar um limite de WIP apenas porque a equipe está sempre passando por ele. Aproveite essa oportunidade para aumentar a capacidade – idealmente, ao treinar a equipe e fornecer a cada membro novos conjuntos de habilidades ou tornando alguns aspectos do processo de desenvolvimento mais eficientes.

Meta 1: manter a consistência no dimensionamento das tarefas. Ao dividir requisitos e histórias de usuário, é importante manter as tarefas com até 16 horas de trabalho. Assim, você aumenta a capacidade da equipe de fazer estimativas com confiança e evita gargalos. Nada atrasa tanto uma equipe e atrapalha os limites de WIP como um item de trabalho grande obstruindo o pipeline.

Meta 2: mapear os limites de WIP de acordo com as habilidades da equipe. O exemplo acima assume que os membros da equipe têm conjuntos de habilidades similares. Se sua equipe tem especialistas , o trabalho em limites em andamento pode ser diferente. Crie um status específico para o trabalho do especialista. Se houver obstáculos nesse status, use a oportunidade para mostrar aos outros membros da equipe como adicionar capacidade extra ao conjuntos de habilidades do especialista e aumentar o fluxo em toda a equipe.

Meta 3: reduzir a ociosidade. Quando alguém da equipe tiver tempo livre, encoraje-o a ajudar nas atividades da equipe. Essa pessoa contribuirá para a produtividade geral da equipe e aprenderá algo.

Meta 4: proteger uma cultura de engenharia sustentável. Os limites de trabalho em andamento não foram feitos para apressar o trabalho dos desenvolvedores para evitar sobrecarga em um status específico. Eles devem dar suporte a práticas sólidas de engenharia ágil que protejam a qualidade do produto e a integridade da base de código. 

Se a equipe estiver pronta para implementar limites de WIP, use o template de quadro Kanban para começar grátis.