Kanban: evolua suas entregas com métricas

Principais métricas - Apresentação

Olá, sou o Roberto Sabino, sou instrutor na Alura, sou especialista em engenharia de software e agilidade, e estou aqui para convidar você para o treinamento Kanban Métricas. Esse treinamento é uma parte 2, nós já fizemos o Kanban parte 1, onde aprendemos os conceitos, onde acompanhamos uma história bem bacana de implantação da equipe da Léia Líder.

Ela fez uma sugestão para a gestão, para os desenvolvedores, de trocar de Scrum para Kanban. Nós agora continuamos com o mesmo cenário, só que agora nós já trocamos para Kanban, nós continuamos fazendo manutenção de sistema de concessão de crédito da Bytebank, só que agora temos que evoluir o nosso sistema Kanban.

Para isso nós temos métricas. Por exemplo, o nosso tempo de atendimento. Será que eu consigo diminuir o tempo de atendimento e manter a qualidade que eu entrego as coisas para o meu cliente? Se eu conseguir fazer isso, será que eu posso considerar que eu estou evoluindo?

E o meu cycle time, como ele pode me ajudar? Será que simplesmente limitar o trabalho em andamento vai fazer com que eu melhore a minha vazão? Ou será que eu tenho que fazer alguma outra coisa para que a minha vazão chegue naquilo que eu espero? As métricas me ajudam a medir para eu saber se eu estou evoluindo e se eu não estou evoluindo eu posso procurar o caminho da evolução no meu sistema produtivo Kanban.

Nós vamos analisar isso em várias situações e também no quadro, onde, muitas vezes, eu vou mostrar para você cenários onde vamos depois aprender a metrificar esses cenários. Como essa movimentação dos cartões está refletindo nas minhas métricas? Será que está bom, será que está ruim? Será que dá para melhorar?

É isso o que vamos analisar em vários cenários. Depois ainda vamos ver algumas outras coisas como, por exemplo, a Lei de Little, que vem da Teoria das Filas, vamos fazer umas contas, vamos chegar a algumas conclusões, vamos analisar essas contas e essas conclusões no quadro também, em relação ao nosso quadro.

Também vamos analisar o gráfico Cumulative Flow Diagram, ou Diagrama de Fluxo Cumulativo, para entender como podemos, batendo o olho nesse gráfico, saber se o trabalho está bom, se tem que melhorar quais sãos os pontos de melhoria. Isso tudo vamos aprender nesse curso Kanban Métricas.

“Sabino, como eu sei se esse curso, Kanban Métricas, é para mim?”. É muito fácil, se você fez o curso 1, Kanban Aprendendo os Conceitos, gostou do curso, chegou no final você falou: “eu quero ver a próxima temporada” - esse curso aqui é para você. Então vem comigo, vamos trabalhar com métricas, agora vamos trabalhar com números e entender como vamos evoluir esse quadro Kanban. Espero você na primeira aula, um abraço.

Principais métricas - Recordando nosso caminho

Vamos começar o nosso Kanban Métricas? Tem alguns avisos aqui no começo. O primeiro deles é que existe um curso Kanban Conhecendo o Método, que vem antes deste aqui, e é muito importante que você faça esse curso primeiro. Por quê? Porque vamos conhecer todo o cenário que nós vamos trabalhar agora nas métricas, e métricas são um pouco complicadas, porque entra uma matemática no meio, às vezes dá confusão.

Então tem que estar bem antenado no contexto de tudo o que está rolando no nosso cenário, com os personagens e tudo mais. Uma outra coisa é: esse curso é um curso que rola uma matemática em alguns momentos, porque é um curso de métricas. Às vezes é necessário voltar, ver o vídeo de novo, isso é normal. É normal.

É claro que no vídeo eu não vou ficar repetindo várias vezes o conceito justamente porque você tem esse recurso de tentar ver o vídeo de novo, tentar fazer uma conta no canto para ver se está batendo ou não. Então isso é normal, neste curso aqui é normal. Eu vou começar fazendo uma revisão do curso anterior, rápido, só neste vídeo aqui, para lembrarmos, porque, às vezes, você já fez o curso faz um tempo, é bom darmos uma relembrada.

