1. O documento discute os princípios e objetivos do sistema Kanban, incluindo limitar o trabalho em progresso, entregas frequentes com alta qualidade, e melhoria contínua do processo. 2. É descrito como implementar Kanban em nível de time e escalar para a organização, com métricas como lead time e fluxo de valor versus falhas. 3. É enfatizada a cultura de melhoria contínua através da transparência, limites, classes de serviço e revisões operacionais.

1. Kanban – David Anderson

2. Introdução
• Sistema puxado
• Motivação 1: maneira sistemática de obter
ritmo sustentável de trabalho
• Motivação 2: introduzir mudanças de
processo com resistência mínima
• Kanban é o mecanismo que sustenta o
Sistema Toyota de Produção e sua abordagem
kaizen para melhoria contínua
• Crescimento em adoção após Agile 2007

3. Definições
• “kanban”: cartões sinalizadores
• “sistema kanban”: sistema puxado
implementado por cartões sinalizadores
• “Kanban”: metodologia de melhoria de
processo incremental e evolutiva que evolui
na comunidade de desenvolvimento Lean de
software

4. Kanban
• Qualquer situação em que se deseje limitar
coisas dentro de um sistema (ex: jardim em
Tóquio)
• Quantidade de cartões disponíveis limita WIP
• Políticas do processo explícitas
• Melhoria incremental através da descoberta
repetitiva de problemas

5. Objetivos de Kanban
• Aperfeiçoar o processo atual
• Entregar com alta qualidade
• Melhorar a previsibilidade do lead time
• Melhorar a satisfação dos funcionários
• Proporcionar folga para permitir melhoria (requisições
urgentes + melhorias processo)
• Simplificar priorização
• Fornecer transparência no projeto e operação do
sistema
• Projetar um processo para viabilizar o surgimento de
uma organização de Alta Maduridade

6. Definições
• Baixa qualidade pode representar o maior desperdício em
desenvolvimento de software
• Reduzir trabalho em progresso aumenta a qualidade
• Melhoria na qualidade aumenta confiança com outras áreas (ex:
operações)
• Entregas com frequência aumentam confiança com áreas de
negócio/marketing
• Sistema puxado expõe gargalos e cria folgas
• Priorização vale pouco sem qualidade ou previsibilidade
• Fazer mudanças para reduzir variabilidade requer folga
• Reduzir variabilidade reduz a necessidade de folga
• Reduzir variabilidade reduz tokens, WIP e lead time
• Folgas viabilizam oportunidades de melhoria

7. Capacidade em Excesso

8. Custo de Atraso

9. Melhorias
• Gerenciar gargalos
• Eliminar desperdício
• Reduzir variabilidade

10. Cultura Kaizen
• Indivíduos se sentem com poder, agem sem
medo, espontaneamente se
unem, colaboram, inovam
• Confiança
• Transparência -> efeitos de falta de ação ou
ações -> colaboração
• Limites -> “pare a linha” e swarming
• Limites e classes de serviço -> poder de
puxar, tomar decisões -> auto-organização

11. Implementando
• Limite a implementação para dentro da área
do departamento
• Modele o fluxo atual limitando WIP
• Defina tipos de item de trabalho
• Item de trabalho deve ter informação
suficiente para equipe decidir o que puxar
• Sistema eletrônico para estatísticas + parede
física

12. Reuniões
• Reuniões de priorização
• Standups diárias com foco no quadro, não nas
pessoas
• Pós-standup -> melhorias no processo
• Triagem regular do backlog

13. Cadência de Entrega/Saída
• Entregas de software em intervalos regulares
• Kanban separa cadência de entrega da
cadência de priorização
• Existem custos de transação/entrega (antes
era de um dia)

14. Eficiência de Entrega
Eficiência = (CT – CE) / CT
– Onde CT é o Custo Total do software produzido
– E CE é o Custo de Entrega
• Para aumentar eficiência de entrega:
– Aumentar CT -> intervalo entre entregas (ocidental)
– Diminuir os custos de entrega (Lean) – CONSEGUIMOS
EVOLUIR BASTANTE NESTE PONTO!

