Em tempos de sociedade global e tecnologia muito presente, os desafios das equipes de desenvolvimento são elevados a um novo patamar. Agora, além dos desafios de manter as habilidades técnicas atualizadas e otimizadas e da ótima comunicação com o cliente, também é necessário estabelecer ótima comunicação e colaboração com equipes parceiras remotas em um time global.
No projeto em que atuo, temos equipes de desenvolvimento e testes em continentes diferentes, com diferentes culturas, diferentes fusos horários e, claro, diferentes maneiras de abordar o projeto. Para alcançarmos entregas consistentes e dentro dos prazos criamos, em conjunto, um padrão universal de desenvolvimento.
Por que um padrão?
A partir do momento em que um software chega para o desenvolvimento é natural que haja curiosidade e até ansiedade para ver os resultados. Do lado técnico é preciso gerenciar as expectativas, o prazo e também a qualidade de código considerando não é apenas o produto final a ser alcançado, mas a facilidade de manutenção futura em que as chances de ter novas pessoas no time são grandes.
Com várias equipes de desenvolvimento no mesmo projeto mundo afora, as possibilidades de haver desalinhamento de padrões de código e estruturas são enormes e, essa divergência, gera impactos principalmente para manutenções futuras.
Se os times trabalham de maneira diferente o resultado claro é que, quando houver necessidade de manutenções no código feito por outro time, haverá inicialmente confusão e depois necessidade de entendimento para então se alcançar a meta estabelecida. Fica fácil de perceber que mais tempo será preciso e a data especificada pode não ser alcançada.
Somando ao caso da manutenção, também deve-se citar a curva de aprendizado de novos colaboradores. Se existem diferentes padrões no código, o aprendizado nitidamente será mais lento afetando a produção e a entrega do time como um todo.
Para evitar esses problemas e otimizar tanto a produção quanto a manutenção e as entregas é imprescindível que os times tenham muito bem definido como devem atuar, assim, por mais que hajam grandes diferenças entre as pessoas, os resultados serão os mesmos e, então, a pluralidade interpessoal será direcionada para multiplicar os bons resultados.
Guidelines e testes unitários
Discutindo os pontos de divergência entre times e também com o cliente, chegamos à conclusão de que precisaríamos definir o padrão de projeto que deveria ser aplicado a todos os desenvolvedores e também que precisaríamos garantir que os comportamentos dos componentes desenvolvidos fossem respeitados e mantidos. Para isso criamos as “Guidelines de desenvolvimento”, nosso guia de boas práticas para a programação e também passamos a usar com mais precisão os testes unitários.
As guidelines trouxeram para os times o lugar comum, ou seja, existe agora uma maneira bem especificada e clara de como se deve escrever o código, qual arquitetura usar, quais comportamentos devem ter determinados tipos de componentes. Uma vez definidas, as guidelines foram formalmente apresentadas ao cliente, aprovadas e incorporadas ao processo dos times. Sendo assim, quando um commit novo chega com código que não está dentro dos parâmetros, o próprio processo (code review) reprova e o manda de volta para que o desenvolvedor corrija e deixe seu código dentro das boas práticas.
Para garantir que tudo funcione bem, os testes unitários que já eram aplicados passaram a ser parte estratégica do processo de desenvolvimento. Agora, se o desenvolvedor terminou sua tarefa, mas não escreveu o respectivo teste unitário ou, por alguma razão, fez com que testes antigos falhassem, será reprovado no code review. Outros fatores também são levados em consideração na fase de revisão, como a relevância do teste unitário escrito e se o desenvolvedor está pelo menos mantendo a porcentagem de cobertura do código com testes unitários automatizados. Se não estiver agregando valor ou a porcentagem for menor, a tarefa volta para que seja melhorada ou até refeita. Desta maneira podemos garantir que, independentemente do desenvolvedor que está trabalhando, mesmo componentes complexos serão atualizados e nenhum aspecto importante acabará sendo desfeito por descuido.
Resultados alcançados
Os resultados foram mais expressivos do que imaginávamos. Com o conjunto guidelines e testes unitários no processo, de fato conseguimos deixar todos os times na mesma página. Sempre que surge alguma dúvida sobre a implementação o time recorre às guidelines e por elas já consegue se direcionar, seja para resolver a tarefa da melhor maneira possível ou seja para entrar em uma reunião e discutir com maior propriedade os caminhos que devem ser tomados.
Além disso, observamos que nosso cliente está sugerindo, baseado em nosso modelo, para outras frentes de desenvolvimento que também desenvolvam suas guidelines, pois tem se mostrado uma maneira objetiva e efetiva de reduzir questões que poderiam levar um bom tempo para serem resolvidas.
Partindo do pressuposto que novos membros farão parte do time, recebemos a recomendação do cliente de criarmos uma estrutura de ensino para garantir que aqueles que chegarem já aprenderão o que for necessário seguindo estas boas práticas de desenvolvimento. Este procedimento certamente deixará a curva de aprendizado e de integração do novo membro muito mais rápida e direta.
Por último, temos visto que novos projetos também estão adotando as tecnologias que usamos atualmente, um dos fatores que tiveram grande peso na decisão foi a existência de uma ótima infraestrutura de aprendizado além de uma maneira prática e organizada de gerar resultados consistentes entre times de diversos países.
Já trabalhou em um time global e teve desafios diferentes ou até mesmo semelhantes? Compartilhe a sua experiência conosco nos comentários!