Vamos lá? Léia Líder é a nossa líder de equipe, líder de squad, e ela fez uma proposta. A proposta era trocar de Scrum para Kanban. No curso 1, nós implantamos o Kanban e foi um sucesso, a Léia Líder considera que foi um sucesso. Temos que lembrar que o Kanban é um método evolucionário. Essa palavra, ela é bem interessante, porque não usamos ela muito no dia a dia, às vezes falamos mais evolutivo.

Mas aqui a ideia é que dentro deste método, ele vai evoluindo, você como equipe, o seu quadro vai evoluindo, a sua forma de lidar com ele vai evoluindo, então isso é importante. Só que, como eu sei se ele está evoluindo ou não, se eu não tenho algum número que meça o quanto eu estou entregando, ou quanto tempo eu demoro para entregar, ou alguma coisa, algum número que seja importante para mim?

Que eu possa medir: esse número é importante para mim, ele está melhorando, então estamos melhorando. Eu preciso disso e é aqui que entram as métricas. Antes de falarmos de métricas, vamos recordar um pouco o que fizemos no curso 1. Nós vimos o processo de trabalho dessa equipe da Léia Líder, nós vimos um pouco os clientes, como eles trabalhavam, o que eles precisavam.

Nós analisamos a performance do time da Léia Líder junto com os programadores, os desenvolvedores. O time dela é um time de manutenção em sistemas de concessão de crédito - não precisa conhecer nada de crédito e nem de concessão de crédito para acompanhar, nem o curso 1 e nem o curso 2, mas é um cenário que nós usamos.

E começamos comparando o Scrum e Kanban. “Sabino, qual é melhor, Scrum ou Kanban?”. Depende, nós já vamos ver isso daqui a pouco. Aliás, nós já vimos no curso 1 e vamos relembrar agora, mas existe, você vai ver gente que vai defender com unhas e dentes ou Scrum ou só Kanban, e eu não acho que é por aí. Eu acho que temos que analisar o cenário, temos que entender qual é melhor e qual não é.

Mas as análises passam por: o Scrum é mais iterativo e incremental, o Kanban é mais para fluxo contínuo. “Por que você fala, Sabino, é mais para?”. Porque, na verdade, dependendo da forma como você está trabalhando, você vai trabalhar com o Kanban quase que iterativo e incremental e vai trabalhar com o Scrum quase fluxo contínuo, depende de como você está operacionalizando.

Mas a teoria do método Kanban e do framework Scrum trazem essas características: Scrum é iterativo e incremental, Kanban é fluxo contínuo. E eu já falei duas palavras que geram muita confusão: método e framework. O Kanban é um método, o Scrum é um framework. “Sabino, é preto no branco?” Não é. Por quê?

Porque tem gente que chama Kanban de framework, eu não concordo. Eu, particularmente, não concordo. Por quê? Porque um framework é uma forma de trabalho que você tem, dentro desse framework, tudo o que você precisa para começar a trabalhar nesse framework.

Então você tem os papéis, você tem as atividades, você tem os artefatos, você tem tudo, pelo menos o mínimo que você precisa para começar a rodar esse framework. E o Kanban não tem isso. Por quê? Porque o Kanban começa pelo que você já tem. Você pode ter, por exemplo, um product owner e você quer manter o product owner, você pode manter o product owner no seu Kanban.

Ou seja, ele não é um framework que tem os papéis, os artefatos, tudo fechado, que você tem que rodar dessa forma. Claro que o Scrum também - por exemplo, tem gente que roda Scrum e no time de desenvolvimento você não tem só desenvolvedor, você tem especializações. Tudo bem, não tem problema.

Mas o Kanban, ele aceita muito mais isso, então você pode ter, por exemplo, um gerente de projetos no Kanban, não tem problema nenhum. Por isso o Kanban é conhecido como um método, ele é um método de redução de desperdícios e de entrega contínua. Então ele não é um framework, mas sim, você vai encontrar em algumas literaturas algumas pessoas falando que o Kanban é um framework.

