Kanban e o Limite de WIP (Work in Progress)
CONAENGE » Kanban »O Kanban Nasceu na Indústria Automotiva
Uma das formas mais flexíveis que eu conheço para gerenciar fluxos de entrega de produtos ou serviços é o Kanban. O Kanban surgiu na Indústria Manufatureira, especificamente na fabricante de carros Toyota no final da década de 40.
Desde seu início mostrou virtudes como: gestão visual do processo/fluxo; limitação do WIP (Work in Progress/Process); Flexibilidade; Simplicidade; etc.
“Pare de começar e comece a terminar!” Autor Desconhecido
A Indústria do Software Criou a Metodologia Kanban
O sucesso do Kanban na Indústria Automotiva não passou despercebido por outros setores, inclusive pela competitiva e dinâmica Indústria do Software. Na área de software a Metodologia Kanban ganhou muito espaço como uma das ferramentas do Movimento Ágil e das Lean Startups. Certamente teve grande mérito nas tremendas conquistas tecnológicas de nossa civilização nas últimas duas décadas.
Até final do século passado a indústria do software – majoritariamente – usava a metodologia waterfall/cascata, onde havia a prescrição muito bem definida de etapas rígidas que deveriam ser seguidas. O foco de atenção estava no planejamento do projeto, algo que os desenvolvedores de softwares tomaram como exemplo dos engenheiros.
Acontece que os escopos definidos pelos clientes mudam frequentemente, além do que – como trabalho intelectual e criativo – programar é uma atividade que dificulta as estimativas de prazos de entrega, devido a sua complexidade inerente.
Na década de 90, pesquisas mostraram que mais de 70% dos projetos de desenvolvimento de software falhavam em ao menos um destes três itens: cumprimento de prazos; limites de orçamentos; e – o mais crítico de todos – falhavam em atender as necessidades dos usuários finais dos sistemas desenvolvidos.
Para obter resultados mais satisfatórios na criação de softwares, os programadores começaram a utilizar – entre outras ferramentas – a metodologia Kanban para gerenciar o fluxo do trabalho/processo de desenvolvimento de sistemas/softwares.
O Kanban é uma abordagem iterativa e incremental, que enfatiza a melhoria contínua e a colaboração em equipe. É uma metodologia ágil que fornece uma visão clara do trabalho em andamento e ajuda a equipe a identificar gargalos no processo de produção.
Fundamentos da Metodologia Kanban
O Kanban passou no rigoroso teste do tempo – nestes mais de 70 anos em que está sendo usado – e continua sendo aprimorado para tornar as entregas dos times mais satisfatórias e previsíveis, tanto do ponto de vistas das equipes, quanto dos clientes finais.
Para atingir seus objetivos usa esses fundamentos: Visualizar com Quadro Kanban; Gerenciar o Fluxo de Trabalho; e Limitar o WIP.
Visualizar com Quadro Kanban
O quadro pode representar itens concretos, como as peças em produção em uma fábrica, ou trabalhos intangíveis de programadores de computadores/dispositivos. O importante é que o quadro Kanban represente o fluxo de trabalho da equipe.
O quadro Kanban é uma placa dividida em colunas, cada uma representando uma fase do processo de produção, com tarefas ou cartões de trabalho que você move de uma coluna para outra à medida que concluir uma etapa do trabalho.
A grande flexibilidade do Kanban permite que você use um quadro físico, ou que utilize alguma plataforma de software. Particularmente eu – assim como outros consultores – recomendo o começo em quadros físicos. Após a familiarização da equipe com o método Kanban, aí sim usar uma solução por software dará melhor resultado.
E nesse quadro – seja físico ou virtual – é indicado começar com apenas 3 colunas: TO DO; DOING; DONE. Começando com essas 3 fases (A FAZER; FAZENDO; FEITO) os benefícios prometidos pelo Kanban já começam a ser percebidos. (protokanban ➯ Kanban)
É claro que quadros muito mais complexos podem ser desenvolvidos, e isso prova a flexibilidade do método Kanban.
Gerenciar o Fluxo de Trabalho
O Kanban prevê o gerenciamento do fluxo de trabalho e não das pessoas. Essa é uma mudança drástica do “comando e controle gerencial” para uma abordagem mais holística do processo. Ao invés de microgerenciar os indivíduos – buscando mínimos locais – a ideia é buscar uma maior eficiência global gerenciando o fluxo de trabalho da equipe.
Limitar o WIP
É contra intuitivo pensar em aumentarmos a entrega de resultados da equipe, sem a maximização da taxa de utilização dos recursos individuais. Pois é exatamente isso que o Kanban afirma, ou seja, que melhores resultados gerais serão obtidos limitando o WIP (Work in Progress/Process).
Essa mudança de mindset é difícil para o gestor tradicional que – em geral – ao ver a equipe atrasando as entregas, costuma jogar mais trabalho para o time no estilo “produção empurrada”. Agindo assim o gestor apenas gera mais atrasos e frustrações a todos os envolvidos.
Na figura acima, o fluxo contínuo e o regime de “produção puxada” fazem parte do pilar Just-in-Time do TPS (Toyota Production System), modelo de gestão utilizado por inúmeras indústrias manufatureiras.
No universo do desenvolvimento de softwares, a abordagem Kanban suaviza a difícil passagem de desenvolvimento waterfall (em cascata) para o desenvolvimento ágil de aplicações.
O Kanban ameniza o processo de mudança porque ele é não prescritivo, e se adapta ao Cliente. É por isso que dois princípios são “comece pelo que você faz agora” e “melhoria através da mudança evolucionária”.
Analogia com a Vazão de Água em um Duto
Farei uma analogia entre o fluxo de trabalho de uma equipe, com o fluxo de água, para que você entenda perfeitamente alguns conceitos ligados ao Kanban.
Vamos tomar o caso simples de uma mangueira de jardim com vazão em torno de 1.000 l/h (1 m³/h ou 1l/(3,6s)).
O que queremos com a mangueira de jardim é um fluxo contínuo de água, menos turbulento e – idealmente – no regime laminar de escoamento (número de Reynolds menor que 2.000). (PS: na maioria das vezes o regime de escoamento de água em uma mangueira de jardim será turbulento)
Durante a abertura ou fechamento da mangueira de jardim você tem o fluxo de água muitíssimo turbulento. Com pressões e vazões variando abruptamente o manejo é difícil e de pouca serventia prática.
No entanto, na maior parte do tempo você estará em regime menos turbulento de escoamento – que é o regime permanente/estacionário de uso – e que atenderá perfeitamente aos seus objetivos.
Perceba que o fluxo contínuo é desejável mesmo nesse exemplo simples, quanto mais será em um time de desenvolvimento de software ou no chão de fábrica de uma indústria.
Na minha opinião, a principal vantagem do fluxo menos turbulento – em qualquer situação – é a facilidade de previsão de resultados do processo. Veja, uma máquina CNC tem grande repetibilidade em sua operação, o que facilita a programação da produção, quando comparamos com operações manuais.
Comentários de Clientes
Aqui cabe citar o que nossos Clientes de Sistemas APS+MES já afirmaram durante nossas consultorias e implementações. Um deles relatou que a maior variabilidade em um torneamento CNC ocorria justamente na troca manual de peças. Dois operadores se revezavam na máquina em turnos diferentes, e cada um deles tinha uma velocidade particular característica de movimentação de peças. O Cliente observou também grande variância do mesmo operador ao longo do dia.
Outro Cliente comentou que deixa alguns FMSs (Flexible Manufacturing Systems) de milhões de reais operando – sem supervisão humana – aos fins de semana, e que as entregas realizadas são praticamente idênticas ao planejado. Robôs trabalhando “as escuras” são também cada vez mais comuns no Brasil.
WIP = Lead Time x Throughput
Voltando a analogia com a mangueira de jardim, suponha que uma porção de água leva 1 segundo para percorrer da entrada até a saída da mangueira.
Esse tempo entre o começo e o término do processo é o Lead time. E multiplicando o Lead Time pela vazão (throughput) obtemos o WIP. (WIP = Lead Time x Throughput)
Para nossa exemplo temos 1l/(3,6s) vezes 1s que resulta em 0,2778 l/s, ou seja, a cada segundo existe 0,2778 l de água sendo deslocados dentro da mangueira.
Se forçarmos a mangueira de jardim a regimes de trabalho além de sua capacidade, certamente ela irá colapsar. Ora, por que haveríamos de pensar que forçar as pessoas a regimes de trabalho superiores a sua capacidade seria algo sustentável a longo prazo?
Por que Limitar o WIP?
David J. Anderson – criador do Método Kanban – e autor dos livros “Kanban: Successful Evolutionary Change for Your Technology Business” e “Lessons in Agile Management (On the Road to Kanban)” comenta que no início a Indústria do Software contratava programadores muito jovens em regime extenuante de trabalho diário. A qualidade dos apps gerados era ruim e, ao envelhecer, os programadores começaram a adoecer frequentemente por esgotamento. Tudo sinalizava que a situação era insustentável e que o processo de desenvolvimento de software deveria evoluir. Limitar o WIP foi essencial nesta fase evolutiva.
Uma outra prova que limitar o WIP é uma decisão inteligente é na leitura de livros. Você pode obter bons resultados lendo – concomitantemente – de 1 a 5 livros, por exemplo, mas mais de 20 ou 100 livros em leitura simultânea é improdutivo, pois serão muitos setups, e com pouca captura da essência passada pela mensagem de cada livro, não é verdade?
Há restrições em inúmeras atividades que realizamos no intuito de sermos produtivos. Temos que respeitar a capacidade do processo e diminuir um pouco as “iniciativas” e aumentar as “acabativas”, no espírito de “Stop starting, start finishing!” (“Pare de começar e comece a terminar!”).
Comparativo Entre Kanbans da TI e da Fábrica
O Kanban é uma técnica de gestão de produção que tem sido amplamente utilizada na indústria manufatureira e também é aplicável à gestão de projetos de TI. Embora haja algumas semelhanças entre os Kanbans da TI e da fábrica, também existem algumas diferenças importantes.
Semelhanças
O Kanban é usado em ambas as áreas para gerenciar fluxos de trabalho e minimizar atrasos ou gargalos.
Ambos os Kanbans envolvem o uso de cartões ou outros mecanismos de sinalização para indicar a necessidade de trabalho em uma determinada tarefa.
O Kanban é uma técnica visual que ajuda a garantir que os trabalhos sejam concluídos em tempo hábil e que os recursos sejam usados de maneira eficiente.
Diferenças
Os Kanbans da fábrica são mais focados no gerenciamento de materiais e fluxo de produção, enquanto os Kanbans de TI são mais focados no gerenciamento de projetos de software e na gestão de tarefas.
Na fábrica, os Kanbans são mais orientados para a produção em massa de produtos físicos, enquanto os Kanbans de TI são mais adaptáveis a projetos de software e soluções personalizadas.
Os Kanbans de TI são mais dependentes de ferramentas de gestão de projetos e softwares de rastreamento de tarefas, enquanto os Kanbans da fábrica geralmente usam ferramentas mais simples, como quadros de parede ou cartões de papel.
A equipe de TI tende a usar Kanbans mais colaborativos, enquanto a equipe de fábrica tende a usar Kanbans mais hierárquicos.
Em resumo, embora os Kanbans de TI e da fábrica tenham algumas semelhanças em termos de gerenciamento de fluxo de trabalho e uso de sinalização visual, as diferenças no tipo de trabalho e ferramentas utilizadas podem afetar a forma como os Kanbans são implementados e gerenciados em cada contexto.
Comentários Finais
Eu ainda poderia tratar sobre muitos outros assuntos relacionados ao Kanban, como por exemplo: Little Law; Diagrama de Fluxo Cumulativo; Pistas Rápidas no Quadro Kanban; Ferramentas Digitais Gratuitas (Trello, KanbanFlow, … ) etc. Porém creio que já construí uma boa introdução a respeito do tema Kanban.
Adicionalmente, você poderá fazer estudos práticos sobre Kanban com as simulações do Insight Maker. Segue exemplos de baixa, média e alta complexidade. Basta acessar os links e clicar em “Simulate”.
Enfim, o tema Kanban é inesgotável, e o que passei hoje serve como uma introdução a esse importante método de gestão visual de projetos/atividades.
Bons estudos!