15. Cadência de Entrada
• Acordar processo regular para priorizar novo
trabalho
• Dissocia entrada e saída de trabalho
• Estimativas representam custos que devem
ser medidos
• Pode ter reuniões regulares ou ser por
demanda (quando os custos forem baixos,
nosso caso!)

16. Estabelecendo Limites
• Limites de WIP devem ser acordados com todos
os stakeholders (decisões unilaterais podem ser
difíceis de defender com o sistema sob stress)
• Estabelecer baseado no número médio de
itens/pessoa
• Pequenos
• Ajustados empiricamente
• Alocar capacidade por projetos/itens de trabalho
utilizando raias (próxima figura)

17. Alocação de Capacidade

18. Classes de Serviço
• Otimizar satisfação do cliente
• De acordo com impacto no negócio
• Fáceis de identificar (cores ou raias)
• Definir políticas
• Classes de risco maior podem requerer estimativa
• Meta de lead time (SLA) por classe de serviço
• Medir % de entregas que atendem lead time
• Time puxa trabalho com base nas políticas
• Capacidade também pode ser alocada por classe
de serviço

19. Classe de serviço: Expedição
• Trazem valor pro negócio às custas do lead
time de outros itens
• Apenas 1 requisição de expedição é permitida
em qualquer momento
• Uma requisição de expedição deve ser puxada
imediatamente. Outro trabalho será colocado
on hold para tratá-la
• Limites de WIP podem ser quebrados para
acomodar uma requisição de expedição

20. Classe de serviço: data fixa
• Custo de atraso como multa ou 1º grau
• Exibir data de entrega na story
• Deve ser analisado e estimado (é viável?)
• Itens grandes devem ser quebrados e
reanalisados (continuam sendo data fixa?)
• São puxados antes de itens de menor risco
• Aceitam os limites de WIP
• Podem ser promovidos para expedição

21. Classe de serviço: padrão
• Separados por tamanho: P, M ou G
• Usam mecanismo de fila (FIFO)
• Equipe puxa item padrão mais antigo (se não
há item de expedição ou data fixa)
• Não é realizada estimativa de esforço ou
tempo
• São entregues geralmente dentro de X dias
em m% dos casos

22. Classe de serviço: intangível
• Custo de atraso intangível (ex: migrar sistema até
2013)
• Pode ter capacidade alocada
• Fornece folga para itens de maior prioridade
• Pode não ter acordo de SLA ou ser muito mais
frouxo
• Ex: migrar versão Badgeville (hoje é intangível,
amanhã pode virar expedição)
• Faz sentido alocar 5% pra essa classe?
Precisamos dela?

23. Métricas - CFD

24. Métricas – Lead Time

25. Métricas
• Lead time previsível permite time perguntar
ao PO: “Qual feature você gostaria de ter no
ar em X dias?”
• Medir demandas de valor x falha
• Medir % de itens entregues dentro do SLA
• Medir tempo/quantidade de itens bloqueados

26. Escalando
• Acompanhar 2 níveis hierárquicos de itens:
– Customer marketable (ex: +marcas, home)
– Granulares, tamanhos similares (user stories)
• Raias facilitam visualização
• Recursos compartilhados devem desenvolver
seus próprios kanbans
• Portfolio de projetos para resolução de
conflitos

27. Escalando – 2 níveis

28. Revisões Operacionais
• Reuniões mensais de 2 horas para toda a
organização
• Departamentos reportam dados objetivos
• Feedback e melhoria contínua na empresa
• Constroem confiança mútua
• Entender problemas e desafios de todas as áreas
• Analisar dados ruins e exaltar os bons da mesma
maneira

29. Por onde começar?
• Definir políticas iniciais e explícitas para:
– Limites de WIP
– Metas de lead time
– Classes de serviço
– Priorização
– Entrega
Com todos os stakeholders!