Meu conselho é: não discuta, é melhor. Maturidade do time, nós discutimos também. Por quê? Porque é mais fácil, às vezes, você implantar Kanban - de novo, por quê? Começa pelo que você já tem. Às vezes é mais fácil implantar Kanban do que implantar Scrum, o Scrum necessita desse mínimo, tem que ter PO, tem que ter Scrum Master, tem que ter time de desenvolvimento.

O time tem que ter de tantas a tantas pessoas, as sprints têm que ser de tanto a tanto tempo, todas essas coisas temos que ter no Scrum. Então, às vezes, um time com maturidade muito baixa em Ágil se adapta melhor ao Kanban. Por outro lado, às vezes o time tem maturidade tão baixa que ele não conseguirá começar pelo que ele já tem, ele precisa dar um choque, e talvez seja melhor o Scrum. Então vai muito do cenário.

Depois vimos - essa aqui talvez, essa comparação backlog versus gestão visual, é a que dará mais dúvidas. Por quê? Porque o Kanban tem backlog e o Scrum tem gestão visual. Mas o Kanban, ele é baseado na gestão visual - visual mesmo - e o Scrum é baseado em backlog. Por quê?

Porque o Scrum guide fala de backlog, ele fala de como você vai cuidar do backlog, mas ele não te obriga a ter uma gestão visual. Só que a agilidade traz para a gestão visual, assim como a agilidade também traz para backlog, sem eu necessariamente estar falando de Scrum ou Kanban.

Então aqui, provavelmente, você vai usar os dois nos dois - provavelmente. Mas o Kanban, ele necessita da gestão visual e o Scrum necessita do backlog. Muito bem, a Léia Líder, ela chega a uma conclusão, que é uma conclusão meio que um consenso das pessoas sensatas, que o Scrum, ele é bom para produto novo e ele é bom para produto em produção, mas ele não é muito bom para manutenção de produtos.

O Kanban, ele não é muito bom para produto novo, mas ele é bom para produto em produção e para manutenção de produtos. Aqui fica um quadro que te dá mais ou menos uma ideia. Se você trabalha em uma equipe de manutenção de sistemas, de manutenção de produtos, de manutenção de aplicativo, talvez o Scrum não seja a melhor coisa para você.

Falamos de Proto-Kanban, como começa, isso aqui não é nada novo, não é uma coisa diferente. Proto-Kanban nada mais é do que você começar a fazer Kanban mesmo sem fazer Kanban. Ou seja, eu estou começando, eu fiz o meu quadro, tem um monte de coisas que eu não fiz ainda, mas é o Proto-Kanban, é um começo de Kanban, é um quase Kanban. Tem o Scrumbut também, não tem?

É parecido, mas o Porto-Kanban, a ideia é que você tenha um começo, um gérmen, depois você tem um broto, depois ele floresce, enfim, você terá, no futuro, um sistema Kanban completo, mas você não consegue começar com um sistema Kanban completo, então você começa com um Proto-Kanban, um projeto, protótipo, de Kanban. Não precisa se preocupar, não precisa gravar esse nome, não precisa nada.

Falamos um pouco da gestão visual em si, para entender um pouco como era, como não era, comparamos o quadro físico com o quadro eletrônico. Lembrando que eu estou fazendo uma revisão rápida de tudo o que vimos no curso 1. Se não fez o curso 1, vale muito a pena ver.

Depois nós trabalhamos com o que aconteceu na prática, então nós analisamos a prática da Léia Líder dentro do squad dela. Vimos uma raia de urgentes, que se usa muito no Kanban, quais são as coisas que temos que ver, porque tivemos que criar uma política explícita, porque essa prática de ter políticas explícitas é boa no Kanban.

E entramos no ponto, que talvez seja uns dos pontos que conecta muito com esse curso 2, que é a limitação do work in progress. Quanto eu tenho que limitar o meu WIP dentro do Kanban? Isso é importante, mas vamos falar um monte de vezes disso. E falamos também que colaborar com o cliente é melhor que usar a redução de WIP como uma muleta para não atender direito o cliente.

