Busca avançada

Agile em Projetos de Software: O que não te contaram

segunda-feira, 24 de agosto de 2020 por Eduardo Spaki
Agile em Projetos de Software: O que não te contaram

O mercado nunca foi tão favorável à adoção do Agile em Projetos de Software. Cada vez mais abrimos redes sociais, como o Linkedin, e vemos profissionais se certificando em Scrum, fotos de Squads altamente produtivas, etc.

Eis que vem um sentimento de distanciamento, onde você parece ser o único fora desse jogo… não é mesmo?

Pois olha, se você está distante, muitos outros podem estar também, inclusive o recém certificado e a Squad “Dream Team”.

Muitas outras vezes já citei aqui, exemplos como: Ao levar meu carro no mecânico, quero saber duas coisas, “quanto?” e “quando?”. E isso vale para boa parte dos produtos e serviços que consumimos.

Tanto para Pessoa Física, quanto para Pessoa Jurídica (sim, ao fornecer um produto para uma empresa a mesma te fará essas duas perguntas).

Outro exemplo que cito bastante é aquele, onde você comprou um produto com um preço muito em conta, fica orgulhoso e cheio de si, pela boa negociação… durante uma semana! Depois disso o produto apresenta problemas, dada a sua qualidade “barata”. Há exceções, mas quem vive delas?

Quem nunca comprou aquela camiseta que encolheu ou desbotou na primeira lavada? E a mesa de jantar das pernas bambas? - Aqui estamos falando do ditado: o barato que sai caro!

O Software não está imune a isso. Quem está investindo no projeto quer saber “quanto?” e “quando?”, mas também está disposto a fazer uma boa pechincha para ter algo mais “barato”.

Quais as consequências disso para você? Veremos.


Sprints

Começou o projeto e o Scrum Master chega para você e fala “Você estará alocado full time no projeto. Portanto você tem 40h semanais para planejar as atividades da sprint, ok!?”

Aqui está a primeira armadilha: o projeto já nasceu atrasado, não importa quantas horas extras sua “Dream Team Squad” fará.

Quem é produtivo 40h na semana? Não vai nem ao banheiro, durante as 8 horas de trabalho? Está querendo enganar quem?

Além disso, e as reuniões?! Não estou nem falando das reuniões de negócio, estou falando dos rituais Agile/Scrum, como Planning, Review, Daily e Retro.

E sempre há sprints entregues que acarretam em bugs ou atividades imprevistas para a próxima semana.

Há artigos na Internet que botam isso em números, mas ao descontar tudo isso, de 40h iniciais, temos algo entre 25 e 30 horas semanais.

E olha como escala rápido (no melhor estilo “conta de padaria”):
•    40h previstas - 25h realizadas =  15h de “atraso”.
•    15h de “atraso” vezes 5 profissionais = 75h de “atraso”.
•    75h de “atraso” vezes 26 semanas (aproximadamente 6 meses de projeto) = 1950 horas.

Ou seja, o projeto já começou 2000 horas atrasado!


Estimativa

“Estimativa” é igual “Assertiva”? Não!

Eis que na Planning do projeto o Scrum Master te pergunta a Estimativa de uma determinada atividade. Você responde: Dois dias.

Então ele vai ao cliente e afirma com convicção categórica: Em dois dias, tudo estará pronto e funcionando!

Ele usou algo que é uma “previsão”, probabilística, incerta e volátil... para prometer algo concreto e preciso.


Cronograma

Não satisfeito em fazer a Planning da primeira Sprint, o Scrum Master diz: Como cada um aqui tem 40h semanais e nossa sprint é semanal, definam todos os story points e ordem de execução dos mesmos. Assim teremos uma visão geral do projeto com o cronograma das Sprints.

Para agilistas mais puristas, o parágrafo anterior foi muito estranho!

Apesar da entrega contínua, ou seja, planeja uma sprint, executa a mesma, para só então planejar a próxima, sempre há o “quanto e quando”.

E sempre há mesmo. Se o projeto está sendo feito por uma “Software House”, para um cliente de um ramo qualquer (geralmente não “tecnológico”) o cliente pagou um valor fechado para ter um software em uma determinada data.

