DevSecOps

30 jul, 2014

Você conhece a diferença entre o sistema kanban e o método Kanban?

100 visualizações
Publicidade

O sistema kanban, na sua forma mais básica, é um sistema puxado e limitado, que permite a visualização do fluxo de trabalho, buscando a geração de valor por pessoas. Generalizando, é isso que o mercado entende por modelo ou sistema kanban. E assim foi definido originalmente, quando ele surgiu na indústria de produção como um “cartão visual” – traduzindo o termo.

Já o Método Kanban (idealizado por David J. Andersen), oferece uma abordagem evolutiva e incremental para mudança de processos e sistemas nas organizações. Na prática, o Método Kanban consiste em executar um sistema kanban focado em kaizen (promover pequenas alterações no processo, causando menor resistência à mudança) e gestão.

Você pode executar um Sistema kanban sem, efetivamente, utilizar o Método Kanban. Justamente daí surge a dúvida: k ou K? Espero que com as definições acima, você não tenha mais esta dúvida.

Falando um pouco mais sobre as bases do Método Kanban:

Princípios:

  • Comece com o que você tem hoje;
  • Implemente mudanças evolutivas e incrementais;
  • Respeite o processo atual, seus papéis, responsabilidades e cargos;
  • Estimule a liderança em todos os níveis da organização.

Propriedades:

  • Visualize o processo;
  • Limite o WIP (work-in-progress);
  • Gerencie e meça o fluxo;
  • Torne as políticas dos processos explícitas;
  • Implemente mecanismos de feedback;
  • Melhore colaborativamente e com métodos científicos.

Os princípios do Método Kanban são restrições que devem ser aceitas para qualquer iniciativa de implementação do método e como se pode observar, não são restrições de grande impacto, sendo fácil respeitá-las.

Ainda é possível fazer uma distinção, considerando as implementações menos profundas (que correspondem à maioria das implementações realizadas no mercado) e limitadas às duas primeiras propriedades, como Kanban básico. Enquanto isso, as demais propriedades podem nos ajudar a melhorar os processos, possibilitando uma aplicação mais avançada do método, ou seja, o Kanban avançado.

Mergulhando mais fundo no assunto, no sentido de uma aplicação avançada de Kanban, devemos considerar os conceitos de transição, kaizen, pensamento sistêmico, métricas, variabilidade, políticas explícitas e perfis de risco.

Pergunte-se: por que adotar o Kanban?

O processo de mudança acarreta uma perda de capacidade em função da curva de aprendizado. Normalmente se houve a metáfora da gestação: “9 mulheres não geram um filho em 1 mês”. Isso poderia ser verdade em uma linha de produção tradicional, mas não em desenvolvimento de software. Dobrar o tamanho de uma equipe não vai dobrar a sua capacidade, pelo menos não instantaneamente. Entenda por “capacidade” não apenas o resultado produtivo da equipe, mas também a comunicação, a habilidade técnica e estrutural, dentre outros.

Desta forma, grandes mudanças ocasionam maior perda de capacidade, o que, diga-se de passagem, não é bom. No Lean, este tipo de mudança é conhecido como Kaikaku, uma revolução com quebras de paradigmas. O gráfico abaixo representa este tipo de transição:

1rI5_34JRTNyTGK7iYMCKxZGUSOrhWgGKq7ETgg-1

Agora imagine que o gráfico acima representa um ano de capacidade de uma empresa, até a retomada da capacidade anterior perde-se tempo significativo, não é mesmo?! Outra observação importante: pode ocorrer abandono às mudanças, caso não haja um comprometimento efetivo na organização.

Com o Kanban, o objetivo é tornar a curva de aprendizado menor, retomando a capacidade anterior mais rapidamente e com menor resistência às mudanças. Agora veja o gráfico à seguir:

1_8qfLUI0hmVhKr21WbJX_ul3bIPjmWddgbU6aw-1

Esta é a cultura Kaizen, mais evolutiva e gradual do que revolucionária. Perceba que a retomada da capacidade anterior ocorre de forma muito mais rápida, podendo ainda, atingir capacidade maior à anterior logo em seguida.

Primeiro Kaizen

Durante uma implantação de Kanban, o primeiro kaizen serve para visualizar o processo e, a partir desta visualização, buscar disfunções no método como por exemplo o WIP alto, a falta de comunicação entre equipes de diferentes etapas do processo, os gargalos, bem como demandas de falhas (esta última, um fator muito importante).

Outra disfunção que pode ser observada no estágio do primeiro Kaizen é a alta variabilidade no throughout, uma das principais métricas do Kanban. Quando isso ocorre, o processo fica imprevisível, não sendo possível, por exemplo, prever as entrega

12BfJKjj1fg8H_OmoSjtn9xl8i3JWD0Qp8Uv0fw-1

De acordo com a prática do pensamento sistêmico, inicialmente não se deve alterar o processo, apenas visualizá-lo, observando o propósito do sistema. Outros padrões que podem ser observados através de pensamento sistêmico:

  • Fábrica de Bugs: demanda de falhas altas;
  • Software Inútil: funcionalidades não utilizadas;
  • Empresa de RH: pessoas insatisfeitas com o processo, causando alta rotatividade de colaboradores;
  • Entrega de Valor: entender o que agrega maior valor para os stakeholders e priorizar as demandas relacionadas.

Assim, com o Kanban implantado no processo atual, o mesmo será visualizado de forma que os problemas ficarão exposto e visíveis a todos. Em sistemas complexos, como um processo de desenvolvimento de software, muitas vezes só é possível deduzir o comportamento do sistema através dos resultados ou do output do sistema. Razão pelo qual, por exemplo, no Scrum as cerimônias de review e retrospect são realizadas após os Sprints, para se ter conhecimento dos resultados e com base nos mesmos buscar a melhoria contínua.