Falamos de Teoria das Filas, isso foi na aula 5, nós entramos em Teoria das Filas, e é justamente aqui que começa este curso de métricas, porque a Teoria das Filas é justamente o que dá base para começarmos a falar. E falamos, no final de lead time, cycle time, WIP e throughput, que é o tempo de atendimento, o tempo de ciclo, trabalho em andamento e o tempo de vazão.

É daqui que começamos, já no próximo vídeo começamos a falar das métricas com Kanban, as principais métricas, e como você vai usar essas métricas para medir se o seu Kanban está evoluindo ou não.

Principais métricas - Principais métricas

Vamos dar uma relembrada nos conceitos das métricas antes de entrarmos nas métricas propriamente ditas? No curso 1, nós já trabalhamos um pouco com métricas, então já tínhamos visto algumas coisas. A Léia Líder já tinha dito para a equipe que há dois passos para usar métricas: o primeiro é aprender a teoria e o segundo é entender na prática.

A teoria nós já vimos, já conhecemos, então o time já conhece, agora vamos aprofundar na prática. Nós vimos lead time, tempo de atendimento; cycle time, tempo de ciclo; WIP, que é work in progress ou trabalho em andamento; e vimos o throughput, que também é, ou pode ser conhecido como tempo de vazão.

O que é o lead time? Lead time é o tempo necessário para percorrer todo o ciclo - vamos dar uma rabiscada nessas coisas para vermos? Será a única hora que veremos conceito, depois é prática o tempo todo, então vamos aproveitar esses minutos de teoria. É o tempo necessário para percorrer todo o ciclo de produção. Tem um problema aqui, o problema é: o que é o ciclo de produção?

O ciclo de produção é sempre desde o pedido do cliente até a entrega para o cliente. Significa que, por exemplo, no nosso quadro, quando a Léia Líder decidiu junto com o Léo Rico, que é o cliente, que as coisas que estão em backlog ainda não estão pedidas - tudo o que aparecer vamos pôr em backlog, mas não vamos começar a trabalhar, só vamos começar a trabalhar quando essa coisa vier para análise.

Então quando esse pedido chega em análise é quando ele realmente começa o ciclo de produção, e esse ciclo de produção vai até finalizado. Ou seja, no nosso caso, o nosso ciclo de produção vai de análise até finalizado, o nosso backlog é um estacionamento de um monte de coisas, mas que não estão em andamento ainda.

Isso está de acordo, a Léia Líder e o Léo Rico entraram em um acordo então está tudo bem, não tem problema nenhum. Isso só vira discussão, isso só é um problema quando um acha uma coisa e outro acha outra. Como eles estão de acordo, não tem problema nenhum. Então o lead time será muito importante para medir as melhoras.

Olha que importante: medir e melhorar. Como eu posso evoluir se eu não consigo medir? Não consigo, então precisamos medir. Vamos para o nosso cycle time, o tempo de ciclo normalmente é usado para medir o tempo de uma atividade, que é a mudança de uma coluna para a outra, mas pode ser usado para medir qualquer ciclo que seja importante.

No nosso caso, vamos ver que existe sim um ciclo que é importante, esse ciclo importante é - ou melhor, dois, nós teremos dois ciclos muito importantes, de análise até aguardando testes, é o primeiro ciclo importante. Esse ciclo tem três atividades, ou três colunas, então eu tenho 1, 2, 3. Eu poderia ter três cycle times, um cycle time de análise, um de fazendo e um de aguardando teste.

Posso medir esses cycle times? Posso, mas o que estamos dizendo é que o cycle time de análise até o aguardando teste, para nós, é um cycle time que é importante, você pode medir assim. Depois teremos de quando começa a testar até que ele esteja entregue, é um segundo cycle time, que tem duas atividades, e que vamos medir o tempo deste primeiro cycle time e do segundo cycle time, dos dois.

De novo, isso só é um problema se tiver diferença de opinião, senão está tudo tranquilo. A Léia Líder sugeriu: podíamos usar o cycle time para medir o tempo gasto entre a análise e os testes. Por que isso? Nós vamos ver no decorrer do treinamento porque esse cycle time é importante.

