Menos reunião e mais post-it: Kanban na prática

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ática2. Conceitos básicos3. 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

RendimentoTempo de Ciclo =

Lei de Little(1961)

WIP


Lei de Little(1961)

WIP


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

Método Kanban

2. Limite WIP1.Visualize o trabalho

3. Gerencie o fluxo

Três regras “oficiais”

1. Comecem onde vocês estão2. Evoluam gradualmente e observem resultados3. 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

Em andamento Pronto

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

Método Kanban

2. Limite WIP

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

WIP e Qualidade

WIP e Produtividade

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




Aceite PO




Aceite PO




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

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

Cumulative Flow Diagram (CFD)

Quais métricas usar

https://leanpub.com/actionableagilemetrics



Limite o WIP!

Mas acima de tudo...

O livro que mais recomendo

Obrigado :)

http://bit.ly/kanban-ciasc

[email protected]

Menos reunião e mais post-it: Kanban na prática

Education