É muito dificil que um cliente tenha certeza sobre i que deseja até que pensem algum tempo com um protótipo, então se usar essa metodologia a opção de voltar atrás implica em custos muito elevados para refazer parte do trabalho;
É muito dificil que um cliente tenha certeza sobre i que deseja até que pensem algum tempo com um protótipo, então se usar essa metodologia a opção de voltar atrás implica em custos muito elevados para refazer parte do trabalho;
Waterfall costuma ser uma "carta na manga" de desenvolvedores de soluções que se preocupam apenas em receber uma demanda, desenvolver e ao fim entregar para o cliente. Isso sem contar com o re-trabalho, citado perfeitamente pela Graziela Cristina, que costuma ser algo previsível por quem adota tal metodologia. O desenvolvimento é demorado, trabalhoso, porém o re-trabalho (e é nesse momento que o Waterfall se torna um pouquinho Ágil, quando o desenvolvedor começa a pedir feedbacks do cliente para evitar um ciclo sem fim de re-trabalhos) demanda muito mais recursos (principalmente do fator humano e tempo) do que o desenvolvimento primário.
Como diriam nossas avós: Preguiçoso acaba por fazer o trabalho duas vezes.
A ideia saber que o Waterfall funciona, porém, pode trazer consequências futuras ao projeto, caso ocorra alguma mudança interna (Mudança ou acréscimo de funcionalidade por parte da parte contratante) ou mudanças externas (Tecnologia nova, não aceitação de mercado por parte do produto), tudo isso fica mais difícil de contornar quando se utiliza desse meio de gestão. Já utilizando ferramentas ágeis, conseguimos fazer com que o produto contorne os problemas com maior facilidade, seja por mudanças internas ou externas, o funcionamento desse tipo de gestão permite essa flexibilidade e garante de certa forma uma autonomia.
O método Waterfall é apenas mais um método dentre os inúmeros que existem para entrega de valor, seja qual área for. No caso do desenvolvimento de software (que tem a característica principal da maleabilidade e a possibilidade reconstrução de valor continuamente, diferente por exemplo de um hardware - equipamento eletrônico fisico ou paredes de uma casa, ou uma ponte, que para reconstrução de valor envolve a destruição do entregável para posterior reconstrução) o uso de waterfall pode levar a processos engessados, morosos e que geram entregáveis desatualizados em relação ao objetivo de valor (que pode ter evoluído durante a execução do processo de análise->concepção->engenharia, qual demanda que o software tenha que ser pensado como um grande elemento monolítico e que tenha que ter cada fase totalmente concluídas antes de prosseguir para a próxima, onde a análise fica muito distante da engenharia em relação a tempo). O modelo waterfall faz sentido para soluções de hardware (placas eletrônicas, casas, pontes, etc) ou de softwares críticos (como por exemplo softwares voltados para o mercado militar) mas para softwares comerciais, seja b2b, b2c ou b2c2b acaba que sendo uma escolha bastante questionável devido ao seu pouco dinamismo e capacidade de adaptação às constantes e rápidas mudanças de necessidade dos usuários.
Trás consequencias futuras, onde não se obtem bons resultados quando o projeto é mais complexo. Com opções mais ageis, temos opções de dar a volta por cima, em curto espaço de tempo.
Eu acho que todos os projetos iniciam com o método Waterfall, pois, o cliente quando solicita um software ou aplicativo ele na maioria das vezes só quer saber do resultado final. Dessa forma começa a se estruturar o projeto através do método Waterfall, principalmente se não temos conhecimento do de todos os processos do negócio do cliente. Durante o desenvolvimento percebemos quantas coisas precisam ser adicionadas e que não foram previstas no Waterfall.
Pensando no exemplo citado pelo professor, sobre a Eng.civil, é notável como o Waterfall nela se aplica perfeitamente e compreendendo a engenharia de software é notável que alguns momentos esta metodologia é aplicada, ainda que para o cliente não seja algo que poderíamos definir como viável, pois este acabaria ficando preso a um "acordo" pré estabelecido, suponhamos que o cliente no inicio do projeto solicitou que seu software tivesse um leitor e gerador de código de barras, porém, com o avançar da tecnologia e demanda do mercado, este mesmo cliente solicita a alteração para leitor e gerador de QrCode, seria muito difícil seguir esta alteração ao longo do projeto. portanto penso que o Waterfall é mais um atraso que um ganho.
o Mundo e a tecnologia, e a necessidade dos clientes estão em constante evolução tudo muda e se atualiza muito rapido então um projeto padronizado e linear, etapa por etapa, não se enquadra mais nesse contexto.
o Mundo e a tecnologia, e a necessidade dos clientes estão em constante evolução tudo muda e se atualiza muito rapido então um projeto padronizado e linear, etapa por etapa, não se enquadra mais nesse contexto.
o Mundo e a tecnologia, e a necessidade dos clientes estão em constante evolução tudo muda e se atualiza muito rapido então um projeto padronizado e linear, etapa por etapa, não se enquadra mais nesse contexto.
o Mundo e a tecnologia, e a necessidade dos clientes estão em constante evolução tudo muda e se atualiza muito rapido então um projeto padronizado e linear, etapa por etapa, não se enquadra mais nesse contexto.
Tenho uma visão mais de cliente. A forma "waterfall" de projeto pode parecer boa, a princípio, mas como o exemplo citado, tudo muda e o objetivo é atender a necessidade do cliente. Onde trabalho, por exemplo, teve uma troca de CRM, o CRM novo veio bem cru e conforme estamos utilizando, verificamos pontos de melhoria para nossa necessidade de atendimento, estendendo assim os custos e tempo de projeto, horas e horas de trabalho a mais porque o que se pediu a princípio não atende mais o que é necessário, novos projetos de formas de pagamento, outros meios de atendimento, outras plataformas a integrar ao CRM, plataformas antigas que são projetos já fechados, fora a adaptação ao novo CRM com suas funcionalidades particulares, etc. Pela alta mutabilidade da necessidade do cliente, um projeto waterfall me parece 'ultrapassado' para as necessidades do mercado em si.
O método waterfall tem aspectos que mostram-se necessário no início do projeto sim, eu imagino. Segui-lo à risca ao longo do desenvolvimento é que parece ser um grande risco. Deduzo que quanto maior for o tempo de desenvolvimento do projeto, maior o risco de se manter preso ao modelo de cascata. Com a dinâmica atual dos negócios, tanto em relação à regulamentações quanto às demandas do próprio mercado, o método waterfall pode impedir a entrega do valor concebido inicialmente, tendo o potencial de gerar frustração do negócio.
O ponto chave para se iniciar um projeto é a metodologia de gerenciamento utilizada. Saber escolher a que melhor se encaixa pode reduzir "N" fatores de riscos. P.s.: Só de pensar em todos os testes de uma vez só minha cabeça até dói. kkkkk
metodologia Waterfall, palavra em inglês que significa cascata, é considerada a forma mais tradicional de gerenciar projetos. Assim como os fluxos de trabalho de construção e fabricação, essa metodologia é um processo sequencial. A abordagem Waterfall foi a principal e mais utilizada metodologia de desenvolvimento de software desde que foi introduzida nos anos 70. Naquela época, os gerentes de projeto usavam o Waterfall como uma maneira de trazer uma estrutura mais organizada para o desenvolvimento de software.
O Método Waterfall para o desenvolvimento de Software não é interessante pois precisamos sempre implementar, melhorar e atualizar o software de acordo com a demanda. O cliente inicialmente pode até não querer uma mudança ou uma melhoria mais inicialmente mais não há como escapar pois as tecnologias avançam e evolui muito rapidamente e ultimamente estamos avançando muito mais rápido.
O modelo waterfall traz um certo " engessamento" do software, pois como é muito difícil alterar módulos já prontos, trás um certo problema caso o cliente mude de ideia. As alterações podem trazer muitas dificuldades em todo o processo. Pode ser interessante para software gratuito, onde pequenas empresas que estão iniciando no mercado possam utilizar desde o início, para que tenham seus dados em um sistema ao invés de utilizar planilhas. Interessante também para quem desenvolve, pois pode ser utilizado como protótipo para um outro sistema pago e mais robusto, tendo assim um feedback maior de vários usuários e até mesmo idéias de novas implementações.
Utilizar o modelo waterfall onde os elementos sequências do projeto já estão estabelecido e não podem ser alterados pode gerar um certo problema em projetos relacionados a TI, imprevistos podem aparecer durante a realização do projeto, o cliente pode mudar de ideia, podem surgir novas ferramentas e até mesmo forças maiores que não podem ser controladas que afetam diretamente o modelo de execução do projeto (vide a pandemia). Trabalhar com modelos mais flexíveis em TI demanda um constante mind set de melhoria e agilidade para que os impedimentos do projeto sejam limpos e a motivação do time de execução também não caia.
Utilizar o modelo waterfall onde os elementos sequências do projeto já estão estabelecido e não podem ser alterados pode gerar um certo problema em projetos relacionados a TI, imprevistos podem aparecer durante a realização do projeto, o cliente pode mudar de ideia, podem surgir novas ferramentas e até mesmo forças maiores que não podem ser controladas que afetam diretamente o modelo de execução do projeto (vide a pandemia). Trabalhar com modelos mais flexíveis em TI demanda um constante mind set de melhoria e agilidade para que os impedimentos do projeto sejam limpos e a motivação do time de execução também não caia.
Os empecilhos do modelo Waterfall para o desenvolvimento de software, bem como para as ditas "engenharias tradicionais", estão relacionados diretamente com à necessidade de velocidade na adaptação ao mercado e resposta às demandas do cliente, que são reflexo de uma realidade cada vez mais diversa e dinâmica.
Em um segmento que tem inovação e disruptura como características basais não há espaço para essa rigidez.
Falando sobre a necessidade de adaptação, e aproveitando o exemplo citado no vídeo, podemos ter como exemplo a tendência atual da construção civil que, de adoção de plantas flexíveis, para atender à demandas específicas do clientes enquanto se mantem dentro dos padrões burocráticos.
Isso está em total consonância com o que foi apontado no podcast inicial sobre como aderir ao modelo de negócio ágil: olhar pra dentro, ver travas, admitir travas, criar soluções próprias pra destravar. Que é também a maneira para o desenvolvimento de software tradicional evoluir.
O modelo Waterfall pode até ser usado como desenho de fluxo de desenvolvimento, contudo se usado com rigidez torna um software obsoleto rapidamente.
Os empecilhos do modelo Waterfall para o desenvolvimento de software, bem como para as ditas "engenharias tradicionais", estão relacionados diretamente com à necessidade de velocidade na adaptação ao mercado e resposta às demandas do cliente, que são reflexo de uma realidade cada vez mais diversa e dinâmica.
Em um segmento que tem inovação e disruptura como características basais não há espaço para essa rigidez.
Falando sobre a necessidade de adaptação, e aproveitando o exemplo citado no vídeo, podemos ter como exemplo a tendência atual da construção civil que, de adoção de plantas flexíveis, para atender à demandas específicas do clientes enquanto se mantem dentro dos padrões burocráticos.
Isso está em total consonância com o que foi apontado no podcast inicial sobre como aderir ao modelo de negócio ágil: olhar pra dentro, ver travas, admitir travas, criar soluções próprias pra destravar. Que é também a maneira para o desenvolvimento de software tradicional evoluir.
O modelo Waterfall pode até ser usado como desenho de fluxo de desenvolvimento, contudo se usado com rigidez torna um software obsoleto rapidamente.
O método Waterfall é bem enrigecido e não suporta mudanças no decorrer do projeto. Uma vez que o plano seja assinado pelo cliente, para que haja alguma alteração, é preciso que todas as fases sejam refeitas. Em contrapartida, a engenharia de software é repleta de mudanças, quase que diariamente. Seja por mudanças no entendimento e pedido do cliente, seja por normas e leis externas ou por lançamentos de ferramentas mais modernas no mercado, o ponto é que um modelo em que o cliente não possa alterar de maneira rápida, não é bom para esse tipo de trabalho.
Apesar dos benefícios a metodologia Waterfall impõe grande rigidez à execução do projeto. Quando uma etapa foi inteiramente concluída, a opção de voltar atrás e refazer parte do trabalho implica em custos elevados. O teste é feito muito tarde no ciclo de vida do projeto, o que significa que provavelmente será tarde para fazer alterações.
Na engenharia os métodos de gestão de projetos passam sim por algumas validações e adaptações. Há por exemplo, a aprovação do desenho de alguma peça, a alteração de determinado ângulo ou característica geométrica. Porém essas validações ocorrem em etapas iniciais, uma vez o desenho aprovado, o desenvolvimento ocorrerá até que a fabricação aconteça ,e só no fim na fase de validação e teste novas alterações são discutidas caso o projeto não tenha atendido completamente a necessidade. Isso certamente não iria contemplar a maleabilidade necessária para a eng. software.
Bem, o waterfall é considerada a forma mais tradicional de gerenciar projetos. Assim como os fluxos de trabalho de construção e fabricação, essa metodologia é um processo sequencial. Uma de suas principais vantagens é que, para que o planejamento seja realizado, é necessário avaliar e estruturar as etapas com antecedência e prever cenários variados, por isso o cliente sabe o que esperar. Eles terão uma ideia do tamanho, custo e cronograma para o projeto e saberão qual será o resultado do seu projeto. Porém os clientes e outras partes interessadas normalmente não têm certeza sobre o que desejam até que passem algum tempo com um protótipo e isso é uma das principais desvantagens dessa método pois apesar dos benefícios, a metodologia waterfall impõe grande rigidez à execução do projeto pois quando uma etapa foi concluída, a opção de voltar atrás e refazer parte do trabalho implica em altos custos e o teste acaba sendo feito muito tarde no ciclo de vida do projeto, o que significa que provavelmente será tarde para fazer alterações e além disso é bastante arriscado realizar todos os testes extensivos uma vez que o projeto está quase pronto, devido à pressa, especialmente quando se trabalha com prazos apertados.
Bem, o waterfall é considerada a forma mais tradicional de gerenciar projetos. Assim como os fluxos de trabalho de construção e fabricação, essa metodologia é um processo sequencial. Uma de suas principais vantagens é que, para que o planejamento seja realizado, é necessário avaliar e estruturar as etapas com antecedência e prever cenários variados, por isso o cliente sabe o que esperar. Eles terão uma ideia do tamanho, custo e cronograma para o projeto e saberão qual será o resultado do seu projeto. Porém os clientes e outras partes interessadas normalmente não têm certeza sobre o que desejam até que passem algum tempo com um protótipo e isso é uma das principais desvantagens dessa método pois apesar dos benefícios, a metodologia waterfall impõe grande rigidez à execução do projeto pois quando uma etapa foi concluída, a opção de voltar atrás e refazer parte do trabalho implica em altos custos e o teste acaba sendo feito muito tarde no ciclo de vida do projeto, o que significa que provavelmente será tarde para fazer alterações e além disso é bastante arriscado realizar todos os testes extensivos uma vez que o projeto está quase pronto, devido à pressa, especialmente quando se trabalha com prazos apertados.
O metodo waterfall trás benefícios para algumas áreas, mas para a área de desenvolvimento ele não é viável. Porque no projeto de desenvolvimento de software sempre tem mudança no caminho, as vezes o cliente pensa em algum no inicio mas conforme o desenvolvimento vai acontecendo ele acaba mudando de ideia. E no método de cascata essas mudanças demora muito para acontecer, muitas vezes após o projeto executado dificilmente poderá ser alterado.
O método waterfall é um método sem dúvida muito interessante, não é a toa que é e foi um dos métodos mais utilizados pelas empresas, contudo possui suas limitações, como a dificuldade em alterar o percurso no meio do caminho. Utilizar este tipo de método, principalmente na eng. de software, é algo bastante inviável devido ao dinamismo que a área exige.
Como o desenvolver do software necessita de analises, implementações e retornos para ajustes, este processo de fabricação Waterfall não encaixa bem.
Acredito que os 03 principais empecilhos que o Método Waterfall pode apresentar em um projeto são, em primeiro lugar, a demora em poder alterar o projeto, o que faz com que ele possa vir a ficar defasado frente à concorrência; a demora em receber um feedback, o que pode gerar muita frustração de ambas as partes. Como é um modelo que as etapas só avançam quando a anterior já está completa, essas demoras são muito maiores do que os prazos do modelo Agile.
O principal empecilho do Waterfall é a lentidão na entrega final do projeto, uma vez que surgem necessidades de alteração durante o desenvolvimento do mesmo causando muito retrabalho.
O principal empecilho do Waterfall é a lentidão na entrega final do projeto, uma vez que surgem necessidades de alteração durante o desenvolvimento do mesmo causando muito retrabalho.
Acho que a desvantagem na metodologia waterfall, esta na rigidez de prazos e execução de um projeto, pois a cada etapa concluida, fica quase impossivel em voltar em realizar um novo acerto, demandando tempo, alem de custos.
Acho que a desvantagem na metodologia waterfall, esta na rigidez de prazos e execução de um projeto, pois a cada etapa concluida, fica quase impossivel em voltar em realizar um novo acerto, demandando tempo, alem de custos.
Acho que a desvantagem na metodologia waterfall, esta na rigidez de prazos e execução de um projeto, pois a cada etapa concluida, fica quase impossivel em voltar em realizar um novo acerto, demandando tempo, alem de custos.
O principal impecilho, como citado pelo instrutor, é a demanda modificar por questões externas ao projeto de desenvolvimento, e assim, o cliente ter algum prejuizo no seu negocio e isso refletir no produto final, nesse caso, o software. Assim a importancia para entender o modelo agile, é a sua otimização de recursos humanos e financeiros na entrega de um software.
Entendo que são duas ótimas metodologias, assim como todo método requer uma análise. Por exemplo, em uma construção de um software até mesmo a melhoria dele tal metodologia não seja a melhor, por mais que exista os requisitos, tudo pode acontecer como alteração nas regras de negócios, inclusão de novos requisitos, reteste, entre outros. Nesse caso, considerando que a metodologia Waterfall é mais "robusta" e inflexível ocasionaria problemas pois somente após a implementação seria necessário uma mudança diferente da ágil que trabalha-se com "Pequenos Entregáveis" e que são testados, aprovados e assim, seguem para produção, sendo assim, permitindo uma maior flexibilidade e escalabilidade.
Como o professor citou, se acontece uma mudança, como exemplo, de regulamentação, no método Waterfall a mudança não será feita de modo tão dinâmico, o que pode gerar até mesmo custos adicionais ao cliente.
No decorrer do desenvolvimento de um software pode ter várias mudanças de escopo, no modelo cascata é preciso esperar todo o processo terminar para que mudanças sejam feitas, o que acaba gerando mais gastos e perda de tempo.
A minha experiência pessoal foi sempre maior com o desenvolvimento in-company e, neste caso, o desenvolvimento é feito de forma compartilhada entre o pessoal de tecnologia e o pessoal usuário das aplicações, portanto, isso tende a superar a problemática que seria gerada por um Modelo Waterfall tradicional. No entanto, no caso dos modelos mais recentes, é preciso considerar que, muitas vezes, a área de tecnologia está em outro CNPJ, prestando serviços, sob contrato, com o cliente e mudanças de direção, sejam por que causa forem, vão gerar aditivos de contrato, no mínimo. E, com certeza, antes do aditivo virá um desacordo em função da mudança de especificações do serviço a ser realizado ou a se entregue, dado que, muitas vezes, o serviço está quase inteiramente realizado quando precisa ser modificado. Nesse sentido o modelo Waterfall é disfuncional, no entanto, no caso de minha experiência pessoal ele, de fato, nunca foi algo radical e, ao contrário, sempre teve uma boa parcela de flexibilidade para absorver essas situações, que não são incomuns, de mudanças de percurso durante o desenvolvimento.
Penso que o Waterfall tende a engessar a otimização do produto (software) pela rigidez do escopo. Ao aprovar o projeto, o cliente pressupõe antecipadamente o que quer, sem necessariamente ter visão clara do que precisa.