Fluxo Unificado: Perspectiva de um Desenvolvedor – Resultados

No artigo anterior, falei sobre as principais ações que foram tomadas para a adoção do modelo de Fluxo Unificado. Agora, é hora de falarmos sobre quais resultados partiram dessas ações, quais benefícios surgiram e que nos deixam confiantes de que tomamos boas decisões.

Ausências com menos impacto

Um resultado óbvio da nossa transição do modelo de equipes por projeto para o Fluxo Unificado foi que, para cada projeto, entraram mais desenvolvedores atuando em seu código. Dessa forma, não há mais preocupações do tipo: “a única pessoa que domina frontend no time está em férias” ou “quem fez esse módulo foi a Maria, temos que esperar ela voltar”.

A equipe trabalha continuamente para, além de entregar valor ao cliente, compartilhar internamente as tomadas de decisão e o conhecimento gerado durante o desenvolvimento. Isso se dá principalmente pela prática do Pair Programming e o Workshop de Histórias em Done (ambos foram abordados no artigo sobre ações da série). Assim não sentimos um impacto tão grande com ausências no time, mesmo que inesperadas. 

Isso porque, numa equipe dedicada a um projeto, qualquer ausência poderia significar uma represa no fluxo, o que não deixamos acontecer na equipe única, pois nesses casos a prioridade é revista e os desenvolvedores são remanejados para dar vazão ao que está mais à frente no board. A prática de code-review também nos auxilia a manter nossos padrões de projeto e qualidade das entregas.

Menos pressão nas pessoas

Já que ausências agora geram menos atrito, as pessoas ficam mais livres para planejá-las. São extremamente raros os casos de adiamento de férias na última hora ou, até mesmo, ter que deixar de participar de algum evento para ajudar alguma entrega.

Isso graças à menor dependência de pessoas específicas. Já que agora dentro da equipe existem mais pessoas que podem dar manutenção no que cada desenvolvedor criou. O desenvolvedor em questão deixa de ser um gargalo para manter alguma área de um sistema, ficando assim livre para atuar em outras áreas e aprender mais sobre elas, podendo reduzir a pressão em outros colegas, e assim sucessivamente.

Aumento da autonomia

No dia a dia tentamos ao máximo não trabalharmos sozinhos. Porém, quando necessário, é importante que os desenvolvedores consigam fazê-lo. Todo o esforço para compartilhar conhecimento e abertura para participação em tomadas de decisão contribuem continuamente para que os membros da equipe sejam mais capazes e autônomos. Tanto para implementar soluções quanto para tomar decisões sobre elas.

Dessa forma, conseguimos priorizar o que é mais importante e tem mais valor ao cliente em nível de negócio. Sem necessidade de priorizar demandas de acordo com quem está disponível para puxá-las. Hoje conseguimos que a demanda mais prioritária seja atendida pelos membros livres na equipe. Independente do projeto ou de qual parte do sistema ela se trata.

Trabalhamos com sistema puxado, como demonstrado no quadro acima. Não há uma camada de gestão nos dizendo o que fazer, mas sim a prática de sempre analisar o quadro kanban da direita para a esquerda. Cabendo ao desenvolvedor entender onde é mais importante atuar, seja entrando para parear em alguma história em andamento ou puxando uma nova.

É sempre bom lembrar que esses benefícios só foram atingidos por cooperação total de toda a equipe. É sobre isso que será o próximo artigo da série: as responsabilidades dos colaboradores no modelo Fluxo Unificado.

Lembrando que é é o 3º post da série, confira os outros posts aqui:

1º Post: Fluxo Unificado: perspectiva de um desenvolvedor – Motivações

2º Post: Fluxo Unificado: perspectiva de um desenvolvedor – Ações

4º Post: Fluxo Unificado: perspectiva de um desenvolvedor – Responsabilidades