Kanban no Fluxo Único - sessão Show me your board, Agile Trends 2016

605 visualizações

Publicada em

Slides da apresentação realizada pelo gestor de fluxo Aldo d'Aquino sobre o Kanban no Fluxo Único no evento Agile Trends 2016 que inaugurou este ano uma sessão especial, a Show Me Your Board.

Publicada em: Software
0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
605
No SlideShare
0
A partir de incorporações
0
Número de incorporações
128
Ações
Compartilhamentos
0
Downloads
14
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Localizado junto aos desenvolvedores
    Fluxo contínuo
  • Versão virtual
    Atende aos membros remotos do time e aos clientes
    Facilita a coleta de métricas
  • O método Kanban oferece uma abordagem evolutiva e incremental para mudança de processos e sistemas
    Na prática, consiste em executar um sistema kanban focado em kaizen e gestão
    Promovendo pequenas mudanças, com menor resistência
  • Princípios do método Kanban
  • Propriedades do método Kanban
  • Fluxo único, um time executa diversos projetos
    Basicamente utilizamos demandas dos tipos Stories, Improvements e Bugs
    As cores indicam o projeto a qual a demanda pertence
    Classes de serviço
    Expedite (destacada em vermelho): demandas que necessitam de resolução rápida, com alta prioridade e que não precisam respeitar a fila de demandas;
    Highlander, só pode haver uma!
    Demandas fora do fluxo único (destacada em verde): é uma swimlane para demandas que não julgamos conveniente incluir no fluxo único, como por exemplo, um projeto de sistema legado que possui muita variabilidade;
    Lane eficiência (destacada em rosa): demandas para melhoria da eficácia e eficiência do processo Taller, por exemplo, melhorias em Continuous Delivery.
    Normalmente é utilizada quando da disponibilidade de capacidade;
  • Avatares indicam os responsáveis, líder e pair
    Pontos verdes (touch time)
    Pontos vermelhos (queue time)
    Demandas muito grandes - Monster
    Impedimentos com post-its pequenos na cor rosa
  • A equipe, alinhada com a estratégia da empresa, deve definir suas políticas
    Fluxo
    Ready for Dev
    Ready for Homolog
    To Deploy
    Done
    Mudança de escopo
    Impedimentos
    WIP
  • Fluxo único
    Implantando a partir de 18/08/2015
    Padronizado
    Até final março de 2015 não existia um fluxo padronizado para todos os projetos
    Flexível
    O fluxo padrão permitiu adaptações pontuais, mas mantendo a estrutura geral
  • Apenas demandas contratadas
    1º ponto de comprometimento
    Lead time
    Pouco esforço de análise
    Precedida pela coluna Icebox
    Caixa de idéias
    Sem impacto no fluxo
  • Atuação do Analista de Negócios junto com o cliente
    Quebra das demandas
    Definição de valor
    Verificação de dependências
    Verificação de demandas similares
    Etapa não obrigatória, em alguns casos, a demanda passa direto para Ready for Development
  • Demandas prontas para desenvolvimento
    Título
    Descrição
    Critérios de Aceitação
    Anexos
  • Desenvolvimento - Working software
    Programação em pair
    Contato direto entre desenvolvedores e cliente
    Ciclos de feedback curtos
    Agile Testing Coach - Blog do Walmyr, Talking about test
    Remoção da coluna de QA
    Remoção dos silos entre devs e testers
    Fim do vai e volta de demandas para ajustes
    Princípio do Lean: Integrar a Qualidade
  • Demandas prontas para validação do cliente
    Inclusão de Test Directions
    Publicada no ambiente de homologação
    Desenvolvedor informa diretamente ao cliente por IM
  • Validação do Cliente
    Outro ponto de atuação forte do Analista de Negócios
    Demandas com não conformidades são impedidas, de forma visual e o motivo fica disponível para todos
    Cliente informa impedimento diretamente aos desenvolvedores por IM
    Após eventuais ajustes, a demanda é desimpedida e o cliente é informado novamente
  • Validada pelo Cliente e pronta para entrega
  • Normalmente publicada em ambiente de produção
  • Dailies
    Cada dia 1 líder
    Percorrendo o board da direita para esquerda, focando nas demandas que estão mais próximas de serem finalizadas
    "O que precisamos fazer (como um time) para avançar com cada demanda?"
    Start finishing, stop starting!
    O time percebe que o sistema é dele e o resultado mais importante para o time/sistema é entregar valor, fazendo as demandas chegarem em DONE;
  • As interações ficam muito mais ricas com o board físico
  • Retrospectivas
    Fun Retrospectives
    Cadência é muito importante
    Acompanhamento das resoluções
  • Kick-off
    Alinhamento dos objetivos do projeto
    Alinhamento das políticas do fluxo
    Alinhamento do planejamento
  • Status do projeto
    Métricas
    Projeções
    Expectativas
  • Status do projeto
    Métricas
    Projeções
    Expectativas
  • Múltiplos projetos - 6 projetos em média
    Fila única
    Time: 8-10 devs
  • Fluxo único facilita tratar a variabilidade:
    Velocidade de cada projeto, em caso de repriorização, por exemplo, todos os membros do time já possuem conhecimento de todos os projetos, inclusive ambiente de desenvolvimento (Cultura DevOps!)
    Férias de membros do time
  • Todos participam de todos os projetos
    Já possuem o ambiente específico
    Todos estão por dentro do que está acontecendo em cada um deles
  • Menos reuniões -> menos desperdício
    Mais foco na gestão do fluxo
  • O cliente faz a definição de valor
    $$$
    Traz dinheiro
    Reduz custos
  • Cost of Delay Dividev by Duration = CD3
    Por que dividido pela duração?!
    Podemos ajustar alocação!
    Podemos negociar os custos!
    Mas o tempo não pode ser reposto!
  • Custo do time / número de demandas entregues
    Inversamente proporcional ao throughput
    $$$: Muda o foco das conversas!
  • CMD é diretamente proporcional à formação do time
  • Métrica absoluta
    Quantas demandas entregues em um intervalo de tempo
  • Limitado, mas não fixo… é gerenciado
  • Lead time: desde a solicitação da demanda até a entrega;
    Cycle Time de Dev: desde que a demanda é priorizada e disponibilizada para desenvolvimento;
    Ou, para cada etapa do fluxo!
  • Visão Geral
    2 anos de métricas
    Até 30/03/2015
    Filas!!!
    WIP alto: passou de 250!!!
    Disfunções do fluxo: demandas entregues, mas não foram colocadas em Done!
    % Bugs: 22%
    % Valor: 28%
    Eficiência: 42%
    Lead time???
    Sem icebox: tudo junto e misturado
    Cycle Time médio de Dev: 3d
  • Visão Geral
    2 anos de métricas
    Até 30/03/2015
    Filas!!!
    WIP alto: passou de 250!!!
    Disfunções do fluxo: demandas entregues, mas não foram colocadas em Done!
    % Bugs: 22%
    % Valor: 28%
    Eficiência: 42%
    Lead time???
    Sem icebox: tudo junto e misturado
    Cycle Time médio de Dev: 3d
  • Disfunções no fluxo
    Demandas não são levadas até Done
    Falta de disciplina ou alinhamento sobre o processo???
  • Sem outliers e disfunções
    Mais previsibilidade
  • A partir de 18/03/2015
    WIP decrescente
    % Bugs: ~ 19%
    % Valor: ~ 73% (melhoria de 160%)
    Eficiência: 43%
    Lead time: ~ 10 dias
    Com a inclusão do Icebox, passamos a considerar a data em que as demanda foram realmente solicitadas (requested = To do) e a execução foi alinhada
    Também passamos a saber exatamente a "pressão de entrada" do fluxo
    Cycle Time médio: ~ 5 dias
    Maior, porém com muito mais eficácia
  • A partir de 18/03/2015
    WIP decrescente
  • A partir de 18/03/2015
    WIP menor, o Cycle Time também reduziu
  • Sem uma definição de valor, o sistema acaba otimizando por outra coisa
    Quantidade de demandas que agregam valor para o cliente (user stories e improvements, por exemplo) / total de demandas entregues
  • Quantidade de Bugs / total de demandas entregues
  • Touch time / Cycle Time de Dev
  • Em relação ao throughput
    média / desvio padrão
  • Visão geral
    Priorização
    Previsibilidade
    Capacidade
    Performance
    Pontos de otimização
  • Board de Dev Corresponde à coluna Production
  • Mapeia o ciclo de compra do cliente
    Projetos fechados entram para o board de portifólio
  • Mesma estrutura de fluxo da equipe de desenvolvimento
    (Muito) Mais a criatividade!
  • O board é uma ferramenta!
    A cultura Lean é que nos permitiu evoluir até aqui
  • Kanban no Fluxo Único - sessão Show me your board, Agile Trends 2016

    1. 1. Kanban no Fluxo Único Show me your Board Aldo d'Aquino aldo@taller.net.br
    2. 2. Quem sou ★ Aldo d'Aquino ★ Formado em Ciências da Computação ★ 17 anos trabalhando com desenvolvimento de software ★ 2 anos e meio atuando na Gestão de Fluxo da Taller
    3. 3. 47 Requested
    4. 4. Método Kanban
    5. 5. ● Comece com o que você tem hoje ● Respeite o processo atual ● Implemente mudanças evolutivas e incrementais ● Estimule a liderança
    6. 6. ● Visualize o processo; ● Limite o WIP; ● Gerencie o fluxo; ● Torne as políticas explícitas; ● Implemente mecanismos de feedback; ● Busque a melhoria contínua;
    7. 7. Gestão Visual
    8. 8. Políticas Explícitas Fluxo Ready for Dev Ready for Homolog To Deploy Done Mudança de escopo Impedimentos WIP
    9. 9. O Fluxo
    10. 10. Dailies
    11. 11. Retrospectivas quinzenais
    12. 12. Kick-off
    13. 13. Relatórios Semanais
    14. 14. 14 7 73%
    15. 15. Fluxo Único
    16. 16. Múltiplos projetos
    17. 17. Variabilidade
    18. 18. Disseminação do conhecimento
    19. 19. Redução dos custos de coordenação
    20. 20. BVP Priorização das demandas
    21. 21. CoD Value Urgency Duration CD3 = Priorização dos projetos
    22. 22. Métricas
    23. 23. CMD Cu$to Médio por Demanda = cu$to / entrega$
    24. 24. CMD Custo Médio por Demanda Custo Tempo
    25. 25. CMD Formação do Time R$ 123,45 R$ 234,56
    26. 26. Vazão
    27. 27. WIP
    28. 28. Cycle Times
    29. 29. 30/03/2015 18/08/2015
    30. 30. 30/03/2015 18/08/2015
    31. 31. 30/03/2015 18/08/2015
    32. 32. 30/03/2015 18/08/2015
    33. 33. % Valor
    34. 34. % Falhas
    35. 35. Eficiência do processo
    36. 36. Estabilidade do Fluxo
    37. 37. Auxílio à tomada de decisões ★ Visão geral ★ Priorização ★ Previsibilidade ★ Capacidade ★ Performance ★ Pontos de otimização
    38. 38. Integração do Board
    39. 39. Portifólio
    40. 40. Comercial
    41. 41. Núcleo de Criação
    42. 42. Obrigado! aldo@taller.net.br blog.taller.net.br
    43. 43. Referências ● blog.taller.net.br ○ http://blog.taller.net.br/kanban-ou-kanban/ ○ http://blog.taller.net.br/os-principios-da-gestao-de-mudancas-do-kanban/ ○ http://blog.taller.net.br/testers-coluna-de-qa-em-extincao/ ● Essencial Kanban Condensed Guide ○ http://leankanban.com/guide/ ● blog.leankit.com ○ http://100mil.leankit-dev.com/blog/2015/07/does-this-fizz-good-webinar ○ http://100mil.leankit-dev.com/blog/2015/04/flow-driven-product-development ○ http://leankit.com/blog/2014/03/wip-limits-journey-safely-unknown-part-1-3/ ○ http://info.leankit.com/kanban-roadmap ● www.rallydev.com/blog ○ http://www.infoq.com/presentations/agile-quantify

    ×