Vira e mexe encontro no mundo do desenvolvimento ágil gente falando essa frase do título: “Aqui não trabalhamos com prazos” ou “Desenvolvimento ágil não tem prazo”. O curioso é que em nenhum momento no manifesto ágil, prazos são citados. Nem nos 4 valores, nem nos 12 princípios. Nem para dizer que existem, muito menos para dizer que não existem.

Mas essas frases são facilmente encontradas em conversas especialmente entre pessoas desenvolvedoras. E, sim, eu já estive lá. Acredito que já falei coisas parecidas com essas cerca de 12 ou 13 anos atrás.

Eu associo essa distorção especialmente à dois fatores:

1. Uma má interpretação dos valores do manifesto ágil, especialmente de “Indivíduos e interações mais que processos e ferramentas” e “Colaboração com o cliente mais que negociação de contratos”;
2. Um exagero e tomada de decisão errada a partir da premissa de que seres humanos são ruins para estimar prazos.

Vou tentar separar meu raciocínio nessas duas frentes.

Má interpretação dos valores

Muitas vezes o entendimento dos dois valores citados acaba sendo um pouco equivocado na minha percepção.

Já tive discussões onde esses valores foram usados como argumentos para que não se fizesse estimativas de prazos em projeto e que se tentasse falar com o cliente que “vai estar pronto quando estiver pronto”.

A ideia por trás disso é que quando se fala de “indivíduos e interações mais que processos e ferramentas” seria uma justificativa para não se fazer qualquer tipo de estimativa ou medição pois isso seriam “processos e ferramentas”. Além disso, dar um prazo ao cliente seria “negociar um contrato” e se fizermos isso “não estamos seguindo os valores do manifesto ágil”.

O primeiro caso é um argumento muito fácil para justificar qualquer coisa que eu não queira fazer. Não quero ter que seguir algum padrão de código? É um processo, então não faremos. Não quero seguir um padrão de arquitetura X ou Y que o time vem seguindo? Chamo de processo 😂.

Brincadeira à parte, para ambos os casos, existe uma frase no manifesto ágil que vem logo após os valores e que as pessoas costumam ignorar. Ela diz:

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

A frase diz por si só: não devemos ignorar o que está direita mas sim focar mais no que está a esquerda. Valorizamos mais indivíduos e interações, mas ainda há valor em processos e ferramentas, apenas temos que ser criteriosos e priorizar um sobre o outro.

Quando a gente fala do valor “Colaboração com o cliente mais que negociação de contratos” acho que é onde a coisa de se discutir um prazo ‘grita’ mais. Invariavelmente clientes/negócios precisarão ter prazos, previsões e previsibilidade para tomadas de decisões e criação de vantagem competitiva. E alguns dos princípios do manifesto trazem isso de forma intrínseca quando falam de “satisfazer o cliente”, “visando vantagem competitiva para o cliente” e quando inclui “pessoas de negócio” constantemente nos princípios.

Seres humanos são ruins para estimar prazos

Isso é fato, não é um exagero (e talvez não só prazos, mas para deixar o texto menos longo vou ficar só nisso).

O exagero fica por conta de dizer que por isso então não se deve fazer nada a respeito e ficar à deriva. Como diriam os mais velhos, é “jogar o bebê fora junto com a água”.

Como eu disse acima, negócios (sejam eles próprios ou de clientes) precisam de dados para tomadas de decisões que direcionem para um norte e que inclusive possam ajudar como vantagem competitiva. Um desses dados é uma previsibilidade (ou prazo) de entrega de uma feature ou produto, até para que haja algum tipo de planejamento.

Isso não deve significar que é necessário se passar um prazo exato com data e hora para que a entrega aconteça mas sim ter conversas constantes entre time e negócio para que se possa ter previsibilidade. Novamente eu vou voltar nos princípios do manifesto que diz:

“Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.”

Parafraseando o que Érica Briones disse em uma conversa no Twitter, dizer ao negócio que deve haver uma margem de erro ou até mesmo dizer que o time não irá trabalhar fazendo estimativas, num processo de #NoEstimates, por exemplo, é algo bem diferente de dizer que não se trabalha com prazo.

“Solução” para o imbróglio

Já disse algumas vezes durante o texto, mas nunca é demais repetir: Negócios precisam de previsibilidade. De um jeito ou de outro, precisamos conseguir prover isso para auxílio nas tomadas de decisões.

Quando o time de desenvolvimento está com medo de apresentar um prazo ou estimativa, provavelmente 2 coisas devem estar acontecendo:

1. O time tem medo que quem vai receber essa informação vai assumir como algo assinado e escrito em pedra que nunca pode mudar;
2. O time não consegue ou não sabe passar uma estimativa pois não saber medir essas coisas.

Curiosamente a solução para o primeiro item está justamente no valor do manifesto que é erroneamente usado para não se fazer estimativas:

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

É preciso que seja criado um ambiente de segurança e que todos estejam cientes que desenvolvimento de software não é um cenário complicado e sim complexo (Cynefin). E essa colaboração com o cliente precisa ser constante, com transparência e negociação também constantes e de ambos os lados.

Já para a questão de não saber gerar essas estimativas, conseguir pegar métricas, trabalhar em melhorias contínuas do processo de entrega, e adaptar constantemente são medidas que aos poucos vão corrigindo esse problema. Mas creio que isso merece um texto exclusivo à respeito.

O importante é um entendimento mais amplo desse tema e pararmos de replicar esses argumentos falsos sobre prazos. E a partir disso, passarmos a entender melhor como conseguir o ambiente e os dados corretos para se trabalhar as estimativas necessárias.