Desenvolvimento ágil limpo

Este texto foi originalmente publicado na Trilha de Valor #83: Rede de contatos, que foi enviada no dia 10 de agosto de 2024. Para receber a newsletter na sua caixa de entrada, inscreva-se aqui.

Já faz um tempo que li o livro “Desenvolvimento ágil limpo”, mas estou com os conceitos dele há bastante tempo na minha cabeça e decidi compartilhar sobre ele na newsletter.

Esse não é um livro que pretende atingir consenso. O autor já é uma pessoa controversa por si só e o tema que ele explora tem muita discussão sobre o que é certo e o que é errado. Desde que o manifesto ágil foi criado, muitas interpretações diferentes sugiram, frameworks foram criados e eventos foram organizados. Por ter como material base um texto tão curto, parece meio óbvio que a agilidade teria ramificações que nem sempre estariam de acordo com as intenções dos seus criadores.

E é exatamente esse ponto que o autor explora: quais são as intenções originais do manifesto ágil e o que significa de verdade trabalhar com agilidade. O livro apresenta o que é a metodologia ágil, as suas motivações e práticas. Essas práticas são divididas em:

• Práticas de negócios
• Práticas de equipe
• Práticas técnicas

Vou comentar um pouco sobre essas práticas, porque achei bem interessante relembrar como trabalhar com a agilidade de forma simples e direta e avaliar o que estou fazendo desnecessariamente no dia a dia.

O autor compartilha várias práticas de cada tipo, mas vou focar em compartilhar uma de cada.

Prática de negócios

A primeira prática de negócios compartilhada é sobre o planejamento. Existem diversas técnicas que podem ser aplicadas, mas o autor foca em poucas que já são mais do que suficientes para organizar o dia a dia do trabalho do time.

Precisamos relembrar que estimativas são imprecisas. Por isso, usamos algumas práticas para melhorar as estimativas, mas cientes de que nunca vamos acertar com certeza. Conforme o trabalho evolui, conseguimos aumentar o nosso nível de certeza, mas não podemos tentar atingir uma certeza de 100%.

Para melhorar a nossa certeza, o autor sugere a estimativa de 3 pontos. O time estima um desenvolvimento de acordo com o nível de confiança:

• O melhor cenário: 5% de confiança
• O cenário mais provável: 50% de confiança
• O pior cenário: 95% de confiança

No momento de negociar prazos e dar visibilidade sobre as entregas, a visibilidade do nível de confiança ajuda quem é responsável por essas informações. Também acredito que o time tem muito mais segurança de falar abertamente sobre estimativas, porque fica claro que é possível entregar em um prazo menor, mas as condições atuais provavelmente vão elevar o prazo para os valores em níveis de confiança maiores.

Para ficar mais claro, podemos pensar num exemplo. Existe uma demanda que pode ser entregue em até 3 dias, quando todas as condições forem perfeitas. Mas, se formos considerar que alguns impedimentos acontecem e que dependemos de outras pessoas para a demanda avançar no fluxo, talvez 5 dias seja o cenário mais provável. Mas, se estamos numa semana com feriado, tivemos um bloqueio no fluxo de deploys que ocasionou uma fila, pode ser que a gente não entregue antes de 10 dias, sendo esse o pior cenário.

Prática de equipe

Uma prática de equipe que achei bem interessante foi a do agradecimento na Daily. Ao invés de apenas falar de avanços do trabalho, a sugestão é que se use esse espaço para agradecer a ajuda recebida.

Eu li esse livro com um desenvolvedor do time e ele aplicou essa prática na nossa Daily assíncrona. Foi visível o quanto lembrar de agradecer publicamente por uma ajuda recebida muda o clima do time. E posso falar por experiência própria que muda o dia de quem recebeu o agradecimento.

É uma prática simples e direta, mas que ajuda na construção de laços dentro do time e motiva o compartilhamento de conhecimento e a ajuda entre os integrantes do time.

Prática técnica

A prática técnica que mais gosto de ver no dia a dia do time é a programação em dupla (pair programming). Que é quando duas pessoas trabalham em estreita colaboração em um único problema de código.

Eu considero uma ótima forma de compartilhar conhecimento e de criar relacionamento entre as pessoas do time. Com o passar do tempo, as pessoas se aproximam e ficam mais à vontade para pedir ajuda. Outra vantagem, principalmente para quem tem mais contexto, é que com o passar do tempo as pessoas também entendem o sistema e não precisam mais pedir ajuda sobre muitos problemas.

Idealmente, conforme o conhecimento é compartilhado, a programação em par vai exigindo menos da pessoa com mais conhecimento do time. Porque o conhecimento é nivelado e todos se tornam capazes de atender qualquer demanda que chega para o time. Digo idealmente porque de nada adianta se apoiar na programação em par sem aprender e usar esses momentos apenas para conversar.

Entendo quem tem um certo preconceito com a prática, mas, quando bem utilizada, ela pode elevar o nível do time rapidamente.

O autor também fala sobre como se tornar ágil e o livro finaliza com textos de autores convidados que expandem o tema. Achei que a leitura valeu muito a pena e me fez refletir bastante sobre o quanto reflito a agilidade de verdade no dia a dia do time.

Se você tem dúvidas sobre o que é ser ágil de verdade, ler a respeito a partir do ponto de vista de quem esteve desde o início envolvido na criação do manifesto ágil é uma boa forma de aprender mais sobre.

Até a próxima!

Copiar link