Kanban Apresentação Encontro Rational 2013

Encontro Rational de Desenvolvimento de Software – 12 de março de 2013 – São Paulo

Aplicando Kanban ao Desenvolvimento de
Software
Moacyr Mello – mcmello@br.ibm.com

Encontro Rational de Desenvolvimento de Software

Building better software
© 2012 IBM Corporation

Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013

Agenda

 Kanban, o quadro

 Kanban, o sistema

– Método empírico e receita de aplicação

– Conceitos para comparação com Scrum

– Limitação de WIP e visualizações

2 © 2013 IBM Corporation


É antiga a história de processos iterativos

 1930’s – processo iterativo Plan-Do-Study-Act

 1940’s – Deming promove o ciclo PDSA

 1950’s
– Projeto NASA X15 foi iterativo e de muito sucesso
– Projeto NASA Mercury – iterações de ½ dia com time-boxed e TDD

 1950’s – Conceitos de produção Lean
– Kaizen – Eliminação de desperdício através de melhoria contínua em atividades, padrões e processos
– O trabalho padrão é apenas uma referência para fazer melhor... kaizen, melhoria contínua
– Aproveitar a capacidade de pessoas comuns

 1968 – IBM Research recomenda o desenvolvimento iterativo …..


2000’s – Lean software development
Baseado nos conceitos do Toyota Lean Production
http://www.poppendieck.com/

 Conceitos Lean - Agile, aplicados ao desenvolvimento
 Após o manifesto Agile, muitas direções de busca
 Alternativas aos processos da década de 90
 Simplificação do desenvolvimento

改善 Kaizen
看板　ｋａｎｂａｎ



O que é kanban?

看板　ｋａｎｂａｎ　 cartão de sinalização ou sistema de sinalização

 O que ele sinaliza?
 Essencialmente sinaliza a disponibilidade para realizar um trabalho. Um cartão é anexado a
um trabalho. O trabalho pode ser iniciado apenas quando o cartão está disponível.

 O cartão segue o trabalho através do fluxo do sistema de trabalho. Um novo trabalho deve
esperar na fila até que um cartão esteja disponível. Portanto na sua essencia há limitação de
WIP e reconhecimento da limitação de capacidade do sistema de trabalho.
(WIP: Work In Progress)

 Como o novo trabalho depende da liberação de capacidade, o sistema é conhecido como
“sistema puxado”, ao invés de “empurrado com base na demanda”.



Sistemas “puxados” e a visualização do kanban

 Permitem que as pessoas examinem por si mesmas o que precisa ser feito. O trabalho torna-
se auto-dirigido
 Tem melhor comportamento quando enfrentam variabilidade
 É uma abordagem “just in time” que permite decisões de trabalho em tempo real
 A forma de visualização é através de um quadro onde aparecem “estados” do fluxo de
trabalho:

Reference: M & T Poppendieck, Lean Software Development. 2003 : Chapter 4



Teoria das filas

 A chave é reduzir o tempo de ciclo, o tempo que leva da entrada até a saída do sistema.

Entrada
 Praticar uma taxa constante de chegada e controlar o que entra na fila
 Liberar pequenas quantidades de trabalho
 Definir prioridades e selecionar trabalho é crítico
 Liberar trabalho continuamente é ainda mais crítico

 Taxa de entrada > taxa de saída  saturação
 Taxa de entrada = taxa de saída  instabilidade
ol ga
 Taxa de entrada < taxa de saída  estabilidade
ia rf
Cr



Metáfora dos escoteiros

Mais capacidade que o gargalo
Folga na capacidade
Tempo ocioso

Abordagem do Kanban

Conceito Objetivo Escoteiros Desenvolvimento

DRUM Define o passo O mais vagaroso Gargalo

BUFFER Protege o passo Folga na corda Fila do gargalo

A corda é presa entre o primeiro Sistema puxado
ROPE Obriga o passo
escoteiro e o mais vagaroso (Kanban)


Visualização do kanban

 Limitando WIP (work in progress) – designa explicitamente quantos itens de trabalho (work
itens) podem ser trabalhados em cada estado
 WIP é limitado por estado do fluxo de trabalho Papéis
Pessoas
Atividades
Ordem de tarefas
Arquitetura

3 2

u
fila o
lo g
back fila




Visualização do Scrum

 Limitando Velocity (produção num time-box) – utiliza a velocidade média de consumo de
itens de trabalho (work itens) para limitar o tamanho do Sprint Backlog
 WIP é limitado por unidade de tempo

l og
back




