Aquele board no Trello não torna sua equipe ágil!
Infelizmente é comum olhar para equipes de desenvolvimento que desejam ser ágeis e focam apenas em processos/ferramentas. Nesse post vamos conversar um pouco sobre como a cultura de revisão de trabalho pode ajudar sua equipe a ser ágil.
Por que focar em ferramentas/processos é ruim?
Porque a ideia da agilidade é tornar as equipes mais flexíveis as necessidades do cliente, para que dessa maneira seja possível entregar valor de forma contínua mantendo as expectativas alinhadas.
Se forcarmos demais nas ferramentas e nos processos podemos decorar todas as siglas, fazer todas as reuniões e possuirmos todos os papéis em nossa equipe.
Porém, infelizmente, isso não vai garantir que a equipe consiga cumprir os requisitos do manifesto ágil, sendo assim, não estaria trabalhando de tal forma.
Quando penso em agilidade …
A primeira coisa que me vem a mente é o manifesto ágil, seus valores e seus princípios. Podemos notar nos princípios que o foco do manifesto ágil são as pessoas e suas interações para chegar a um bom resultado final.
Logo, Scrum e outras práticas são formas de se tentar organizar uma boa equipe para chegar a isso. Lembre-se, siglas e rituais não substituem bons profissionais!
Qual a relação entre code review o manifesto ágil?
Para falar melhor sobre isso, vamos observar alguns dos princípios do manifesto:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Mudar algo crítico em um projeto é algo comum e aprender a conviver com isso é essencial. Agora, pensando em algum projeto, consegue imaginar fazer alguma mudança dessas perto da finalização do projeto sem cobertura de testes? — Seria o caos!
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Tem uma frase que ouvimos muito na era das startups que é “se for para errar, erre cedo”. Quanto mais demoramos para validar algo com o cliente ou para entregar uma funcionalidade, mais recursos serão desperdiçados. Então, uma boa prática para resolver isso é mantêr seu cliente por perto, procurando sempre mostrar o que está fazendo com pequenas entregas contínuas.
As metodologias de trabalho mais antigas tinham um problema grave (entre vários outros) que o cliente só olhava o resultado final no fim do projeto. Com isso, os desenvolvedores poderiam ter passado um ano desenvolvido a coisa errada. Por isso lembre-se: mantenha o cliente por perto, entregue sempre pouco e constante.
Continuous attention to technical excellence and good design enhances agility.
Fazer trechos de código ruins pode parecer uma boa ideia quando o prazo está apertado e para justificar isso pensamos “depois eu volto e arrumo isso aqui”. Mas você nunca voltará!
Partindo do princípio que devemos ter um bom design em nosso software para ele crescer saudável, o code review surge como uma boa forma de fazer revisão por pares, deixando nosso código bem escrito.
Como podemos trabalhar de uma forma ágil então?
Não existe fórmula mágica nem bala de prata para resolver essa questão. Tentar vender soluções prontas em caixinhas geralmente tem um nome: charlatanismo. O que precisamos mesmo é conhecer a realidade de nossa equipe, empresa, clientes e buscar nos adaptarmos da melhor forma possível.
Pela minha experiência em empresas, já utilizei ideias que posso compartilhar. E são essas:
Cooperação entre todos
Como é a relação com seus colegas de time? Vocês conversam abertamente sobre os problemas? Como é sua relação com o cliente? Vocês conversam com frequência ou apenas entre longos intervalos de tempo?
Boas práticas e boa arquitetura
Como já falamos em outros posts desenvolver algo ruim além de ser falta de profissionalismo é também um atraso no desenvolvimento do software. Como você conseguiria fazer alterações em um projeto com facilidade se ele estiver mal feito e sem testes?
Conclusão
Como vimos logo acima para ser ágil tem muito mais a ver com cooperação, desenvolver um projeto com qualidade (TDD, boas práticas, boa arquitetura, etc) do que seguir a risca manuais.
Vale lembrar que não mencinei todos os 12 príncipios, sendo todos eles sujeitos a interpretação. Mas se você fechar esse texto pensando em ler o manifesto e tentar entender o que ágil significa para você, já estarei muito feliz. :)
