Kanban no Fluxo Único - sessão Show me your board, Agile Trends 2016
•Descargar como PPTX, PDF•
6 recomendaciones•1,768 vistas
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.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Kanban no Fluxo Único - sessão Show me your board, Agile Trends 2016
Similar a Kanban no Fluxo Único - sessão Show me your board, Agile Trends 2016 (20)
Más de Taller Negócio Digitais
Más de Taller Negócio Digitais (20)
Kanban no Fluxo Único - sessão Show me your board, Agile Trends 2016
- 1. Kanban no Fluxo Único Show me your Board Aldo d'Aquino aldo@taller.net.br
- 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
- 4. 47 Requested
- 6. ● Comece com o que você tem hoje ● Respeite o processo atual ● Implemente mudanças evolutivas e incrementais ● Estimule a liderança
- 7. ● Visualize o processo; ● Limite o WIP; ● Gerencie o fluxo; ● Torne as políticas explícitas; ● Implemente mecanismos de feedback; ● Busque a melhoria contínua;
- 10. Políticas Explícitas Fluxo Ready for Dev Ready for Homolog To Deploy Done Mudança de escopo Impedimentos WIP
- 11. O Fluxo
- 21. Dailies
- 24. Kick-off
- 26. 14 7 73%
- 27. Fluxo Único
- 29. Variabilidade
- 31. Redução dos custos de coordenação
- 33. CoD Value Urgency Duration CD3 = Priorização dos projetos
- 34. Métricas
- 35. CMD Cu$to Médio por Demanda = cu$to / entrega$
- 36. CMD Custo Médio por Demanda Custo Tempo
- 37. CMD Formação do Time R$ 123,45 R$ 234,56
- 38. Vazão
- 39. WIP
- 40. Cycle Times
- 48. % Valor
- 49. % Falhas
- 52. Auxílio à tomada de decisões ★ Visão geral ★ Priorização ★ Previsibilidade ★ Capacidade ★ Performance ★ Pontos de otimização
- 54. Portifólio
- 56. Comercial
- 62. 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
Notas del editor
- 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