Uma mudança por vez

Há algum tempo venho estudando sobre produtividade em times ágeis através de alguns materiais na internet, livros e também pesquisando como as empresas trabalham. A intenção é poder trazer alguma coisa nova para o time em que trabalho. Time esse que é composto de 8 desenvolvedores (2 são consultores), 1 UX, 1 coordenador, 1 PO e é subdividido em 2 partes: Plataforma, que cuida das APIs e painéis de administração; e Webmail, que cuida do desenvolvimento e manutenção do webmail ofertado pela empresa.

Nós ainda somos um time que engatinha no ágil. Digo isso porque muitos dos processos ainda são extremamente engessados, o que acaba atrasando a entrega de valor para o usuário. Quando entrei nesse time, a cerca de 2 anos atrás, utilizávamos o famoso “SCRUM, but…” e era uma verdadeira bagunça. A bagunça era tanta que nem métricas de Lead e Cycle time eram possíveis de ser extraídas. Foi só quando um novo coordenador assumiu o time que a bagunça do processo sumiu. Agora é possível gerar várias métricas legais e gráficos geniais!

Apesar dos processos terem melhorado, internamente as coisas ainda são uma bagunça. E por internamente eu me refiro aos processos que deveriam nos ajudar a escrever códigos melhores, como MRs, descrição de histórias e até ferramentas que nos auxiliam a evitar erros bobos.

Pensando nessa situação caótica, eu pensei por um tempo em como fazer as coisas melhores. Olhei para o SCRUM e seus ciclos e me questionei: Porque não tentar implementar uma mudança a cada X período de tempo? Comecei então uma longa jornada que está longe do fim!

Tentei organizar um “backlog mental” com os problemas mais críticos que tínhamos, ficando mais ou menos assim:

  • Branchs sendo mergeadas no master com teste quebrando
  • Código escrito fora dos padrões já pré-estabelecidos
  • Histórias de usuário gigantes
  • Entregas gigantes
  • MRs sendo abertos sem atender os critérios de aceite básicos
  • MRs sem nenhuma descrição do que foi feito
  • Falta de visibilidade de erros de JS

Esses são só alguns dos problemas que eu encontrei na época! E solucionar todos ao mesmo tempo era impossível devido a diversos fatores: 1) Eu sozinho não conseguiria escrever código suficiente para automatizar o que fosse preciso; 2) O time não conseguiria se adaptar a todas as mudanças se tudo acontecesse de uma vez só; e 3) É preciso algum tempo para amadurecer algumas ideias (o famoso jogar verde para colher maduro).

Comecei pelo mais crítico:

Testes quebrados no master!

O ser humano é um bicho preguiçoso. Fato! Automatize todo e qualquer trabalho braçal para evitar dores de cabeça no futuro, pois um dia alguém vai se cansar de executar essas tarefas e elas serão empurradas para debaixo do tapete. Foi o que aconteceu com os nossos testes.

Precisei de algumas semanas de trabalho extra, além do meu horário, para refazer nosso Docker de desenvolvimento e configurar o CI do gitlab para rodar os testes de JS em cada commit.

Ainda não tínhamos testes de PHP no projeto nessa época (outro problema), mas teste quebrado no master… nunca mais!

Feito isso, o time achou um pouco estranho na primeira semana e não sabia como lidar com essa novidade. Tivemos um pequeno período de adaptação e então continuei as melhorias, de maneira incremental.

Hoje, olhando para trás, vejo que já melhoramos muito! Corri atrás de aprender a fazer testes com PHPUnit e repassei o conhecimento ao time, configurei novos pipelines no CI para automatizar ainda mais a garantia de qualidade do código e, mais recentemente, estou trabalhando na melhoria da qualidade dos nossos MRs e na visibilidade dos erros de JS.

A qualidade dos MRs, neste primeiro momento, é representada pelos seguintes critérios:

  1. Resolução de 1 problema apenas: cada MR deve conter apenas o código necessário para solucionar um problema específico ou implementar uma única história de usuário.
  2. Um bom entendimento do que estou avaliando: envolve uma boa descrição do que é para ser feito e do que foi feito.

O segundo critério é o que tenho atuado mais ativamente, pois é mais fácil de se resolver. O primeiro é mais complicado pois envolve diversos fatores externos (não é um problema que surge exclusivamente no time de dev): histórias bem definidas e priorizadas; histórias pequenas (precisam entregar algum valor); Fluxos bem definidos…

Como estou atuando no primeiro critério? Várias vezes ao dia eu monitoro o que está sendo criado no backlog e sugiro ao PO e UX algumas melhorias nos critérios de aceite, granularidade e prioridade das histórias. Como não sou expert em histórias de usuário ou UX, vez ou outra acabo fazendo sugestões que levam ao erro ou que não entregam valor ao usuário mas, como estamos em um processo de melhoria e aprendizado, errar faz parte.

Fazendo essas pequenas mudanças em ciclos, o time tem se adaptado muito bem e estão, inclusive, mais ativos nesse processo de melhoria. Acredito que se todas essas modificações tivessem sido colocadas na mesa de uma só vez, tudo estaria em baixo do tapete novamente.

Meu backlog mental de problemas ainda contém muitos itens, mas acredito que o próximo passo seja fazer o time ter ownership, se importar… Só assim vamos conseguir atingir a excelência!

Esse texto foi mais um review em modo texto do que estou fazendo por agora. Uma maneira de desabafar sobre problemas profissionais e pensar em soluções.