O work in progress, eu acho que de todos, é aquele que está mais óbvio o que é porque nós trabalhamos muito com ele no primeiro curso. Então eu vou passar meio direto, e vamos falar bastante dele aqui de novo também. Trabalho em andamento, que é work in progress, é como chamamos todas as tarefas já iniciadas que ainda estão em processo de produção.

Eu iniciei? Sim. Terminei? Não. Então é work in progress. Mas também podemos medir o work in progress de um momento específico. Por exemplo, eu posso dizer: qual é o WIP de fazendo neste momento? Serão todas as tarefas, os cartões, que estiverem em fazendo. Neste caso aqui, 3, seria 3 WIP de fazendo.

Mas, de verdade, tudo que estiver entre análise e não tiver chegado em finalizado ainda - eu vou apagar essa linha porque não ficou bom. Temos que pensar aqui, será o seguinte: de análise até testando - mas depois do teste, não tem deploy? Nós não colocamos isso no Kanban, então o nosso sistema Kanban, ele não enxerga isso.

Se eu quiser controlar coisas que acontecem depois do teste e antes de finalizar, eu preciso colocar novas colunas aqui, o que pode acontecer sem problema nenhum. Mas, por enquanto, terminou de testar, se eu puxar para finalizado, acabou. Eu não fiz assim: finalizado pronto para finalizar e finalizado. Então o Kanban não está controlando isso.

Então quando chega no finalizado não é mais work in progress, porque terminou, neste caso. “Sabino, depois do teste, já terminou?”. Não sei, mas neste nosso Kanban sim. Pode ser que tenha que fechar pacote, tenha que entregar, tenha a aprovação de um, de outro. Tudo bem, mas não estamos controlando. Nós precisaríamos de uma outra coluna que representasse todo esse processo.

Lembre que o Kanban representa o processo, então ele tem que representar o processo. Por isso que eu estou dizendo: o que é work in progress geral? Work in progress é tudo o que estiver em análise até testes, é work in progress, mas eu posso perguntar qual é o work in progress de uma coluna específica de acordo com a necessidade de métricas que eu tiver.

Work in progress é super tranquilo porque trabalhamos com ele a todo momento, falamos dele a todo momento, então não tem como não entender. Já vimos que o WIP é fundamental para o uso do método Kanban e a Léia Líder está nos lembrando: é importantíssimo diminuir o WIP, é uma meta.

Se você ainda tiver dúvidas sobre isso, dê uma olhada de novo no curso 1, que falamos disso: diminuir o WIP é uma meta. Muito bem, e o throughput, por último, mas não menos importante, vazão, é a quantidade média de entregas que o time consegue fazer em um período de tempo. Por exemplo, o time entrega 4 cartões em dois dias, então a média é 4 cartões em dois dias.

Uma coisa que vamos ver, muito interessante, é que as métricas, elas não são medidas em uma vez, temos que criar uma base histórica para podermos saber qual é o número daquela métrica, e ela tem que ser atualizada com o tempo.

As tarefas podem ficar mais complexas, o time pode ter mudanças, o cenário pode ter mudanças, e precisamos de médias dessas métricas, precisamos de média histórica, precisamos saber o histórico frente às mudanças de contexto, várias coisas que podem mudar as métricas.

A vazão é o principal medidor da nossa produtividade. Podemos melhorar se pudermos medir. Isso aqui é muito importante, nós trabalhamos um pouco essa ideia no curso 1, mas o curso 2 é o que vai deixar bastante claro que medir é fundamental para podermos melhorar. Estão aqui as principais métricas do Kanban. Mas agora vamos começar a olhar na prática essas métricas e algumas outras também importantes, como podemos usar isso, na prática.

Sobre o curso Kanban: evolua suas entregas com métricas

O curso Kanban: evolua suas entregas com métricas possui 162 minutos de vídeos, em um total de 41 atividades. Gostou? Conheça nossos outros cursos de Gestão de Produtos em Inovação & Gestão, ou leia nossos artigos de Inovação & Gestão.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Principais métricas
• Teoria de Little
• Cenários
• CFD e eficiência de fluxo
• Métricas na prática
• Maturidade alcançada