O sistema Kanban começou sua jornada na década de 1950 nas linhas de produção da Toyota, após o qual foi transferido para escritórios e se tornou uma ferramenta importante para gerentes de projetos.
A flexibilidade ilimitada da prática e sua capacidade de auto-organizar o pessoal permitiram eficiência onde outras abordagens não funcionaram. É o caso em que o cartão de visita do sistema se tornou o próprio cartão — ele se estabeleceu como uma moeda interna em organizações que implementaram o Kanban.
Origem
Assim como o conceito de manufatura Lean, o sistema Kanban foi desenvolvido por gerentes da Toyota. O autor do sistema, o engenheiro japonês Taiichi Ohno, foi inspirado pelos princípios operacionais dos supermercados americanos, onde os clientes selecionavam os produtos de que precisavam. O papel de “supermercado” na Toyota era desempenhado pelo armazém.Lá, cartões de sinalização — que é o que “kanban” traduz literalmente do japonês — eram trocados entre os trabalhadores, que regulavam manualmente o processo de produção.Cartões eram anexados a caixas com peças. Esses rótulos indicavam informações sobre o número da peça e a quantidade, qual departamento as estava enviando e para onde deveriam chegar.
O trabalhador diretamente envolvido na montagem de máquinas (“descendente”) pegaria peças da caixa à qual o “kanban” solicitando reabastecimento estava anexado. O cartão era removido e passado juntamente com a caixa vazia para o transportador até o armazém. Lá, outro trabalhador preparava uma nova caixa com peças sobressalentes, à qual o “kanban” de produção — uma etiqueta contendo informações sobre as peças sobressalentes produzidas — estava anexado.
O “kanban” de produção era substituído por um “kanban” solicitando reabastecimento e enviado para a linha de produção de peças sobressalentes — “ascendente”. Assim, exatamente a quantidade de peças especificada no cartão foi produzida. A caixa com novas peças sobressalentes era colocada por transportadores na linha de montagem.
Princípios do Kanban
Os gerentes da Toyota articularam 6 regras formadoras do sistema:
- Trabalhadores do “descendente” removem exatamente tantas peças do estoque quanto especificado no kanban
- Trabalhadores do “ascendente” também fornecem peças estritamente de acordo com os cartões
- Nada é produzido ou movido sem um kanban
- O kanban deve sempre estar anexado às peças
- Peças defeituosas não são usadas no sistema
- Reduzir o número de cartões kanban torna a gestão mais sensível a mudanças. Mas, sem extrema necessidade, não é aconselhável mudar o número estabelecido de cartões.
O Kanban é um sistema “puxar”. Ele cria um equilíbrio entre um fluxo constante, que elimina custos de espera, e uma quantidade mínima de trabalho em andamento (WIP), que reduz os riscos de superprodução. O WIP é regulado usando cartões: seu número é fixo, e as instruções neles orientam os trabalhadores “descendentes”.
O limite de WIP consiste em proporção ao número de cartões kanban, que é calculado com base nos níveis de vendas e na variabilidade estatística nos processos atuais. O número máximo de etiquetas — a “energia” no sistema — garante o nível superior de WIP em qualquer momento. O WIP também é limitado pelo princípio de puxar: a velocidade de produção do lado ascendente depende da velocidade de trabalho do lado descendente.
O gráfico mostra que um dos elementos básicos do sistema é a cultura Kaizen. Processos autônomos e variabilidade padrão liberam a gestão de supervisão constante, permitindo que se concentrem na melhoria do desempenho dos funcionários.
Aplicação do Kanban em TI
O sistema Kanban, continuando a fornecer benefícios nas linhas de produção, penetrou no domínio do software.
Apenas cartões, que contêm informações sobre prazos, descrições ou números de processo e o nome do executor, agora estão anexados não a caixas de peças sobressalentes, mas a quadros com colunas divididas:
- Backlog — tarefas a serem concluídas
- Tarefas atualmente em desenvolvimento
- Tarefas concluídas, mas ainda não entregues aos testadores
- Tarefas prontas para entrega ao departamento de testes
- Tarefas passando pela revisão do gerente de projeto (PM)
- Tarefas concluídas
Número é geralmente escrito acima das colunas — o limite, que indica o número máximo de processos nelas. O limite do backlog é calculado dependendo do tempo de entrega. Se houver 5 processos de trabalho no sistema e o tempo médio de conclusão de cada um for de 1 dia, o backlog pode ser limitado a 5.
A estrutura acima não é rígida — dependendo das especificidades do projeto, colunas improvisadas podem ser adicionadas. Um sistema Kanban pode muitas vezes ter a necessidade de definir critérios para a prontidão da tarefa antes da execução. Nesse caso, aparecem duas colunas, referidas em inglês como specify (esclarecendo parâmetros) e execute (assumindo o trabalho).
- Outra coluna com uma fila prioritária pode ser adicionada. Quando um executor se torna livre, precisa limpar essa coluna de tarefas primeiro antes de assumir outras.
- Tarefas que não foram concluídas são ou retornadas ao backlog ou riscadas do esquema.
- O Kanban não incentiva o multitasking, limitando assim o número de processos para cada executor.
- O trabalho concluído é melhor do que várias tarefas iniciadas.
- Um segundo trabalho pode ser assumido se o primeiro estiver bloqueado.
- O tempo para execução da tarefa deve ser equilibrado. Um prazo muito curto pode afetar a qualidade. Um limite excessivamente estendido consome recursos da equipe e aumenta os custos de processo.
Por que o quadro Kanban é usado em todos os lugares em vez de, por exemplo, tablets ou grandes monitores? Os defensores do sistema respondem a essa pergunta afirmando que um quadro comum tem duas vantagens: é simples e fornece controle visual. É fácil fazer alterações nele e incentiva a interação tátil e social entre os membros da equipe.
Vantagens e Desvantagens do Kanban
O Kanban tem as seguintes vantagens:
- Flexibilidade no planejamento. A equipe se concentra exclusivamente no trabalho atual, com a prioridade das tarefas definida pelo gerente.
- Alto engajamento da equipe no processo de desenvolvimento. Devido a reuniões regulares, transparência do processo e oportunidades para auto-organização, os funcionários se unem e mostram interesse genuíno.
- Duração do ciclo mais curta. Se as habilidades necessárias são possuídas por várias pessoas, a duração diminui; se apenas uma pessoa as possui, um gargalo surge. Assim, os funcionários devem compartilhar conhecimento otimizando a duração do ciclo. Isso permite que toda a equipe trabalhe em tarefas paradas e restaure o fluxo síncrono.
- Menos gargalos. Os limites de WIP permitem a rápida identificação de gargalos e áreas problemáticas que surgem devido à falta de foco, mão de obra ou habilidades.
- Visibilidade. Quando todos os executores têm acesso aos dados, fica mais fácil identificar gargalos. As equipes Kanban, além dos próprios cartões, geralmente utilizam dois relatórios comuns: gráficos de controle e fluxo cumulativo.
Na prática, o sistema mostra ótimos resultados em áreas de produção não essenciais:
- grupos de suporte de software ou help desks.
- O Kanban funciona bem na gestão de startups sem um plano claro, mas onde o desenvolvimento ativo está acontecendo.
O Kanban também tem desvantagens:
- o sistema funciona mal com equipes de mais de 5 pessoas
- não é destinado ao planejamento de longo prazo.
Diferenças em relação ao Scrum
O Scrum, como o Kanban ágil, é uma metodologia flexível que também é frequentemente aplicada na esfera de TI. As diferenças entre eles não são óbvias à primeira vista. Existem muitas semelhanças, por exemplo, a presença de um backlog em ambas as abordagens.
Scrum | Kanban | |
Ritmo | Sprints repetidos de duração fixa | Processo contínuo |
Saída de liberação | No final de cada sprint após aprovação do gerente de projeto (proprietário do produto) | O fluxo continua sem interrupção ou a critério da equipe |
Papéis | Proprietário do produto, mestre Scrum, equipe de desenvolvimento | Equipe liderada pelo PM; em alguns casos, treinadores de Kanban ágil estão envolvidos |
Métricas-chave | Velocidade da equipe | Tempo de entrega |
Em relação à aceitabilidade de mudanças | Durante um sprint, mudanças são indesejáveis, pois podem levar a erros de cálculo nas tarefas | Mudanças podem ocorrer a qualquer momento |
Exemplos de Aplicação em TI
Direto da Microsoft: O Debut do Kanban no Desenvolvimento de Software
O uso dos princípios Kanban na tecnologia da informação começou um pouco mais de 10 anos atrás. David Anderson, um dos principais promotores do Kanban para desenvolvedores de software, consultou a Microsoft em 2005. Eles estavam insatisfeitos com o desempenho de seu departamento — XIT Sustained Engineering, que consertava bugs em aplicativos internos. No início do ano de relatório, esse departamento era o pior de sua divisão. O backlog excedia o tamanho aceitável em cinco vezes, e o tempo de entrega para processar um pedido era tipicamente de cinco meses.
O novo PM, com as consultas de Anderson, aumentou a produtividade do departamento problemático em 155% em nove meses. O tempo de entrega agora era de cinco semanas, o backlog voltou a um tamanho normal, e a conclusão oportuna das tarefas estabilizou em 90%. Todos esses resultados foram alcançados com uma integração mínima de novos funcionários; a equipe continuou a consertar bugs da mesma maneira — só mudaram as abordagens para organizar o trabalho.
Um fato interessante: o gerente de programa Dragos Dumitriu, que se propôs a reverter a situação no XIT, foi simplesmente cativado pelo livro de Anderson. Para sua surpresa, ele conheceu o ideólogo do Kanban no próprio Microsoft onde havia começado apenas um dia antes. Dumitriu pediu ajuda a Anderson com sua tarefa, e este concordou em aplicar os princípios de seu livro na prática.Dumitriu encontrou um departamento composto por três desenvolvedores e três testadores, que tinham 80 pedidos acumulados no backlog. O próprio PM foi temporariamente nomeado, uma vez que os requisitos do trabalho incluíam expertise em tecnologia ASP, administração do SQL Server e conhecimento do MS Project Server. A gestão imaginava um “tecnólogo” que pudesse codificar, preparar relatórios e prever a carga do backlog nesta posição. Como se acreditava na época, o problema do departamento seria revelado se uma grande quantidade de dados fosse coletada. Dumitriu não era esse “tecnólogo”.
No entanto, ao começar a analisar as operações do XIT ao lado de Anderson, ele rapidamente identificou os principais fatores que afetavam negativamente a velocidade do departamento:
- Prever as implicações (ROM) de atender a um pedido levava muito tempo. Tanto o desenvolvedor quanto o testador tinham que gastar um dia de trabalho realizando os cálculos necessários, verificando o código e completando a documentação. Em média, um pedido chegava a cada dia. Segundo os cálculos do PM, 40% da produtividade do departamento ia para o ROM;
- Prioridade era dada a pedidos de maior valor. O XIT era financiado com base no valor do pedido. A priorização de pedidos era discutida mensalmente em reuniões de gerentes de departamento com clientes — gerentes de outros departamentos. Com um backlog crescente na velocidade atual, onde apenas 6 – 7 pedidos eram processados mensalmente, as prioridades de outros pedidos mudavam constantemente devido à passagem do tempo. Muitos deles eram adiados para um “muito depois”, não igual ao próximo mês.
- No estágio do ROM, metade dos pedidos eram filtrados. Alguns eram grandes demais e foram requalificados como projetos a serem transferidos para outros departamentos, outros eram caros demais e simplesmente cancelados. Alguns pedidos não eram levados para o desenvolvimento porque a implementação levaria muito tempo. Assim, 40% da produtividade do departamento era gasta na análise de pedidos, 50% dos quais eram descartados. Cerca de 15 – 20% dos recursos de trabalho foram desperdiçados.
- O trabalho preparatório sobre pedidos poderia se arrastar por meses antes que a implementação começasse. Cálculos na fase do ROM podiam ser perdidos ou esquecidos durante esse tempo. Especialmente se a implementação fosse conduzida por um desenvolvedor diferente daquele que começou a análise.
Soluções Kanban para o departamento problemático da Microsoft
No final de 2005, a produtividade do departamento aumentou em 155%. Para melhorar ainda mais o trabalho do XIT, dois funcionários foram contratados: um desenvolvedor e um testador. O número de pedidos no backlog diminuiu para 10, e um desenvolvedor processou consistentemente 11 pedidos por trimestre. Em média, 56 pedidos foram concluídos por trimestre em comparação com 11 anteriormente. O custo dos pedidos caiu de $7500 para $2900.
Aplicação na Corbis
Depois de alcançar sucesso na Microsoft, Anderson em 2006 começou a enfrentar uma nova tarefa complexa. Agora ele trabalhava na Corbis — outra empresa de Bill Gates, que ainda não havia saído da MS. Uma das atividades da Corbis era licenciamento de fotos. Naquela época, era a segunda maior biblioteca de fotos de estoque do mundo, com um banco de dados de cerca de 3,5 mil imagens.
A tarefa de Anderson era acelerar os lançamentos principais da empresa. O intervalo entre seus lançamentos era de três meses e poderia crescer ainda mais. Apenas discutir o plano de lançamento levava à gestão duas semanas. Era necessário estabelecer o lançamento de lançamentos secundários ou atualizações a cada duas semanas. Ao mesmo tempo, recursos-chave precisavam ser direcionados para o projeto principal.
Um quadro Kanban apareceu no escritório da Corbis, onde Anderson falava com a equipe diariamente. O objetivo do PM era melhorar o controle visual sobre os processos, incentivar a auto-organização e uma maior responsabilidade pessoal entre os executores. O sistema Kanban também visava reduzir a supervisão do gerente e aumentar a produtividade.
Além de cartões coloridos e gráficos, uma “lixeira” apareceu no quadro — para onde tarefas que eram grandes demais eram enviadas.
Foto da apresentação oficial apresentação
Um Sistema Kanban para Sustaining Engineering em Sistemas de Software por David J Anderson
O sistema Kanban esclareceu quando o fluxo deixa de ser suave e onde ocorrem atrasos, o chamado gargalo. Discussões rápidas com a equipe ajudaram a identificar problemas atuais. Por exemplo, os testes levavam 3 dias, o que impactava negativamente o cronograma de lançamento. Três funcionários se reuniram e encontraram uma maneira de reduzir o tempo para um dia.
Um gargalo é uma seção do esquema ou algoritmo das operações da empresa, onde limitações de recursos ou produtividade humana reduzem acentuadamente a capacidade do fluxo de tarefas. Uma escassez de mão de obra, uma internet ruim ou um diretor de férias bloqueiam ou desaceleram a execução de tarefas.
Limites para cartões Kanban foram definidos de maneira empírica duas vezes. Na coluna “pronto para desenvolvimento”, os limites foram aumentados. Uma nova coluna — “pronto para teste” — também surgiu. Muitos pedidos para o lado descendente foram mal formulados, causando desperdícios de tempo desnecessários. Portanto, o PM investigou as operações do fluxo superior e encontrou erros.
O procedimento de revisão de pedidos poderia levar 100 dias, mas os lançamentos ainda começaram a surgir a cada duas semanas conforme planejado. As decisões sobre o conteúdo do lançamento eram tomadas 5 dias antes da publicação. A prática de contagem, como no caso do departamento XIT na Microsoft, foi abandonada em favor da produtividade. As prioridades das tarefas eram definidas de acordo com o “custo dos atrasos” ou prontidão dos recursos.
O sistema Kanban não apenas ajudou Anderson a alcançar o objetivo definido, mas também melhorou a moral dentro da equipe. Graças a discussões coletivas e visibilidade dos processos, os funcionários estabeleceram confiança uns nos outros. A equipe também abraçou o Kaizen, ou seja, a prática de melhoria contínua.
Programas e Aplicativos para KANBAN
Trello
Sistema popular de Kanban para gerenciamento de tarefas. É notado por seu apelo visual e interface amigável. Os usuários destacam sua super flexibilidade.
Kanbantool
Quadro gratuito para dois usuários. Suporte API e interfaces touch.
Lean Kit Kanban
Quadro gratuito para cinco usuários com boas recursos de colaboração. Suporte API e capacidades de importação/exportação, estatísticas extensas.
Kanbanize
Serviço completamente gratuito com funcionalidade decente. Seus proprietários garantem um aumento de 300% na produtividade ao usar seu produto.
Worksection
Ukrainian SaaS — aplicação para rastreamento rápido e gerenciamento de projetos. Atualmente, além de contabilizar finanças e prazos, há um gráfico de Gantt. Nos próximos meses, os desenvolvedores irão adicionar um quadro Kanban com opções de personalização, tornando o serviço ainda mais adequado para Kanban.
Veredito
O Kanban é uma prática que ajuda a alcançar o sucesso, enquanto o uso apenas de métodos ágeis não é obrigatório. Mudanças significativas são alcançadas eliminando o tempo perdido, gerenciando gargalos e reduzindo a variabilidade.
No entanto, mudanças bem-sucedidas exigem tempo. Elas ocorrem gradualmente, enquanto a resistência da equipe às inovações é mínima. O sistema Kanban motiva o pessoal a melhorar sem mudanças nos métodos de engenharia.
Livros para o artigo são fornecidos por kniga.biz.ua