Como especificar limites de WIP no Kanban?

Considere um quadro Kanban típico:

Entrada, Análise, Pronto para Desenvolvimento, Desenvolvimento, Pronto para Construção, Teste, Pronto para Liberação

Como especificar limites de WIP para cada coluna? alguma fórmula?

Não, nenhuma fórmula. Não existe um.

Depende muito da maneira como sua equipe trabalha, das práticas que você usa etc. Se você emparelhar um programa, terá limites mais baixos na coluna de desenvolvimento do que vários desenvolvedores.

Se você introduzir o Kanban na equipe existente, poderá tentar mapear todo o trabalho atualmente em andamento nos MMFs e, em seguida, ver quantos recursos você possui em diferentes colunas. Daria a você uma ideia dos limites que você realmente tem no momento e este é um bom ponto de partida para definir os limites do Kanban.

Outro conselho que você recebe é acompanhar o instinto de sua equipe. Faça o que achar certo. Em seguida, monitore se seus limites não estão muito apertados ou muito frouxos e ajuste. Algumas pessoas dizem que "o conselho dirá a você" e isso é basicamente verdade. Se você atingir o gargalo a cada semana, provavelmente terá limites muito baixos. Se um ou dois bloqueadores não são um problema, os limites são muito altos.

Escrevi um post sobre como estabelecemos nossos limites quando estávamos criando nosso quadro Kanban: http://blog.brodzinski.com/2009/11/kanban-story-kanban-board.html

Eu tentei dois extremos, ambos sugeridos por pessoas diferentes. Um é usar limites altos e ajustá-los até doer, e o outro é o contrário, para começar com n-1, em que n é o número de pessoas que poderiam puxar uma tarefa para essa coluna. O último é mais doloroso para equipes novas no Kanban, mas nos ajudou a chegar a um ponto de maximização de fluxo mais rápido que a primeira opção, porque quando sentimos dor (gargalos), nosso primeiro instinto foi examinar o problema de aumentar o limite WIP como um último recurso e, como resultado, descobrimos e resolvemos vários problemas de processo que poderiam ter sido invisíveis de outra maneira.

Enquanto eu concordo, não existe uma fórmula como tal - ao mesmo tempo, existe a possibilidade real de modelar o seu processo Kanban. Isso o ajudará a simular resultados prováveis ​​para coisas como tempo de ciclo, tempo de espera, eficiência, etc.

Eu implementei um simulador que modela nosso processo Kanban. Ele simula o fluxo de histórias em geral sob nossas restrições Kanban em torno dos limites WIP e dos recursos da equipe. Temos um estado que exige revisão de clientes externos. Todos suspeitávamos que esse estágio era algo que matava nosso tempo de ciclo, fazendo backup de nossas histórias.

A intuição era marcar o tempo dessa etapa, mas não sabíamos se isso simplesmente levaria o problema a outro lugar. Também não sabíamos até onde ir com o boxe do tempo, nem quão grande seria uma melhoria.

Está tudo muito bem dizendo apenas continuar aprimorando, mas pode ser muito perturbador. As pessoas se acostumarão a um processo e ficarão frustradas com alguém constantemente tentando ajustar um palpite. Portanto, você geralmente precisa fazer um bom caso antes de implementar a mudança.

Ao modelar, você pode ajustar sem interrupções e ter uma confiança muito maior de que seus ajustes proporcionarão o resultado desejado. Além disso, isso ajudará você a obter sua fórmula mágica.

Eu começaria com um número de "slots" em cada coluna que é igual ao número de pessoas que buscariam trabalho na coluna associada. Isso revelará gargalos ou pontos problemáticos. Abordar o ponto de dor até que ele se foi.

Com o tempo, experimente reduzir o número de slots em cada coluna.

Uso duas técnicas para especificar o limite WIP quando iniciamos um novo projeto ou uma equipe.

No caso de um projeto de desenvolvimento: estamos trabalhando em pares (estamos executando o XP), o que significa que dois membros podem trabalhar em um elemento de cada vez. Se a equipe consistisse em 6 pessoas, o WIP seria 3, com base na frase anterior. No entanto, a programação em pares é uma tarefa cansativa e, às vezes, os colegas gostariam de trabalhar um pouco sozinhos, eu dou mais um, então o limite WIP para 6 membros seria 4.

Quando falamos de um projeto de manutenção, teste de verificação ou suporte, verifico quanto trabalho paralelo os diferentes colegas podem fazer, somar esse número e subtraí-lo com um. Por exemplo, todos da equipe mencionada anteriormente podem cuidar de 2 problemas paralelos, isso faria o limite WIP 12, mas com o -1, é 11. O -1 garante que a equipe permaneça focada e trabalhe em conjunto. Se, nesse caso, o limite do WIP fosse 12, todos trabalhariam em seu máximo dois cartões e nenhuma colaboração aconteceria.

Quero enfatizar que uso essas técnicas apenas no início, quando o projeto / equipe começa. Posteriormente, o ajuste do limite WIP é dever da equipe com base em seus sentimentos, carga, objetivo etc.