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.
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
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;
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