Já se o projeto é da TI da empresa para uma área qualquer dentro da própria empresa, saiba que há um centro de custos com um budget definido para o ano. Então por mais “agile” que parece para você, há sim um deadline muito bem definido que é ignorado.


Scrum Master ou Gerente de Projetos?

Dados os exemplos reais, já citados até aqui, você deve estar se questionando: Pois esse Scrum Master mais parece um Gerente de Projetos.

E é mesmo, só que “Scrum Master” é mais “cool”, e dá a impressão de que você está envolvido em um projeto “moderno e descolado”. “Ajuda” na moral do time.


O Gerente de Projetos não é bom!

Ele não é bom para o projeto ou para você?

O fato é que, os agilistas mais puristas vão defender suas iniciativas, mas sempre será um trabalho difícil casá-las com o “quanto e quando”.

Afinal de contas, você não aceitaria ouvir do seu mecânico: Não sei quando vai ficar pronto, mas vai pagando uma quantia semanal até quando de fato seu carro estiver funcionando 100%.

Voltando à realidade apresentada, em projetos como esse, no fundo todos sabem que estão enganados, mas se agarram na esperança de que um milagre vai resolver tudo antes do prazo.

Tanto sabem, que o gerente e a área combinam um prazo para conclusão do projeto, antes mesmo de ter alguma estimativa. Depois das estimativas traçadas, quando alguém questionar que o número de horas não cabe dentro do prazo, sempre tem aquele discurso: Vamos dar um jeito. Vamos fazer umas horas extras e a equipe é boa, vai entregar as atividades antes dos prazos!

E o papel do “Scrum Master/Gerente de Projetos” a essa altura é garantir essa pressão!

Como assim!? No entendimento mais superficial da coisa, um bom gerente de projetos é aquele que conhece e aplica as técnicas necessárias para garantir um bom andamento do projeto.

No caso do Scrum master, garantir as técnicas/premissas agile. Porém aqui vale ressaltar uma coisa: Agile por Agile não entrega software. Assim como aqueles mais preocupados em documentar o software, afinal de contas o cliente comprou um Software, não comprou Agile ou documentos.

De qualquer maneira, esse é o entendimento esperado do que esperar de um GP ou SM.

Mas na prática, com já dito, o cliente quer o software. Cabe o SM/GP manter a pressão para que as coisas sejam executadas o quanto antes. Ou seja, se para você parece que o GP é um “ogro”, que mal sabe de Agile ou Gerência de Projetos, para o cliente ele é fundamental, devido a pressão que ele está exercendo para alimentar aquela esperança de que tudo ficará pronto no prazo.


Mas o projeto será concluído no prazo?

Se o projeto for entregue no prazo, será grosseiro, entrando na categoria “barato que saiu caro”. Ou seja, algum custo até foi controlado (mesmo com algumas horas extras), mas poderá ser um software feio, instável…. Bem “meia boca”.

Agora, se mesmo com toda a pressão a equipe está prezando por algo bem feito, então o projeto está atrasado, correndo o risco de ser cancelado.


Então não há salvação?

Claro que há. Quando pararem de tratar projeto Agile como rápido, há chances!

Agile significa ser reativo a mudanças com agilidade.

O Google emplacou muito bem isso quando lançou o Gmail, em seu “beta eterno”. Ou seja, era um software que se preocupou em fazer primariamente o que deveria fazer e foi se refinando com o tempo…. Até hoje e não vai parar.

Se o projeto tiver mais essa visão evolutiva, ano após ano, e menos um produto de caixinha pronto para consumo...se pararmos de compararmos software com produto de mercado, a tecnologia será surpreendente e disruptiva.


Agile em Projetos de Software: Como faço?

Aqui na Code21, optamos por uma abordagem que tem dado certo quando o assunto é agile em projetos de software. Mesmo encarando projetos grandes, sempre optamos por entregas e fases pequenas.

Por mais que um cliente chegue com uma demanda grande, orçamos sempre pedaços, e após entregar esse “mini projeto”, partimos para o próximo orçamento e execução.

É mais fácil (e barato) controlar imprevistos em um projeto de 2 meses do que de 1 ano.


Sua opinião

Sim, foi um texto duro, provocativo… mas quero saber se já participou de algo assim?

Concorda ou discorda?

Convido você para o debate.

 

Compartilhar