O que são 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 são claramente visíveis antes de uma situação se tornar extrema.
Por que os limites de WIP são importantes?
Então agora você está pensando: "Fale mais!" (bem, espero que esteja.)
Os limites de WIP melhoram a produtividade e reduzem a quantidade de trabalho "quase feito" forçando a equipe a se concentrar em um conjunto menor de tarefas. Em um nível fundamental, os limites de WIP incentivam uma cultura de "concluído". E, o mais importante, os limites de WIP tornam os bloqueadores e os obstáculos visíveis. As equipes podem analisar itens de bloqueio para que eles sejam entendidos, implementados e resolvidos quando há um claro indicador de qual trabalho existente está causando um gargalo. Uma vez que os bloqueios são removidos, o trabalho da equipe começa a fluir de novo. Esses benefícios garantem que incrementos de valor sejam entregues aos clientes mais rápido, tornando 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.
Pode parecer estranho para equipes novas no uso dos limites de WIP. Reserve um tempo para discussão nas primeiras iterações. Entenda como e o motivo pelo qual a equipe atinge os limites de WIP. Resista à tentação de fazer ajustes arbitrários. Se uma violação se tornar consistente, é um sinal de que o limite de WIP é muito restritivo ou que o processo da equipe é ineficiente.
Uso dos limites de WIP em equipes ágeis
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 gente recomenda definir os limites de WIP depois de monitorar o número médio de itens de trabalho em cada status para alguns sprints. Abaixo é possível ver um quadro ágil de exemplo com os limites de WIP usados por uma equipe de desenvolvimento de software comum.
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.
- Os limites de WIP são usados conforme a necessidade para que a equipe não encontre mais problemas. ("Teto de dívida", alguém?)
- Todos têm muitas "tarefas secundárias" nas quais trabalhar quando estão ociosos.
- Os membros da equipe ficam à espera de mais trabalho em vez de se prenderem aos obstáculos.
- Adicionar mais horas pessoais em obstáculos persistentes é melhor do que melhorias nas práticas de engenharia ou nos processos da equipe.
Quatro metas paras as equipes ágeis que usam limites de WIP
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 individuais. Ao dividir requisitos e histórias de usuário, é importante manter as tarefas individuais com não mais do que 16 horas de trabalho. Assim você aumenta a capacidade da equipe de estimar com confiança e ajuda a evitar gargalos. Nada atrasa uma equipe e atrapalha os limites de WIP como um grande item de trabalho obstruindo o pipeline.
Quando os limites de trabalho em andamento estão funcionando para a equipe, o tempo de ciclo do item vai diminuir. O tempo de ciclo é a quantidade de tempo que leva para concluir um item. Confira a página sobre métricas ágeis para saber mais.
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.
