A transição para o Fluxo Unificado apresentou diversos desdobramentos. Várias ações ocorreram em paralelo e encaminharam a operação para o seu funcionamento atual. Listo aqui as mais notáveis para a equipe de desenvolvimento.
Equipe Única
Aos poucos, as equipes que existiam dentro da Taller foram se aglutinando em uma equipe única. Mas isso não aconteceu de uma vez só. Inicialmente unimos dois projetos de um mesmo cliente para testar o modelo. Em seguida, um terceiro projeto, agora de outro cliente, foi adicionado a esse fluxo. Até estarmos em uma equipe única atendendo todos os projetos e absorvendo os novos, foram cerca de seis meses.
É importante entender que fazer fluxo unificado e ter apenas uma equipe de desenvolvimento na empresa não são sinônimos. Ainda não testamos esse modelo com mais de vinte desenvolvedores, por exemplo. Então pode ser que em empresas maiores hajam dois ou mais fluxos. O que importa é que as equipes não sejam criadas em razão de uma demanda específica. Mas sim, sejam parte do ecossistema da empresa.
Desenvolvedores Full Stack
Para evitar ilhas de conhecimento, evitamos que as pessoas tenham foco em apenas uma especialidade. Todos devem ter autonomia para entregar uma história que envolva toda a stack do projeto. É evidente que cada um se destaca em áreas distintas, mas sempre há o esforço para nivelar o conhecimento e diminuir a dependência. Quando uma pessoa não tem domínio o suficiente para desenvolver uma demanda, ela procura alguém que a auxilie e lhe passe o conhecimento necessário.
Pair Programming
Várias das ações visam, de alguma forma, o nivelamento do conhecimento do time, o pair programming é onde isso acontece de forma mais recorrente. Fazemos um esforço diário para que pessoas trabalhando sozinhas sejam exceção, e não a regra. A equipe se organiza para juntar os pares e geralmente eles são compostos de uma pessoa que possui o conhecimento para executar a demanda e outra que vai aprender com ela.
Uma prática que ajuda a reforçar o pair programming é a limitação do WIP. Em nosso contexto, não usamos isso para forçar o pareamento especificamente, mas com o limite atual é improvável que haja muito mais do que uma tarefa por par na etapa de desenvolvimento e, mesmo que isso ocorra, não é necessariamente algo ruim: pode significar que as outras etapas estão muito mais otimizadas e que podemos concentrar os kaizens no desenvolvimento. De toda forma, mesmo que uma coisa não force a outra, consideramos que limitar o que está em progresso e fazer pareamento são práticas complementares.
Disciplina na Daily
Pode parecer óbvio, mas geralmente não é. A daily é uma reunião cara pelo fato de envolver muitas pessoas, e por isso deve ser rápida e tratar do que realmente é relevante para o time como um todo. Por isso, quando unificamos as equipes por conta do fluxo unificado, definimos um horário. (antes cada equipe tinha o seu, que geralmente não era fixo) e nos cobramos constantemente para mantê-lo. Além disso, mesmo que haja atrasos, a reunião começa no horário marcado com quem estiver presente.
Como Fazemos a Daily
Seguimos o modelo Kanban, então todos olhamos para o board (presencialmente fazíamos um stand-up meeting em frente ao board físico, hoje, como trabalhamos de forma remota, alguém da equipe mostra sua tela numa conferência e “pilota” a reunião), começamos pelas demandas das colunas mais à direita. Isso, porque o valor que está mais perto de ser entregue tem mais prioridade, já que está com o andamento mais avançado.
Assim é o board da operação. Quando falei em limite de WIP acima, referia-me ao limite de cartões que podem haver contando o que tem em “Ready for dev” até “Ready for delivery”. Nesta imagem, o WIP é de 12 itens. Não existe uma regra específica limitando o WIP por coluna, mas quando metade dos itens está numa só coluna. Por exemplo, sabemos que ali há um gargalo e que devemos atuar para dar vazão nesta etapa específica.
Coding Dojos
Semanalmente, reunimos toda a equipe por algumas horas para treinar alguma habilidade técnica. De uns meses pra cá temos seguido o formato de Coding Dojo, praticando com exercícios simples e sempre seguindo o TDD, mas também adotamos formatos diferentes quando queremos estudar algo novo ou compartilhar algum conhecimento que está ilhado na equipe.
Workshop de Histórias em Done
Em uma retrospectiva do time, foi levantado que muitas histórias eram desenvolvidas sem que toda a equipe entendesse a solução. Fazendo com que futuras manutenções em algumas partes de um projeto exigissem pessoas específicas. Para diminuir esse gargalo, semanalmente escolhemos algumas das principais demandas entregues na semana anterior, para que os responsáveis por elas expliquem de maneira técnica para toda a equipe como o problema foi resolvido, além de apresentarem as decisões tomadas. Essas explicações são gravadas pela equipe e mantidas para uma futura consulta.
Demandas de Eficiência
Temos um BVP com histórias criadas pelo time que visam aumentar nossa eficiência na operação. Isso pode incluir tasks de performance em builds e deploys, configurações de padrões de projeto como code styling, entre outras melhorias que nos deixam mais eficientes no dia-a-dia. O BVP de eficiência funciona como um projeto: suas histórias entram no mesmo fluxo de desenvolvimento de acordo com uma cadência de entrega de histórias de clientes (por exemplo: a cada x demandas de valor, entra uma de eficiência ou até a demanda atual de eficiência se encerrar).
Com essas ações, conseguimos nos tornar uma equipe mais resiliente e eficaz. E que se comunica e se organiza muito bem para resolver os problemas. No próximo artigo da Série Fluxo Unificado, vou abordar os principais resultados obtidos pelas ações que falei aqui. Então fiquem de olho!
Lembrando que esse é o 2º post da série, confira os outros posts aqui:
1º Post: Fluxo Unificado: perspectiva de um desenvolvedor – Motivações
3º Post: Fluxo Unificado: perspectiva de um desenvolvedor – Resultados
4º Post: Fluxo Unificado: perspectiva de um desenvolvedor – Responsabilidades