Introdução ao método Kanban para melhorar fluxo de trabalho

Menos reunião, mais post-it!
Introdução ao método Kanban

Oe!
Rodrigo Vieira
Pai, nerd, agilista, programador, gerente de produto e de projeto
Uso Kanban há mais ou menos 6 meses
(em TI isso significa que já sou sênior)

Agenda
1. Jogo das Cartas: Lei de Little na prática
2. Conceitos básicos
3. Cenários baseados em casos reais (ou seja, no meu trabalho)
4. Perguntas, bate-papo

Jogo das
cartas
Estamos contratando (início
imediato):
○ 4 “operários”
○ 4 “supervisores”
○ 1 “gerente de operações”

Retrospectiva do jogo
- Como vocês se sentiram nas diferentes
situações?
- Como vocês entendem o resultado
encontrado?

3 números e uma Lei
Rendimento
(Throughput)
WIP
Tempo de Ciclo
(Lead Time)

Lei de Little
(1961)
Tempo de Ciclo =
WIP
Rendimento

Lei de Little
(1961)
WIP
Rendimento
Tempo de Ciclo =

Kanban: Sinalização
● Sinalização de capacidade
● Trabalho é sempre “puxado”, e não “empurrado”
● Sistematizado na Toyota/Japão (TPS)
● Todos nós usamos há muito tempo!

Método Kanban
2. Limite WIP1.Visualize o
trabalho
3. Gerencie o
fluxo

Três regras “oficiais”
1. Comecem onde vocês estão
2. Evoluam gradualmente e observem resultados
3. Respeitem papéis e responsabilidades
Como adotar Kanban

Conheça a...
Softweria
■ Startup com 6 empregados, desenvolvem software mobile e Web
■ 1 admin/comercial/gerente de produtos (PO)
■ 3 devs
■ 1 designer
■ 1 QA/suporte
■ Estão tocando 3 projetos e tentando desenvolver um produto próprio

A lista é longa...
1. Muitos atrasos nas entregas e correria
2. Não sabem quem está fazendo o quê
3. O QA reclama que chegam muitos bugs “básicos” na mão dele e que precisa testar
na pressa por causa dos prazos estourados
4. O PO reclama que o produto deles está abandonado e defasado
5. Tarefas sem priorização clara, priorizadas pelo “grito” do cliente ou do chefe
6. Tarefas abandonadas na metade
7. Alguns desenvolvedores são especialistas em algumas partes dos projetos mas não
sabem como trabalhar em outras partes (cada área do projeto tem um “dono”)
8. Ninguém quer fazer deploy (colocar a nova versão no ar) por que é um trabalho
muito longo e tem que ser feito à noite
9. Não veem uma saída pra essa situação a não ser trabalhar ainda mais!

Método Kanban
1.Visualize o
trabalho

Backlog Pronto
1. Separaram o que estava em andamento e o que não
tinha sido iniciado ainda (backlog)
Em Andamento

2. Removeram do backlog as tarefas que não estavam
prontas para serem trabalhadas
Backlog ProntoEm Andamento

Backlog Aceite POEm dev QA DeployDesign Feito!
3. Mapearam em maior detalhe o processo atual

Anatomia de um Post-It
Kanban
#435
RV
15/11 27/11
Bug no gráfico
de acessos
Número de
referência (ex
no Trello, Jira,
TFS)
Título
Data de início Data de fim
Responsável
Use o post-it
para outras
sinalizações
relevantes ao
time

Efeito Zeigarnik
(1927)
1. Um sistema de tensão será criado quando o indivíduo receber uma tarefa
para realizar.
2. Quando a tarefa for concluída, a tensão desaparecerá.
3. Se a tarefa não for concluída, a persistência da tensão resultará na maior
probabilidade de o indivíduo lembrar-se da tarefa.
https://revistaculturacidadania.blogspot.com.br/2012/06/artigos-o-efeito-zeigarnik-e-motivacao.html

4. Definiram WIP desejado (decidiram reduzir 30% o
atual)
Backlog Em dev QA DeployDesign Feito!Aceite PO
Limite WIP = 20 (atual: 33)

Doing Fila Doing Fila Doing Fila Doing Fila Doing
5. Para parar de “empurrar” tarefas, criaram filas por
serviço
Backlog Em dev QA DeployDesign Feito!Aceite PO

6. Para chegar ao limite WIP de 20, eles combinaram de
parar de puxar novas tarefas do backlog até terminar o
que já estava em progresso
Backlog Em dev QA DeployDesign Feito!
Aceite PO

Pare de começar, e comece a
terminar!
Aceite PO

Aceite PO

8. Chegaram a 20! Agora eles combinaram manter esse
limite por algumas semanas, e observar o que acontecia
Aceite PO

Tempo de Ciclo
WIP diário
médio
Tempo de ciclo
médio (dias)
Semana 1 33 8.7
Semana 2 30 8.0
Semana 3 27 7.5
Semana 4 20 6.0
Semana 5 20 5.1
Semana 6 20 5.2

Tempo de Ciclo
WIP diário
médio
Tempo de ciclo
médio (dias)
Rendimento
(WIP/TC)
Semana 1 33 8.7 3.7
Semana 2 30 8.0 3.7
Semana 3 27 7.5 3.6
Semana 4 20 6.0 3.3
Semana 5 20 5.1 3.9
Semana 6 20 5.2 3.8

Método Kanban
3. Gerencie
Fluxo

“Evite medidas locais de eficácia e eficiência.
Meça o desempenho do sistema inteiro com relação à
meta
Teoria das Restrições (ToC)

