Quais são os empecilhos que o Waterfall pode trazer ao desenvolver um Software?

Independente de ser ágil ou não:

1. Ambos possuem estimativas, e nenhum cliente vai ficar feliz em saber que um projeto que estava estimado para 20 sprints sera realizado em 36.

2. Em um projeto grande, com um ano de desenvolvimento, seja ágil ou não possível prever como estará o time, se alguns membros da equipe saírem existira dificuldade na substituição e na performance do novo membro.

3. Trabalhei em um projeto longo, por mais de 16 sprints de 3 semanas, uma decisão errada no inicio do projeto, por não possuir a visão do todo, comprometeu algumas sprints, o cliente teve que arcar com duas sprints de mudança de arquitetura.

Prefiro a metodologia ágil, não pela adaptabilidade e sim por ela entregar valor ao cliente antes, e não apenas no final do projeto.

OK Evandro, entendo seu ponto, mas continuo acreditando que, em uma metodologia ágil, fica muito mais fácil dialogar com o cliente a respeito de imprevistos. E o valor final pago pelo cliente se torna mais justo, visto que ele pagou apenas o que foi realmente desenvolvido, e a equipe foi paga por tudo que trabalhou.

em uma metodologia ágil, fica muito mais fácil dialogar com o cliente a respeito de imprevistos.

Sim. Metodologia ágil pressupõe "Cliente Presente" e "Transparência". No Waterfall o gerente tentaria recuperar o atraso/imprevisto sem comunicar ao cliente.

E o valor final pago pelo cliente se torna mais justo, visto que ele pagou apenas o que foi realmente desenvolvido, e a equipe foi paga por tudo que trabalhou.

Não necessariamente, isso depende do modelo de faturamento e não da metodologia. Já vi contrato onde a empresa era paga por homem/hora e o além do Product Owner o Scrum Master também era do cliente.

Alguns contratos são por story points, outros são homem/hora e outros são por funcionalidades...

Não necessariamente, isso depende do modelo de faturamento e não da metodologia.

OK, mas em uma metodologia waterfall, as horas do projeto são, normalmente, definidas no planejamento, então, digamos que temos um projeto definido em X horas, mas meu time, por algum motivo, levou X+Y horas para desenvolver este projeto, as horas que orcei não foram suficientes, porém, como este valor foi estipulado antes, não existe a possibilidade de alteração, então eu saio no prejuízo. Agora pensando no cenário contrário, este mesmo projeto levou X-Z horas para ser desenvolvido, então o cliente acabou pagando por horas que não foram utilizadas, e isso não é uma coisa legal também.

Concorda?

Concorda?

Sim. Mas um detalhe, seja ágil ou não, se um projeto/funcionaliza tem tempo X eu tempo vender por um valor X + Y e tento fazer minha equipe desenvolver em X - W. Capitalismo é dureza... Eu puxo pela minha empresa e a contratante puxa por ela... Capitalismo selvagem.

OK Evandro, mas ai já saímos da questão da metodologia e entramos na questão de política de empresa. Eu enxergo no ágil uma forma de ser mais justo tanto com minha empresa quanto com o cliente, porém, não posso garantir que a concorrência, ou mesmo o cliente, sigam essa mesma política. Mas beleza, entendi teu ponto inicial e concordo que essa metodologia agrega sim muito valor (não falando de valor econômico agora) em muito menos tempo e sei que atualmente isso é basicamente uma exigência do mercado.

A dependência das fases é um grande empecilho. Finalizar toda a fase de análise antes de iniciar o sistema e colocá-lo para ser testado é um problema. Como mostrado no curso, muitas vezes ou não sabemos ou sabemos pouco para fecharmos um documento que represente exatamente o que o usuário precisa. Em uma metodologia ágil os feedbacks guiam o produto.