{"id":8963,"date":"2019-04-24T15:55:30","date_gmt":"2019-04-24T18:55:30","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=8963"},"modified":"2019-04-24T16:05:57","modified_gmt":"2019-04-24T19:05:57","slug":"ajudando-o-time-a-respeitar-limite-de-wip-com-um-truque-simples","status":"publish","type":"post","link":"https:\/\/blog.plataformatec.com.br\/2019\/04\/ajudando-o-time-a-respeitar-limite-de-wip-com-um-truque-simples\/","title":{"rendered":"Ajudando o Time a Respeitar Limite de WIP com um Truque Simples"},"content":{"rendered":"
Voc\u00ea j\u00e1 ouviu falar em Limite de WIP e seus benef\u00edcios. A Lei de Little<\/a>\u00a0diz que o\u00a0throughput<\/a><\/em>\u00a0tende a aumentar e o\u00a0lead time<\/em><\/a> tende a diminuir conforme se limita o trabalho em progresso. Existem atividades pr\u00e1ticas muito l\u00fadicas para mostrar o ganho em limitar WIP, e geralmente os times se mostram convencidos na hora… Por\u00e9m, em muitas vezes, \u00e9 s\u00f3 voltar para a correria do dia a dia para o limite de WIP ser desrespeitado.<\/p>\n A quebra do limite de WIP, muitas vezes impulsionada por press\u00e3o em entregas ou motivos similares, \u00e9 mais do que o desrespeito a uma conven\u00e7\u00e3o: \u00e9 a quebra de pelo menos dois princ\u00edpios \u00e1geis<\/a>:<\/p>\n Como gerente de projetos \u00e1geis, me senti desafiado a buscar solu\u00e7\u00f5es melhores para lidar com isso, e tive um bom achado nesse v\u00eddeo<\/a>, que serviu de base para este blog post<\/em>.<\/p>\n O quadro abaixo ilustra um board de projeto fict\u00edcio, baseado em casos reais (talvez voc\u00ea tenha se deparado com algo bem parecido no seu time), de forma f\u00e1cil de reproduzir em uma ferramenta como Jira ou Trello.<\/p>\n <\/p>\n Kanban fala de gest\u00e3o de filas (um pouco sobre isso aqui<\/a>). Filas s\u00e3o estados no quadro onde o trabalho n\u00e3o est\u00e1 necessariamente sendo feito, mas sim esperando para ser feito. <\/p>\n Em laranja, temos as colunas de fila. Esse agrupamento por “design”, “desenvolvimento” e “teste” considera unicamente o nome das colunas usadas no quadro tradicional, e as etapas em cada uma delas.<\/p>\n Olhando o quadro assim, aparentemente n\u00e3o tem nada anormal. Mas vamos adicionar algumas issues<\/em>:<\/p>\n <\/p>\n Uma equipe n\u00e3o t\u00e3o familiarizada e madura com os conceitos de Kanban, ao olhar a imagem acima, teria alta probabilidade de dizer que ”a equipe de testes n\u00e3o est\u00e1 dando conta”<\/strong>.<\/p>\n Quando o trabalho de desenvolvimento termina, o cart\u00e3o \u00e9 movido para a coluna “ready to test<\/em>“. Para uma equipe com baixa maturidade em Kanban, enviar o item para a coluna “ready to test” alimenta o pensamendo de “acabei a minha parte, vou puxar outro card”<\/strong>. A pr\u00f3pria nomenclatura<\/strong> da coluna colabora com a ideia de que acabou o desenvolvimento e, agora, aquele item \u00e9 Aqui entra a proposta deste texto: vamos fazer uma pequena altera\u00e7\u00e3o nessas colunas, mantendo os cards nas mesmas posi\u00e7\u00f5es relativas, mas deixando as filas \u00e0 direita:<\/p>\n <\/p>\n Adicionamos uma etapa “backlog<\/em>” do lado esquerdo e invertemos a posi\u00e7\u00e3o das filas.<\/p>\n Olhando agora, ser\u00e1 que evidenciamos que o problema pode ser o time de desenvolvimento estar produzindo num ritmo muito maior que a capacidade do sistema? Kanban n\u00e3o \u00e9 sobre aproveitamento de recursos (n\u00e3o se trata de m\u00e1quinas que, se n\u00e3o trabalharem 24\/7, v\u00e3o gerar preju\u00edzo), mas sim sobre\u00a0otimizar o fluxo<\/strong>.<\/p>\n Olhando no agrupamento de “desenvolvimento”, a coluna cheia agora est\u00e1 l\u00e1 dentro. Fica dif\u00edcil para o detrator do limite de WIP alegar que “n\u00e3o tem nada na fila dele”. Se tem coisa no “done”, tem coisa na etapa dele. O item s\u00f3 sai de “desenvolvimento” quando ele \u00e9\u00a0puxado<\/strong>\u00a0para a coluna “doing<\/em>” de teste. Este \u00e9 o sistema puxado. Ser\u00e1 que essa vis\u00e3o n\u00e3o ajuda o time a promover colabora\u00e7\u00e3o e auto-organiza\u00e7\u00e3o? No exemplo, o time de desenvolvimento poderia ajudar nos testes para esvaziar a fila de “Desenvolvimento – Done<\/em>“.<\/p>\n Tem tudo a ver com como nosso c\u00e9rebro interpreta, \u00e0s vezes subconscientemente, a disposi\u00e7\u00e3o da informa\u00e7\u00e3o.<\/p>\n Vale ressaltar que em times maduros, essa abstra\u00e7\u00e3o talvez n\u00e3o fa\u00e7a diferen\u00e7a, pois as pessoas j\u00e1 sabem que os itens no quadro pertencem a todos do time, e o que realmente importa \u00e9 entregar valor no fim.<\/p>\n Apenas para sua melhor visualiza\u00e7\u00e3o, caro leitor, vamos voltar ao quadro original, reordenando as colunas:<\/p>\n <\/p>\n Como est\u00e1 o quadro do seu time? Quer testar essa pequena mudan\u00e7a e contar pra gente como foi?<\/p>\n","protected":false},"excerpt":{"rendered":" Voc\u00ea j\u00e1 ouviu falar em Limite de WIP e seus benef\u00edcios. A Lei de Little\u00a0diz que o\u00a0throughput\u00a0tende a aumentar e o\u00a0lead time tende a diminuir conforme se limita o trabalho em progresso. Existem atividades pr\u00e1ticas muito l\u00fadicas para mostrar o ganho em limitar WIP, e geralmente os times se mostram convencidos na hora… Por\u00e9m, em … \u00bb<\/a><\/p>\n","protected":false},"author":78,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[3],"tags":[123],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/8963"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/78"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=8963"}],"version-history":[{"count":26,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/8963\/revisions"}],"predecessor-version":[{"id":9009,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/8963\/revisions\/9009"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=8963"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=8963"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=8963"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
\nSe analisarmos o quadro acima e ilustrarmos de outra maneira, sem mudar o fluxo, temos:<\/p>\nproblema<\/del> responsabilidade da equipe de testes. Isso parece muito com um sistema empurrado<\/strong>, o contr\u00e1rio do que o Kanban prega, o sistema puxado.<\/p>\n