Dito isso, o Kanban surge com o intuito de promover mudanças de um cenário não desejado, como fábrica de bugs, produção de software inútil ou, uma empresa de RH, para um cenário de maior entrega de valor. Porém, mudanças são difíceis, principalmente em função do engajamento das pessoas mantendo o processo como algo habitual. Então é interessante que as mudanças do processo estimulem o engajamento das pessoas promovendo mudanças reais.

Políticas explícitas

Outra propriedade do Kanban, menos praticada mas não menos importante, é tornar as políticas explícitas. Elas ditarão o comportamento da equipe e após o primeiro Kaizen (quando o processo atual já foi observado e as políticas foram explicitadas), em conjunto, pode-se fazer criticas e propor mudanças, como por exemplo: limitar o WIP, a política de deploys, a agenda de cerimônias e o padrão de comunicação entre os times, dentre outras. No entanto, as mudanças propostas deverão ainda levar em conta a cultura Kaizen, ou seja, uma menor curva de perda capacidade!

Segundo Kaizen – Limitar o WIP

Muitas vezes, quando não limitamos o WIP observamos que o processo acaba por ter uma variabilidade alta no throughput e na vazão das demandas, o que torna o sistema imprevisível. A partir do momento que criamos a política de limitar o WIP, o processo passa a ter menor variabilidade e sendo mais previsível. Claro, isso não ocorre instantaneamente, como podemos ver nos gráficos a seguir.

1R7P61aSAvcJgb6eHiGFS9D8h1gFXq7mEO87LUw18TgUDeF0__HnpfbVUPBvJ5g8S934wKsgSg2z3w1rgpjVVWtipdttGDEOhQTnWH5yW3BejqDUY_B7A1aZ5gY4i2vAnzhJDBScpiwqY1NJCDQ4xaMzTRxA

Na prática, o WIP baixo tem quase o mesmo efeito do time box e do Scrum, mas com menor resistência emocional das pessoas envolvidas no processo. Pode-se observar muito mais resistência em uma mudança que afete as etapas do processo, do que simplesmente reduzir a carga nestas etapas. E por que o WIP limitado e baixo diminui a variabilidade das entregas? Isso pode ser explicado pela Lei de Little sobre Teoria das Filas, onde temos:

Throughput = WIP / Leadtime
Ou invertendo a formula:
Leadtime = WIP / Throughput

É importante considerar estas três variáveis: vazão, tempo de entrega e quantidade de trabalho em progresso. Temos controle sobre a quantidade de trabalho em progresso e não temos controle sobre o tempo de entrega das demandas, que pode ser observado mas não controlado, dependendo da capacidade da equipe.

Relacionando WIP e Leadtime quando temos WIP baixo, consequentemente temos um Leadtime menor e da mesma forma, Leadtime menor e Throughput maior. Isso é a base de um sistema kanban e é matemático. Desta forma, no Kanban nós não temos, ou melhor ainda, não precisamos de estimativas. Ao invés disso, podemos predizer quando uma demanda será entregue e isso, com base nas métricas acima. Em um sistema complexo é inútil tentar prever o comportamento do sistema, já no Kanban, a previsibilidade é obtida através do comportamento observado, neste caso, o Leadtime.

Nos exemplos e gráfico mostrados até aqui, observa-se que a partir do momento que o WIP foi limitado a variabilidade diminui, o Leadtime diminui e estabilizou, como mostra o próximo gráfico:

1G1QHJzcFmtLsByfv3PJ122w1ex5n6ADxmhSdwg

Normalmente a raiz desta melhora está relacionada ao fato que a equipe passa a colaborar mais entre si e não que as pessoas estejam trabalhando mais rápido. E após a estabilização do Leadtime, o tempo que uma demanda leva para percorrer todas as etapas do processo é conhecido. Assim não precisamos estimar, basta conhecer o Leadtime médio.

Além da falta de limite ou de um limite alto no WIP, podemos citar também como outros fatores que causam variabilidade do Leadtime (impedimentos), o tipo e complexidade das demandas, ou ainda, troca de prioridade entre elas, problemas de comunicação entre a equipe e outros fatores mais. Uma abordagem que pode ser utilizada para tratar a variabilidade em função do tipo/complexidade da demanda, é classificá-la por exemplo, em pequena, média ou grande. Mas isso pode gerar uma complexidade extra e na maioria das vezes, não se faz necessário.

De tudo o que foi dito até aqui, Throughput e Leadtime são as métricas mais básicas do Kanban. É possível também avaliar o seu processo analisando métricas como demandas de falhas, de valor ou ainda, de melhorias. Assim, a ideia básica do Kanban é equilibrar demanda e capacidade. É muito mais fácil controlar a entrada de demandas para a equipe do que a sua capacidade, e essa demanda de trabalho pode ser controlada de diversas formas, entre elas, posicionamento de mercado, gestão de risco ou redução do número de demandas de falhas.

Por fim, pensando no modelo econômico Lean, que podemos resumir em duas palavras: custo e valor, vemos que o Kanban pode nos ajudar a reduzir custos e aumentar a entrega de valor. Com as duas últimas imagens fica fácil perceber que a redução dos custos, mesmo quando pequena, pode proporcionar um grande aumento na geração de valor.

1wTYMX2XZ5DntaazFvPFIOgidfnpaPsgo9JM84w

1h_Aw1DnW2705zY0Ivjta4SoGo8bjAvLZwoNHcA

Artigo elaborado com base da Palestra de Rodrigo Yoshiama realizada no evento Agile Brazil 2012.