Fluxo contínuo. Como se faz a transição a partir de iterações? #dwildt101 ep 34

Fluxo contínuo. Pensamento Lean. E veio em conversa pelo twitter uma pergunta do Walmyr Filho:

Falar sobre Fluxo contínuo, sobre quando um time sai de iterações (scrum) e passa a fazer uso de entregas com fluxo, leadtime / takttime, uso de kanban – Walmyr Filho

Eu lembro sempre de coisas que me levam para buscar of fluxo contínuo, e digo que mesmo que um time escolha manter iterações de trabalho, ainda assim essa busca é muito saudável:

  • Controlar o trabalho em andamento, WIP (Work in progress). Com isto podemos usar as regras de wip para adicionar mais trabalho pareado, para impedir que o trabalho fique parado, enfim, muito pode ser feito apenas organizando as etapas de um quadro e visão sobre o trabalho em andamento.
  • Minimizar variação das demandas. Queremos menos variabilidade. O que quero dizer com isto? Evitar cartões de tamanho 1 e tamanho 100. Quanto menor o tamanho do cartão, menos risco envolvido nele. Certamente existe mais clareza na definição de um cartão com tamanho 2 do que em um cartão com tamanho 40. E existe uma proximidade nos cartões com tamanho 2 e 3.

Na uMov.me estamos em um ponto onde temos uma visão sobre pontuação e sobre número de funcionalidades por semana de trabalho. Estes dois números estão estáveis. Isto quer dizer que o time poderia parar de estimar em story points e nada mudaria, se ele manter o máximo de cartões que podem ser trabalhados no quadro.

E como está sua equipe? Fluxo contínuo, buscando fluxo contínuo, feliz com o uso de iterações sem se preocupar com estas questões que falei?

Ah, para quem quiser olhar o episódio 4 onde falo de timebox e fluxo contínuo, fica o link.

— Daniel Wildt (já está assinando meu canal do youtube?)

6 thoughts on “Fluxo contínuo. Como se faz a transição a partir de iterações? #dwildt101 ep 34

  1. Bom dia Daniel.
    Em nossa empresa adotamos algumas metodologias ágeis. Utilizamos uma espécie de scrumban. Porém prece que a coisa não acontece. Não sei se esta relacionada a motivação da equipe de desenvolvimento ou se é o problema da estrutura da empresa. Não conseguimos entregar valor para nossos clientes. Trabalhamos em um ERP para agronegócio no Paraguai. Somos líderes de mercado. Porém demoramos muito para entregar valor para o cliente. Utilizamos Delphi estruturado, muito amarrado. Geramos versões da aplicação de 15 em 15 dias (sprints), mas para essas versões chegarem ao cliente, vai mais de 30 dias. Utilizamos o desenvolvimento em par, mas na última semana de entrega “despareamos” para finalizar as demandas que ficaram de fora. Gostaria de umas dicas de como podemos motivar a equipe para dar o sangue e seguir a risca o desenvolvimento em par. Temos também o pessoal do produto que não acredita no pareamento e dizem que estamos diminuindo nossa produtividade com o pareamento. Se puder me ajudar agradeço. E te parabenizo pela iniciativa dos videos.

    1. George. Obrigado pelo comentário!

      Na terça feira que vem sai um vídeo da minha série #PartiuAgile onde falo da sprint e tem muita coisa legal lá pra você.

      Sobre o trabalho em par o ideal é manter o ritmo. Olhando de longe parece que o time está planejando mais do que consegue entregar e me pergunto o quanto essa semana sem trabalho em par, com mais pressão, não está causando de problema nas entregas da iteração. Perceba aí se aparecem defeitos decorrentes da primeira semana ou da semana sem par.

      E não digo que é culpa da falta de pareamento. Existem times com diferentes dinâmicas de trabalho em par. Vou falar mais disso no Daniel Wildt responde ep 36 ok?

      Por agora te passo algumas coisas para olhar:

      – tentar reduzir o comprometimento da iteração para poder parear 100% do tempo.

      – pensar se o time precisa parear 100% do tempo. Tenta ver se existem situações onde se pode começar pareado e depois um desenvolvedor pode seguir sozinho. Fazemos isto na uMov.me em diversas situações.

      – garantir que existe pareamento para reduzir risco e para nivelar conhecimento.

      – sobre as entregas que demoram pra chegar nos clientes, é em virtude de testes manuais de homologação ou algo relacionado ao processo de atualização por parte dos clientes?

      Sobre a questão da produtividade pareado ou não no final do dia o que vai valer é fluxo de trabalho correto. Você precisa encontrar um ritmo onde o time consiga produzir certo na primeira vez e encontrando o ritmo de pareamento ideal para sua equipe.

      Sendo em Delphi, pode ser que não exista testes automatizados. Isto aumenta o risco de defeitos e da necessidade de testes manuais. Neste sentido buscar uma ferramenta de teste funcional automatizado pode ser uma forma de validar regras de negócio e criar uma casca de segurança para manutenção do código fonte. Olhe o produto da TestComplete ou soluções OpenSource como http://www.sikuli.org/ ou http://www.gearheadforhire.com/articles/ruby/win32-autogui/using-ruby-to-drive-windows-applications

  2. Olá Daniel.
    Sobre as entregas, sim fazemos testes manuais de homologação e temos uma equipe de campo, especializada em atualizar as versões nos clientes.
    Vou procurar mais a respeito das ferramentas de testes automatizados e verificar os temas que abordou acima.

    Obrigado pela atenção!
    Aliás, muito bom o vídeo de ontem…

    1. Muito legal George! E na semana que vem tem o Daniel Wildt responde episódio 36, onde falo mais sobre planejamento e sobre pareamento. Vai ser mais uma oportunidade de trocarmos ideia por aí!

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s