Pressione enter para ver os resultados ou esc para cancelar.

Mudança de contexto é um problema? O que descobrimos com a Teoria do Fluxo Unificado

Uma das dúvidas recorrentes quando conversamos e apresentamos o fluxo unificado pode ser resumida da seguinte maneira: mas os desenvolvedores mudarem de projeto em cada história não é um problema? Os autores ágeis não nos alertaram sempre para este “problema”? Como vocês têm lidado com isso? O time não perde a visão do todo?

A resposta para parte destas perguntas é sim, mas com ressalvas.

Esta ressalva tem nome: organização. O principal problema da mudança de contexto em projetos diferentes é a falta de organização do fluxo, do time e, inclusive, da empresa. Hoje projetos não são mais aquelas entidades monstruosas que precisam de cinco anos para ver a luz do dia.

Empresas espertas, que valorizam a experimentação e o entendimento do mercado antes de assumir certezas, possuem módulos como projetos, reduzindo assim o tempo total de um projeto para dois meses. Com estas proporções, reduziu-se a “parafernália” necessária para o entendimento do propósito, planejamento e execução de um projeto, reduzindo o período necessário para este entendimento de semanas para horas.

Esta simplificação geral do sistema, faz com que menos informações sejam necessárias para pintar a ideia do todo, fazendo com que o sequenciamento estratégico das demandas exerça um papel fundamental para a manutenção do entendimento geral, possibilitando que a perda de visão do todo seja minimizada.

Aqui nossas experimentações com o fluxo unificado provaram alguns pontos interessantes. Ideia do todo não é efeito direto e absoluto de termos times dedicados a cada projeto.

A ideia do todo depende muito mais de cada pessoa que da estrutura de trabalho do fluxo. Existem pessoas que desenvolvem uma ideia do todo de cada projeto mais facilmente em um fluxo unificado e outras pessoas não a desenvolvem mesmo trabalhando de forma dedicada no projeto.

Descobrimos que a perda da “visão detalhada do todo” é muito pequena e exerce pouca relevância para o resultado final, mesmo para times onde a análise de negócio está distribuída no próprio time. Isso acontece porque todos os projetos estão em andamento na dinâmica do fluxo e a perda da memória de cada projeto, depois das primeiras semanas, é quase nula. O sistema aprende a trabalhar desta forma, criando mecanismos de defesa contra os problemas encontrados. A única exigência é uma gestão inteligente e atenta.

Quando na Taller tomamos a decisão de seguir em frente com o fluxo unificado, esta questão pesou bastante. Em vez de desistirmos, pois isso culturalmente nos agredia bastante, decidimos começar a questionar: mudança de contexto existe desde sempre, do contrário as pessoas estariam trabalhando no primeiro projeto da vida até hoje. Assim qual o limite seguro? Precisamos de intervalos entre essas mudanças? Qual o intervalo mínimo necessário? Se incluirmos todo o sistema nessa dinâmica, com quanto tempo a perda da memória passa a ser significante?

Neste período lembramos que em desenvolvimento de softwares, os freelas são comuns e grande parte dos profissionais de desenvolvimento possuem atividades paralelas à sua atividade diária. Mudanças de contexto acontecem o tempo todo e parecem saudáveis.

Obviamente, por estarmos caminhando para o segundo ano de fluxo unificado em toda a empresa, conseguimos responder a todas estas perguntas de forma positiva para unificarmos nosso fluxo. Descobrimos que se você mantém o seu fluxo sobre controle, com controle de WiP e métricas de fluxo, se possui um processo para olhar para este fluxo continuamente e busca sempre uma forma de beneficiar a vazão do seu sistema, se está sempre olhando para as necessidades dos seus clientes¹, é absolutamente seguro que esta mudança de contexto seja por história.

Entretanto, como já foi dito, buscamos estratégias para lidar com estas questões com inteligência. No reabastecimento da fila, olhamos para o equilíbrio do fluxo e manipulamos a matemática da priorização obtida com a análise deste equilíbrio. Nesta manipulação agrupamos as histórias o máximo possível para uma sequência lógica para a melhor saúde do fluxo.

Com a redução do custo de coordenar vários times para uma coordenação estratégica do fluxo, reduzimos o investimento em tempo e em artefatos para manter a operação da organização.

¹Clientes externos (outsourcing) ou clientes internos (departamentos e produtos)


***
Recado da Taller:
Criamos o Programa de Otimização da Gestão Ágil para quem quiser levar as práticas de eficiência de trabalho para dentro da sua empresa.

Conheça a Programa →

***

  • Klaus Wuestefeld

    As pessoas na nossa área lêem vários livros, acompanham várias séries, jogam vários jogos, fazem vários cursos, acompanham várias discussões online, tudo sem problema de perda de contexto. O problema não é chavear de contexto 5 ou 6x por dia. A mente humana curiosa já se entedia naturalmente com muito mais de uma hora fazendo a mesa coisa. O problema é chavear com uma interrupção a cada 5 min.

    Uma vantagem de se trabalhar em várias coisas chaveando contexto é que o inconsciente continua trabalhando em todas elas ao mesmo tempo e os lampejos vem.

    • celsoMartins

      Exato Klaus. O maior problema na minha visão é começar várias coisas e não terminar. Ter várias coisas em andamento, não terminadas, em progresso. Se o WiP estiver fora de controle, realmente será um problema, mas de disciplina de processo e não de mudança de contexto.

  • Marcelo Carmizini

    Olá, Celso! Parabéns pelo texto!

    Temos um cenário que se resume a junção de dois times. O grande desafio que estamos observando é em relação as tecnologias que eram bem específicas de um dos times e agora passa a se tornar comum. Imaginamos que a curva de aprendizagem tende a ser maior devido as mudanças de contexto com frequência, pois envolve produtos e tecnologias diferentes.

    • celsoMartins

      Olá Marcelo. Muito obrigado pelas palavras.

      Esta curva será tão acentuada quanto a diferença real entre as tecnologias, algo como Ruby x Pascal ou Java x COBOL. Se forem tecnologias/plataformas/linguagens próximas como Java e C# ou Ruby e Python (forcei um pouco nessa) não tende a ser tão acentuada. Caso a empresa trabalhe com linguagens modernas como Ruby e Python essa mudança é ainda mais suave. Eu já trabalhei como desenvolvedor com mudança de contexto entre Java x Ruby x Delphi e foi bem de boa.

      Abs!