Your SlideShare is downloading. ×

Kanban

1,048

Published on

Resumo do livro Kanban do David Anderson

Resumo do livro Kanban do David Anderson

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,048
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
29
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 – EntregaCom todos os stakeholders!

×