Quadro kanban com dois níveis

Olá! Este artigo conta como chegamos ao quadro kanban em dois níveis mostrado na figura abaixo.

Inicialmente, os nossos quadros kanban tinham um nível. Cada demanda fluía livremente pelo quadro independentemente das demais. Raras vezes, fazíamos uma demanda esperar por outra para ser implantada ou para ser testada. O artigo Tangibilizando os Resultados mostra uma versão deste quadro com um nível.

Então, alguns eventos aconteceram: 

Evento 1: Uma janela de mudanças foi definida, permitindo a implantação em produção somente em um dia da semana. Isto nos levou a agrupar as demandas para a implantação. 

Evento 2: Notamos que alguns erros em produção decorriam da falta de testes integrados das demandas de um mesmo sistema. Ou seja, as demandas eram testadas isoladamente, mas quando agrupadas apresentavam erros. Então, passamos a testar em conjunto as demandas de um mesmo sistema que seriam implantadas em um release.

No quadro kanban, a solução inicial para agrupar as demandas foi anotar, em vermelho, um mesmo número no post-it de cada uma para indicar que deveriam ser testadas, homologadas e implantadas em conjunto. Ou seja, anotando o número 2 em 3 post-its indicava que os 3 formavam um release e deveriam seguir juntos do teste até a implantação. Este processo de relacionar as demandas por números nos post-its deve ter de 1 a 2 meses. Até que...

Até que aconteceu o Evento 3: os limites de WIP do Desenvolvimento não estavam sendo respeitados pelo próprio time, causando um acúmulo de demandas na coluna Desenvolvimento Pronto. Outro problema que notamos foi que a utilização dos números dificultava bastante a visualização do relacionamento das demandas, principalmente, quando eram vários releases em desenvolvimento.

Então, criamos as raias que vão do Para Fazer até o Desenvolvimento Pronto como mostrado pela figura acima. Agora, a facilitação visual não deixa dúvidas sobre o relacionamentos entre as demandas! Cada raia representa um release e, quando uma demanda é priorizada, deve ter um post-it azul na primeira coluna do Para Fazer, representando um release. Quando todas as demandas de um release estão prontas, este post-it azul anda também para o pronto, ocupando a última coluna do Desenvolvimento. Mas isso não quer dizer que esta raia esteja liberada para a priorização de um novo release. A liberação só ocorre quando são iniciados os testes/homologação. Nessa hora, o post-it azul é movido com todas as demandas do release dependuradas nele. Assim, se o time não iniciar os testes/homologação, de forma a manter as demandas fluindo pelo quadro, logo não poderão puxar mais trabalho para o desenvolvimento.

Uma vantagem desta abordagem é deixar bem claro que há um limite de releases simultâneos no Desenvolvimento, já que a restrição é física: 6 raias = 6 releases.