ToC: uma analogia
6 20 4 ?12 7

ToC: uma analogia
6 20 4 ?12 7
O rendimento global do sistema é determinado pelo rendimento
do gargalo.
Qualquer tentativa em forçar um rendimento no sistema acima
desse limite causará ineficiência e defeitos.

ToC: um processo de
melhoria contínua
1. Identifique o gargalo
2. Decida como tirar maior proveito do gargalo
3. Adeque todo o processo ao gargalo
4. Otimize o gargalo para aumentar sua capacidade
5. Repita o processo para encontrar o próximo gargalo

Aceite PO
Situação 1: Designer está disponível mas o sistema está
no limite de WIP

Aceite PO
Sugestão: O designer foi dar uma ajuda pro QA, e um
dev foi fazer o deploy para liberar 3 posições

Aceite PO
Situação 2: QA está sempre com muito trabalho pra
fazer (gargalo)

Backlog Em dev QA (4) DeployDesign Feito!
Aceite PO
Sugestão 1: Estabelecer limite WIP nesse serviço para
aumentar capacidade do gargalo (ToC)

Aceite PO
Sugestão 2: Trocar ordem dos serviços de QA e PO para
evitar que o trabalho passe duas vezes pelo gargalo de
QA

Aceite PO
Sugestão 3: O time de desenvolvimento vai começar a
escrever testes unitários e adotar “code review” para
aumentar a chance do trabalho passar pelo QA de
primeira (Kaizen)

Aceite PO
Sugestão 4: O time vai anotar nos post-its toda vez que
um trabalho voltar do QA para desenvolvimento, para
monitorar a métrica de “taxa de bugs” no tempo

Aceite PO
Situação 3: O gerente/comercial/PO nunca está
disponível para fazer o trabalho dele

Aceite PO
Sugestão 1: Capacitar e dar autonomia para o time atuar
como PO quando preciso (Kaizen)

Doing Fila Doing Fila Doing Fila Doing
Limite WIP = 18
Sugestão 2 (vinda do time): Avaliar se essa etapa é
realmente necessária. Testar processo sem essa etapa
por 4 semanas e checar métricas (taxa de bugs, tempo
de ciclo, taxa de falhas com clientes).
Como tem menos 1 pessoa, baixaram o limite WIP para
18

Limite WIP = 18 (atual: 18 + 2 bugs inesperados)
Situação 4: trabalho emergencial bagunça todo o
processo!

Sugestão: criar uma “linha expressa” para bugs urgentes,
com uma política de prioridade absoluta para o que
estiver lá

Limite WIP = 18
Situação: o chefe começou a colocar trabalho na “linha
expressa” alegando que é trabalho muito muito
importante para a sobrevivência da empresa

Limite WIP = 18
Sugestão: deixar o chefe usar a linha expressa, mas com
limite de 1 trabalho por semana (ele vai ter que priorizar)

Limite WIP = 18
Situação 5: o time nunca tem tempo para trabalhar no
produto da empresa (ele nunca é priorizado)

Limite WIP = 18
Sugestão: o time acordou que a cada 4 trabalhos para
clientes, 1 será para o produto (ou seja, darão 20% do
tempo ao produto)

Limite WIP = 18
Situação 6: tem trabalho que só um dos
desenvolvedores sabe fazer

Limite WIP = 18
Sugestão: o time de desenvolvedores concordou que
vão sempre pegar o trabalho no topo da fila, e se
necessário fazer “pair programming” (Kaizen)

Limite WIP = 18
Situação: a fila de deploy fica grande e todo mundo
odeia fazer deploy à noite

Limite WIP = 18
Sugestão: o time decidiu liberar um dos colegas para
estudar “continuous integration” para um dia terem
deploy automático (Kaizen) e poderem baixar ainda mais
o WIP

Vamos ver aquela
lista
1. Muitos atrasos nas entregas e correria
2. Não sabem quem está fazendo o quê
3. O QA reclama que chegam muitos bugs “básicos” na mão dele e que precisa testar
na pressa por causa dos prazos estourados
4. O PO reclama que o produto deles está abandonado e defasado
5. Tarefas sem priorização clara, priorizadas pelo “grito” do cliente ou do chefe
6. Tarefas abandonadas na metade
7. Alguns desenvolvedores são especialistas em algumas partes dos projetos mas não
sabem como trabalhar em outras partes (cada área do projeto tem um “dono”)
8. Ninguém quer fazer deploy (colocar a nova versão no ar) por que é um trabalho
muito longo e tem que ser feito à noite
9. Não veem uma saída pra essa situação a não ser trabalhar ainda mais!

Quais métricas usar
■ Tempo de ciclo
■ Rendimento ou Taxa de entrega (Throughput)
■ Taxa de defeitos (cartas andando pra trás)
■ Tempo de fila
■ Tempo de trabalho efetivo (touch time)
■ Eficiência: Touch time/Tempo de ciclo

Quais métricas usar
https://leanpub.com/actionableagilemetrics

Limite
o WIP!
Mas acima de tudo...

Obrigado :)
http://bit.ly/kanban-ciasc
rodrigo.vieira@gmail.com

Introdução ao método Kanban para melhorar fluxo de trabalho

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Introdução ao método Kanban para melhorar fluxo de trabalho

Semelhante a Introdução ao método Kanban para melhorar fluxo de trabalho (20)

Mais de Rodrigo Vieira

Mais de Rodrigo Vieira (11)

Último

Último (20)

Introdução ao método Kanban para melhorar fluxo de trabalho