Como eu já devo ter mencionado aqui algumas vezes, eu participo de dois grupos de programadores que, são, sem dúvidas, totalmente fora da curva. Um deles é o Welcome To The Django, do meu amigo Henrique Bastos, e o outro é o Python Pro, do meu amigo Renzo Nucitelli. Os dois cursos possuem grupos no Telegram onde há discussões diárias sobre os mais diversos assuntos. Volta e meia também falamos sobre programação.

Essa semana, meu amigo Vinicius Assef compartilhou um artigo muito interessante lá no Telegram do Python Pro que questionava o porquê de os desenvolvedores de software odiarem metodologias ágeis.

O artigo compartilha uma série de prints de posts apontando diversos defeitos na metodologia. Alguns deles:

Metas arbitrárias e prazos fora da realidade:

Burocracia e limitação da criatividade do desenvolvedor:

Pressão em cima do desenvolvedor para realizar seu trabalho:

Carta branca para postergar o trabalho difícil:

Esses são exemplos de algumas críticas que a autora do post selecionou. Na minha opinião são críticas muito válidas e que refletem a realidade de muitos ambientes de desenvolvimento de software.

O questionamento que fica é: Isso é desenvolvimento ágil?

O que é o Manifesto Ágil?

Antes de tudo, acho importante para a discussão definir e entender o que é o Manifesto Ágil.

O Manifesto Ágil é uma declaração de valores e princípios criada em fevereiro de 2001 por 17 programadores que já praticavam métodos que na época eram definidos como métodos leves.

Essa definição veio justamente de um contraponto aos métodos pesados, como o desenvolvimento em cascata, que na prática eram ruins porque havia muita burocracia e micro-gerenciamento. O foco era em tornar o processo eficiente, mas no meio se perdia eficácia. Imagine levar 6 meses para desenvolver 50 funcionalidades, e então, ao colocar o software em produção, descobrir que somente 10 eram necessárias?

Já havia um interesse de uma grande quantidade de pessoas em métodos que ajudassem as equipes a serem mais eficientes. Nessa época já existiam  SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, etc.

Foi quando o grande Uncle Bob resolveu criar um evento para a galera discutir sobre esses métodos. Foi nesse evento que, depois de muita discussão, encontrou-se um consenso sobre como deveriam ser os métodos ágeis de desenvolvimento. 

Eis que nasce o Manifesto Ágil!

Vocês entenderam tudo errado

“Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”

Este é o Manifesto Ágil traduzido.

Ao olharmos as críticas dos desenvolvedores citadas no post, nós vemos que esses valores se perderam completamente.

“Metas arbitrárias e prazos fora da realidade”

“Pressão em cima do desenvolvedor para realizar seu trabalho”

Cadê o valor “Colaboração com o cliente mais que negociação de contratos”?

“Burocracia e limitação da criatividade do desenvolvedor”

Cadê o valor “Indivíduos e interações mais que processos e ferramentas“?

“Carta branca para postergar o trabalho difícil”

Cadê o valor “Responder a mudanças mais que seguir um plano“?

No post, a autora cita uma talk do Uncle Bob criticando as certificações Ágil. Segundo ele, o Agile foi criado originalmente por programadores, e não por gerentes de projeto. A partir do momento em que se cria um “canto da sereia” como uma certificação Ágil, o que temos na prática são dúzias de gerentes de projetos “certificados” que consomem dois dias de conteúdo, pegam um pedaço de papel e acham que isso significa alguma coisa.

Uncle Bob argumenta que os gerentes de projetos sequestraram um movimento que, em sua origem, foi criado de programadores para programadores.

E ele está coberto de razão!

O objetivo principal do movimento ágil é “descobrir maneiras melhores de desenvolver software”. Entregar software mais rápido é consequência, e não causa.

Um gerente de projeto que nunca programou não tem a capacidade de analisar o quão importante é resolver um débito técnico, ou quantas estórias somos capazes de entregar, ou o quanto é importante investirmos tempo escrevendo testes. Somente nós programadores temos.

Para compreender o que é desenvolvimento ágil em sua plenitude é preciso estar no campo de batalha, é preciso ter skin in the game. 

Cada escolha, uma renúncia

Em outra talk, também citada pela autora, o Uncle Bob fala sobre débito técnico. Ele argumenta que a velocidade de um time Scrum em entregar estórias é diretamente proporcional a velocidade de uma base de código apodrecer. Ou seja, quanto mais rápido se avança, mais bagunçado fica seu ambiente. O resultado disso é que conforme o tempo passa a eficiência do time cai, porque é cada vez mais difícil mudar o software.

Você acha que um gerente de projetos que nunca sujou a mão em código legado tem a capacidade de mensurar isso? É óbvio que não tem.

É por isso que um dos valores é “Software em funcionamento mais que documentação abrangente“. No fim do dia, o que gera valor para o cliente é entregar software funcionando. Direção é mais importante que velocidade.

Os trade-offs sempre vão existir. Ao escolher velocidade, nós abrimos mão de qualidade. Para aproveitarmos os benefícios de metodologias ágeis é preciso entender o manifesto ágil. O objetivo não é fazer software mais rápido, o objetivo é fazer software da melhor maneira possível.