Scrum
 Pequenos times, cross-funcionais e auto-organizados
 Pequenos itens de trabalho em unidades de entrega bem específicas, priorizados e
estimados
 Tempo dividido em iterações curtas de comprimento fixo
 Plano de Releases e priorização de acordo com o cliente
 Otimização do processo através de retrospectiva a cada iteração ou sprint

Kanban
 Visualize o fluxo de trabalho através de estados do fluxo num quadro visual
 Limite o WIP designando explicitamente a quantidade de itens por estado do fluxo
 Medir o lead time (tempo médio para completar um item) também chamado cycle time
 Utilize Lead time como a métrica básica para o planejamento e melhoria do processo
 Gargalos, procure vazios no quadro kanban
 O tamanho do loop de feedback vc pode escolher!



Acompanhamento

 Em Scrum usamos Sprint Burndown charts como a forma básica de acompanhar a sprint

 Não há necessariamente um gráfico para Kanban, é costume usar Cumulative Flow diagram:



Scrum-kanban

 Scrum prescreve time-box e portanto algum tipo de “batch” na implementação dos
requisitos
– A sucessão de sprints produzem uma cadência positiva para as releases
 Kanban não prescreve time-box
– Podemos escolher quando planejar, melhorar o processo ou liberar releases. Seja de uma forma
sob-demanda ou em períodos regulares, para construir uma cadência
 Scrum prescreve 3 papéis
 Kanban não prescreve nenhum papel
– Isto não significa que não podemos ter um Product Owner junto com Kanban, significa apenas que
o método não exige um PO
 Ambos prescrevem que o time deve seguir num passo sustentável
– O propósito é entregar valor e perpetuar a empresa
 A filosofia de Kanban é Kaisen: mude pouco mas para melhor, constantemente. Portanto
kanban é o que menos impacta o processo corrente



Kaisen

さんむ　３　Ｍｕ‘
ｓ
むだ　ｍｕｄａ
• Desperdício, o que não agrega valor

むら　ｍｕｒａ
• Desencontro das coisas

むり　ｍｕｒｉ a
g
r f ol
• Trabalhar acima da capacidade ia
Cr



Caminho suave para amadurecimento e prosperidade...

 Não buscar igualar a capacidade à demanda (forçando a capacidade)
 Equilibrar o fluxo primeiro limitando WIP, então encurtando prazos e entregando
frequentemente
 Ao equilibrar demanda e rendimento, criar folga para permitir melhoria
 Ganhar a confiança da organização com aumento de previsibilidade
 Avaliar alocação de capacidade por tipo de iten de trabalho (wi) ou classe de serviço
 Melhorar a priorização para aumentar valor
 Criar ritmo sustentável !



Previsibilidade

 Limitando WIP (work in progress) para estados e filas, (buffers e backlogs), criamos folga e
aumentamos a previsibilidade

5 3 3 2

u
fila o
lo g
back fila




Variabilidade

 Causas internas e/ou externas
 Templates tendem a diminuir a variação de itens de escrita de requisitos
 Treinamento, exemplos e uma teoria consistente de requisitos também diminuem a
variabilidade (um bom Modelo de Uso de requisitos)
 Rework
– Taxa de defeitos e outras métricas, ajudam a entender a variabilidade de retrabalho
 Ambiguidade
 Classes de serviço mal formuladas



Classes de serviço

 Classes de serviço classificam o trabalho de modo a priorizar os recursos. São uma política de
priorização que determina uma maneira prévia de como os itens são puxados no sistema.

 Solicitação de novas features
– Padrão ou com data de entrega fixa
 Solicitação de mudança
 Manutenção
 Defeitos
– Defeitos em produção
– Defeitos de alto impacto
– Defeitos com alta prioridade

 Melhoram a valiação do sistema, evitam estimativas desnecesárias e/ou detalhadas
 Tem uma política previamente definida: WIP?, Release? FIFO? Equipe? Linha de SCM?



Classes de serviço

 Limitando WIP para estados e filas, de acordo com a classe de serviço, aumentamos a
previsibilidde

5 3 3 2

20%

40%

40%

R



Técnicas podem ser combinadas!

 Observe valores e princípios
 “Não desenvolva apêgo a nenhuma arma ou tradição de luta”
Miyamoto Musashi


Kanban Apresentação Encontro Rational 2013

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (9)

Semelhante a Kanban Apresentação Encontro Rational 2013

Semelhante a Kanban Apresentação Encontro Rational 2013 (20)

Mais de Felipe Freire

Mais de Felipe Freire (12)

Kanban Apresentação Encontro Rational 2013

Notas do Editor