Tradicional x Ágil: Qual metodologia dá mais visibilidade para o projeto?

Como se comportam no tempo projetos ágeis e tradicionais em relação a visibilidade do projeto?

No início de um projeto no modelo Plan Driven há um grande marco de lançamento. É o momento em que todos — time, diretoria, investidores — elaboram e acordam um plano. Algumas decisões sobre arquitetura são tomadas, há muita transparência sobre o processo, todos estão envolvidos e têm muitas informações sobre o novo produto que estão prestes a criar.

Depois, a visibilidade da equipe e do projeto começa a cair. O trabalho está sendo feito, mas o que a equipe de produto está fazendo não é acompanhado pelo resto da empresa. Isso continua ao longo de quase toda a execução do projeto. Já vivi casos em que equipes de desenvolvimento desapareceram por um ano ou mais, estavam trabalhando “na parte de infraestrutura”. O restante da organização não sabe o que está acontecendo na tecnologia.

No fim do projeto, todos ficam ansiosos. A equipe de vendas começa a pressionar a de produto. Os vendedores querem “o que está pronto até agora” para iniciar as vendas.

Os programadores dizem que não é possível mostrar nada, que o sistema foi desenvolvido em várias camadas, a de infraestrutura é a única que está pronta, mas ainda faltam as interfaces do usuário. “Tudo o que temos agora são algumas APIs” — já ouvi muito essa frase.

O sistema, que nunca foi testado, começa a ser validado, e o que mais aparecem são bugs e erros. Enquanto isso, a ansiedade de todos vai se transformando em irritação, pois os prazos estão vencendo.

Os programadores reclamam da microgestão; não conseguem mais trabalhar porque precisam ficar preenchendo relatórios de status diários. Os executivos vão ficando nervosos, fizeram promessas, que talvez não consigam cumprir, para os clientes e para o mercado.

Nesse momento, a equipe de produto entra na jornada de trabalho de 80 horas. Fins de semana no escritório, pânico pelos prazos eminentes, pela quantidade de bugs que não para de aumentar e a discrepância entre as expectativas e o que foi realmente desenvolvido.

Isso é tão comum, que a jornada de 80 horas e os programadores passando finais de semana inteiros no escritório são aceitos como algo normal dentro do processo de criação de software. Daí vem o estereótipo do profissional de tecnologia que passa a madrugada programando sem parar.

Na metodologia ágil, como as entregas são frequentes, o projeto nunca perde a visibilidade, e todos são poupados desse enorme estresse de uma grande entrega final.